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. 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 <eliot.mira...@gmail.com> wrote: >>> >>> Hi Thomas, >>> >>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev >>>> <pharo-dev@lists.pharo.org> wrote: >>>> >>>> <mime-attachment> >>> 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 and the utility method is probably useful. >>> >>> Do you want to remove the method simply because there are no senders in the >>> image? >>> >>> If so, this is indicative of a serious problem with the Pharo development >>> process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk >>> try and build a VMMaker.oscog image on Pharo 7, the system is broken, in >>> part because of depreciations and in part because useful methods >>> (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been >>> removed. >>> >>> Just because a method is not in the image does not imply it is not in use. >>> It simply means that it is not in use in the base image. As the system >>> gets modularised this issue will only increase. There are lots of >>> collection methods that exist as a library that are not used in the base >>> image and removing them would clearly damage the library for users. This >>> is the case for lots of so-called system code. There are users out there, >>> like those of us in the vm team, who rely on such system code, and it is >>> extremely unsettling and frustrating to have that system code change all >>> the time. If Pharo is to be a useful platform to the vm team it has to be >>> more stable. >> -- >> www.feenk.com >> >> “The smaller and more pervasive the hardware becomes, the more physical the >> software gets." >> >> >
