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 < tdupriez@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