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