----- 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? >> 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
