Greg Troxel <[EMAIL PROTECTED]> writes:
> So a (ice-9 slib) that does
>
> (define-module (ice-9 slib))
> ([load guile.init])
>
> would be fully adequate, and avoid the messy symlinking issue?
Yes, I think that would probably work similarly. I wasn't actually
proposing that we use a symlink, just
So a (ice-9 slib) that does
(define-module (ice-9 slib))
([load guile.init])
would be fully adequate, and avoid the messy symlinking issue?
--
Greg Troxel <[EMAIL PROTECTED]>
___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.or
Greg Troxel <[EMAIL PROTECTED]> writes:
> I don't have any, but note that we need to have
>
> (use-modules (ice-9 slib))
>
> make adequate symbols visible in the using module. Given that
> guile.init has code to use define-public most of the time, putting the
> load insidde the module definition
Rob Browning <[EMAIL PROTECTED]> writes:
> $ ./pre-inst-guile
> guile> (load-from-path "slib/guile.init")
> guile> (require 'new-catalog)
> guile> (require 'fft)
> guile> fft
> #
> guile>
>
> At least from this admittedly trivial test, ignoring ice-9/slib.scm
> and using the slib g
Greg Troxel <[EMAIL PROTECTED]> 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-vicinit
Greg Troxel <[EMAIL PROTECTED]> writes:
> (define-module (ice-9 slib)
> :export (slib:load
> implementation-vicinity
> library-vicinity
> home-vicinity
> scheme-implementation-type
> scheme-implementation-version
> make-random-state
>
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Greg Troxel <[EMAIL PROTECTED]> writes:
> >
> > You are right, but if you object to going from what we have to what I
> > posted, I don't see your point.
>
> I was hoping the issue could be killed for good, ie. impervious to
> anything guile.init might do
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> You are right, but if you object to going from what we have to what I
> posted, I don't see your point.
I was hoping the issue could be killed for good, ie. impervious to
anything guile.init might do in the future :-).
> slib needs to define the API tha
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Greg Troxel <[EMAIL PROTECTED]> writes:
> >
> > (define-module (ice-9 slib)
> > :export (slib:load
> >implementation-vicinity
> >library-vicinity
> >home-vicinity
> >scheme-implementation-type
> >scheme-implementati
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> (define-module (ice-9 slib)
> :export (slib:load
> implementation-vicinity
> library-vicinity
> home-vicinity
> scheme-implementation-type
> scheme-implementation-version
I would worry very much that these a
I got it to work, and it is non-global. As I see it, the ice-9 slib
module has a bunch of definitions, and programs that want to use them,
including require, have to use-module it. This is how it always
worked. I ended up doing it the same way, except using guile.init
instead of the homegrown co
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> If all modules inherit from guile-user, then that sounds right. But
> this would expose slib's require machinery to all guile programs, even
> those that haven't asked for it, and that's not good.
I'm unsure if it would work any other way (ie. non-globa
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I wondered if perhaps ice-9 slib was supposed to be like a proper
> module, giving an slib environment only in those application modules
> using it, and not when not used, if you know what I mean.
gnucash fails still, but it gets a lot further. I think yo
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> Whether there is something deeper with gnucash, I don't know, but I
> have no reason to think so yet.
I wondered if perhaps ice-9 slib was supposed to be like a proper
module, giving an slib environment only in those application modules
using it, and not
I put the following in ice-9/slib.scm, and while a bit gross, let me
load stdio and use printf. This assumes that slib is a directory in
pkgdatadir; pkgsrc systems install it in /usr/pkg/share/slib and then
symlink it to /usr/pkg/share/guile/slib.
;; Load slib's init file directly, implicitly sym
Ah. Do we have someone from the gnucash world who can say what it
should look like or how it should work?
It's not that complicated. With the new slib, you get behavior like
this:
> guile
guile> (use-modules (ice-9 slib))
guile> (require 'stdio)
ERROR: Unbound variable: with-load-pathname
A
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> I believe this should be fixed for 1.6.8; breaking slib breaks
> gnucash.
Ah. Do we have someone from the gnucash world who can say what it
should look like or how it should work?
___
Guile-user mailing list
Do you have replacement content for ice-9 slib that works? Is it
necessary to export symbols, or to define-module first so that all of
guile.init's symbols are in the global namespace?
With explicit loading of guile.init (and no ice-9 slib), and a
UNIX/unix case fixup in guile.init, I am able to
Alan Grover <[EMAIL PROTECTED]> writes:
>
> I have the same problem with 1.6.4 (no surprise) and slib3a2.
>
> First, Kevin Ryde once wrote me:
>> Incidentally, the (ice-9 slib) module which comes with guile probably
>> doesn't work with the latest slib, running up guile.init as described
>> in the
I have the same problem with 1.6.4 (no surprise) and slib3a2.
First, Kevin Ryde once wrote me:
> Incidentally, the (ice-9 slib) module which comes with guile probably
> doesn't work with the latest slib, running up guile.init as described
> in the slib docs is the way to go.
I found that ice-9/sl
I'm investigating why in NetBSD pkgsrc the update of slib to 3a2
breaks the guile-slib package, failing when it tries to build the
catalog:
cd /usr/pkg/share/guile/slib; guile -q -s /usr/pkgsrc/devel/guile-slib/files/ge
ncat.scm
ERROR: Unbound variable: with-load-pathname
gencat.scm is provided
21 matches
Mail list logo
