unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Rob Browning <rlb@defaultvalue.org>
Subject: Future of ice-9/slib.scm.
Date: Tue, 15 Nov 2005 21:23:23 -0800	[thread overview]
Message-ID: <878xvpupx0.fsf@trouble.defaultvalue.org> (raw)


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


             reply	other threads:[~2005-11-16  5:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-16  5:23 Rob Browning [this message]
2005-11-16  7:50 ` Future of ice-9/slib.scm klaus schilling
2005-11-16 10:14   ` Andy Wingo
2005-11-17 19:16     ` Rob Browning
2005-11-16 15:38 ` Greg Troxel
2005-11-18  3:56   ` Rob Browning
2005-11-18 11:46     ` Greg Troxel
2005-11-19 14:22     ` Marius Vollmer
2005-11-19 18:09       ` Rob Browning
2005-11-19 21:43         ` Rob Browning
2005-11-19 23:38           ` Marius Vollmer
2005-11-20  1:06             ` Rob Browning
2005-11-20 20:01               ` Rob Browning
2005-11-20 21:09                 ` Kevin Ryde
2005-11-20 23:27                   ` Rob Browning
2005-12-09 20:42                     ` Rob Browning
2005-12-11  0:59                       ` Kevin Ryde
2005-12-11  6:08                         ` Rob Browning
2005-12-12 19:39                           ` Greg Troxel
2005-12-13  1:33                             ` Rob Browning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878xvpupx0.fsf@trouble.defaultvalue.org \
    --to=rlb@defaultvalue.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).