Greg Troxel <[EMAIL PROTECTED]> 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 enoug
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
great
Kevin Ryde <[EMAIL PROTECTED]> 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 stab
Rob Browning <[EMAIL PROTECTED]> 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
Rob Browning <[EMAIL PROTECTED]> 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 planni
Kevin Ryde <[EMAIL PROTECTED]> 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 alias
Rob Browning <[EMAIL PROTECTED]> 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
Rob Browning <[EMAIL PROTECTED]> 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
Marius Vollmer <[EMAIL PROTECTED]> 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 exa
Rob Browning <[EMAIL PROTECTED]> 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
Rob Browning <[EMAIL PROTECTED]> 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
Marius Vollmer <[EMAIL PROTECTED]> 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.
Rob Browning <[EMAIL PROTECTED]> 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
[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 th
Greg Troxel <[EMAIL PROTECTED]> 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
Andy Wingo <[EMAIL PROTECTED]> 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 @defaultva
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.
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
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
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 rele
20 matches
Mail list logo
