From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-user@gnu.org, Kevin Ryde <user42@zip.com.au>
Subject: Re: new slib and guile 1.6.7
Date: Mon, 07 Nov 2005 23:38:33 -0800 [thread overview]
Message-ID: <87irv34miu.fsf@trouble.defaultvalue.org> (raw)
In-Reply-To: <rmir7a1l34f.fsf@fnord.ir.bbn.com> (Greg Troxel's message of "31 Oct 2005 17:42:56 -0500")
Greg Troxel <gdt@ir.bbn.com> writes:
> Here's the code snippet from ice-9/slib.scm, with use of load that
> respects the prefix (NetBSD/pkgsrc puts things in /usr/pkg, not /usr).
>
> (define-module (ice-9 slib)
> :export (slib:load
> implementation-vicinity
> library-vicinity
> home-vicinity
> scheme-implementation-type
> scheme-implementation-version
> make-random-state
> <? <=? =? >? >=?
> require)
> :no-backtrace)
>
> ;; Load slib's init routine.
> (load (string-append (assoc-ref %guile-build-info 'pkgdatadir)
> "/slib/guile.init"))
I haven't had a chance to delve very deeply here, but I just grabbed
the debian 3a2-2 tree, unpacked it, edited guile.init to fix the one
case problem (UNIX -> unix), then symlinked the slib dir as ./slib
into my guile 1.6 CVS checkout and tried this:
$ ./pre-inst-guile
guile> (load-from-path "slib/guile.init")
guile> (require 'new-catalog)
guile> (require 'fft)
guile> fft
#<procedure fft (ara)>
guile>
At least from this admittedly trivial test, ignoring ice-9/slib.scm
and using the slib guile.init directly seems to work.
So do we have any known arguments against just using slib's guile.init
and submitting fixes upstream?
--
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-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2005-11-08 7:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-21 18:54 new slib and guile 1.6.7 Greg Troxel
2005-10-21 20:06 ` Alan Grover
2005-10-21 21:40 ` Kevin Ryde
2005-10-28 13:33 ` Greg Troxel
2005-10-28 22:47 ` Kevin Ryde
2005-10-28 23:40 ` Greg Troxel
2005-10-29 19:52 ` Greg Troxel
2005-10-30 0:48 ` Kevin Ryde
2005-10-30 14:35 ` Greg Troxel
2005-10-30 23:58 ` Kevin Ryde
2005-10-31 22:42 ` Greg Troxel
2005-10-31 23:52 ` Kevin Ryde
2005-11-02 15:30 ` Greg Troxel
2005-11-02 20:16 ` Kevin Ryde
2005-11-04 15:46 ` Greg Troxel
2005-11-06 18:08 ` Rob Browning
2005-11-08 7:38 ` Rob Browning [this message]
2005-11-08 18:01 ` Greg Troxel
2005-11-08 19:43 ` Rob Browning
2005-11-09 14:56 ` Greg Troxel
2005-11-20 2:29 ` 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=87irv34miu.fsf@trouble.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=guile-user@gnu.org \
--cc=user42@zip.com.au \
/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).