Hi Andreas (and thanks Doug for forwarding this to me.  For some reason
I did not get this mail although I've been getting other mailing list
posts),

Andreas Raab wrote:
> I'm having some serious trouble with some of the recent changes to 
> debugging Squeak processes. One of the things that we absolutely
> needed in Croquet includes a faithful process debugging ability, e.g.,
> a way to debug expressions like "Processor activeProcess" and friends.
> I've recently hacked up a pretty good first-order approximation for
> this in Croquet and while looking at 3.6 (in order to port this forward)
> I ran into great trouble.
>
> What's the deal? It is essentially that the operations for context
> simulations are intertwined with the "regular" operations on 
> processes.

All the simulation behavior is in the 'changing suspended state'
protocol in Process.  So it is not too intertwinded.  Maybe it would be
better to rename this 'simulation'.

> My little hack was based upon running the context simulation itself from 
> the process we're debugging (by inserting the context simulation into the
> process and simulate from there) which cannot work if the simulation
> modifies the process itself (which it does in 3.6).

You have to modify the process because you are executing it even if its
one step at a time.

> While some arguments
> (in terms of code reuse) can be made for inserting much of the simulation
> facilities into class Process itself it seems to me that we really 
> need a separation between "running" a process and "simulating" its
> execution.

Simulating a process IS running a process.  It is just that Smalltalk
code (in 'changing suspended state') is updating the process and context
state instead of the VM.  Although to speed things up the simulate code
in #complete: hands off execution to the VM until a specified context
completes than the simulation takes over again (old #quickStep).  We
could add a preference here to do it all in simulation (slowly) if
desired.

An implementation issue with the fast #complete is that instead of
resuming the suspended process (the process being debugged) to get the
VM to run it, the UI process (the process executing the suspended
process) swaps suspendedContexts with the suspended process, so it just
continues executing in the VM but really is executing the suspended
processes stack.  This is tricky.  I would like to switch it so it just
resumes the suspended process, while the UI process waits.

> I've long thought that the debugger (model) really ought to be a tool
> which establishes the means for simulating a process "from the outside" 
> rather than being tied to the UI controlling it. Looking at the changes in 
> 3.6 it almost feels as if there is a similar intent in the changes done, 
> except that what I think is a debugger responsility has been moved inside 
> class Process itself (e.g., methods like #completeStep: etc). Naturally, this
> leads to big trouble if any of the assumptions about what is called by the
> debugger and what is called by the regular execution machinery goes 
> wrong.

I agree.  What you call the non-UI debugger, I call the simulator.  In
my VI4 implementation I did have a Simulator.  But when trying to adapt
my changes to the current Squeak I tried not to change too much (my
mistake).  So your right, it would be better to have all the 'changing
suspended state' code in a separate "Simulator" class (and not in
ContextPart because we are manipulating the whole execution stack
(process), not a single context).

> So here's my question: Has anyone ever seen a good model for separating
> the three aspects of a) running a process (e.g., what should be in class
> Process),  b) simulating it (e.g., what should be in a debugger that has
> no UI responsibilities at all), and c) providing the interface to the UI (e.g.,
> what we have today in class Debugger)?

Yes just move the 'changing suspended state' code to a new Simulator
class and have the debugger interact with it.

> I'd be willing to give this a shot since we _really_ need this (I don't
> think we can move Croquet forward to 3.6 without it) and I think it'd 
> be valuable for other applications as well. Any pointers, ideas, thoughts,
> comments are welcome.

Moving the simulation code out into a simulator, is just an organization
(asthetics) issue.  The simulator is there, just in Process 'changing
suspended state'.  So this should not hold you back.  The fast
#complete: is probably the real problem your running into.  It would be
cleaner to to resume the suspended process directly instead of swapping
contexts (see #jump).  Also, you probably want the option to disable the
fast #complete: all together and simulate the entire call.

Let me know if you want to make this change to #complete:.  Or if you
want me too.

Cheers,
Anthony