From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: Exceptions Date: Tue, 27 Sep 2005 17:45:07 +0200 Organization: LAAS-CNRS Message-ID: <874q86qzuk.fsf@laas.fr> References: <6efab235050925145055ba774c@mail.gmail.com> <873bns2f26.fsf@laas.fr> <6efab2350509261220665afe20@mail.gmail.com> <87br2ezyth.fsf@laas.fr> <6efab235050927035441b39b85@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1127837407 6749 80.91.229.2 (27 Sep 2005 16:10:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 16:10:07 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 27 18:10:04 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKI0f-000890-N8 for guile-user@m.gmane.org; Tue, 27 Sep 2005 18:08:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKI0e-0002Gm-Vq for guile-user@m.gmane.org; Tue, 27 Sep 2005 12:08:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKHzM-0001Xp-NU for guile-user@gnu.org; Tue, 27 Sep 2005 12:07:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKHzL-0001WQ-1F for guile-user@gnu.org; Tue, 27 Sep 2005 12:07:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKHxQ-0000I6-Q2 for guile-user@gnu.org; Tue, 27 Sep 2005 12:05:28 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EKHfE-0000O7-UH for guile-user@gnu.org; Tue, 27 Sep 2005 11:46:41 -0400 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id j8RFkalU024068; Tue, 27 Sep 2005 17:46:37 +0200 (CEST) Original-To: Vorfeed Canal X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 6 =?iso-8859-1?Q?Vend=E9miaire?= an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Vorfeed Canal , guile-user@gnu.org In-Reply-To: <6efab235050927035441b39b85@mail.gmail.com> (Vorfeed Canal's message of "Tue, 27 Sep 2005 14:54:21 +0400") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4790 Archived-At: Hello, Vorfeed Canal 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. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user