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.devel Subject: Re: Text collation Date: Mon, 23 Oct 2006 09:56:20 +0200 Organization: LAAS-CNRS Message-ID: <87wt6rxy6z.fsf@laas.fr> References: <877j00cirs.fsf@laas.fr> <87hcz3mqhr.fsf@zip.com.au> <87r6x0qjyy.fsf@laas.fr> <877iyrbxj7.fsf@raven.defaultvalue.org> 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 1161590296 28911 80.91.229.2 (23 Oct 2006 07:58:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Oct 2006 07:58:16 +0000 (UTC) Cc: Guile-Devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 23 09:58:12 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 1Gbuh4-0002M3-9z for guile-devel@m.gmane.org; Mon, 23 Oct 2006 09:57:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gbuh3-0003G1-KJ for guile-devel@m.gmane.org; Mon, 23 Oct 2006 03:57:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gbugg-0002ya-2f for guile-devel@gnu.org; Mon, 23 Oct 2006 03:57:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gbugd-0002xC-RL for guile-devel@gnu.org; Mon, 23 Oct 2006 03:57:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gbugd-0002wy-GA for guile-devel@gnu.org; Mon, 23 Oct 2006 03:57:31 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gbugd-0006Uu-Bv for guile-devel@gnu.org; Mon, 23 Oct 2006 03:57:31 -0400 Original-Received: by laas.laas.fr (8.13.7/8.13.4) with SMTP id k9N7vPco023171; Mon, 23 Oct 2006 09:57:27 +0200 (CEST) Original-To: Rob Browning X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 2 Brumaire an 215 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: Rob Browning , Guile-Devel In-Reply-To: <877iyrbxj7.fsf@raven.defaultvalue.org> (Rob Browning's message of "Sun, 22 Oct 2006 19:01:32 -0700") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id k9N7vPco023171 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:6173 Archived-At: Hi, Rob Browning writes: > ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > >> While I agree that this practically precludes use of those functions >> by C programmers (as is the case for those SRFIs that are >> implemented in C) > > Actually, if I understand you correctly, this isn't the case. The > SRFIs (which provide C interfaces) are definitely intended for use by > C programmers. The programmers just have to make sure to include the > correct -lguile-srfi-* for the SRFI in question. 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). 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. > Then the startup process should be relatively unaffected, and > ice-9/i18n.scm would just do something like this: > > (define-module (ice-9 i18n) ...) > (scm-init-i18n) 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. > This would avoid the need to make it possible to use dynamic-link for > items that are already in libguile. Of course, whether or not the > approach is a good idea is a different question. 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. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel