The simulation guard was introduced to avoid crashing the VM when attempt to simulate certain behavior. If such behavior no longer causes crashes, it's fine to remove them (be sure to actually step through it to see if there's a problem or not).

Cheers, - Andreas

On 9/7/2010 10:23 AM, Eliot Miranda wrote:

Hi All,

 the simulation guard in BlockClosure/BlockContext>>newProcess

(primitive 19) prevents creating processes during debugging which means, amongst other things, one can't step into displayingProgress: blocks which is /very/ annoying. What's the rationale? My first unconsidered instinct is that it's OK to crate and schedule processes during simulation; one simply shouldn'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?

(SystemNavigation new browseAllSelect: [:m| m primitive = 19])

[BTW, re being able to debug a process when it becomes resumable, it would be good to have the VM's resume primitive do some sanity checking, e.g. failing if the receiver's context doesn'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]

best Eliot