Hi Jaromir,

> The other problem I raised in [...]

> is that the really executing process (which really is the genuine process)
> is invisible to the user because it responds true to isTerminated! In order
> to make this process visible I tweaked a bit the isTerminated as you can see
> at the top of the printscreen.


In this discussion, you should always specify whether "responds to" involves a sender within a simulated or genuine "context". ;-) I am still not convinced that this is an actual problem.

Best,
Marcel
Am 15.03.2021 09:35:15 schrieb Jaromir Matas <m at jaromir.net>:

> Hi Jaromir,


> thanks a lot for your answer! Great to hear that you have found some other
> examples that would benefit > from my patch as well. :-)

Hi Christoph,

I've realized there's one disadvantage to your patch. It quite successfully
masks the real issue but every occurrence/application of the patch leaves
one suspended process behind - the one that was left prematurely through the
non-local return - see the enclosed printscreen after two iterations of your
example:



Purple highligted processes are being left behind every occurrence of the
patch application.

The other problem I raised in
http://forum.world.st/Please-try-out-Fixes-for-debugger-invocation-during-code-simulation-tp5127684p5127748.html
is that the really executing process (which really is the genuine process)
is invisible to the user because it responds true to isTerminated! In order
to make this process visible I tweaked a bit the isTerminated as you can see
at the top of the printscreen.

The scary part is after one occurrence of the issue the image may happily
run with the invisible UI forever - or to be precise until another error
occurs and the invisible becomes visible :)

Best,





-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210315/edf71bb6/attachment-0001.html>