Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Thien-Thi Nguyen <address@hidden> 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
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/libc.so.6 and so on - complex and not-so-fast process. You've
optimized minor part of the whole process (scan over few directories)
- even if you'll somehow optimize it totally away the whole process
will not be significally faster. And if you really need this last
5-10% of speed guile is wrong choice anyway.

>    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.

Is this scheme->sofile scheduled already ? Are we actully SURE it will
actually happen someday ? Who and when will write this thing ? If we
are not sure then all this conglomeration have a simple name:
premature optimization. And "premature optimization is the root of all
evil" (Donald E. Knuth).

> the point is, wherever you decide additional modules should go, it's enough
> to update the module catalog so that guile can find it.

Who or what will update the catalog ? What is the guarantee that
catalog will be kept in updated state ? Is it similar to tetex where
you can put file in /usr/share/texmf/tex directory and it'll be
happily ignored unless you'll rerun some obscure program ? This is
prime candidte for the "most hated misfeature of tetex" award in my
eyes...

> this supports local policy, which is one of our shared concerns.

It violates KISS and IMHO this is bigger problem."Keep solution as
simple as possible, but not simpler".

GUILE 1.7.2 fails the second part, no doubt about it (i.e.: this
solution is too simple thus does not really solve the problem):

$ ./configure --prefix=/somewhere/there ; make ; make install
$ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
ERROR: In procedure dynamic-link:
ERROR: file: "libguilereadline-v-16", message:
"libguilereadline-v-16.so: cannot open shared object file: No such
file or directory"

The question is: does your solution fail the first ?

> is it not better to eliminate (or reduce) search?  why use find(1) when
> you have locate(1)?
>
Funny for you to offer this anology. This is from my system:
-- cut --
$ man locate ; man slocate
No manual entry for locate
No manual entry for slocate
-- cut --
I'm using equery(1) and find(1) quite often, though. The first one
does answer the question: "where is this file MUST be?", the second
one "where is this file is NOW?" while locate answer the question
"where was this file 12 hours ago?" - and this is the question I
rarely (if ever) need to ask myself.

VFS *already* includes cache for filesystem (yes - both false
positives AND false negatives are cached), I do not need another one -
especially manually maintained one. I've seen A LOT OF such systems
(Tomcat, tetex, etc, etc). In 9 out of 10 cases speedup in negligible
while consistency problems are very real.

>    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.
>
No so fast. WHO is writing this entries:
-- cut --
((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")
-- cut --
And when ? Who will change this entry from tmpfile.so.0.0.0 to
tmpfile.so.1.0.0 after API change ?

> 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.
>
Argh. I can hack my way around perfectly fine (my first mail 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 technical one,
but this is type of problem I'd like to avoid by switching from PHP to
GUILE. I do not like to see situation where "this thing works only
with PHP 4.4.0 but not with PHP 5.0 while that thing is not compatible
with PHP 5.0.0-5.0.4 but still other thing requires PHP 5.0.5". In
this light guile 1.4.1.1xx is VERY bad: it looks like we have
"official GUILE", then TTN GUILE, also there will be Vorfeed-GUILE (if
I'll decide to keep my own hack for my own use) and so on. Not a
pretty sight.

> [2] http://www.glug.org/people/ttn/software/guile-sdl/GUILE-FIXES
>
Now I'm officially confused. I've dowhnloaded
guile-1.6-missing-tools.tar.gz. Ok. Now I can produce "module
catalogs" (this is exactly what I want to avoid, but Ok) - yet there
are no way to actually USE them ? What good will it do for me ? Guile
still will load libraries from /lib and /usr/lib only and I still can
not keep libraries for two versions of guile in different places...