[m-dev.] proposed command set for the internal trace based debugger

[Peter Schachte]

On Wed, 3 Jun 1998, Fergus Henderson wrote:

> > Peter Schachte wrote:
> > > Wouldn't it be possible to have a debug version of the library that
> > > makes file opening and closing commands "trail" their effects so they
> > > can be redone?  Ideally it would be possible for writers of libraries
> > > containing destructive modes to also write mostly destructive versions and
> > > have the debugger optionally use those instead in a systematic way, so they
> > > could be retried.  Note that when code is being "skipped" over (in Prolog
> > > terminology), you can just use the destructive version, for full speed and
> > > lower memory usage.
> > 
> > In fact we have a better scheme in mind (based on *all* I/O actions
> > generating a log record, and being able to roll the log forward/backward
> > at will)
>
> I think you can combine the advantages of these two approaches.

I don't really see an advantage of the logging scheme over the mostly
destructive scheme.

When doing file-based IO, undoing is usually not too hard.  For reading or
sequential writing, the usual cases, you just need to store the file
position.  For non-sequential writing, you'll have to save what is about to
be written over so you can put it back (or you could always spit out an
error message when the user tried to redo over something like this.  For
file deletion, you could just rename the file instead, and remember to
actually delete it later.  None of this seems terribly hard.  And it has the
advantage of working properly when you later allow dynamic reloading of
modified code, so different actions are performed on subsequent attempts.

As for screen IO, that can't really be undone, but I actually think that's
an advantage.  When you're debugging some code that prints out the wrong
thing, the easy way to do it is to skip over something, and see if the wrong
thing comes out on your screen.  If so, you retry, creep a bit, and
recursively try the same thing; if not, you creep and recursively try the
same thing. If the IO only happens once, you can't see what's happening the
second time.

> > > You seem to have omitted the REDO port.  That one's pretty important.
> > 
> > We did not omit it by oversight. The Mercury execution model does not
> > permit a redo port without requiring the compiler to perform a pessimization.

For the Quintus debugger, we handled this by having the debugger create the
needed choicepoints.  Of course, the Quintus debugger is a one-process
debugger, so this was pretty easy.  Is there any way to have the debugger
trigger a little stub of C code in the debuggee, running more or less as an
interrupt, which would push the appropriate nondet frame to give control
back to the debugger on failure?


-Peter Schachte               | The fantastic advances in the field of
mailto:pets at cs.mu.OZ.AU       | communication constitute a grave danger to
http://www.cs.mu.oz.au/~pets/ | the privacy of the individual.
PGP: finger pets at 128.250.37.3 |     -- Earl Warren