[squeak-dev] SimulationSideEffectWarning (was: The Trunk: Kernel-nice.1386.mcz)

Christoph Thiede christoph.thiede at student.hpi.uni-potsdam.de
Sun May 2 17:30:30 UTC 2021


Hi all,

I just wanted to pick up this item from my list again and add a
SimulationSideEffectWarning (I think this is a better name than my former
proposal, EscapeFromSimulationWarning) to
#doPrimitive:method:receiver:args:.

As discussed below, it should allow pedantic clients of the simulator to
avoid situations in which the code to be executed escapes from the control
of the simulator, e.g. when it uses #fork. On the other hand, unaware
clients such as the debugger should not be disturbed by unimportant
warnings. However, critical attempts should still be reported, i.e. when a
debugger reaches a simulation guard (primitive 19).

However, I'm not yet sure in which exact situations the warning should be
caught/suppressed and in which not. Here is a list of possible situations:

- Use the stepping buttons in a debugger: SUPPRESS (except simulation guard)
- Return entered value in a debugger: SUPPRESS (except simulation guard)
- Terminate a process: SUPPRESS
- Context class >> #trace.../#tally...: NOTIFY
- MessageTally: NOTIFY
- Context class >> #runSimulated:: NOTIFY
- Morphic "debug action" (of a button, menu item, etc.): SUPPRESS
- Debug it: SUPPRESS (what about simulation guards?)
- (external project) SimulationStudio/Sandbox: NOTIFY (!)

Based on this collection, I considered adding a handler in the public
Process selectors for debugging (protocols: *System-debugging and 'changing
suspended state'). This would also emphasize the different roles of Context
and Process in the debugging machinery (Process also holds the
responsibility for process-faithful debugging).

Still, there is one edge case that would violate this rule: Imagine a
subclass of Debugger that would be side-effect aware, i.e. care about
EscapeFromSimulationWarnings. Since the debugger only talks to the Process,
it would not be able to handle these warnings following my proposal from
above. This is not only a fictive experiment but I'm indeed considering a
SandboxDebugger at the moment which would actually need this. For this
concrete case, of course, I could hack my exception handler into my Context
subclass, too, but the existence of this example makes we wonder whether my
proposal from above is actually useful.

What is your opinion on this matter? Would you agree to my list of aware and
non-aware simulation clients? When do you think we should suppress
EscapeFromSimulationWarnings and when not?

Best,
Christoph



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list