On Mon, Jun 16, 2008 at 9:48 AM, Lukas Renggli <[EMAIL PROTECTED]> wrote: > On 6/16/08, Damien Cassou <[EMAIL PROTECTED]> 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) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
