Re: Modified load-path proposal

[Neil Jerram <neil@ossau.uklinux.net>]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Neil Jerram <neil@ossau.uklinux.net> 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...

Good, thanks.

>>  -- Scheme Procedure: initialize-packages . package-names [...]
>
> 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.

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.

> 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?

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

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

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

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.

Does that sway you at all?  Anyone else?

     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user