Debugger woes

Andreas Raab andreas.raab at gmx.de
Sun Aug 31 17:01:05 UTC 2003


Hi Guys,

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

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.

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

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.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list