Re: Line number and source file names in stack trace, part 1

From: Michael Hohn <hohn_at_math.utah.edu>
Date: Fri, 24 Dec 1999 13:26:39 -0700 (MST)

   Michael Hohn writes:
>
> The filename/line feature is very handy to have, but I don't
> know if I want to dedicate 2 words per cell for that purpose.
> If, memory consumption doesn't grow when I turn debugging off
> at run time, it'll be very nice...
>
> That was another concern. It may be better (and more flexible) to
> add just a single SCM pointer (1 word) to the obj struct, and use an
> alist when needed.

   Shiro is right, your solution has an important memory penalty. Since
   all objects are built on top of the struct obj, it means that it costs
   everywhere (the overhead is 2 words on a 3 words structure). Another
   approach could be to let the reader enter each cons in a table (tested
   with eq?). I think you can get the same functionality this way. It
   will globally cost probably more than your solution, but will have a
   zero cost when you are not debugging. What do you think?


                   -- Erick

How about this:
o introduce globals *source-info-keep* (a flag, default #f) and
    *source-info-table* (the hash table)
o change the reader to check *source-info-keep* -- a (slight?) speed
    penalty
o change error.stk to incorporate available information in stack dumps

The hash table should pose no significant speed penalty, and by
separating flag and table, debugging information can be kept
selectively.

Any other suggestions/ideas?

Michael
Received on Fri Dec 24 1999 - 21:27:18 CET