[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plan for 2.0
Re: Plan for 2.0
Mon, 05 Jan 2009 18:21:13 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
"Neil Jerram" <address@hidden> writes:
> We're clearly moving towards a 2.0 release.
> 2. The "vm" branch. Once the review of "master" is done, we'll merge
> "vm" into "master".
> 3. The "ossau-gds-dev" branch. This contains some minor improvements
> to the Emacs interface. After the review of "master" is done, we'll
> merge "ossau-gds-dev" into "master".
I'd do (3) before (2) because it's probably easier.
> 4. Any other changes (including bug fixes) that we think are important
> to get done before 2.0. I propose to review the bugs in Savannah, and
> also recent email discussions, to identify these.
Yeah, let's fix bugs! We still have several bugs reported against 1.8
that need care.
> Is there anything else? In particular, am I right in thinking that
> the BDW-GC work is not ready yet?
The BDW-GC branch is fully functional, and the user-visible API changes
are frozen. What may (or may not) be a stopper are:
1. The lack of `gc-live-object-stats'.
2. Different fields of `gc-stats'.
3. Different behavior of weak hash tables, see
This can be fixed, but I'm unclear whether it's worth it (comments
4. Possible guardian glitches (`guardians.test' seems to be too
permissive to catch non-obvious problems).
I also need to post additional benchmark results.
> One specific query... Although I advocated removing GH before, I
> don't feel 100% confident that that's the right thing for 2.0. I'm
> wondering now if we should instead move the GH code into a separate
> library, "libgh", but continue to provide this as part of the Guile
> distribution. Moving the code out of libguile will still achieve the
> important objectives of (1) reducing the size of the libguile code
> that developers need to look at and work with, and (2) ensuring that
> GH is implementable on top of the advertised SCM API; but keeping
> libgh in the distribution will be a significant help for users who are
> still using GH (who will just need to add -lgh to their link line).
I never considered it urgent, but I think it should be either completely
removed (as is currently the case) or left in `libguile'. Moving it to
another library would make it essentially worthless since it would make
it incompatible anyway.
We could ship a C compatibility header as Andy suggested, but I'm not
sure it's 100% needed.
> I still think we should remove all GH-related documentation, as we
> don't want to do anything to encourage further GH usage. The GH code
> itself is sufficient IMO for showing how someone can migrate their
> code from GH to SCM.
Re: Plan for 2.0, Neil Jerram, 2009/01/07