Future of ice-9/slib.scm.

Future of ice-9/slib.scm.

[Rob Browning]

As some of you may have noticed from recent posts to guile-user, Guile
doesn't work with the latest SLIB.  The most general cause of the
current problem appears to be that slib.scm has bitrotted to the point
of breakage.

The question then is, how should we fix this, both in 1.6 and in
future releases?  (I've spoken to the SLIB author, and he's interested
in working with us.)

Although I'm not sure of the exact history behind slib.scm, it appears
to be a modified version of an older SLIB guile.init.  The problem is
that upstream's guile.init has changed.  Among other things, new
functions have been added to guile.init.  Some of these functions are
critical to SLIB's startup, and none of them exist in ice-9/slib.scm.
There are other functions that exist in both files, but have differing
definitions.  It's not always clear which of those differences are
intentional and which just indicate stale code.

In the long run, it seems like the best solution may be to try to work
with the SLIB upstream on guile.init and then just load that file from
ice-9/slib.scm.  However, even if we do decide to do that in the long
run, how should we handle 1.6 now?  There's seems to be a definite
tension between providing a minimal fix, and trying to make sure our
diverged slib.scm isn't doing more harm than good.

For example, even if we patch up 1.6's slib.scm, perhaps by copying
the missing functions from the upstream guile.init, what kind of SLIB
environment will that leave you with?  Will critical functions still
be missing or have incorrect/stale definitions, and more generally, is
it more important to be "correct" with respect to SLIB, or to differ
as little as possible from previous 1.6 behaviors?

How important is it that 1.6's behavior with respect to older versions
of SLIB (versions that already worked) remain unchanged?  Certainly
someone already using guile 1.6.7 successfully with some older version
of SLIB might not be happy if 1.6.8 no longer worked with their SLIB
install.

One very strict way to approach this would be to do something like
this in ice-9/slib.scm:

  (if (detect-older-slib?)
    (load-from-path "old-slib.scm")
    (load-from-slib "guile.init"))

or similar.  Though I don't know if there's an official way to
discover the version of slib that's in the path without loading it.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Future of ice-9/slib.scm.

[klaus schilling]

Rob Browning writes:
 > 

 > The question then is, how should we fix this, both in 1.6 and in
 > future releases?  (I've spoken to the SLIB author, and he's interested
 > in working with us.)

how about converting the individual slib files into guile modules?

Klaus Schilling


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

Re: Future of ice-9/slib.scm.

[Andy Wingo]

Hi Klaus,

On Wed, 2005-11-16 at 08:50 +0100, klaus schilling wrote:
> how about converting the individual slib files into guile modules?

I thought about this in the past. It is however a maintainance
nightmare. If you don't believe me you are free to try it and see ;)

Cheers,
-- 
Andy Wingo
http://wingolog.org/



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

Re: Future of ice-9/slib.scm.

[Rob Browning]

Andy Wingo <wingo@pobox.com> writes:

> I thought about this in the past. It is however a maintainance
> nightmare. If you don't believe me you are free to try it and see ;)

I don't think I'd want to try this unless the upstream was interested
in facilitating it.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Greg Troxel]

  How important is it that 1.6's behavior with respect to older versions
  of SLIB (versions that already worked) remain unchanged?  Certainly
  someone already using guile 1.6.7 successfully with some older version
  of SLIB might not be happy if 1.6.8 no longer worked with their SLIB
  install.

A good question.  While I'm generally in favor of backwards
compatibility, I suspect that people tend to upgrade slib without a
lot of issues (other than this one).

  One very strict way to approach this would be to do something like
  this in ice-9/slib.scm:

    (if (detect-older-slib?)
      (load-from-path "old-slib.scm")
      (load-from-slib "guile.init"))


An easier approach is to put in the if, but with *use-old-slib-init*,
define that to #f, and put in NEWS to set that to #t if trouble.  That
gives people a low-grief way to recover, but without a lot of
guile maintainer time.

I would expect that as long as the older slib version has the
define->define-public hack then the guile.init that came with it would
work fine.


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


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

Re: Future of ice-9/slib.scm.

[Rob Browning]

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

> An easier approach is to put in the if, but with *use-old-slib-init*,
> define that to #f, and put in NEWS to set that to #t if trouble.  That
> gives people a low-grief way to recover, but without a lot of
> guile maintainer time.

Hmm.  If there isn't an easy way to detect the SLIB version, then
that'd definitely be worth considering.

> I would expect that as long as the older slib version has the
> define->define-public hack then the guile.init that came with it
> define->would
> work fine.

Indeed.  If I felt relatively certain that just calling

      (load-from-slib "guile.init")

would do the right thing with the current SLIB version, then I'd be
inclined to consider that as a solution, even in 1.6.8, whenever we
detect a "newer" SLIB[1].

However, to have a good sense that loading guile.init *would* "do the
right thing", I or someone else probably needs to go through
guile.init with reasonable care, while consulting the current
slib.scm, to make sure the differences look "OK".  My suspicion is
that much of guile.init is just fine, but there are some comments in
slib.scm that may warrant a bit of investigation.

If there's anyone else here who has the time and wants to attempt that
evaluation (and probably raise questions here), then that would be
great.  Otherwise, I'll try to get to it soon, though it might not be
until this weekend at the earliest.


[1] Though actually, the current SLIB release still has the unix/UNIX
  symbol case issue (which has been fixed in CVS).  I believe it also
  doesn't define the (ice-9 slib) module if it detects guile 1.6, so
  we'd still need at least a small wrapper.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Greg Troxel]

  [1] Though actually, the current SLIB release still has the unix/UNIX
    symbol case issue (which has been fixed in CVS).  I believe it also
    doesn't define the (ice-9 slib) module if it detects guile 1.6, so
    we'd still need at least a small wrapper.

Good points; I had forgotten about the case problem because slib is
patched in NetBSD pkgsrc so i have a fixed version.

I understand your concern, but as I see it things are quite broken
now.  One could reasonably take the approach of

  ask Aubrey to make a new point release with symbol case fixed

  make ice-9/slib just a define-module/load wrapper, with an option
  for users to revert

  declare any problems with guile.init bugs in slib and fix them there

That will have a little short-term pain but get us quickly to a
non-broken state.


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


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

Re: Future of ice-9/slib.scm.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Indeed.  If I felt relatively certain that just calling
>
>       (load-from-slib "guile.init")
>
> would do the right thing with the current SLIB version, then I'd be
> inclined to consider that as a solution, even in 1.6.8, whenever we
> detect a "newer" SLIB[1].

What does SLIB itself say how it wants to be used with Guile?

My impression is that there are two uncoordinated approaches to glue
Guile and SLIB together.  On one side, Guile itself tries to adapt to
SLIB (and we failed to keep this adaptation current), on the other
side, SLIB adapts to Guile.

I'd say that we should keep our side of the glue really minimal.  It
is pretty big and reaches deep into both Guile and SLIB at the moment,
and that is what makes it break over time.

[ Ooops, I just see that in Debian unstable, slib 3a2-2 conflicts with
  guile-1.6-libs 1.6.7-1.1.  Hmm.
]

guile.init from SLIB and slib.scm from Guile seem to have considerable
overlap.  I'd say we should remove that overlap from our slib.scm.

If we know that this will break older versions of SLIB for sure, and
those older versions are not _that_ old, we can try to keep them
working.  But if don't know now, or those versions are really old
indeed, we can take care of them as needed.

But I'd say that now it is important to get current versions of Guile
working with current versions of SLIB.  Everything else is optional.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: Future of ice-9/slib.scm.

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

> What does SLIB itself say how it wants to be used with Guile?

I believe SLIB's preference is for Guile users to load guile.init.

> [...]
>
> But I'd say that now it is important to get current versions of Guile
> working with current versions of SLIB.  Everything else is optional.

I think your assesment pretty much matches mine.

My current intention is to sit down when I have time and see if I can
figure out what changes, if any, we would have to make to the current
guile.init in order to be able to rely on it, rather than the code in
slib.scm.

Greg Troxel's suggestion may also be worth considering -- that we
might also provide an easy way to request execution of the older
slib.scm code.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> My current intention is to sit down when I have time and see if I can
> figure out what changes, if any, we would have to make to the current
> guile.init in order to be able to rely on it, rather than the code in
> slib.scm.

So here's round one.

Quite a few items in slib.scm are already in guile.init, and so we can
just drop those.  There are some other bits that I wanted to present
for discussion and double-checking.

As background, at the point when any of this code executes, the
current module is (ice-9 slib).

A minor difference regards output-port-width.  The version in slib.scm
returns 80 where the version in guile.init returns 79.

A more significant question regards evaluation.  In slib.scm we have:

  (define-public slib:eval
    (lambda (x) (eval x slib-module)))
  (define defmacro:eval
    (lambda (x) (eval x (interaction-environment))))

where guile.init has:

  ;;; SLIB:EVAL is single argument eval using the top-level (user) environment.
  (define slib:eval
    (if (string<? (scheme-implementation-version) "1.5")
        eval
        (let ((ie (interaction-environment)))
          (lambda (expression)
            (eval expression ie)))))

  (define defmacro:eval slib:eval)

The major difference here is that SLIB's slib:eval evaluates in
interaction-environment rather than the slib module.  It looks like
the current defmacro:eval behaviors are the same.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> A minor difference regards output-port-width.  The version in slib.scm
> returns 80 where the version in guile.init returns 79.
>
> A more significant question regards evaluation.  In slib.scm we have:
> [...]
> where guile.init has:
> [...]

I'd say that in both cases, and in fact in all cases of overlap,
guile.init should win.  Having differing definitions is clearly bad,
and since SLIB has a guile.init, we should bow to it.

Whenever we want to do things differently, we should push those
changes into SLIB.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: Future of ice-9/slib.scm.

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

> Whenever we want to do things differently, we should push those
> changes into SLIB.

Certainly.  That's what I assume we're trying to determine here.
i.e. are there any changes in the current slib.scm that haven't made
it upstream, but should?

For example, aside from the "eval in interaction-environment vs slib"
issue, see also the comments in slib.scm regarding *features* and
slib:load.  Do we need or want to preserve any of those changes?

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> For example, aside from the "eval in interaction-environment vs
> slib" issue, see also the comments in slib.scm regarding *features*
> and slib:load.  Do we need or want to preserve any of those changes?

With respect to some of the *features*, it looks like guile.init
handles 'random by just adding the two functions that Guile's native
implementation was missing.  I think this probably means that the
FIXME in slib.scm has been fixed, and Guile doesn't need to
inappropriately remove 'random from *features* anymore.

Similarly, it looks like the slib.scm ENHANCE-ME regarding arrays may
be satisfied by the current guile.init.  It appears that guile.init
arranges for Guile's native arrays to function correctly as SLIB
arrays.  If so, then it should be OK to drop the slib.scm code that
removes 'array from *features*, but someone else may want to
double-check.

I've examined much of the rest of the slib.scm code and sent a few
questions upstream.  At this point, I think I have a pretty good idea
about what should be done with almost all of the code except the
following:

  - slib:eval -- should it be using slib-module or
    interaction-environment?

  - slib:load -- see the FIXME there.

  - *vicinity-table*, install-require-vicinity, and
     install-require-module -- these don't exist in guile.init (or
     SLIB).  Do we still want or need them?

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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Kevin Ryde]

Rob Browning <rlb@defaultvalue.org> writes:
>
> With respect to some of the *features*, it looks like guile.init
> handles 'random by just adding the two functions that Guile's native
> implementation was missing.

I might have reported that, looks like it's fixed.

> I think this probably means that the
> FIXME in slib.scm has been fixed, and Guile doesn't need to
> inappropriately remove 'random from *features* anymore.

Yep.  (Of course the removal of 'random was entirely appropriate when
there were functions missing.)

> If so, then it should be OK to drop the slib.scm code that
> removes 'array from *features*, but someone else may want to
> double-check.

Sounds likely.  Same story I think, extra bits added.

>   - slib:eval -- should it be using slib-module or
>     interaction-environment?

There's something going on in the whole of guile.init with modules
that I couldn't figure out.  Eg. the aliasing define to define-public.
There's probably a reason for it.


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

Re: Future of ice-9/slib.scm.

[Rob Browning]

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

> Sounds likely.  Same story I think, extra bits added.
>
>>   - slib:eval -- should it be using slib-module or
>>     interaction-environment?
>
> There's something going on in the whole of guile.init with modules
> that I couldn't figure out.  Eg. the aliasing define to define-public.
> There's probably a reason for it.

If I understand the code correctly, guile.init does the same thing,
and in both cases, the purpose is to change any top-level define into
a define-public.

Actually, now that I look, since the slib docs specifically state that
slib:eval will evaluate items in the current top-level environment,
guile.init's use of interaction-environment seems more appropriate.

By the same logic, slib:load shouldn't be using a load path; it should
be a normal load as documented in the slib docs, and as implemented in
guile.init.

I suppose that leaves just the vicinity related definitions in
question.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> I suppose that leaves just the vicinity related definitions in
> question.

As far as I can tell, the vicinity related definitions aren't exported
or documented, so I think we can just drop those too.

For those still following this discussion, I'm planning to put the
following code into guile-1.6 in Debian unstable as the contents of
ice-9/slib.scm, and presuming no one has any improvements or
objections, I'll also commit it to 1.6 CVS a bit later.

With this arrangement, users who find they really need the old slib
behavior in 1.6, will be able to set *guile-use-old-ice-9-slib* to #t.
This define will not be included in in 1.8.

(if (and (defined? '*guile-use-old-ice-9-slib*) *guile-use-old-ice-9-slib*)
    (load-from-path "ice-9/slib-old.scm")
    (begin
      
      ;; The goal here is to eventually *only* rely on guile.init and
      ;; communicate any needed fixes upstream, but for now, we still
      ;; need to do a bit of the work here.
      ;;
      ;; At some point, we will probably just want to require a "new
      ;; enough" version of slib (perhaps with Guile 1.8).  In that
      ;; case, we'll probably just load guile.init, and then test the
      ;; version.

      ;; These can be removed if/when we require a "new enough"
      ;; version of SLIB.
      (define-module (ice-9 slib))
      (provide 'hash)

      (load-from-path "slib/guile.init")

      ;; This can be removed if/when we require a "new enough" version of SLIB.
      (if (not (defined? 'browse-url))
          ;; Nothing special to do for this, so straight from
          ;; Template.scm.  Maybe "sensible-browser" for a debian
          ;; system would be worth trying too (and would be good on a
          ;; tty).
          (define-public (browse-url url)
            (define (try cmd end) (zero? (system (string-append cmd url end))))
            (or (try "netscape-remote -remote 'openURL(" ")'")
                (try "netscape -remote 'openURL(" ")'")
                (try "netscape '" "'&")
                (try "netscape '" "'"))))))

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Kevin Ryde]

Rob Browning <rlb@defaultvalue.org> writes:
>
> With this arrangement, users who find they really need the old slib
> behavior in 1.6, will be able to set *guile-use-old-ice-9-slib* to #t.

I'd be inclined to make one radical change, and not worry about the
old stuff.  Someone can still grab slib.scm from 1.6.4 or whatever if
they really need it, ie. don't want to update immediately.

>       ;; These can be removed if/when we require a "new enough"
>       ;; version of SLIB.

I'd also be inclined to do that now too, I don't think there's any
special merit in an old slib.  Anyone wanting one can always
(presumably) run it up with "guile -lguile.init" the way slib
specifies.

>       (provide 'hash)
> ...
>       (if (not (defined? 'browse-url))

Without sounding like a broken record :) ... I wouldn't worry these
either.  If slib has a problem then leave the fixes for there :-).


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

Re: Future of ice-9/slib.scm.

[Rob Browning]

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

> I'd be inclined to make one radical change, and not worry about the
> old stuff.  Someone can still grab slib.scm from 1.6.4 or whatever
> if they really need it, ie. don't want to update immediately.

I wouldn't be comfortable with that approach for a stable release.  In
general, I want to try and make sure that all of our stable releases
have little or no affect on existing systems, aside from bug fixes.

Unfortunately, it is true that the changes I'm planning here have the
potential to break existing systems, but I'm willing to accept that,
given the fairly trivial, one-line, workaround.  (Of course, I'd still
be happier if we didn't have to require affected people to change any
code.)

Also, I'm not positive, but I think some of the remaining bits in
slib.scm may not have made it into an SLIB release yet.  They will,
but I'm not sure they have yet.

With respect to 1.7, I believe I essentially agree with you.  My
current plan for 1.7 is to change slib.scm to more or less just read:

  (load-from-path "slib/guile.init")

-- 
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Future of ice-9/slib.scm.

[Greg Troxel]

I agree that a few lines of code for backwards compat are warranted.
Really it's a bug that user code needs to do anything, but I don't
think that's worth it.

The comments about 'new enough' are unsatisfying; if you could give a
version that's too old, and one that's new enough it would help
greatly, even if there's an uncertain interval in the middle.

After this is in CVS, and seems to work, it would be nice to have a
release for packagers to update.

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


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

Re: Future of ice-9/slib.scm.

[Rob Browning]

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

> I agree that a few lines of code for backwards compat are warranted.
> Really it's a bug that user code needs to do anything, but I don't
> think that's worth it.

Agreed.  It's not ideal, but seems a reasonable compromise.

> The comments about 'new enough' are unsatisfying; if you could give a
> version that's too old, and one that's new enough it would help
> greatly, even if there's an uncertain interval in the middle.

I'm not sure I understand you correctly, but if you're saying what I
think you're saying, then you probably don't have to be concerned.
The comments in the code were just speculation about what we might
want to do in 1.8, in particular that 1.8's slib.scm will probably
just look like this:

  (load-from-path "slib/guile.init")

and might or might not include a few more lines to check
*SLIB-VERSION* and "do something".  Either way there be clear notes
regarding any requirements in NEWS and the documentation.

> After this is in CVS, and seems to work, it would be nice to have a
> release for packagers to update.

Absolutely.  I was ready to attempt the release quite a bit back, but
have held it up for this issue.

I should be adding this code to 1.6 CVS in the next few days, and then
I'll fire the release process back up.

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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel