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?
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 <[email protected]> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev
<[email protected]> 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."
