Hi,
Vorfeed Canal [EMAIL PROTECTED] writes:
But what about GUILE extensions written in C ? Lack of sane
place to put C glue libraries bothers me.
Extension libraries written in C can also be thought of as actual
libraries (for example, they may export C functions that wrap/unwrap
Scheme
On 9/27/05, Kevin Ryde [EMAIL PROTECTED] wrote:
Vorfeed Canal [EMAIL PROTECTED] writes:
I'm not talking about GUILE libraries. I'm talking about EXTENSIONS
libraries. While GUILE libraries for different versions of GUILE can
happily live in /usr/lib (they have different API versions) this
From: Vorfeed Canal [EMAIL PROTECTED]
Date: Tue, 27 Sep 2005 14:11:47 +0400
Too much: we have two distinct things - stand-alone scheme modules
and non-stand-alone C glue code (:autoload is deprecated,
rememeber?).
i'm afraid i can't share in this we. i use standalone shared
Hello,
Vorfeed Canal [EMAIL PROTECTED] 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
From: Vorfeed Canal [EMAIL PROTECTED]
Date: Tue, 27 Sep 2005 18:36:33 +0400
One filesystem access ? This *is* joke, right ? Dlopen of
tmpfile.so.0.0.0 is FAR from being one filesystem access! You will
need access to /lib/ld-linux.so.2 anyway and then it'll check for
On 9/27/05, Thien-Thi Nguyen [EMAIL PROTECTED] wrote:
compiling scheme to native is part of the original vision. i don't know
what scheduled means, but i know that i'm personally interested in it
and that it is not out of my reach technically. on the other hand, i'm
never sure about other
From: Vorfeed Canal [EMAIL PROTECTED]
Date: Tue, 27 Sep 2005 21:47:26 +0400
Ok, I still think this message-catalogs idea is needlessly complex,
but we can agree to disagree on that issue.
ok. i agree to disagree.
I think that your solution is too complex for today's needs and
