Hi Terry,

> I don't have a version of Squeak as I am just a lurker.
> However, I think I can help considering I wrote the latest
> version of the VW PDP debugger.

Thanks, it's great to have a third opinion on these issues.

> Andreas's concern about the croquet real-time scheduler
> is an additional wrinkle.  But, from an Squeak perspective
> it would be better if the debugger did not have to
> address special croquet concerns.

I agree but that was essentially the reason why I wanted to be able to
handle most of the debugging activities "outside" of the process being
simulated so that (for example) a CroquetProcess might use a CroquetDebugger
instead of a "normal" one. This is why I said it would be nice to have an
association between the debugged process and its debugger so the process can
simply pass requests on to the debugger "just in case" some special action
needs to happen. In the default case these actions may do nothing so it
would be simple to substitute debuggers for varying needs.

> In vw I would solve
> using a normal exception handler.  When a process is
> terminated in VW, a terminate exception is raised. 

This isn't currently the case in Squeak.

> A croquet process could catch this exception and not allow
> it to continue if the process was being debugged.  The
> handler could optionally extend the deadline or place it
> into a special state so the scheduler.  To make this
> consistent the process would also have to be notified
> when it was resumed by the debugger.  This could be
> done by adding a #resumeByDebugger method to Process
> that raises an exception when resumed by the debugger.
> This would allow the process to properly change its
> deadline.

Right. If you follow down this path (which is certainly doable) you end up
with essentially the same mechanisms that I was describing - just bundled up
in one place (class Process) and using tons of not-too-nice ways of
interactions along context chains (what happens if there is a catch-all
handler somewhere on the stack? Just recently David used one ;) So what I'm
really arguing for here is a better separation of concerns and a
teenie-weenie bit of explicit knowledge within class Process about whether
it may be debugged or not.

Also, note that the situation of process termination is a minor aspect for
Croquet. Termination semantics are well enough defined and the standard
semantics of Squeak processes work just fine for it. It's the actual
debugging activity, all the sends involved where we may have to deal with
the fact that the current process is being debugged and may therefore have
"slightly different" rules.

Cheers,
  - Andreas