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
ty spirit, it's nice to share your code. these are
the things i have done (i feel your pain, really!) and that you probably
will need to do to some extent. why? if you have no giant's shoulders
to stand on, that is an opportunity for you to become a giant yourself.
I agree it
ail to
mailing list contained working patch, after all - somewhat limited
"proof of concept" yet working). But then I'll be forced to repeat the
process for each and every extension I'll ever use! And THIS is what I
want to avoid. I agree it's more social problem then technica
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
After latest PHP fiasco (when "maintenance release" PHP 5.0.5 broke
most PHP programs) I decided that "enough is enough - I need to change
language for future projects".
I've checked with few alternatives and found that I like SXML better
then other packages (Perl, Python, etc). Thus GUILE - it's
21 matches
Mail list logo
