[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plan for 2.0
From: |
Ludovic Courtès |
Subject: |
Re: Plan for 2.0 |
Date: |
Mon, 12 Jan 2009 18:08:55 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
Hello,
"Neil Jerram" <address@hidden> writes:
> That's good, but I think I didn't explain the possible problem fully,
> i.e. that the substitute won't work. Because of how Guile saves and
> restores continuations (by copying the stack), and how it uses alloca
> to create space for debug information on the stack, we must have an
> alloca() that really does use the stack, and not one that uses the
> heap. And when I last checked, the common substitute definition of
> alloca() uses the heap.
Aaah, you're right. Then we should use the `alloca-opt' module instead,
which does what we want AFAIU.
(Note that systems without `alloca ()', are probably very rare.)
> master has a line "serial 9", branch_release-1-8 doesn't. I believe
> it's a standard of some kind to have a "serial" line, so we added it
> in master, but preferred to avoid perturbing 1.8.x.
Right, it's "good practice" (info "(automake) Serials").
>>> eval.c/eval.i.c
>>> - still need to compare old eval.c against new eval.i.c
>>> - why does eval.i.c contain code that is common to both modes and that
>>> is not compiled twice?
>>
>> Like what? The top of the file is in `#ifdef DEVAL'.
>
> I would have thought that the point of eval.i.c is to hold the code
> that gets compiled twice (debug and non-debug). If there is #ifdef
> DEVAL code in eval.i.c, it seems to be better to move it back to
> eval.c.
Agreed.
>>> SCM_INTERNAL (grep diffs for SCM_INTERNAL to get list of affected functions)
>>
>> Speaking of which, some functions were left external (e.g.,
>> `scm_i_string_chars ()') under the assumption that if we changed that in
>> 1.8 (which was my plan back then) it would break apps. We may need to
>> revise that.
>
> I can't immediately remember what the latest consensus on that was...
IIRC, nobody cares. :-)
Thanks,
Ludo'.
Re: Plan for 2.0, David Séverin, 2009/01/09