guile-user
[Top][All Lists]
Advanced

[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 13:13:55 -0400

   From: Vorfeed Canal <address@hidden>
   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/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.

i suppose "understatement" is more appropriate than "joke" for "one
filesystem access"; i don't count things outside guile's direct control.

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

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

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

there is a tool to update the catalog.  the format is documented, so you
can even write your own tool if that fits in better w/ your methodology.

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

that is a nice way to think about things in the abstract.  i suppose if
the system exists and it works in practice, that is another nice way to
look at it.

   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 ?

i don't really know what "first" you are referring to here, but the code
is similar to the QUICK-START script from the Guile-SDL distribution dir.
you can try that out to see how things go.

   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 think you're missing the point: for files that don't move a lot (like
installed modules) caching the module name to filesystem location
mapping is an overall win.  if your installed modules move a lot, you
need a system where caching is easy to update and/or disable.  if you
judge the system by other criteria (such as implementation complexity),
you are allowing yourself to be distracted.

   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 ?

the short answer is: "make install".  for examples, please see
Makefile.am files in Guile-SDL and Guile-PG, as well as guile 1.4.x
top-level Makefile.am.

   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.

when you are forced to repeat a process, it behooves you to codify it.
when you have community 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's more social problem then technical one, but this is type
   of problem I'd like to avoid by switching from PHP to GUILE.

switching to guile will not help you avoid these problems. 

   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.

good or bad, guile 1.4.x is useful to me.  i hope it or parts of it can
be useful to you, but i cannot help you further than describing my own
thought processes as i believe them to coincide w/ yours.

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

how it will do you good is hard to predict.  it depends on your ability
to empathize as well as your ability to analyze what is there and to
realize what is not.

thi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]