From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Future of ice-9/slib.scm. Date: Tue, 15 Nov 2005 21:23:23 -0800 Message-ID: <878xvpupx0.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1132118653 12926 80.91.229.2 (16 Nov 2005 05:24:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Nov 2005 05:24:13 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Nov 16 06:24:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EcFld-0002Gy-Jn for guile-devel@m.gmane.org; Wed, 16 Nov 2005 06:23:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EcFlc-0004AL-PG for guile-devel@m.gmane.org; Wed, 16 Nov 2005 00:23:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EcFlX-0004A7-FA for guile-devel@gnu.org; Wed, 16 Nov 2005 00:23:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EcFlV-00049u-UB for guile-devel@gnu.org; Wed, 16 Nov 2005 00:23:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EcFlV-00049r-Qu for guile-devel@gnu.org; Wed, 16 Nov 2005 00:23:25 -0500 Original-Received: from [70.85.129.156] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EcFlV-0006ou-Qn for guile-devel@gnu.org; Wed, 16 Nov 2005 00:23:26 -0500 Original-Received: from omen.defaultvalue.org (localhost [127.0.0.1]) by defaultvalue.org (Postfix) with ESMTP id B075F91251 for ; Tue, 15 Nov 2005 23:23:26 -0600 (CST) Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by omen.defaultvalue.org (Postfix) with ESMTP id 45BE03F4A for ; Tue, 15 Nov 2005 21:23:24 -0800 (PST) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 7D31A41196; Tue, 15 Nov 2005 21:23:23 -0800 (PST) Original-To: guile-devel@gnu.org User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) 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:5393 Archived-At: As some of you may have noticed from recent posts to guile-user, Guile doesn't work with the latest SLIB. The most general cause of the current problem appears to be that slib.scm has bitrotted to the point of breakage. The question then is, how should we fix this, both in 1.6 and in future releases? (I've spoken to the SLIB author, and he's interested in working with us.) Although I'm not sure of the exact history behind slib.scm, it appears to be a modified version of an older SLIB guile.init. The problem is that upstream's guile.init has changed. Among other things, new functions have been added to guile.init. Some of these functions are critical to SLIB's startup, and none of them exist in ice-9/slib.scm. There are other functions that exist in both files, but have differing definitions. It's not always clear which of those differences are intentional and which just indicate stale code. In the long run, it seems like the best solution may be to try to work with the SLIB upstream on guile.init and then just load that file from ice-9/slib.scm. However, even if we do decide to do that in the long run, how should we handle 1.6 now? There's seems to be a definite tension between providing a minimal fix, and trying to make sure our diverged slib.scm isn't doing more harm than good. For example, even if we patch up 1.6's slib.scm, perhaps by copying the missing functions from the upstream guile.init, what kind of SLIB environment will that leave you with? Will critical functions still be missing or have incorrect/stale definitions, and more generally, is it more important to be "correct" with respect to SLIB, or to differ as little as possible from previous 1.6 behaviors? How important is it that 1.6's behavior with respect to older versions of SLIB (versions that already worked) remain unchanged? Certainly someone already using guile 1.6.7 successfully with some older version of SLIB might not be happy if 1.6.8 no longer worked with their SLIB install. One very strict way to approach this would be to do something like this in ice-9/slib.scm: (if (detect-older-slib?) (load-from-path "old-slib.scm") (load-from-slib "guile.init")) or similar. Though I don't know if there's an official way to discover the version of slib that's in the path without loading it. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel