From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.devel Subject: Re: Plan for 2.0 Date: Fri, 16 Jan 2009 00:25:41 +0000 Message-ID: <49dd78620901151625i200f1c27r39bd360d4741392@mail.gmail.com> References: <49dd78620901031038i6f6c678o5cebc21b217374d2@mail.gmail.com> <87sknxoeie.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1232065563 25243 80.91.229.12 (16 Jan 2009 00:26:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2009 00:26:03 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 16 01:27:15 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LNcYK-0005gF-Is for guile-devel@m.gmane.org; Fri, 16 Jan 2009 01:27:12 +0100 Original-Received: from localhost ([127.0.0.1]:34414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNcX4-0007XP-BI for guile-devel@m.gmane.org; Thu, 15 Jan 2009 19:25:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNcWx-0007X9-TQ for guile-devel@gnu.org; Thu, 15 Jan 2009 19:25:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNcWw-0007Wx-GH for guile-devel@gnu.org; Thu, 15 Jan 2009 19:25:47 -0500 Original-Received: from [199.232.76.173] (port=53203 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNcWw-0007Wu-D9 for guile-devel@gnu.org; Thu, 15 Jan 2009 19:25:46 -0500 Original-Received: from fg-out-1718.google.com ([72.14.220.159]:34512) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNcWt-0006zD-73; Thu, 15 Jan 2009 19:25:43 -0500 Original-Received: by fg-out-1718.google.com with SMTP id l26so708349fgb.30 for ; Thu, 15 Jan 2009 16:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=NEJIl7lWdu6T++sw2beFvlAozyeC2T9f2nQR0EmL6pY=; b=BT17L9Z/PQNr8UFR9bw4WMXxO+m1RcleT2N9m3BnJAPPSmrd/LfJsiZMrRmFm9Ljjl jGEaIo1UavuGbLgN5WLs6kAq+AhJhUx24zLYRp4sdK884qlx21Ztr9ROCzCS85EO3iid toPx+sH2yyPTqNbmkR4LIId78MEKRQyi0UCkA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dQQcPK7C45cY1O77Wu9FmmG50rRs/HYvK/6oM8g0zST9QoX1GLoJNns/1/52RX/mVl 8IZkIAcnSjnobk39BNacu3KZtTuy7Qdmqnw1rZoltBMcDK8RVYgRWjBA1MwVTHLgpdg5 e3H3lARtlMuuEqYBvqXdZBTmQmWAh1yVjTEdo= Original-Received: by 10.180.253.10 with SMTP id a10mr624394bki.65.1232065541838; Thu, 15 Jan 2009 16:25:41 -0800 (PST) Original-Received: by 10.181.208.17 with HTTP; Thu, 15 Jan 2009 16:25:41 -0800 (PST) In-Reply-To: <87sknxoeie.fsf@gnu.org> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8038 Archived-At: 2009/1/5 Ludovic Court=E8s : > Hello! > > "Neil Jerram" 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