Hi all,<br>
<br>
I would be cautious with adding such a feature since it would be likely to overflow you with redundant debuggers when you are stepping "through" some very complex operation. Still, I see your need for such a feature and thank this might be a nice extra feature, maybe as an opt-in or when combined with some clever heuristics.<br>
<br>
On the implementation side, detecting the resumption of a process during simulating is pretty easy. See SimulationSideEffectWarning [1] which prepares the simulator for reacting to these events conveniently from the debugger. Maybe I should revise and merge this one soon. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
[1] <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215469.html">http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215469.html</a><br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-01-22T19:48:24-06:00, asqueaker@gmail.com wrote:<br>
<br>
> > Dear Squeakers,<br>
> ><br>
> > I was just asking myself, why we cannot debug process forking like this:<br>
> ><br>
> > 0. In the Debugger: [ self doSomething ] "--> next send" fork. nextStatement.<br>
> > 1. Press the Through button.<br>
> > 2. The debugger stops at the next step after the send of #fork: [ self<br>
> > doSomething ] fork. "-->" nextStatement.<br>
> > 3. A second full debugger opens on the new (and now suspended)<br>
> > process: [ self "-->" doSomething ] fork. nextStatement.<br>
> <br>
> I would love that!<br>
> <br>
>