Hello!
One more thought...
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> 3. Benefit from an all-knowing GC. While Guile's GC knows only about
> the stack(s), registers and "cell heap", BDW-GC knows about all of
> a process' storage: stack(s), registers, the whole heap,
> thread
2008/11/8 Ludovic Courtès <[EMAIL PROTECTED]>:
> Hello Guilers!
>
> Below are some of the points (in no particular order) that IMO can make
> it worthwhile to use the Boehm-Demers-Weiser GC [0] in Guile instead of
> Guile's historical GC, from an engineering viewpoint.
This all sounds pretty compe
Andy recently wondered - in connection with his VM implementation and
docs - about when a 1.9.x or 1.10.x release might happen, and that
reminded me about the following thoughts that I've been trying to
crystallize for a while. How should we organize future Guile
releases? I'm interested to hear
If the base Guile C API remains stable, it doesn't matter to me how the
releases occur, because they won't break my libraries or projects.
If the Guile C API needs to change, some sort of notification and beta
pre-release would be preferred, so that I can test my projects before the new
Guile
2008/11/10 Neil Jerram <[EMAIL PROTECTED]>:
>
> I also think it will help us manage API incompatibilities better. I
> think our default position from now on should be to maintain
> source-level (API) compatibility, but it is inevitable that there will
> be exceptions to this.
Any ideas for binary
