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 08:48:54 -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> Reply-To: ttn@glug.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1127828946 9141 80.91.229.2 (27 Sep 2005 13:49:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 13:49:06 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 27 15:48:57 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKFpD-0008LJ-Cs for guile-user@m.gmane.org; Tue, 27 Sep 2005 15:48:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKFpB-0001EL-6Q for guile-user@m.gmane.org; Tue, 27 Sep 2005 09:48:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKEyC-0006lG-Bk for guile-user@gnu.org; Tue, 27 Sep 2005 08:54:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKEy7-0006hf-Fn for guile-user@gnu.org; Tue, 27 Sep 2005 08:54:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKExi-0006Au-UW for guile-user@gnu.org; Tue, 27 Sep 2005 08:53:35 -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 1EKEta-0008FK-48 for guile-user@gnu.org; Tue, 27 Sep 2005 08:49:18 -0400 Original-Received: from ttn by mail.agora-net.com with local (Exim 4.34) id 1EKEtC-0004Lf-72; Tue, 27 Sep 2005 08:48:54 -0400 Original-To: vorfeed.canal@gmail.com In-reply-to: <6efab235050927031160fe348a@mail.gmail.com> (message from Vorfeed Canal on Tue, 27 Sep 2005 14:11:47 +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:4788 Archived-At: From: Vorfeed Canal 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 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user