Hi Marcus,
On Fri, Jan 18, 2019 at 5:15 AM Marcus Denker via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:
>
> > On 11 Jan 2019, at 20:28, Eliot Miranda wrote:
> >
> > 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 <
> tdupr...@ens-paris-saclay.fr> 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.
> >
>
>
> I checked with Thomas
>
> -> for source mapping, we use the API of the method map. The map does the
> “get the mapping for the instruction before”, it just needs to be told that
> we ask the range for an active context:
>
> #rangeForPC:contextIsActiveContext:
>
> it is called
>
> ^aContext debuggerMap
> rangeForPC: aContext pc
> contextIsActiveContext: (self isLatestContext: aContext) ]
>
> So the logic was move from the debugger to the Map. (I think this is even
> your design?), and thus the logic inside the debugger is not needed
> anymore.
>
"Design" is giving my code a little too much respect. I was desperately
trying to get something to work to be able to deploy Cog with the new
closure model. I happily admit that DebuggerMethodMap in Squeak is ugly
code. It had to be extended recently to handle full blocks. But it would
be great to rewrite it.
I dream of a harmonisation of Squeak/Pharo/Cuis execution classes such that
we have the same Context, CompiledCode, CompiledBlock, CompiledMethod,
debuggerMap and BytecodeEncoder (which is effectively the back end of the
compiler that generates bytecode, and the interface to the debugger when
bytecode is analyses or executed in the debugger), which would make my life
easier maintaining the VM and execution classes, especially as we introduce
Sista. I think Opal as a separate compiler is great; the work you've done
with mustBeBoleanMagic is superb. At the same time the Squeak compiler is
fine for its job and I still find it easier to understand than Opal
(probably because I'm not spending enough time with it).
One major reason for the harmonization is bug fixes. Right now I use
SistaV1 and 64-bits as my default work environment, in a 64-bit Squeak
image that was compiled with V3PlusClosures, so that half the