Re: Exceptions

[Ludovic Courtès]

Hello,

Vorfeed Canal <address@hidden> writes:

> 1. Not really:
>   A. They are usually useless for programs not linked to guile - and
> such programs will know where to find them anyway since libguile will
> know this.

Libguile knows where _any_ third party library (the shared object) gets
installed?  This is wrong.  The user knows it, the Scheme module that
loads it knows it, but Guile itself doesn't care.

>   B. If program A is linked to libguile.so.12 (guile 1.6.7) while
> program B is linked to libguile.so.16 (guile 1.7.2) they'll need
> DIFFERENT versions of such libraries - and this is somewhat
> problematic with libtool.

This is true I guess, because `dynamic-link' doesn't allow to specify
version info.  _This_ is an issue and maybe this procedure could be
fixed by allowing the user to pass Libtool-like version information.

Note that `(ice-9 readline)' works around this by having the library
name contain version information.

>   C. While it's true "these libraries can do this and they can do
> that" in almost 100% cases today they just export some functions for
> scheme level.

Maybe.  So what?

> 2. You can not install them "in the usual place" anyway:
>
> $ ./configure --prefix=/somewhere/there ; make ; make install
> $ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
> ERROR: In procedure dynamic-link:
> ERROR: file: "libguilereadline-v-16", message:
> "libguilereadline-v-16.so: cannot open shared object file: No such
> file or directory"
>
> Oops ?

That doesn't look so weird to me.  The convention on Unix systems is
that you _have to_ specify at run-time a list of directories where
libraries may be searched for by the loader.

> I did not. Right now it's IMPOSSIBLE to install two versions of guile
> at all - let alone in the sane way
> (/usr/bin/guile-{1.6,1.7},/usr/lib/guile-{1.6,1.7},/usr/share/guile-{1.6,1.7}

Debian has two Guile packages that may be installed together alongside.
Guile itself would work fine.  Even `(ice-9 readline)' will work fine
thanks to the workaround above.

The only thing (admittedly important!) that may not work, though, is
other extension libraries, as we noted above.

> so I can not see how guile development is done in first place (it's
> standard practice to have 3-4 different versions of program while it's
> in developmet and guile does not work this way at all - and even if
> you'll fix guile itself third-party extensions will not obey your
> decision).

This is true.  The point is that there is apparently no sufficient
manpower to address all these issues.  In particular, I guess the
current Guile developers work hard to improve Guile itself, at the
expense of breaking binary compatibility.

Note, however, that Guile 1.6 was compatible at the source-level with
Guile 1.4 (and people were greatly encourage to drop the `gh_'
interface), and Guile 1.7 is source-level compatible with Guile 1.6 (and
it also encourage users to migrate to the new API when relevant).

Apparently, the C API of Guile 1.7 was designed to me as much
``future-proof'' as possible, given the goals that can be envisioned
today.  The internals are no longer exposed to the C user.  I'm
confident in the relative stability of this API.

> I've tried it few years ago and back then it was not really usable:
> was not able to even work with 10GiB partition. Today... It does not
> even detect my SATA HDD in my NForce4-based system. May be I've used
> too old version, of course... or did something wrong. Plus AFAIK even
> today it's still "not recommended for production use" - after >10
> years of development and I'm not really interested in OS development
> (or for that matter GUILE development): I want something that WORKS.
> NOW. It's Ok if I need to spend some time with tuning/fixing, but not
> YEARS, sorry.

Why don't you sponsor a few developers, or even just a single one?

Thanks,
Ludovic.