[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new slib and guile 1.6.7

From: Rob Browning
Subject: Re: new slib and guile 1.6.7
Date: Mon, 07 Nov 2005 23:38:33 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Greg Troxel <address@hidden> 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)>

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 and; previously
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

reply via email to

[Prev in Thread] Current Thread [Next in Thread]