From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Text collation Date: Tue, 24 Oct 2006 01:37:48 -0700 Message-ID: <87ac3m2joj.fsf@raven.defaultvalue.org> References: <877j00cirs.fsf@laas.fr> <87hcz3mqhr.fsf@zip.com.au> <87r6x0qjyy.fsf@laas.fr> <877iyrbxj7.fsf@raven.defaultvalue.org> <87wt6rxy6z.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1161679464 25897 80.91.229.2 (24 Oct 2006 08:44:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Oct 2006 08:44:24 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 24 10:44:22 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GcHtR-000223-La for guile-devel@m.gmane.org; Tue, 24 Oct 2006 10:44:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcHtR-0004l9-2N for guile-devel@m.gmane.org; Tue, 24 Oct 2006 04:44:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GcHnG-0001Yw-GT for guile-devel@gnu.org; Tue, 24 Oct 2006 04:37:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GcHnD-0001VJ-Bk for guile-devel@gnu.org; Tue, 24 Oct 2006 04:37:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcHnD-0001Uv-4E for guile-devel@gnu.org; Tue, 24 Oct 2006 04:37:51 -0400 Original-Received: from [70.85.129.156] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GcHnD-00017v-10 for guile-devel@gnu.org; Tue, 24 Oct 2006 04:37:51 -0400 Original-Received: from omen.defaultvalue.org (localhost [127.0.0.1]) by defaultvalue.org (Postfix) with ESMTP id 315D090DDF for ; Tue, 24 Oct 2006 01:37:49 -0700 (PDT) Original-Received: from raven.defaultvalue.org (raven.defaultvalue.org [192.168.1.7]) by omen.defaultvalue.org (Postfix) with ESMTP id DD360340AA for ; Tue, 24 Oct 2006 01:37:48 -0700 (PDT) Original-Received: by raven.defaultvalue.org (Postfix, from userid 1000) id C7F9F127003; Tue, 24 Oct 2006 01:37:48 -0700 (PDT) Original-To: Guile-Devel User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6174 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > I don't think this is actually the case: there are currently 4 > shared libraries in the `srfi' directory, but none of them is > documented in the manual and the C functions they export are not > mentioned either (that's what I meant by "practically preclude": > it's technically possible to use them but it's not documented). Actually, in general, the SRFI scm_* functions are intended for public use. If not, then all of the relevant scm_* functions would/should have been named scm_i_*. Also, you definitely can't judge by the presence or lack of documentation. Guile's documentation has often taken a while to catch up with the code. (BTW, does documentation snarfing work right for C functions in libraries outside libguile? If not, then that's just a bug.) > I would expect it to be done on purpose: For instance, the contents > of `libguile-srfi-srfi-1' changed noticeably as some functions were > rewritten in C and this is not something we want users to be aware > of. Note that when Marius moved the SRFI-13 and SRFI-14 functions to libguile, he still kept the C library for backward compatibility. I believe this was specifically so that people who were already using those functions wouldn't be affected. > Yes, I'm open to that if we consider it a better option than having > another shared lib. > > The issue, IMO, is that this is not very "scalable" either: we still > end up adding one function call in `scm_i_init_guile ()' that > systematically gets in the way. I'm actually not sure which (of the discussed approaches) I think is best. I suppose first we'd need to consider the extent to which we want to move toward a more modular ice-9 (more modular core), and then determine how we might want to implement that modularity. > Right. What I had in mind was to have, say, `(dynamic-link)' (with > no arguments) translate to `lt_dlopen (NULL)', so that we could > access symbols contained within the executable. Now, I'm not sure > this would work in all cases, for instance when the executable is > not `guile' itself. Well, if we wanted to take this approach, and if lt_dlopen(NULL) wouldn't do what was intended, perhaps there is some other way to accomplish the same thing (i.e. to make sure you get the current libguile.so), but I don't know offhand. --=20 Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 7= 3A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel