Re: Towards source information in evaluated code

--000000000000dcd2ca064fd4b329
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Mikael Djurfeldt <mikael@djurfeldt.=
com>
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 rathe=
r
> 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=E2=80=AFPM No=C3=A9 Lopez via Developers li=
st 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=E2=80=99t 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=E2=80=99t there when it happened, and I=E2=80=99m=
 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=C3=A9
>>
>

--000000000000dcd2ca064fd4b329
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>BTW, you can list the configuration options for debug=
ging with:</div><div><br></div><div>(debug-options &#39;all)</div><div><br>=
</div><div>and set options with values using debug-set!=C2=A0as in:</div><d=
iv><br></div><div>(debug-set! frames 4)</div></div><br><div class=3D"gmail_=
quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, =
Apr 19, 2026 at 8:34=E2=80=AFPM Mikael Djurfeldt &lt;<a href=3D"mailto:mika=
[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I&#39;ll let ot=
her people answer the question regarding what to do, but here&#39;s a bit o=
f Guile history:</div><div><br></div><div>Guile once had reasonably nice ba=
cktraces. 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 machin=
e code---which is great! It is understandable that the developers involved =
wouldn&#39;t complicate the rather tremendous effort by trying to keep all =
of the previous, nice, features. They may have thought that something equiv=
alent could be added later.</div><div><br></div><div>For those historically=
 interested, it seems possible to compile=C2=A0<a href=3D"https://ftp.gnu.o=
rg/gnu/guile/guile-1.6.8.tar.gz" target=3D"_blank">https://ftp.gnu.org/gnu/=
guile/guile-1.6.8.tar.gz</a> if one adds the following two lines to the top=
 of libguile/__scm.h</div><div><br></div><div>#include &lt;stddef.h&gt;<br>=
#include &lt;stdlib.h&gt;<br></div><div><br></div><div>To switch on automat=
ic backtraces when entering the interpreter, do the following:</div><div><b=
r></div><div>(debug-enable &#39;backtrace)</div><div><br></div><div>Best re=
gards,</div><div>Mikael</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Apr 14, 2026 at 10:36=E2=80=AFPM No=
=C3=A9 Lopez via Developers list for Guile, the GNU extensibility library &=
lt;<a href=3D"mailto:[email protected]" target=3D"_blank">guile-devel@gnu=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">Hi everyone,<br>
<br>
I got myself in a bit of a rabbit hole tonight, I wanted to figure out<br>
how to have evaluated code give good backtraces.<br>
<br>
So I started digging in (ice-9 eval), and I saw no debug information<br>
coming from `memoize-expression&#39;.<br>
<br>
So I started digging in memoize.c, and I saw no debug information, and I<br=
>
didn=E2=80=99t understand too much, and gdb was having a hard time with the=
<br>
structs.<br>
<br>
So I started digging the git log, and I saw this:<br>
<br>
Andy Wingo, 2009 b7742c6b7132544b9d6cd9cb32c09e2084ad9e52<br>
* libguile/memoize.c: New memoizer, which runs before evaluation,<br>
=C2=A0 checking all syntax before evaluation begins. Significantly, no<br>
=C2=A0 debugging information is left for lexical variables, which is not so=
<br>
=C2=A0 great for interactive debugging; perhaps we should change this to ha=
ve<br>
=C2=A0 a var list in the future as per the classic interpreters. But it&#39=
;s<br>
=C2=A0 quite fast, and the resulting code is quite good. Also note that it<=
br>
=C2=A0 doesn&#39;t produce ilocs, memoized code is a smob whose type is in =
the<br>
=C2=A0 first word of the smob itself.<br>
<br>
The same commit mentions that it was made as part of the C-based<br>
evaluator that was supposed to be only used for bootstrapping, but it<br>
turns out that our scheme-based evaluator uses the same memoization.<br>
<br>
So, what to do? I wasn=E2=80=99t there when it happened, and I=E2=80=99m pr=
obably<br>
missing a lot of historical information. What was the plan?<br>
<br>
Should it be that a new memoization is made in scheme to go with the<br>
scheme evaluator, or that the existing memoization is adapted to keep<br>
debug information?<br>
<br>
Or am I completely off the mark?<br>
<br>
Thanks,<br>
No=C3=A9<br>
</blockquote></div>
</blockquote></div>

--000000000000dcd2ca064fd4b329--