[m-dev.] Suggestion: ^C throws an exception

[Fergus Henderson]

On 22-Nov-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> > The term browser has limits on the size of the terms that it displays.
> > So I don't quite understand how you would accidentally print 
> > out a huge
> > term, unless perhaps you had explicitly set those limits very high.
> > Was that the case?
> 
> Come to think of it, what did happen was that I asked for a stack trace
> after the program had got to some very deeply nested call.  It would have
> taken forever for the stack trace to finish printing.

Ah.

For execution traces, we have the `scroll' mdb command,
which causes the debugger to stop and prompt you every N lines of output.
Currently it is not enabled by default, but probably it should be.

However, we don't have anything similar for stack traces.
For stack traces we try to compress the stack trace by doing
simple run-length encoding, i.e. instead of displaying

	  foo
	  bar
	  bar
	  bar

we display

	  foo
	3*bar

But that's all we do.  If you have an indirectly recursive
procedure, the stack trace could be very long indeed.
And we don't prompt the user every N lines of output,
we just print it all out.

Part of the problem is that stack tracing can happen either
as a result of an explicit command in the debugger,
or as a result of an uncaught exception or other fatal error.
In the latter case, prompting the user is difficult,
because the program might not be running interactively.

> Hmm, you're right.  There appear to be two sources of human we would
> like to be able to recover from here:
> 
> (1) the user accidentally continues execution within the debugger rather
> than stepping through code, or some such, and wants to interrupt execution
> and return to the debugger as soon as possible;
> 
> (2) the user accidentally asks the debugger to deliver a ridiculous amount
> of information and wants to halt delivery of output as soon as possible.
> 
> I think your patch addresses (1) but not (2).

Right.  But we already address quite a few sub-cases of (2).
The term browser deals with it by having limits on the size of its output.
Execution tracing deals with it using the `scroll' command
(which we ought to make enabled by default).
Printing of stack traces remains problematic.
The output from the "help" command is another instance where
scroll control would be useful; currently it generates output
which may in some cases scroll off the screen, and depending on
your environment, it may be difficult to recover that output.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------