From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vorfeed Canal Newsgroups: gmane.lisp.guile.user Subject: Re: PHP to GUILE Date: Tue, 27 Sep 2005 18:36:33 +0400 Message-ID: <6efab23505092707369aa72e5@mail.gmail.com> 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> Reply-To: Vorfeed Canal NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1127832336 20823 80.91.229.2 (27 Sep 2005 14:45:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 14:45:36 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 27 16:45:33 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKGeS-0002OU-Jc for guile-user@m.gmane.org; Tue, 27 Sep 2005 16:41:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKGeR-0003zF-TM for guile-user@m.gmane.org; Tue, 27 Sep 2005 10:41:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKGd6-0003gg-T0 for guile-user@gnu.org; Tue, 27 Sep 2005 10:40:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKGcw-0003aw-Qc for guile-user@gnu.org; Tue, 27 Sep 2005 10:40:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKGcv-0003Yf-Dq for guile-user@gnu.org; Tue, 27 Sep 2005 10:40:13 -0400 Original-Received: from [72.14.204.194] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EKGZP-0001oA-3Z for guile-user@gnu.org; Tue, 27 Sep 2005 10:36:35 -0400 Original-Received: by qproxy.gmail.com with SMTP id e14so290333qbc for ; Tue, 27 Sep 2005 07:36:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gcBEdwBMoiJtumwu+MoifQ0qiccWF5Gu0z8c6sefRMioPnj7U6VA9IU71AcHjKO2dAmez6n4O1HqGSfkOH08RzTXznJnqpwNHfq+BadNRu4306a8HCSryi6AtVXf1SNEIzse6P7UA+IXDIGMjTLqOMQMffQxyTCq9SwlLh4vJtQ= Original-Received: by 10.65.123.7 with SMTP id a7mr270161qbn; Tue, 27 Sep 2005 07:36:34 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Tue, 27 Sep 2005 07:36:33 -0700 (PDT) Original-To: guile-user@gnu.org In-Reply-To: Content-Disposition: inline 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:4789 Archived-At: On 9/27/05, Thien-Thi Nguyen 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 enou= gh > 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=3D/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... _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user