Greetings! Robert Boyer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
