[Gcl-devel] Re: error with error

[Camm Maguire]

Greetings!

Robert Boyer <address@hidden> writes:

> > Would you be content with
> >
> > 1. having such info only available when interpreted or compiled with
> >   safety 3.
> > 2. having a more minimal set available when errors are triggered in
> >   the error handler?
> 
> Excellent questions.  The answer to 1 is basically no.
> 
> I don't want anything to interfere with maximum possible execution speed
> when running code compiled at SAFETY=0, and that is how I am almost
> always running, though I strongly recommend SAFETY=3 to beginners and I
> joyfully fall back to SAFETY=3 as a *very* last resort in attacking
> intractable bugs.
> 
> However, on a SAFETY=0 error, I want precisely as much info as can be
> VERY easily obtained about the functions, variables, and bindings that
> led to the error.  Please merely show me what is easily known by walking
> back up the 5 stacks.  I really don't care one iota about the different
> stacks or even about which info is on which stack.
> 
> If something like setting SPACE=0 or DEBUG=3 would give me more
> debugging info but in no way reduce running speed, though perhaps taking
> more space somewhere, I wish I knew about such settings and would be
> happy to employ them to the max.
> 
> Bob
> 

Would it then be acceptable to have essentially no information at
safety 0 by default, but full information if the offending command is
rerun using the same compiled code with (si::use-fast-links nil) set
at runtime?

If not, I think we have a direct conflict.  Collecting any debugging
information at all necessarily slows down function calling.  Even in
C, one does much better by losing -g in favor -f -fomit-frame-pointer.

If this is acceptable, then we should have with runtime fast-links off
a full call stack with call arguments and special bindings available
in the debugger.  We will not have block information (i.e. catch) or
let binding information unless running interpreted or compiled at
safety 3.  I.e. the safety 0 no-fast-link debugging option is
essentially interpreted only at function call boundaries and makes
such information alone visible to the debugger. Is this OK?

An alternate idea, now that we have the source available is to throw
back 5 levels up the stack and rerun the interpreted source with the
same arguments on error, or at least provide a debugger command to
easily do so.

Take care,

> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah