--- Begin Message ---
Yeah, it's a bit unfortunate you assumed I wanted to remove the method.
It brought up a not so pleasant discussion.
Everyone makes mistakes. :-)
So if I understand, this method gives the pc that maps to the ast node
the debugger should highlight when a context is selected in the stack
widget? If I'm right, how comes that this method has no senders in the
debugger code? That would mean this feature is also implemented
somewhere else.
Thomas
Le 11/01/2019 à 20:28, Eliot Miranda a écrit :
Hi Thomas,
forgive me, my first response was too terse. Having thought about it in the
shower it becomes clear :-)
On Jan 11, 2019, at 6:49 AM, Thomas Dupriez
wrote:
Hi,
Yes, my question was just of the form: "Hey there's this method in DebugSession.
What is it doing? What's the intention behind it? Does someone know?". There was no
hidden agenda behind it.
@Eliot
After taking another look at this method, there's something I don't understand:
activePC: aContext
^ (self isLatestContext: aContext)
ifTrue: [ interruptedContext pc ]
ifFalse: [ self previousPC: aContext ]
isLatestContext: checks whether its argument is the suspended context (the
context at the top of the stack of the interrupted process). And if that's
true, activePC: returns the pc of **interruptedContext**, not of the suspended
context. These two contexts are different when the debugger opens on an
exception, so this method is potentially returning a pc for another context
than its argument...
Another question I have to improve the comment for this method is: what's the high-level
meaning of this concept of "activePC". You gave the formal definition, but
what's the point of defining this so to speak? What makes this concept interesting enough
to warrant defining it and giving it a name?
There are two “modes” where a pc us mapped to a source range. One is when
stepping a context in the debugger (the context is on top and is actively
executing bytecodes). Here the debugger stops immediately before a send or
assignment or return, so that for sends we can do into or over, or for
assignments or returns check stack top to see what will be assigned or
returned. In this mode we want the pc of the send, assign or return to map to
the source range for the send, or the expression being assigned or returned.
Since this is the “common case”, and since this is the only choice that makes
sense for assignments ta and returns, the bytecode compiler constructs it’s pc
to source range map in terms of the pc of the first byte if the send, assign or
return bytecode.
The second “mode” is when selecting a context below the top context. The pc
for any context below the top context will be the return pc for a send, because
the send has already happened. The compiler could choose to map this pc to the
send, but it would not match what works for the common case. Another choice
would appear be to have two map entries, one for the send and one for the
return pc, both mapping to the source range. But this wouldn’t work because
the result of a send might be assigned or returned and so there is a potential
conflict. I stead the reasonable solution is to select the previous pc for
contexts below the top of context, which will be the pc for the start of the
send bytecode.
HTH
Cheers,
Thomas
On 11/01/2019 13:53, Tudor Girba wrote:
Hi,
@Eliot: Thanks for the clarifying answer.
I believe you might have jumped to conclusion about the intention of the
question. Thomas asked a legitimate question. Without users of a method it is
hard to understand its use. It does not necessarily imply that the intention is
to remove it, but it does show that someone wants to understand.
As far as I know, Thomas actually wants to write a test to cover that usage. I
am sure that you appreciate and encourage that :).
@Thomas: Thanks for this effort!
Cheers,
Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev
wrote:
in a stack of contexts the active pc is different for the top context. For
other than the top context, a context’s pc will be pointing after the send that
created the context above it, so to find the pc of the send one finds the
previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or
exception. When interrupted, a process is stopped at the next suspension point
(method entry or backward branch) and the top context in the process is the
context to be displayed in the debugger. When an exception occurs the
exception search machinery will find the signaling context, the context that
raised the exception, which will be below the search machinery and the debugger
invocation above that. The active pc of the signaling context will be the of
for the send of digbsl et al.
So the distinction is important an
