On Jun 16, 2008, at 9:48 AM, Lukas Renggli 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.
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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
