[Pharo-project] Writing a conditions for breakpoint

Igor Stasenko siguctua at gmail.com
Mon Jan 26 18:57:37 EST 2009


2009/1/27 Gary Chambers <gazzaguru2 at btinternet.com>:
> If I remember rightly the existing breakpoint scheme just recompiled the
> method without source logging. Naturally you could get into a horrible mess
> with the source not matching the bytecodes.
>
> Just a thought. Since that, I believe, was why "breakpoints" were considered
> broken.
>

I'm using different approach by changing the method in method's
dictionary without doing any change in original compiled method.
Then, once your program runs to the point of method invocation - its
intercepted ,and there are a number of choices:
- break into debugger
- continue running as usual
etc.

This is enough for start (you can set a breakpoint on method
entry/exit, but can't place break inside of method's body).
For more advanced, it would require step by step execution of method's
bytecodes (in same way as debugger doing this), then you can pick any
bytecode position to place a break there. This can be possible only in
a good cooperation with debugger - because for placing breakpoint
inside a method body you need to provide a UI to select the place by
showing a user the method source, and then interpreting user's input
to a bytecode position.

I think being able to break at method entry/exit is well enough to
cover about 99% of all cases where you need breakpoints (remember -
this is smalltalk and methods tend to be very short).
The rest 1% you may require only if you want to debug a bytecodes.

> Regards, Gary.
>
> ----- Original Message -----
> From: Mariano Martinez Peck
> To: Pharo-project at lists.gforge.inria.fr
> Sent: Monday, January 26, 2009 9:33 PM
> Subject: Re: [Pharo-project] Writing a conditions for breakpoint
>
>>
>> here, i'm speaking about setting breakpoints using UI i.e. without
>> changing the method.
>> I wrote a simple OB-based breakpoint manager, where you can edit
>> breakpoints list and possibly set a condition to break.
>> Of course, you can always put 'wand isZapped ifTrue: [self halt]'  in
>> any method, but this having one huge drawback:
>> once you modify the method, a change is recorded into .changes, as
>> well as many other parts of the system get notified about such change.
>> But we don't want to mark packages modified, nor unnecessary pollute
>> .changes file only because we need to test some functionality (by
>> putting a breakpoint), right?
>> Because such practice makes harder to manage the source code (you
>> forced to always get back to places where you put the halt to remove
>> it, and this is a bit annoying).
>
>
> +1 100%
>
>>
>> > --
>> > Damien Cassou
>> > http://damiencassou.seasidehosting.st
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > Pharo-project at lists.gforge.inria.fr
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> ________________________________
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list