2009/1/27 Igor Stasenko <[email protected]>: > 2009/1/27 Gary Chambers <[email protected]>: >> 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. >
Even more, i think going so deep (enable breaks in method's body) its not worth efforts - in the end, user can always choose to write 'self halt' at any place he may need to. Without any extra efforts from our side :) >> Regards, Gary. >> >> ----- Original Message ----- >> From: Mariano Martinez Peck >> To: [email protected] >> 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 >>> > [email protected] >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ________________________________ >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
