[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PHP to GUILE
From: |
Thien-Thi Nguyen |
Subject: |
Re: PHP to GUILE |
Date: |
Tue, 27 Sep 2005 08:48:54 -0400 |
From: Vorfeed Canal <address@hidden>
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 object
libraries in cron-walk (part of ttn-do)[1], and in other places, all the
time, and guile 1.4.x does not deprecate #:autoload (as far as i can
tell). for example (from cron-walk), the module `(database tmpfile)'
has this entry in ~/local/lib/guile/1.4.1.106/.module-catalog:
((database tmpfile)
scm_init_module
"scm_init_database_tmpfile_module"
() . "/home/ttn/local/lib/guile/1.4.1.106/database/tmpfile.so.0.0.0")
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.
Plus C glue code is architecture-dependent (thus must be in /usr/lib
somewhere) while scheme code is not (so it must go in /usr/share
somewhere).
all modules distributed w/ guile 1.4.x are installed in arch-dependent
dirs, in anticipation of the eventuality of scheme->sofile compilation,
thus sidestepping this problem. the point is, wherever you decide
additional modules should go, it's enough to update the module catalog
so that guile can find it. this supports local policy, which is one of
our shared concerns.
Too little: there are no supports for translators anyway
(or I'm wrong and it IS possible to write module in Logo?).
here is the entry for module (ice-9 q), in the same module catalog:
((ice-9 q)
. "/home/ttn/local/lib/guile/1.4.1.106/ice-9/q.scm")
you can see that its form differs from that of (database tmpfile).
essentially, a module's "implementation type" is one of the pieces of
metadata that is encoded in the module catalog. this means that the
system is ready to support other types. however, i will concede that
presently, the actual load operation (`load' vs `dlopen') to be used for
any particular implementation type is not yet specifiable. so i agree
halfly.
So I think for today simple search over two distinct lists (one for
architecture-dependent glue code and one for architecture-independent
scheme modules) are the best solution. Later when we'll have
translators and everything may be module catalogs will be usefull, but
not today.
is it not better to eliminate (or reduce) search? why use find(1) when
you have locate(1)?
I *AM* aware. But I think that modules catalogs are overkill for what
is awailable today and not enough for what is really needed in the
future. Thus it's better to use simpler approach: less complexity and
more-or-less the same benefits. Once we'll have loadable translators
and everything related we'll need some more complex approach.
the user pov sees no complexity:
(use-modules (ice-9 q) (database tmpfile))
complexity in implementation is another question.
And scheme code and shared object libraries are different enough to
make lumping them together rather impractical, while list and TCL are
not supported anyway - so what's the point ?
in practice (from user pov), lumping them together works fine.
the point (in this case) is to advance the guile module system while
honoring the past (as opposed to spurning it), solving its problems by
generalizing the partial solutions (of the past) and then respecializing
them to apply to new domains. when a problem is not yet solved, that's
an opportunity to hack. obviously, there is still hack potential in
supporting logo (for example).
To be frank the main part of doc is not even module system
specification and/or something like this but answer on simple question
WHY?. Why guile 1.4.1.1xx was ever developed ? Why parts of it are not
included in later versions of guile (yes, I know it's unofficial - yet
GNU Emacs does include some reimplemented extensions from XEmacs, so
it's not THE reason). I was unable to find this in documentation (or
better yet on site) so I was sure guile 1.4.1.106 is just bugfix
release for modern compilers.
i'm still working on a writeup for these (very relevant) questions. if
you're still around in spring/summer 2006 you'll probably see a post to
guile-user announcing it. if not but you think you might be interested
anyway, let me know and i will cc you.
It's my problem, right.
it is a problem/opportunity of the community and how it interacts.
Since guile 1.4 does not support some features I want/need (GOOPS and
pthreads are major ones) I can not use nice things from your
1.4.1.1xx releases.
ok, i will no longer suggest guile 1.4.x for your situation. instead i
suggest looking at the parts of it that you like and adding them in some
way or another to your methodology. see [2] for work in this vein.
thi
[1] http://www.glug.org/people/ttn/software/ttn-do/
http://www.glug.org/people/ttn/software/ttn-do/scm-html/cron-walk.scm.html.gz
[2] http://www.glug.org/people/ttn/software/guile-sdl/GUILE-FIXES
- Re: PHP to GUILE, (continued)
Re: PHP to GUILE, Vorfeed Canal, 2005/09/26
- Re: PHP to GUILE, Thien-Thi Nguyen, 2005/09/26
- Message not available
- Re: PHP to GUILE, Vorfeed Canal, 2005/09/26
- Re: PHP to GUILE, Thien-Thi Nguyen, 2005/09/26
- Re: PHP to GUILE, Vorfeed Canal, 2005/09/27
- Re: PHP to GUILE,
Thien-Thi Nguyen <=
- Re: PHP to GUILE, Vorfeed Canal, 2005/09/27
- Re: PHP to GUILE, Thien-Thi Nguyen, 2005/09/27
- Re: PHP to GUILE, Vorfeed Canal, 2005/09/27
- Re: PHP to GUILE, Thien-Thi Nguyen, 2005/09/27
Exceptions, Ludovic Courtès, 2005/09/26