[Pharo-project] Writing a conditions for breakpoint
suppose, you have a method, say foo: bar baz: zork and want to set a conditional breakpoint for it.. a most easy way to provide a condition is to ask user for providing a block like: [:receiver :arguments :context | " .... return true to break " ] but more convenient would be to ask user to write a condition as a method: foo: bar baz: zork "put your condition code here" ^ bar == 0 "break if bar is zero" then user naturally would access interesting things w/o need to deal with block-like constructs, where arguments is accessible but in inconvenient manner i.e. type 'bar' instead of 'arguments at: 1' This is very good, except one thing, which i worry about: what if i want to write a condition which needs to test a specific context state. I can freely pass a context in a block, but can't pass it in method , because 'condition' method selector should be same as selector where breakpoint will be installed to. What you think would be better? Or maybe i should let users decide , what is best for them? So, they can write conditions using both forms - as a block closure or as method? -- Best regards, Igor Stasenko AKA sig.
Igor: Sorry not beeing able to help you. I am still learning squeak. However, I would really like conditional breakpoints. I found them very useful in Eclipse IDE. Let me know if you could get them working. Cheers, Mariano On Fri, Jan 23, 2009 at 3:57 PM, Igor Stasenko <siguctua@gmail.com> wrote:
suppose, you have a method, say foo: bar baz: zork and want to set a conditional breakpoint for it.. a most easy way to provide a condition is to ask user for providing a block like:
[:receiver :arguments :context | " .... return true to break " ]
but more convenient would be to ask user to write a condition as a method:
foo: bar baz: zork "put your condition code here" ^ bar == 0 "break if bar is zero"
then user naturally would access interesting things w/o need to deal with block-like constructs, where arguments is accessible but in inconvenient manner i.e. type 'bar' instead of 'arguments at: 1'
This is very good, except one thing, which i worry about: what if i want to write a condition which needs to test a specific context state. I can freely pass a context in a block, but can't pass it in method , because 'condition' method selector should be same as selector where breakpoint will be installed to.
What you think would be better? Or maybe i should let users decide , what is best for them? So, they can write conditions using both forms - as a block closure or as method?
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Jan 26, 2009 at 7:17 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Igor: Sorry not beeing able to help you. I am still learning squeak. However, I would really like conditional breakpoints. I found them very useful in Eclipse IDE. Let me know if you could get them working.
What about #haltIf:? That's already useful. -- Damien Cassou http://damiencassou.seasidehosting.st
2009/1/26 Damien Cassou <damien.cassou@gmail.com>:
On Mon, Jan 26, 2009 at 7:17 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Igor: Sorry not beeing able to help you. I am still learning squeak. However, I would really like conditional breakpoints. I found them very useful in Eclipse IDE. Let me know if you could get them working.
What about #haltIf:? That's already useful.
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).
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Regards, Gary. ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/1/27 Gary Chambers <gazzaguru2@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
________________________________
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/1/27 Igor Stasenko <siguctua@gmail.com>:
2009/1/27 Gary Chambers <gazzaguru2@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.
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: Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
________________________________
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, January 27, 2009 12:01 AM Subject: Re: [Pharo-project] Writing a conditions for breakpoint
2009/1/27 Igor Stasenko <siguctua@gmail.com>:
2009/1/27 Gary Chambers <gazzaguru2@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.
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: Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
________________________________
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/1/27 Gary Chambers <gazzaguru2@btinternet.com>:
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, January 27, 2009 12:01 AM Subject: Re: [Pharo-project] Writing a conditions for breakpoint
2009/1/27 Igor Stasenko <siguctua@gmail.com>:
2009/1/27 Gary Chambers <gazzaguru2@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.
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: Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
________________________________
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Damien Cassou -
Gary Chambers -
Igor Stasenko -
Mariano Martinez Peck