SLIB

SLIB

[Ludovic Courtès]

Hi,

I'd like to fix the SLIB issue in 1.8.3.

SLIB 3a4 works perfectly well with 1.8.  The thing is that `(ice-9
slib)' is of no use.  Instead of using it, I followed the SLIB
instructions:

  $ guile -l /usr/share/slib/init/guile.init 
  guile> (require 'primes)
  guile> (prime? 13)
  #t

Note that the first time you use SLIB, it will create the library
catalog, which requires write access to its directory.

Our `(ice-9 slib)' is essentially a duplicate of `guile.init'.  So I
think what we really want in `(ice-9 slib)' is this (as already
suggested by Greg [0]):

  (define-module (ice-9 slib))
  (load-from-path "guile.init")

Distributions could easily patch it so that it works out of the box.  On
Debian, that would become:

  (define-module (ice-9 slib))
  (load "/usr/share/slib/init/guile.init")

Now, it is true that `guile.init' contains too many Guile-specific
things that ought to be maintained out of SLIB, as Mikael noted [1], but
for the time being, I suggest that we just stick to this approach.
FWIW, other `.init' files that come with SLIB are quite long as well.

Ok to rewrite `(ice-9 slib)' as shown above?

Thanks,
Ludovic.

[0] http://thread.gmane.org/gmane.lisp.guile.devel/6644
[1] http://thread.gmane.org/gmane.lisp.guile.devel/6645



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

Re: SLIB

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

2007/8/11, Ludovic Courtès <ludo@gnu.org>:
> I'd like to fix the SLIB issue in 1.8.3.
>
> SLIB 3a4 works perfectly well with 1.8.  The thing is that `(ice-9
> slib)' is of no use.

It's of no use since no-one has added the functions which Aubrey have
added to guile.init when changing slib:s interface to the interpreter.
 Adding those function is, however, an easy thing to do.  I'm not sure
that the diff I've included is appropriate for the latest slib, but it
could very well be.

Apart from providing a more natural division regarding what belongs to
Guile and what belongs to slib, slib.scm makes sure that each time
some module requires new slib code, it will be loaded into the module
(ice-9 slib) and exported from there.  I'm not at all sure that
guile.init does that, and if it doesn't it will lead to strange
behavior:

If Guile module A requires some slib feature F1, and, later, a totally
unconnected Guile module B requires slib feature F2, which depends on
F1, the loading of F2 may or may not lead to a reload of F2 into
module B (depending on how guile.init has been implemented).  If it
leads to a reload, code will be duplicated in modules A and B.  If it
doesn't load to a reload, F2 won't find the feature F1 which it
requires, since it exists in module A.

Are you sure that your suggested slib.scm doesn't have any of the
above two problems?

[-- Attachment #2: slib.scm.diff --]
[-- Type: text/x-patch, Size: 2472 bytes --]

Index: slib.scm
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ice-9/slib.scm,v
retrieving revision 1.46
diff -r1.46 slib.scm
73a74,145
> ;;; (software-type) should be set to the generic operating system type.
> ;;; UNIX, VMS, MACOS, AMIGA and MS-DOS are supported.
> (define software-type
>   (if (string<? (version) "1.6")
>       (lambda () 'UNIX)
>       (lambda () 'unix)))
> 
> (define (user-vicinity)
>   (case (software-type)
>     ((vms)	"[.]")
>     (else	"")))
> 
> (define vicinity:suffix?
>   (let ((suffi
> 	 (case (software-type)
> 	   ((amiga)				'(#\: #\/))
> 	   ((macos thinkc)			'(#\:))
> 	   ((ms-dos windows atarist os/2)	'(#\\ #\/))
> 	   ((nosve)				'(#\: #\.))
> 	   ((unix coherent plan9)		'(#\/))
> 	   ((vms)				'(#\: #\]))
> 	   (else
> 	    (warn "require.scm" 'unknown 'software-type (software-type))
> 	    "/"))))
>     (lambda (chr) (and (memv chr suffi) #t))))
> 
> (define (pathname->vicinity pathname)
>   (let loop ((i (- (string-length pathname) 1)))
>     (cond ((negative? i) "")
> 	  ((vicinity:suffix? (string-ref pathname i))
> 	   (substring pathname 0 (+ i 1)))
> 	  (else (loop (- i 1))))))
> 
> (define (program-vicinity)
>   (define clp (current-load-port))
>   (if clp
>       (pathname->vicinity (port-filename clp))
>       (slib:error 'program-vicinity " called; use slib:load to load")))
> 
> (define sub-vicinity
>   (case (software-type)
>     ((vms) (lambda
> 	       (vic name)
> 	     (let ((l (string-length vic)))
> 	       (if (or (zero? (string-length vic))
> 		       (not (char=? #\] (string-ref vic (- l 1)))))
> 		   (string-append vic "[" name "]")
> 		   (string-append (substring vic 0 (- l 1))
> 				  "." name "]")))))
>     (else (let ((*vicinity-suffix*
> 		 (case (software-type)
> 		   ((nosve) ".")
> 		   ((macos thinkc) ":")
> 		   ((ms-dos windows atarist os/2) "\\")
> 		   ((unix coherent plan9 amiga) "/"))))
> 	    (lambda (vic name)
> 	      (string-append vic name *vicinity-suffix*))))))
> 
> (define with-load-pathname
>   (let ((exchange
> 	 (lambda (new)
> 	   (let ((old program-vicinity))
> 	     (set! program-vicinity new)
> 	     old))))
>     (lambda (path thunk)
>       (define old #f)
>       (define vic (pathname->vicinity path))
>       (dynamic-wind
> 	  (lambda () (set! old (exchange (lambda () vic))))
> 	  thunk
> 	  (lambda () (exchange old))))))
> 
204a277,278
> (define slib:features *features*)
> 

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: SLIB

[Kevin Ryde]

"Mikael Djurfeldt" <mikael@djurfeldt.com> writes:
>
> slib.scm makes sure that each time
> some module requires new slib code, it will be loaded into the module
> (ice-9 slib) and exported from there.  I'm not at all sure that
> guile.init does that,

I suspect it doesn't.  It'd be cute if going through (ice-9 slib) worked
with the module system so you could get slib in some modules and not
others.  In particular it'd help for the various funcs in slib which
clash with guile core bits, like the different flavour of `system', and
the separate `provided?' feature list which Greg mentioned.  But I think
it depends what Aubrey want to do.  For now I think guile.init is only
really setup to be loaded into the top-level environment to transmute it
into an slib environment.


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

Re: SLIB

[Mikael Djurfeldt]

2007/8/16, Kevin Ryde <user42@zip.com.au>:
> "Mikael Djurfeldt" <mikael@djurfeldt.com> writes:
> >
> > slib.scm makes sure that each time
> > some module requires new slib code, it will be loaded into the module
> > (ice-9 slib) and exported from there.  I'm not at all sure that
> > guile.init does that,
>
> I suspect it doesn't.  It'd be cute if going through (ice-9 slib) worked
> with the module system so you could get slib in some modules and not
> others.

If I understand you correctly, I'd say that it currently does work
like that.  The idea is that slib lives in (ice-9 slib) and that all
public functions are exported from there to all who uses (ice-9 slib).

>  In particular it'd help for the various funcs in slib which
> clash with guile core bits, like the different flavour of `system', and
> the separate `provided?' feature list which Greg mentioned.

I haven't read what Greg has written about this, but, yes, probably
some aspects of slib needs to be updated.

>  But I think it depends what Aubrey want to do.

Yes, ideally, you should coordinate this with Aubrey.  Why not explain
the situation for him?  I think the simplest solution would be to use
the main idea of (ice-9 slib) explained above.  Maybe Aubrey could
strip down guile.init a bit so that ice-9/slib.scm could load
guil.init and add the Guile module system specific things to make
loading into (ice-9 slib) and exporting from it work?

>  For now I think guile.init is only
> really setup to be loaded into the top-level environment to transmute it
> into an slib environment.

I disagree.  Just loading guile.init in its current form simply does
not work together with the Guile module system.  Unfortunately, it
doesn't become obvious until one has used it enough.


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

Re: SLIB

[Kevin Ryde]

"Mikael Djurfeldt" <mikael@djurfeldt.com> writes:
>
> Yes, ideally, you should coordinate this with Aubrey.  Why not explain
> the situation for him?  I think the simplest solution would be to use
> the main idea of (ice-9 slib) explained above.  Maybe Aubrey could
> strip down guile.init a bit so that ice-9/slib.scm could load
> guil.init and add the Guile module system specific things to make
> loading into (ice-9 slib) and exporting from it work?

Yep.  Rob worked on that, or on slib.scm loading guile.init at least.
He checked-in an slib.scm along those lines into the 1.6 branch,

    http://cvs.savannah.gnu.org/viewvc/guile/guile-core/ice-9/slib.scm?revision=1.32.2.10&root=guile&view=markup&pathrev=branch_release-1-6

I'm not certain if it covers every possibility, but it does mean current
and future slib has a good chance of working.  (I've only really nosed
around this stuff lately to let my lint program work with it.)

> Just loading guile.init in its current form simply does
> not work together with the Guile module system.  Unfortunately, it
> doesn't become obvious until one has used it enough.

That might be what I meant.  Slib seems well setup to turn the top level
of any scheme into a more or less uniform slib environment, it's not
clear it tries to know much about modules (in guile or any other
scheme).


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

Re: SLIB

[Rob Browning]

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

> Yep.  Rob worked on that, or on slib.scm loading guile.init at least.
> He checked-in an slib.scm along those lines into the 1.6 branch,
>
>     http://cvs.savannah.gnu.org/viewvc/guile/guile-core/ice-9/slib.scm?revision=1.32.2.10&root=guile&view=markup&pathrev=branch_release-1-6
>
> I'm not certain if it covers every possibility, but it does mean current
> and future slib has a good chance of working.  (I've only really nosed
> around this stuff lately to let my lint program work with it.)

Yes, and I had intended for us to add a similar adjustment to 1.8, but
it didn't happen before the release.

Since Aubrey Jaffer seems quite willing to work with us to accommodate
adjustments to guile.init, I had thought that it might be reasonable
to just alter (ice-9 slib) to load guile.init and begin forwarding all
of our changes to him.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 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

Re: SLIB

[Ludovic Courtès]

Hi Rob,

Rob Browning <rlb@defaultvalue.org> writes:

> Since Aubrey Jaffer seems quite willing to work with us to accommodate
> adjustments to guile.init, I had thought that it might be reasonable
> to just alter (ice-9 slib) to load guile.init and begin forwarding all
> of our changes to him.

So do you mean that `(ice-9 slib)' should just contain `define-module' +
`load' as suggested earlier?  If so, then let's do it.  :-)

I hadn't noticed that 1.6 had already taken this route.

Thanks,
Ludovic.

[0] http://thread.gmane.org/gmane.lisp.guile.devel/6680


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

Re: SLIB

[Rob Browning]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> So do you mean that `(ice-9 slib)' should just contain
> `define-module' + `load' as suggested earlier?  If so, then let's do
> it.  :-)

I was just wondering if we should try to make (ice-9 slib) as minimal
as possible (perhaps even have it only load guile.init) and then work
with Aubrey Jaffer to have guile.init handle everything else.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 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