Hi Neil,
Neil Jerram writes:
> The make-stack frame should say just `[make-stack #t]'.
>
> I would guess this problem was introduced by your cclo->gsubr changes,
> beginning at e20d7001c3f7150400169fecb0bf0eefdf122fe2. I don't mind
> debugging it, but maybe the problem is obvious to you, now I'
Hello,
Neil Jerram writes:
> I think it's inelegant to have to edit a script in order to debug it.
> If there is some generally useful system for debugging/introspection of
> a running Guile program - such as GDS, as I hope it will eventually
> become - it seems more efficient to be able to have
Hello!
Following the inlining of stringbuf storage
(ba54a2026beaadb4e7566d4b9e2c9e4c7cd793e6), the ‘bdw-gc-static-alloc'
branch introduces a small source-level incompatibility. Namely, the
following no longer works:
const char foo[] = "foo";
SCM_SYMBOL (s_foo, foo);
Because of the macrology
Hi,
Andreas Rottmann writes:
> Attached is a patch that extends the read syntax to allow for #| ... |#
> block comments.
Are there objections to this patch? If no, I’ll apply it.
Note that it makes the reader understand this syntax by default, not via
a read option.
Thanks,
Ludo’.
On Fri 02 Oct 2009 02:15, l...@gnu.org (Ludovic Courtès) writes:
> Because of the macrology that’s used to statically allocate stringbufs [0],
> the string has to be a literal:
>
> SCM_SYMBOL (s_foo, "foo");
>
> What do you think?
Need more information :) How widespread is the non-literal usage
l...@gnu.org (Ludovic Courtès) writes:
> Hi Neil,
>
> Neil Jerram writes:
>
>> The make-stack frame should say just `[make-stack #t]'.
>>
>> I would guess this problem was introduced by your cclo->gsubr changes,
>> beginning at e20d7001c3f7150400169fecb0bf0eefdf122fe2. I don't mind
>> debugging
