BTW, you can list the configuration options for debugging with: (debug-options 'all)
and set options with values using debug-set! as in: (debug-set! frames 4) On Sun, Apr 19, 2026 at 8:34 PM Mikael Djurfeldt <[email protected]> wrote: > I'll let other people answer the question regarding what to do, but here's > a bit of Guile history: > > Guile once had reasonably nice backtraces. At some point the whole old > evaluator was replaced as part of the effort to get a compiler and > eventually just-in-time compilation to machine code---which is great! It is > understandable that the developers involved wouldn't complicate the rather > tremendous effort by trying to keep all of the previous, nice, features. > They may have thought that something equivalent could be added later. > > For those historically interested, it seems possible to compile > https://ftp.gnu.org/gnu/guile/guile-1.6.8.tar.gz if one adds the > following two lines to the top of libguile/__scm.h > > #include <stddef.h> > #include <stdlib.h> > > To switch on automatic backtraces when entering the interpreter, do the > following: > > (debug-enable 'backtrace) > > Best regards, > Mikael > > On Tue, Apr 14, 2026 at 10:36 PM Noé Lopez via Developers list for Guile, > the GNU extensibility library <[email protected]> wrote: > >> Hi everyone, >> >> I got myself in a bit of a rabbit hole tonight, I wanted to figure out >> how to have evaluated code give good backtraces. >> >> So I started digging in (ice-9 eval), and I saw no debug information >> coming from `memoize-expression'. >> >> So I started digging in memoize.c, and I saw no debug information, and I >> didn’t understand too much, and gdb was having a hard time with the >> structs. >> >> So I started digging the git log, and I saw this: >> >> Andy Wingo, 2009 b7742c6b7132544b9d6cd9cb32c09e2084ad9e52 >> * libguile/memoize.c: New memoizer, which runs before evaluation, >> checking all syntax before evaluation begins. Significantly, no >> debugging information is left for lexical variables, which is not so >> great for interactive debugging; perhaps we should change this to have >> a var list in the future as per the classic interpreters. But it's >> quite fast, and the resulting code is quite good. Also note that it >> doesn't produce ilocs, memoized code is a smob whose type is in the >> first word of the smob itself. >> >> The same commit mentions that it was made as part of the C-based >> evaluator that was supposed to be only used for bootstrapping, but it >> turns out that our scheme-based evaluator uses the same memoization. >> >> So, what to do? I wasn’t there when it happened, and I’m probably >> missing a lot of historical information. What was the plan? >> >> Should it be that a new memoization is made in scheme to go with the >> scheme evaluator, or that the existing memoization is adapted to keep >> debug information? >> >> Or am I completely off the mark? >> >> Thanks, >> Noé >> >
