Re: Plan for 2.0

[Ludovic Courtès]

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'.