[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Text collation
From: |
Rob Browning |
Subject: |
Re: Text collation |
Date: |
Tue, 24 Oct 2006 01:37:48 -0700 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
address@hidden (Ludovic Courtès) 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.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
- Re: Text collation, Ludovic Courtès, 2006/10/22
- Re: Text collation, Rob Browning, 2006/10/22
- Re: Text collation, Ludovic Courtès, 2006/10/23
- Re: Text collation,
Rob Browning <=
- Re: Text collation, Ludovic Courtès, 2006/10/25
- Re: Text collation, Rob Browning, 2006/10/25
- Re: Text collation, Neil Jerram, 2006/10/25
- Re: Text collation, Rob Browning, 2006/10/25
- Re: Text collation, Ludovic Courtès, 2006/10/26
- Re: Text collation, Neil Jerram, 2006/10/25
- Re: Text collation, Rob Browning, 2006/10/25
Re: Text collation, Neil Jerram, 2006/10/25