Hi Anthony,

> 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)

In this case let me cc you directly ;-)

> 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'.

Okay, I went over the methods and yes, it all looks as if they are used
exclusively for simulation. All but one (very important) place -
Process>>terminate invokes (if not the active process) the full simulation
machinery via popTo: and friends. Can you explain why process termination
has to go to this particular length? It looks as if you've got something
specific in mind here but I don't see why we can't terminate the process
"just the way it used to be" (that is: merely unwind the stack and be done
with it).

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

That is almost (but not quite) correct. You only have to modify the process
"inplace" if you wish to preserve a strict mapping between the "debugged"
and the "real" process state (e.g., so that the process' suspended context
maps exactly to the simulation state). I am not sure if that is either
required or a Good Idea; as a matter of fact I am more leaning towards that
it's not a good idea (considering some of the mechanisms required to debug
something like Croquet's real-time scheduled processes).

One of the changes that I've thought about for the purpose of debugging
processes was to essentially associate a debugger with a process (via
instVar) which - if present - handles attempts to do things with the process
where potentially "incorrect" state (such as suspendedContext) is involved.
The places which come to mind immediately are (for example) #suspend,
#resume, and #terminate but there may be others. In the context of a debug
session, we may indeed forward these requests to the debugger which could
then provide us with the "right" means for handling them.

I think what's really important here is to distinguish between the state a
process is in when it is debugged (simulated) and when it is run by the VM.
Since we can't really simulate the process (as it isn't active) it seems as
if some clear distinction between debugging and running might be rather
helpful. The old (pre 3.6) debugger had that distinction - it might get "out
of sync" at times but for enabling certain kinds of debug facilities that's
exactly what you need.

> 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).

BTW, where exactly does this happen? I have done some pretty weird things
with contexts myself but _that_ method is really beyound me ;-)

> 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).

To the contrary! Discussions like these lay the grounds for people
understanding changes like these, why they were made, what the background is
etc. I think it's important to make them explicit by discussing them and
come up with a common understanding how to do certain things. It is likely
that "just" looking at the simulator would have given me a much harder time
than without this discussion.

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

Will see what can be done here. If you can give me a bit of help regarding
#popTo: it would be greatly appreciated.

> 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.

Yes, certainly so given that I don't even understand what exactly it does
;-)

> 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.

Probably not ;-) I rather like the quickStep facility.

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

Well it would greatly help me if you could answer the above questions. We'll
see how it goes from there.

Cheers,
  - Andreas