From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: Modified load-path proposal Date: Fri, 16 Dec 2005 10:55:49 +0100 Organization: LAAS-CNRS Message-ID: <87hd99z7q2.fsf@laas.fr> References: <878xwx5ld2.fsf@ossau.uklinux.net> <87u0fl3wam.fsf@ossau.uklinux.net> <87oe5s51l4.fsf@ivanova.rotty.yi.org> <87ek6njah0.fsf@ossau.uklinux.net> <87r7adf8h1.fsf@zip.com.au> <87vezhbknv.fsf@ossau.uklinux.net> <87u0ey3mph.fsf@ossau.uklinux.net> <873bmf4ey4.fsf@laas.fr> <87y832l4af.fsf@ossau.uklinux.net> <87irttpf2c.fsf@laas.fr> <87r78duc9d.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1134752942 22374 80.91.229.2 (16 Dec 2005 17:09:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2005 17:09:02 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Dec 16 18:09:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EnJ3e-0004ha-JX for guile-user@m.gmane.org; Fri, 16 Dec 2005 18:07:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnJ4J-0001Bx-C0 for guile-user@m.gmane.org; Fri, 16 Dec 2005 12:08:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EnCll-0007kD-L2 for guile-user@gnu.org; Fri, 16 Dec 2005 05:24:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EnCTC-0005qZ-3M for guile-user@gnu.org; Fri, 16 Dec 2005 05:06:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnCKv-0004z7-6w for guile-user@gnu.org; Fri, 16 Dec 2005 04:57:14 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EnCNJ-0002dC-OW for guile-user@gnu.org; Fri, 16 Dec 2005 04:59:42 -0500 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id jBG9uQkm004060; Fri, 16 Dec 2005 10:56:28 +0100 (CET) Original-To: Neil Jerram X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 26 Frimaire an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , guile-user@gnu.org In-Reply-To: <87r78duc9d.fsf@ossau.uklinux.net> (Neil Jerram's message of "Fri, 16 Dec 2005 00:16:46 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:4995 Archived-At: Neil Jerram writes: > How so? Given that you're about to do a (use-modules (whatnot)), I > can't see that also doing (initialize-packages "whatnot") will make a > significant difference. Because people haven't been doing so for years. Some of us certainly don't want to iterate over each and every Guile module to add this line. It's quite a big change and it's very interpreter-centric (okay, this last point is maybe not the strongest argument I could come up with ;-)). It would be different if the `initialize-packages' line could be added automatically --- in fact, `use-modules' could do it and this would be completely transparent to the module user (more below). Furthermore, other interpreters are less intrusive in that respect AFAIK. >>From a performance viewpoint, you still end up reading _and evaluating_ one more file, thus increasing actual start-up time (because chances are that 90% of the modules that will ever be loaded by a program are loaded at start-up time). > I proposed something very like this before: > http://lists.gnu.org/archive/html/guile-user/2005-10/msg00098.html > But then I changed my mind, for reasons given here: > http://lists.gnu.org/archive/html/guile-user/2005-10/msg00109.html I suspected this to have already been said. Sorry for not looking it up in the archive. > Sure, but simple is a complicated concept :-). For example, the > initialize-packages approach is simple in that it doesn't require a > post-install script to work (whereas the config.scm approach does). Right. But, well, as long as this is encapsulated in some Automake machinery, it doesn't make a big difference. > Things aren't clear cut in terms of cycles either. Suppose you have > 20 Guile packages installed on your computer, spread across 6 > different load path locations. With the config.scm approach you will > always have all 6 locations in your load path, even when running a > script that uses only one package (or no packages at all), so on > average it will take a little longer to load every file that the > script needs. With the initialize-packages approach, the script's > load path will only contain the directories that it really needs. Right. But then, an intermediate approach could consist in having an `init.d' directories where files cannot contain arbitrary code, i.e., they only contain a string (the load path). Additionally, I'd be quite happy if the `initialize-packages' phase could be made automatic. This could be done like this: 1. Packages install their module hierarchy wherever they want; 2. In addition, packages may install a start-up file in, say, /usr/share/guile/packages/ (installing these files into the right Guile directory could be done by a wrapper script, say `guile-install-module-init'). For instance, if I am to install the complete `foo' module hierarchy, then I can install /usr/share/guile/packages/foo.init that will be read, if available, the first time a `(foo SOMETHING)' module is loaded. If that file was available, its content (a string) are added to `%load-path'. More generally, when module `(foo bar)' is loaded for the first time, Guile could: 1. Look for /../packages/foo/bar.init and use its content to augment `%load-path' if available; 2. If the previous file wasn't available, look for /../packages/foo.init and use its content to augment `%load-path' if available; 3. If no `init' file was found, just leave `%load-path' unchanged. This way, `init' files are loaded on demand, like in your `initialize-packages' approach. However, it is less intrusive. This is based on the observation that (i) we want modules to be installable in *any* directory, but (ii) at some point, there must be a *fixed* directory to look for files to bootstrap further file loading. Not being able to execute arbitrary code in an init file is not a problem: anyway, once an init file has been loaded, the module itself can be loaded and execute whatever code it wants. Note that I'm not addressing shared library load paths at all here. However, such a mechanism could certainly be extended to support it. Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user