Hi guys. Funny thing that DebugSession does not exists in Squeak. It was introduced in Pharo to represent the model for debugger.
пт, 11 янв. 2019 г. в 22:34, Thomas Dupriez via Pharo-dev < pharo-dev@lists.pharo.org>: > 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 < > 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." > >>> > >>> > >
