2009/1/27 Gary Chambers <[email protected]>: > > ----- Original Message ----- > From: "Igor Stasenko" <[email protected]> > To: <[email protected]> > Sent: Tuesday, January 27, 2009 12:01 AM > Subject: Re: [Pharo-project] Writing a conditions for breakpoint > > >> 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. > > > Isn't replacing the method dictionary entry the same as replacing the > compiled method? >
nearly the same, except that you don't need to deal with bytecodes and hack method to get what you need. I forgot to add - i'm using a squeak's 'object as method' feature, so it not requires to do hard work with compiler or generating synthetic method with custom bytecodes, which doesn't match the source. > >>> 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 > > > _______________________________________________ > 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
