proposed command set for the internal trace based debugger

[Tyson Richard DOWD]

Peter Schachte <pets at students.cs.mu.oz.au> writes:

>Hi Mireille,

>On Thu, 4 Jun 1998, Mireille Ducasse wrote:

> > >> One other command that would be useful (if it's implementable) would
> > >> be to replace the goal at the current port with one the user types in.
> > 
> > I do not like thi too much as in the end the program that you are
> > tracing is not at all the program source that you have in the file.

>This seems to be the universal response.  I don't understand why.

>I know when I'm debugging C code I sometimes modify variable values and
>continue when I discover that the code didn't do the right thing, it's a
>trivial fix, it took me a long time to get to this point, and I know or
>suspect this isn't the bug I was looking for.  It's just a time saver, as it
>lets you find multiple bugs in a single debugging session.

>As I recall, the InterLisp debugger I used to use (15 years ago!) allowed
>you to substitute a value to return from a suspended call.  I found it very
>useful.  That debugger would suspend calls to non-existent functions, and I
>often found it handy to run code that wasn't fully written, and "manually"
>supply return values for unwritten functions.

>If the Mercury group doesn't want to implement this sort of feature because
>it's difficult, I understand that.  But I don't understand why anyone would
>want not to have such a facility.

I have never found it useful in C debugging, because it expands the
number of suspect bug sources (your code + your changes to variables),
and makes it more difficult to debug.

I find an interpreter useful (try running parts of the program, e.g. a
particular function, with particular inputs) because that is an
independent test.  But I find that changing values or code in a running
programs leads to confusion on my part as to what depends upon what.

What we really need is a separate wish list, so we can sort the
necessary from the merely desirable ;-)