[Pharo-project] something really cool with VW debugger
Hi all if somebody wants to add a really cool feature to the debugger.... in VW we can see as intermediary variable the results of subsets of expression so we we step thru the execution we do not have to select the expression and print it all the time we can simply see the results in the variable. Stef
I also find this really cool. I think the obvious place to add this feature is in Lukas's OB-based debugger. I have no time to do it myself however. On Sat, Jun 14, 2008 at 12:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi all
if somebody wants to add a really cool feature to the debugger.... in VW we can see as intermediary variable the results of subsets of expression so we we step thru the execution we do not have to select the expression and print it all the time we can simply see the results in the variable.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
---------- Forwarded message ---------- From: Lukas Renggli <renggli@gmail.com> Date: Sun, Jun 15, 2008 at 9:54 PM Subject: Re: [Pharo-project] something really cool with VW debugger To: Damien Cassou <damien.cassou@gmail.com>
I also find this really cool. I think the obvious place to add this feature is in Lukas's OB-based debugger. I have no time to do it myself however.
That was for a while in the OB-Debugger. I removed it, because I found it useless and I have the opinion that the stack within a single frame is something that doesn't make sense on the source code level at all. After all this stack is an implementation detail and only exists and makes sense on the bytecode level. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On 6/16/08, Damien Cassou <damien.cassou@gmail.com> wrote:
We are talking about the same thing. However, I still do not understand your answer.
Ok, let me backtrack: 1. In Smalltalk you have a stack of context frames, subinstances of ContextPart. The frames are created when sending messages or when activating blocks. 2. Each of these frames has a little (fixed size) stack that is used on the byte-code level to remember intermediate results and to push receiver and arguments of message sends. Stack 1 is what you commonly see in the debugger and what you usually refer to as "the execution stack". You suggested to display stack 2 in the debugger as well. I don't agree that this is useful, because it violates levels of abstraction. Stack 2 is only meaningful on a bytecode level. It cannot be directly manipulated using the Smalltalk code you see in the Debugger. Unless you exactly know how the compiler generates bytecodes for the current source code, it is not obvious what the stack displays or when it grows or shrinks. Smalltalk debuggers work on the source-level (stack 1), whereas bytecodes are on a level below (stack 2). I believe that should not be mixed. It would be cool to have a Smalltak bytecode debugger, that steps through the bytecodes and where it would make perfect sense to display stack 2. However that was not the point of this discussion. Hope this cleared up things. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mon, Jun 16, 2008 at 9:48 AM, Lukas Renggli <renggli@gmail.com> wrote:
On 6/16/08, Damien Cassou <damien.cassou@gmail.com> wrote:
We are talking about the same thing. However, I still do not understand your answer.
Ok, let me backtrack:
1. In Smalltalk you have a stack of context frames, subinstances of ContextPart. The frames are created when sending messages or when activating blocks.
2. Each of these frames has a little (fixed size) stack that is used on the byte-code level to remember intermediate results and to push receiver and arguments of message sends.
Stack 1 is what you commonly see in the debugger and what you usually refer to as "the execution stack". You suggested to display stack 2 in the debugger as well. I don't agree that this is useful, because it violates levels of abstraction.
Stack 2 is only meaningful on a bytecode level. It cannot be directly manipulated using the Smalltalk code you see in the Debugger. Unless you exactly know how the compiler generates bytecodes for the current source code, it is not obvious what the stack displays or when it grows or shrinks. Smalltalk debuggers work on the source-level (stack 1), whereas bytecodes are on a level below (stack 2). I believe that should not be mixed.
It would be cool to have a Smalltak bytecode debugger, that steps through the bytecodes and where it would make perfect sense to display stack 2. However that was not the point of this discussion.
Hope this cleared up things.
This is much clearer but I have to disagree. I didn't know these details but I was still able to understand and use this pane. It contained valuable information to me in a lot of cases. Moreover, it is sometimes the only way to get the information you want when the statements have border effect (as it was the case when I developed the Nile Stream library). -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Jun 16, 2008, at 9:48 AM, Lukas Renggli wrote:
On 6/16/08, Damien Cassou <damien.cassou@gmail.com> wrote:
We are talking about the same thing. However, I still do not understand your answer.
Ok, let me backtrack:
1. In Smalltalk you have a stack of context frames, subinstances of ContextPart. The frames are created when sending messages or when activating blocks.
2. Each of these frames has a little (fixed size) stack that is used on the byte-code level to remember intermediate results and to push receiver and arguments of message sends.
Stack 1 is what you commonly see in the debugger and what you usually refer to as "the execution stack". You suggested to display stack 2 in the debugger as well. I don't agree that this is useful, because it violates levels of abstraction.
I do not want to discuss that on the theorical level. I found that really efficient to use that to debug with VW.
Stack 2 is only meaningful on a bytecode level. It cannot be directly manipulated using the Smalltalk code you see in the Debugger. Unless you exactly know how the compiler generates bytecodes for the current source code, it is not obvious what the stack displays or when it grows or shrinks. Smalltalk debuggers work on the source-level (stack 1), whereas bytecodes are on a level below (stack 2). I believe that should not be mixed.
It would be cool to have a Smalltak bytecode debugger, that steps through the bytecodes and where it would make perfect sense to display stack 2. However that was not the point of this discussion.
I do not know about stack 2 and stakc 1 and personnally I do not care. This is not my point. What I mentioned was a USER experience: I saw that in VW I can see the result of executed expression within the debugger without having to click+ select + printit and this was really cool because as soon as I got it I went really fast debugging repetitive methods.
Hope this cleared up things.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is much clearer but I have to disagree. I didn't know these details but I was still able to understand and use this pane. It contained valuable information to me in a lot of cases. Moreover, it is sometimes the only way to get the information you want when the statements have border effect (as it was the case when I developed the Nile Stream library
I understand what you are saying and I would certainly agree if I can see that. Because I do not care about the detail, I care about the user experience. If the user experience is cool than this is a step in the right direction. Stef
participants (3)
-
Damien Cassou -
Lukas Renggli -
Stéphane Ducasse