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)