new slib and guile 1.6.7

new slib and guile 1.6.7

[Greg Troxel]

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 by the guile-slib package and is really pretty
simple:

; $NetBSD: gencat.scm,v 1.1.1.1 2000/02/23 20:36:47 jlam Exp $

(use-modules (ice-9 slib))
(slib:load "mklibcat")

It seems that guile has (ice-9 slib) and does not use guile.init from
slib.  I think (ice-9 slib) needs to have support for
with-load-pathname for the new slib to work, but I don't really
understand this.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Alan Grover]

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/slib had to be removed (and replaced at your
preference with something that loads slib/guile.init). Presumably
ice-9/slib should be removed from guile.

Second, I think there is a bug in slib/guile.init related to line 28:

(define software-type
  (if (string<? (version) "1.6")
      (lambda () 'UNIX)
      (lambda () 'unix)))
;

>From what I can tell, use of 'unix vs. 'UNIX is inconsistent throughout
guile.init (and thus causes problems with case-preserving symbols). I
punted and added both wherever either was used:

72c71
<          ((unix coherent ms-dos)      ;V7 unix has a / on HOME
---
>          ((UNIX unix coherent ms-dos) ;V7 unix has a / on HOME
92c91
<          ((unix coherent plan9)               '(#\/))
---
>          ((UNIX unix coherent plan9)          '(#\/))
127c126
<                  ((UNIX COHERENT PLAN9 AMIGA) "/"))))
---
>                  ((unix UNIX COHERENT PLAN9 AMIGA) "/"))))

And third, once you get the error, you must delete slibcat to try again.

And fourth, I have been too lazy to send this bug report to the slib
guy. Could you finish characterizing the behavior, and propose the
(better) fix to the slib guy?

Greg Troxel wrote:
> 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 by the guile-slib package and is really pretty
> simple:
> 
> ; $NetBSD: gencat.scm,v 1.1.1.1 2000/02/23 20:36:47 jlam Exp $
> 
> (use-modules (ice-9 slib))
> (slib:load "mklibcat")
> 
> It seems that guile has (ice-9 slib) and does not use guile.init from
> slib.  I think (ice-9 slib) needs to have support for
> with-load-pathname for the new slib to work, but I don't really
> understand this.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Kevin Ryde]

Alan Grover <awgrover@mail.msen.com> 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 slib docs is the way to go.

Yep, very b0rken these days.  ice-9/slib.scm has been kind of a copy
of slib/guile.init for a long time, and hasn't kept up.  Aubrey Jaffer
is keeping guile.init up-to-date with what he needs/wants for slib.

I posted guile-devel a little while ago threatening to remove or turn
ice-9/slib.scm into (load "guile.init").  I'll try to do that soon.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

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 make a catalog and
load modules.  But even after a catalog is created, the existing ice-9
slib fails to load modules.

I believe this should be fixed for 1.6.8; breaking slib breaks
gnucash.



-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> 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
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

  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
ABORT: (unbound-variable)
guile> (version)
"1.6.8"


This is running the 1.6.8 prerelease announced on the list a week or
so ago, and with NetBSD pkgsrc slib 3.1.2, which is 3a2 in slib
versioning.
The basic issue is that ice-9 slib is no longer providing all the
procedures that slib expects, but slibs guile.init does.

> guile
guile> (load "/usr/pkg/share/slib/guile.init")
guile> (require 'stdio)
guile> (printf "foo %d\n" 2)
foo 2
6

Whether there is something deeper with gnucash, I don't know, but I
have no reason to think so yet.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

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 symbols into the current
;; module.
(load (string-append (assoc-ref %guile-build-info 'pkgdatadir)
		     "/slib/guile.init")))

;; use-modules will fail if the file fails to define the module
(define-module (ice-9 slib))


I'm probably going to  add a patch to pkgsrc's guile entry to change
ice-9/slib.scm to the above; right now gnucash doesn't work in pkgsrc.

Comments on the above, and how better to do it appreciated.


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> 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 when not used, if you know what I mean.

> ;; Load slib's init file directly, implicitly symbols into the current
> ;; module.

To be the same as the slib documented startup then I think it has to
load into the guile-user module, if that doesn't happen already.

The effect would be global, which may or may not be a good thing, but
at least would be the same as the "slib" script program does, say.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

Kevin Ryde <user42@zip.com.au> 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 you are
right about the module system.  What I did  places the guile.init
bindings in the module that calls (use-modules (ice-9 slib)), and not
in the slib module, so that some other modules that does use-modules
will not get them - this is what happened in gnucash.

> To be the same as the slib documented startup then I think it has to
> load into the guile-user module, if that doesn't happen already.

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'll try again, and this time export the symbols from before plus the
new one that precipitated all this.
-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> 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-globally).  I
suspect `require' is module-unaware.  If you load something I suspect
it gets into the current module, then in another module slib thinks
it's already loaded but the definitions are not visible, or whatever.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

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 copy, but still exporting.

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"))





-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> 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 are specific to slib, and when it
adds a few more the module will stop working.  The addition of new
stuff in slib was what broke the existing ice-9/slib.scm.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

Kevin Ryde <user42@zip.com.au> writes:

> Greg Troxel <gdt@ir.bbn.com> 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 are specific to slib, and when it
> adds a few more the module will stop working.  The addition of new
> stuff in slib was what broke the existing ice-9/slib.scm.

You are right, but if you object to going from what we have to what I
posted, I don't see your point.  The current ice-9/slib.scm is tied to
specific slib versions.   If you are feeling that integrating slib
into a module system is messy, then I agree.

sorry if i'm being redundant here:

Slib has an internal API that all scheme impls must meet, and init
files for each impl.  I did not come across documentation of that API;
perhaps we should suggest that to Audrey and also to make a note in
the slib NEWS file :-)

Further complicating things, slib has the notion of 'adding slib to
one's scheme implementation' by modifying the default startup path to
include in our case slib's guile.init.  This is problematic from the
viewpoint of a system where some users/programs want slib and some
don't.  Guile solves this the slib module where if you haven't
(use-modules (ice-9 slib)) then you don't see any bindings.

So, I think the only fully satisfactory solution from a both
functional and software maintenance view is that slib needs to define
the API that guile.init has to provide for users for slib.  There are
of course a lot of internal procedures, but we don't have to export
those.  I'm afraid that the file I sent fails to export some
procedures, but it was enough to make gnucash work with slib.

Looking over the docs and code, it seems that the texinfo manual
defines a bunch of procedures/variables that the user can use.  They
seem to be present, so I looked at slib's guile.init, and it was the
following cool/sick code:

(define base:define define)
(define define
  (procedure->memoizing-macro
   (lambda (exp env)
     (cons (if (= 1 (length env)) 'define-public 'base:define) (cdr exp)))))

which I think results in all the defines in the file being
define-public.
For example, (scheme-implementation-home-page) works, so perhaps we
don't have to explicitly export things, and we can just load
guile.init after doing define-module.


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> 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 that guile.init has to provide for
> users for slib.

I suspect it's not that formal, but rather the init files are only
those bits which have turned out to vary between supported schemes.
The last change for instance moved bits out of the common files into
the init files.

> (define base:define define)
> (define define
>   (procedure->memoizing-macro
>    (lambda (exp env)
>      (cons (if (= 1 (length env)) 'define-public 'base:define) (cdr exp)))))
>
> which I think results in all the defines in the file being
> define-public.

Yes, for top-level defines.  Dunno what that's actually meant to do
though.

Incidentally the test seems to fail in the guile cvs, different
implementation of env or something.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Greg Troxel]

Kevin Ryde <user42@zip.com.au> writes:

> Greg Troxel <gdt@ir.bbn.com> 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 :-).

My latest attempt comes as close as I think we can.

> > slib needs to define the API that guile.init has to provide for
> > users for slib.
> 
> I suspect it's not that formal, but rather the init files are only
> those bits which have turned out to vary between supported schemes.
> The last change for instance moved bits out of the common files into
> the init files.

I think you are right.  But it's currently hard to tell which
definitions have to be exported from the module.  But....


> > (define base:define define)
> > (define define
> >   (procedure->memoizing-macro
> >    (lambda (exp env)
> >      (cons (if (= 1 (length env)) 'define-public 'base:define) (cdr exp)))))
> >
> > which I think results in all the defines in the file being
> > define-public.
> 
> Yes, for top-level defines.  Dunno what that's actually meant to do
> though.

I think the idea is to cooperate with guile's module system and export
all the top-level procedures.

> Incidentally the test seems to fail in the guile cvs, different
> implementation of env or something.

I suppose we either need to fix guile cvs or get some new code for
slib to do what it needs.  Here's results from top-level interactive
in a 1.6.8 release candidate. 

guile> (use-modules (ice-9 format))
guile> (define (a exp env) (format "exp ~A\nenv ~A\n" exp env))
guile> a
#<procedure a (exp env)>
guile> (define b (procedure->macro a))
guile> b
#<macro a>
guile> (b 'foo 'bar)
"exp (b (quote foo) (quote bar))
env (#<eval-closure 80c0b50>)
"


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> (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)

Does someone know the history of our existing slib.scm?  Is it a
slightly or heavily modified version of an earlier slib guile.init?

Also, does anyone already have an idea whether the upstream is likely
to be interested in changes that might make our
integration/maintenance easier, presuming we can figure out what that
might entail?

Thanks
-- 
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

Re: new slib and guile 1.6.7

[Rob Browning]

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

Re: new slib and guile 1.6.7

[Greg Troxel]

Rob Browning <rlb@defaultvalue.org> writes:

>   $ ./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?

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 of (ice-9 slib) seems fine.

Definitely the case error should be fed back upstream.  I think it's
sufficient for guile.init to declare a preferred case and always use
that, since that would work with either case-sensitive or insensitive
parsers.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> 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 of (ice-9 slib) seems fine.

In fact, if you adjust guile.init to not suppress the define-module
statement under guile 1.6, even symlinking ice-9/slib.scm to the
current guile.init seems to work fine, as does a simple
load-from-path.

-- 
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

Re: new slib and guile 1.6.7

[Greg Troxel]

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 <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: new slib and guile 1.6.7

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> 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 observing that it seemed to work
(after minor patches to guile.init).

Also, for anyone interested, we're discussing the SLIB issue further
in a thread on guile-devel.

Thanks
-- 
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