Hi All,<div><br></div><div>    the simulation guard in BlockClosure/BlockContext&gt;&gt;newProcess (primitive 19) prevents creating processes during debugging which means, amongst other things, one can&#39;t step into displayingProgress: blocks which is /very/ annoying.  What&#39;s the rationale?  My first unconsidered instinct is that it&#39;s OK to crate and schedule processes during simulation; one simply shouldn&#39;t expect them to be debugged.  Alternatively one could offer to open a debugger on the new process (perhaps wrap it in some object such that when it receives resume the debugger is spawned?), create the process or fail in doPrimitive:method:receiver:args:.  What do those in the know, know and think?</div>
<div><br></div><div>(SystemNavigation new browseAllSelect: [:m| m primitive = 19])</div><div><br></div><div>[BTW, re being able to debug a process when it becomes resumable, it would be good to have the VM&#39;s resume primitive do some sanity checking, e.g. failing if the receiver&#39;s context doesn&#39;t smell right, or if myList is not nil, which would allow using myList to tag a process created during debugging.  The Cog VM fails the resume primitive if suspendedContext is not a context]</div>
<div><br></div><div>best</div><div>Eliot</div>