From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: PHP to GUILE Date: Tue, 27 Sep 2005 13:13:55 -0400 Message-ID: References: <6efab235050925145055ba774c@mail.gmail.com> <87ll1k61w4.fsf@zip.com.au> <6efab235050926004326d03d6a@mail.gmail.com> <6efab23505092609331abd82b7@mail.gmail.com> <6efab2350509260934639fcc59@mail.gmail.com> <6efab235050927031160fe348a@mail.gmail.com> <6efab23505092707369aa72e5@mail.gmail.com> Reply-To: ttn@glug.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1127842302 23348 80.91.229.2 (27 Sep 2005 17:31:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 17:31:42 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 27 19:31:41 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKJFb-0006Lc-HK for guile-user@m.gmane.org; Tue, 27 Sep 2005 19:28:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKJFa-0002h1-Jb for guile-user@m.gmane.org; Tue, 27 Sep 2005 13:28:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKJFK-0002Za-4H for guile-user@gnu.org; Tue, 27 Sep 2005 13:28:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKJ9t-0001KU-4v for guile-user@gnu.org; Tue, 27 Sep 2005 13:22:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKJ9l-0001Cz-Pj for guile-user@gnu.org; Tue, 27 Sep 2005 13:22:18 -0400 Original-Received: from [207.245.121.137] (helo=mail.agora-net.com) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1EKJ1w-0007cM-NR for guile-user@gnu.org; Tue, 27 Sep 2005 13:14:12 -0400 Original-Received: from ttn by mail.agora-net.com with local (Exim 4.34) id 1EKJ1f-00069z-51; Tue, 27 Sep 2005 13:13:55 -0400 Original-To: vorfeed.canal@gmail.com In-reply-to: <6efab23505092707369aa72e5@mail.gmail.com> (message from Vorfeed Canal on Tue, 27 Sep 2005 18:36:33 +0400) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4793 Archived-At: From: Vorfeed Canal 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 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user