Ok, thanks to you two for these nice answers.
I made a pull-request to improve the comment of the DebugSession class
based on your answers.
Thomas
On 01/12/2018 19:02, Eliot Miranda wrote:
Hi Andrei, Hi Thomas,
Andrei, you are right; they are different and the difference is
important. As you say, suspendedContext is the top (“hot”) context in
a process’s context chain, but interruptedContext is the context which
sent the signal message that eventually raised the exception that
invoked the debugger. suspendedContext is therefore where execution
is in the process, but interruptedContext is where the debugger should
show the stack.
Thomas, because the exception system is implemented in Smalltalk the
handling of the initial signal (eg in Object>>#halt), all the way to
opening a debugger, is itself Smalltalk code, and exists as
activations from suspendedContext to interruptedContext. The
debugger, with help from the exception system, carefully hides this
processing from the programmer. If it did not we would have to wade
through many activations before we found where the exception occurred.
When a process is interrupted by control period things are different.
Here, another process handles opening the debugger and indeed
suspendedContext and interruptedContext are the same.
So the difference between suspendedContext and interruptedContext is
vital to the debugger. Without it we would see the inner machinery
of the exception system when errors or exceptions are raised.
HTH
_,,,^..^,,,_ (phone)
On Nov 30, 2018, at 7:42 AM, Andrei Chis <chisvasileand...@gmail.com
<mailto:chisvasileand...@gmail.com>> wrote:
Hi,
From what I remember they are not always redundant, but I'm not 100%
sure they are both needed.
`suspendedContext` from Process is always the top context of a
process. After execution actions like Step Into, Step Over, Step
Through it will be the same as interruptedContext in the debugger.
They will be different when opening the debugger as a result of an
exception.
Exception>>#debug triggers the workflow for opening a debugger. This
uses `self signalerContext` as the context that is being debugged.
This is the context where the exception was raised and this will be
put in the interruptedContext. As this point the execution of the
current process is not over and it will continue up to
`MorphicUIManager>>#debugProcess:context:label:fullView:notification: `
where the current process is suspended. At that point the two will be
different, as suspendedContext will be the context of the method
MorphicUIManager>>#debugProcess:context:label:fullView:notification:
and the interruptedContext the context that triggered the exception.
But it might be that they are not both needed. One possible option
might be to force the process to step to the context that raised the
exception when the debugger is created. For example
in DebugSession>>process:context:.
Apart from when opening the debugger I do not know if there is
another situation where those two can diverge.
Cheers,
Andrei
On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez
<tdupr...@ens-paris-saclay.fr <mailto:tdupr...@ens-paris-saclay.fr>>
wrote:
Hello,
Instances of DebugSession have an "interruptedContext" and an
"interruptedProcess" instance variable.
Instances of Process have a "suspendedContext" instance variable.
Does someone know if there is a relation between the
interruptedContext of a DebugSession and the suspendedContext of
its interruptedProcess? At first glance it seems like these two
variables are redundant and store the same Context.
Thomas Dupriez