2009/1/5 Ludovic Courtès <l...@gnu.org>: > Hello! > > "Neil Jerram" <neiljer...@googlemail.com> writes: > >> 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.
Agreed. >> 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'. I doubt it's a stopper, but current `gc-live-object-stats' is quite nice. Doesn't libgc have a lightweight object-collected hook that would allow us to implement this? Or is it the problem that would be too bad for performance? > 2. Different fields of `gc-stats'. I would say that this is fine. > 3. Different behavior of weak hash tables, see > http://lists.gnu.org/archive/html/guile-devel/2008-11/msg00015.html . > This can be fixed, but I'm unclear whether it's worth it (comments > welcome!). IIUC, your example to the GC list can be fixed (in the application) by using a (BGC) doubly weak hash table instead. I wonder what is the simplest example of a current Guile weak-key hash table that can't be mapped to a BGC doubly weak one? >> 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. Is your view on this a strong one? I feel fairly sure that we ought to continue to distribute this code - but in a deprecated and undocumented separate library - because I think by doing so we can help users with negligible ongoing maintenance cost. Thanks! Neil
