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 n
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
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
/lib/li
On 9/27/05, Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
>
> when evaluating `(use-modules (database tmpfile))', there is exactly one
> filesystem access, the dlopen of the tmpfile.so.0.0.0; "wrapper" scheme
> code is not necessary.
>
"One filesystem access" ? This *is* joke, right ? Dlopen of
tmpfi
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
On 9/27/05, Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
>
>Hmm... And why "module catalogs" are superior ? I see one reason for
>their existence, but may be there are ones. For example I view this
>feature: "the actual placement of the file in the filesystem is
>decoupled from its m
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 ve
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 is
> NOT true for the extensions: their SO-numb
From: Vorfeed Canal <[EMAIL PROTECTED]>
Date: Mon, 26 Sep 2005 20:34:16 +0400
Hmm... And why "module catalogs" are superior ? I see one reason for
their existence, but may be there are ones. For example I view this
feature: "the actual placement of the file in the filesystem is
d
> > static void *
> > sysdep_dynl_link (const char *fname, const char *subr)
> > {
> > - lt_dlhandle handle;
> > - handle = lt_dlopenext (fname);
> > + lt_dlhandle handle = NULL;
> > + SCM scm_search_path = scm_string_join (*scm_loc_load_path,
> > +scm
Vorfeed Canal <[EMAIL PROTECTED]> writes:
> Unfortunatelly while support for XML in scheme (and guile) is
> excellent this is not the only thing needed for web-programming. I
> found some problems with GUILE core and lack of usefull modules
> (perhaps two problems are related?).
If you mean just
Hello again,
> > Your conclusion is based on your ignorance.
> >
> Possible. Care to enlighten men ?
I already did but you seem to be too eager to prove your point.
> Ok. And then why your plugin-system never loaded this main module instead ?
Because i'ts the opposite, the maim module a
On 9/26/05, Zeeshan Ali <[EMAIL PROTECTED]> wrote:
> >
> > I took a look. Conclusion: it's a mess.
>
> Your conclusion is based on your ignorance.
>
Possible. Care to enlighten men ?
> Please at least read the log yourself first, it's not (xchat-guile
> plugin-system) that guile is unable to find
Hello,
> > Yeah! and you can have a look at the source code of xchat-guile to
> > see how exactly thats done:
> > http://piipiip.net/~zeenix/xchat-guile-0.2.tar.gz
>
> I took a look. Conclusion: it's a mess.
Your conclusion is based on your ignorance.
> Why? Easy: guile.so is installed in
On 9/26/05, Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
>From: Vorfeed Canal <[EMAIL PROTECTED]>
>Date: Mon, 26 Sep 2005 11:43:59 +0400
>
>This means I'm not the only one who feel like this hardcoded path is
>not a good solution.
>
> you may be able to get guile 1.4.x[1] to do what
From: Vorfeed Canal <[EMAIL PROTECTED]>
Date: Mon, 26 Sep 2005 11:43:59 +0400
This means I'm not the only one who feel like this hardcoded path is
not a good solution.
you may be able to get guile 1.4.x[1] to do what you want. all the
compiled modules (shared object libraries followi
On 9/26/05, Zeeshan Ali <[EMAIL PROTECTED]> wrote:
> > With a full path to `load-extension' you can put a module anywhere.
> > If your code is a package in its own right then this is a good thing,
> > so you can be certain to get the right file (ie. whatever crazy
> > directory the user might have
On 9/26/05, Kevin Ryde <[EMAIL PROTECTED]> wrote:
> Vorfeed Canal <[EMAIL PROTECTED]> writes:
>
> With a full path to `load-extension' you can put a module anywhere.
But you can not give control to user then !
> If your code is a package in its own right then this is a good thing,
> so you can be
Hi,
On 9/26/05, Kevin Ryde <[EMAIL PROTECTED]> wrote:
> Vorfeed Canal <[EMAIL PROTECTED]> writes:
> >
> > 1. All C extension files can only be put in /usr/lib - there are no
> > sane way to change libtool's searchpath and there are no sane default.
> > Very annoying.
>
> With a full path to `load-
Vorfeed Canal <[EMAIL PROTECTED]> writes:
>
> 1. All C extension files can only be put in /usr/lib - there are no
> sane way to change libtool's searchpath and there are no sane default.
> Very annoying.
With a full path to `load-extension' you can put a module anywhere.
If your code is a package
20 matches
Mail list logo
