unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: ludovic.courtes@laas.fr (Ludovic Courtès)
Cc: guile-user@gnu.org
Subject: Re: Modified load-path proposal
Date: Tue, 13 Dec 2005 09:38:19 +0100	[thread overview]
Message-ID: <87irttpf2c.fsf@laas.fr> (raw)
In-Reply-To: <87y832l4af.fsf@ossau.uklinux.net> (Neil Jerram's message of "Sat, 03 Dec 2005 13:05:12 +0000")

Hi Neil,

Sorry for the delay in answering your proposal.

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

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

Thanks,
Ludovic.


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


  reply	other threads:[~2005-12-13  8:38 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-13 18:21 Modified load-path proposal Neil Jerram
2005-10-13 18:40 ` Greg Troxel
2005-10-13 22:08   ` Neil Jerram
2005-10-14  0:37     ` Greg Troxel
2005-10-14  1:28       ` Andreas Rottmann
2005-10-15 11:17         ` Neil Jerram
2005-10-15 15:03           ` Greg Troxel
2005-10-15 17:53             ` Neil Jerram
2005-10-22 23:16           ` Kevin Ryde
2005-10-28 17:45             ` Neil Jerram
2005-10-30 18:04               ` Neil Jerram
2005-10-30 18:15                 ` Tomas Zerolo
2005-10-30 20:37                 ` Thien-Thi Nguyen
2005-10-30 22:59                   ` Neil Jerram
2005-10-31 10:55                     ` Thien-Thi Nguyen
2005-10-31 19:22                       ` Neil Jerram
2005-11-08 12:37                         ` Thien-Thi Nguyen
2005-10-31 13:17                   ` Tomas Zerolo
2005-10-30 23:48                 ` Kevin Ryde
2005-10-31 13:20                   ` Tomas Zerolo
2005-10-31 19:20                   ` Neil Jerram
2005-10-31 23:54                     ` Kevin Ryde
2005-11-12  9:47                       ` Neil Jerram
2005-11-01 23:31                     ` Vorfeed Canal
2005-11-12 17:54                       ` Neil Jerram
2005-11-02  8:44                 ` Ludovic Courtès
2005-12-03 13:05                   ` Neil Jerram
2005-12-13  8:38                     ` Ludovic Courtès [this message]
2005-12-16  0:16                       ` Neil Jerram
2005-12-16  1:00                         ` Neil Jerram
2005-12-16  9:55                         ` Ludovic Courtès
2006-01-07 13:37                           ` Neil Jerram
2006-01-11  4:49                             ` steve tell
2006-01-12 18:01                               ` Neil Jerram
2005-10-15 11:24       ` Neil Jerram
2005-10-15 15:01         ` Greg Troxel
2005-10-15 17:49           ` Neil Jerram
2005-10-14  7:24 ` Ludovic Courtès
2005-10-15 11:55   ` Neil Jerram
2005-10-15 15:40     ` Greg Troxel
2005-10-17  8:04       ` Ludovic Courtès
2005-10-17 17:52         ` Greg Troxel
2005-10-18  8:23           ` Search path for C libraries Ludovic Courtès
2005-10-18 10:12             ` Vorfeed Canal
2005-10-17 17:54         ` Modified load-path proposal Neil Jerram
2005-10-18  7:57           ` Ludovic Courtès
2005-10-19 22:30             ` Neil Jerram
2005-10-20  7:56               ` Vorfeed Canal
2005-10-20  8:05               ` Ludovic Courtès
2005-10-20 22:23                 ` Neil Jerram
2005-10-21  7:59                   ` Ludovic Courtès
2005-10-17 18:10       ` Neil Jerram
2005-10-18 16:16         ` Greg Troxel
2005-10-18 21:24           ` Vorfeed Canal
2005-10-19 22:29           ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87irttpf2c.fsf@laas.fr \
    --to=ludovic.courtes@laas.fr \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).