DEBUG

[Robert W. Kerns <RWK at MIT-MC>]

BUG-LISP seems like a pretty silly place to complain about problems with
a personal package belonging to me.  Or are you implying that you think it
should be standard?

Anyway, in response to complaints from my users:

1)  You can't load much of *ANYTHING* into a PDL-OVERFLOW break without
getting another PDL-OVERFLOW break.  For example, try (rplaca - -) (trace -).
This isn't so bad, it's trying to give you another chance to give up before
you screw yourself totally.  If you type an $P you'll win.

2)  It loaded DEFVSX because I couldn't think of a way to get around a problem
with having a DEFVST in a separate file.  I have now figured out how to get
around the problem.  The only file now loaded which was not before is EXTSTR,
which should not break anyone's environment.  It is certainly trivial compared
to DEBUG, GRINDEF, FORMAT, YESNOP, or QUERY-IO, all of which have been used
for a very very long time (although they did not all get loaded immediately,
which used to cause all sorts of screws by autoloading them at bad times).

If loading DEBUG now still causes you problems, you have two options:
  a)  Pre-load it, before you run out of available BPS.  Usually when you
      can't load it it's because you allocated all your pages early.  You
      can trade GC time for the space.
  b)  Use your own tiny package that can't pretty-print or ask you questions.
      It might be reasonale to flush FORMAT/YESNOP, but it would take some work
      and make DEBUG itself larger and uglier

3)  I'm suprised you didn't mention this problem, since it's related to your
complaint.  If you have a large datastructure (other than cdr-long lists),
since the stack is so small when you're in a PDL-OVERFLOW break, a GC can
be disasterous.  The previous version of the debugger used to cons a lot
as you used it, leading to a greater likelyhood of blowouts (PDLOVERFLOW in
GC, MAJOR RESTART UNDERTAKEN ...) the longer you used it.  The newer one
does all of it's consing initially.  The NEWEST one neatly solves the problem
by a special-case hack:  When it encouters a PDL-OVERFLOW break in its scan of
the stack, it expects that there may be recursive calls, and checks for calls
of identical values.  If it finds any, instead of representing each of these
stack frames, it omits the duplicates, counting how many times each duplicate
is omited.  It handles co-recursive functions, etc..  Things which recurse
infinitely (or very deeply) with differing arguments are not omitted, of course
and any consing at all may be too much.  There just isn't any way around it
completely, but this heuristic should help.  The debugger tells you when
it prints a frame how many of its clones have been omitted.

Anyway, give it a try and see what you think.