[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modified load-path proposal

From: Ludovic Courtès
Subject: Re: Modified load-path proposal
Date: Tue, 13 Dec 2005 09:38:19 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Hi Neil,

Sorry for the delay in answering your proposal.

Neil Jerram <address@hidden> writes:

> I think this rules out any kind of iteration through a .d directory
> from init.scm.  Apologies for not seeing this consideration before.

Agreed.  Guile already takes almost two seconds to start up on my
500 MHz G4...

>  -- 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)
>     ...)
> )

Hmm, I don't like it a lot, I find it way too intrusive.  And this may
also have a slight impact on startup time.

Maybe we could instead go for an ad hoc solution.  For instance, have
Guile provide a `guile-setup' program which could be used as follows:

  $ guile-setup add-load-path "/usr/chbouib/guile/"
  $ guile-setup remove-load-path "/usr/local/share/guile/smurf"

In practice, this would modify a single (text) file, say,
`$data/load-paths.cfg'.  This very file would be loaded when Guile is
started, modifying `%load-path' accordingly.  Autoconf macros would make
sure that `guile-setup add-load-path' is called upon installation of a
Guile package.

For efficiency reason, this file should be text-only (e.g., one load
path per line), or it could be more Scheme-friendly (e.g., a sequence of
RnRS strings which may be read by `read').  It should not require any
call to `eval'.

What do you think?

This is certainly not perfect but I think we must strive (i) to keep
things simple and (ii) to avoid wasting more cycles.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]