Subject: debugger for MOO

From: David Whitten <[email-masked]>
Date: Thu, 28 Jan 1993 01:00:27 -0800

Jonathan Bradshaw writes:
>Anyone miss the old "D"ebug mode on MUCKS? Can this be added to the MOO
>server? Basically, it would show each line of code executed as the result.
>Makes debugging a whole lot easier.

Ted [email-masked] writes:

>I've always found the debug bit on verbs to be enough to let me know
>there's a problem.  By adding a few player:tell statements somewhere I can
>get updates on the program and see where things are going wrong.

>Would a debug mode slow things down significantly?
>Falryx
>Falryx (or some derivative thereof @ wherever)

David Whitten:
When I read this, I thought that this would be a neat idea.
If we could use a different permission bit but kind of like 'r'ead 'x'ecute
'w'rite 'd'ebug. It could be 'D'ebug. or 's'ingle-step.

It is true that the debug mode could be slower to execute, since the server must
check for a particular line whether 'D'ebug mode is running. I think in the
most general case that the server should simply call a user defined debug
handler verb before it executes each command in a 'D' permissioned verb.

This would allow the maximal capability with the minimal changes in the server
code. The server already has to allow for saving context of an executing
process to allow for multiprocessing, so much of the existing code could be
used to allow for single stepping. (IE: it saves everything away, then calls
the debug handling verb with the code that was executing, with return telling
what to do. Probably something simple like the return must be an error type
since we can use E_NONE to say, go back to executing, and the other error
types to say 'stop execution with this error').

With the server calling MOO code to provide the debug handler, it would be 
easier to provide a dbx type debugging environment with single-step,
printing variable's values when given names, etc.

Some provision would have to be made to make the variables available to
the debugging environment, since there is not any (to my knowledge) method
of referring to variables in the scope of a different verb.

Comments appreciated,
David ([email-masked]) US:(619)535-7764 [I don't speak as a company rep.]

PS. I just realized that if we had several different permissions that do 
essentially the same as this, and the server would provide a way of accessing
the line that is about to be executed (so the handler could examine it, and
possibly return a different line to execute instead), we could extend the
MOO language without changing the server.
Therefore, we could get multiple inheritance code without Pavel having to
incorporate it into the MOO server!!

PPS. I suggested several different permissions so we could do things like this
in several orthogonal ways.

PPPS. Of course if the server provided multiple inheritance in this way, it
could be rather slow, since the server would have to compile to byte codes
any lines that were changed by the line modify handler before executing it.
but we would declare it in the header to the verb, so the overhead would
have to be paid only when the extension was used.

---

From: [email-masked] (A VAX's nightmare)
Date: Thu, 28 Jan 1993 15:02:03 -0800

Hmm, I think that what was requested would be adequately served not by a
debugger, but rather, something like setting the UNIX echo or verbose variables
where each verb call or each line of code (possibly long and ugly output) would
be echoed before being executed. To me, this seems the best way to do what
is asked however, I personally think the tracebacks are enough.

-Wayne/Sadric@LambdaMOO