From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: Modified load-path proposal Date: Sat, 03 Dec 2005 13:05:12 +0000 Message-ID: <87y832l4af.fsf@ossau.uklinux.net> 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> 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 1133615602 29911 80.91.229.2 (3 Dec 2005 13:13:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2005 13:13:22 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Dec 03 14:13:21 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EiXCJ-0005bt-2W for guile-user@m.gmane.org; Sat, 03 Dec 2005 14:13:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EiXCK-0007fy-KD for guile-user@m.gmane.org; Sat, 03 Dec 2005 08:13:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EiX5w-0005Gi-5G for guile-user@gnu.org; Sat, 03 Dec 2005 08:06:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EiX5s-0005FH-VS for guile-user@gnu.org; Sat, 03 Dec 2005 08:06:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EiX5s-0005FC-Pt for guile-user@gnu.org; Sat, 03 Dec 2005 08:06:24 -0500 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EiX61-0006Di-V9 for guile-user@gnu.org; Sat, 03 Dec 2005 08:06:34 -0500 Original-Received: from laruns (host86-129-132-201.range86-129.btcentralplus.com [86.129.132.201]) by mail3.uklinux.net (Postfix) with ESMTP id 32DD8409FB4 for ; Sat, 3 Dec 2005 13:06:20 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id B46CE6F717 for ; Sat, 3 Dec 2005 13:05:12 +0000 (GMT) Original-To: guile-user@gnu.org In-Reply-To: <873bmf4ey4.fsf@laas.fr> ( =?iso-8859-1?q?Ludovic_Court=E8s's_message_of?= "Wed, 02 Nov 2005 09:44:03 +0100") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) 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:4970 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > Neil Jerram writes: > >> Sorry to have been carrying on this discussion for so long, and for >> changing direction a couple of times. If anyone is still reading, I'd >> appreciate hearing your thoughts (again). > > Just a quick note to say: > > 0. I'm still reading. ;-) Thanks. > 1. Your `init.d' approach looks very promising and simpler than the one > before, which is good. > > 2. I'd let the files in the `init.d' directory do a > `(require-load-path-directory ...)' rather than just containing the > directory name. A good reason for this is that it is anyway very > easy to evaluate those files in a confined environment > (e.g. `null-environment' + the `require-load-path-directory' > binding). OK, but aren't (1) and (2) both a bit scuppered by ... > 3. I'm a bit concerned that this approach is not scalable: opening, > reading, and evaluating say a dozen of files each time Guile is > started may have a noticeable impact on startup time. I think you're right. It makes sense to do something like this for a long-lived program such as Emacs, or for programs whose interactive performance is not a concern, such as ifup and cron. But we'd like (or at least I'd like) Guile to be used for even very quick scripts, and it doesn't make sense to increase the start up time of such scripts by unconditionally loading arbitrary startup code for whatever other Guile packages are installed. I think this rules out any kind of iteration through a .d directory from init.scm. Apologies for not seeing this consideration before. > Maybe those could be loaded lazily, for instance in > `try-module-autoload', the first time `%search-load-path' fails. This would be OK if the package startup file contained only a load path, and not arbitrary code. If the startup file was allowed to contain arbitrary code, that code would presumably be important for the initialization of the package concerned. But it would be skipped if some other circumstance meant that the package's install location was already in Guile's load path. Therefore any load-failure-based mechanism for loading startup files needs to restrict the format of the startup files to just load path directories. It also has two disadvantages in my opinion. Firstly it feels a bit magic/under the covers/non-deterministic, where I would prefer something more explicit/deterministic. Secondly it still has to unnecessarily load the startup files of all Guile packages on the system, because it has no way to map the file name or module that couldn't be loaded to a particular package. So here's yet another proposal. We keep the idea of a package installing a startup file in some directory under $sysconfdir, but we don't do anything with these in init.scm. We provide instead: -- Scheme Procedure: initialize-packages . package-names Load the startup file for each of the packages in PACKAGE-NAMES. The startup file for a given package is only loaded once per Guile run, so `initialize-packages' avoids loading a package's startup file again if it has already been loaded. If one of the named packages doesn't have a startup file, `initialize-packages' calls `package-startup-file-not-found' with the package name as the only argument. By default `package-startup-file-not-found' prints a warning to standard output, but you can `set!' it to something else if that is more appropriate for your application. The idea would be for both Guile applications and Guile modules to use this. A Guile application should know which packages it uses (directly), and so can include an appropriate `initialize-packages' call in its startup script. Similarly a Guile module knows which packages it uses, and so can call `initialize-packages' before trying to use any modules from that package. (In practice this would mean before the define-module form, but I don't see anything wrong with that. For example: (initialize-packages "guile-gtk") (define-module (ossau widgets) #:use-module (gtk gtk) ...) ) I believe this scheme works equally well whether we allow the startup file to contain arbitrary code, or we restrict it to contain just load path directories. If we chose to restrict it, we might want to rename `initialize-packages' to something more precise, such as `merge-package-load-paths'. A possible benefit of the restricted format is that I think we could write an autoconf macro (for configure.in) that would generate and install the startup file completely automatically. But perhaps we can still do that anyway with the arbitrary code format, and allow it to be overridden when the package has particular requirements. So (once again!) please let me know your thoughts. Is this at last the answer? Regards, Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user