Hi all,
I took a closer look at the ActiveProcess concept and I think I found a solution approach to fix all these nasty infinite debugger chains that occurred when any bytecode simulation error occurred. Please see the attached changeset.
The main cognition was the issue that any bytecode simulation error, which is executed behind an #evaluate:onBehalfOf: call, should *not* be debugged on the "behalf-of" process but indeed on the "basic" active process who called #evaluate:onBehalfOf:. Otherwise, the simulating process would not have been stopped by the debugger. See Process >> #step:, for example.
So I added Process >> #basicActiveProcess, which returns the real activeProcess without regard to #effectiveProcess. This method is used by StandardToolSet & debugger in order to identify the process to debug. At other places, #effectiveProcess must be never used as this would take the idea of ActiveProcess ad absurdum and make it impossible to debug certain processing logic.
The changeset also consists of a new test method in DebuggerTests that tests this regression.
So this is a list of recent issues that *won't* crash your image after loading this changeset:
Hi Tim, excellent work!
Coincidentally, I studied the same problem yesterday, but I did not yet complete to report my observations to you. So let me to this hereby:
After many hours of funny debugging, now I could create this minimum failing example:
Processor activeProcessevaluate: [self error. self inform: #foo]onBehalfOf: [] newProcess
Expected behavior: First, a debugger is shown, and after proceeding it, a dialog window is shown.
Actual behavior: Both the debugger and the dialog window are shown asynchronously!
Suspicion of someone who did not yet dive deeply into the activeProcess concept: The debugger resumes the wrong process, as the activeProcess concept simulates a different running process for the error, even against the debugger.
If my theory is correct, we would need to find a way to look behind the scenes of the activeProcess and use it in the debugging code. But first, I really need to learn more about this concept.
(Connection to our Context >> #at: problems: Probably no primitive issue at all, just the fact, that #at: calls itself recursively after the error was proceeded - similar like #doesNotUnderstand: does.)
This is an in-midst-of-work message; just did not want us to any duplicate or redundant work. Will have a closer look at this disgusting problem ASAP!
And vice versa, it would be very nice if you could keep me/us up-to-date!
(Oh, what a fun to debug a self-simulating system ...)
Best,
Christoph