On Monday 17 November 2003 11:43 am, Marcus Denker wrote:
> Am 17.11.2003 um 19:49 schrieb ducasse:
> >>> I would love to have breakpoints in but I do not know the extra  
> >>> complexity
> >>
> >> I have looked into this a bit.
> >>
> >> Terry Raymond's (Crafted Smalltalk) excellent
> >
> > Ye I use it and this is great!
> >
> > My point was more what this cs in squeak implies.
>
> Just had a look at it: It's quite simple... maybe even too simple.
> The way it works is that a new method is compiled with "self break"
> in the first line.
>
> It does: compile the method to get the AST. Then add a "self break"
> statement as the first statement, return the source, compile a method,
> install in methodDict, remember original.
>
> Browser is changed to have a "toggle breakpoint", methods with
> breakpoint are shown bold in the browser.
>
> Problem: the browser shows the code of the newly compiled
> methods, that is: pretty-printed, no comments "self break" in
> the first line. You can even accept the method...
>
> So pretty simple, we can do better I think. But maybe we could
> add this as a first step. Dont know...

You know there's also my "run to here" change set somewhere.

The tricky part is probably going to be making the original source look right 
in the debugger: if you have a modified method, you'd want to show the 
original method in the debugger.

Perhaps using a MethodWrapper that holds both the old method and the desired 
breakpoint(s) (condition and PC) would work: the wrapper would just simulate 
the method until its end or a breakpoint was reached.

If you don't care about how it looks, then it would make sense to just edit 
the code of the method -- convert to AST, insert probes, compile resultant 
source. Save the old method of course, and don't log the changes.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE