add-relative-load-path ?

add-relative-load-path ?

[Andy Wingo]

Hi all,

In the following thread:

  http://thread.gmane.org/gmane.lisp.guile.user/8298/focus=8403

there was a concern that it's difficult to set up the load path for
simple one-off scripts.

I had a proposal that we add something like this:

   (define-syntax add-relative-load-path
     (lambda (x)
       (syntax-case x ()
         ((_ path) (string? (syntax->datum #'path))
          (let* ((src (syntax-source #'x))
                 (current-file (or (and src (assq-ref src 'filename))
                                   (error "Could not determine current file name")))
                 (vicinity (dirname (canonicalize-path current-file)))
                 (path-elt (in-vicinity vicinity (syntax->datum #'path))))
            #`(eval-when (compile load eval)
                (set! %load-path (cons #,path-elt %load-path))))))))

Then in your script you would (add-relative-load-path ".").

Maybe we need an `add-to-load-path' form that handles the eval-when,
actually, so it would be

  (add-to-load-path (dirname (current-source-filename)))

or something like that.  (We'd have to define current-source-filename as
well, in terms of current-source-location.)

What do folks think?  Is it work it?

Andy
-- 
http://wingolog.org/

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Then in your script you would (add-relative-load-path ".").
>
> Maybe we need an `add-to-load-path' form that handles the eval-when,
> actually, so it would be
>
>   (add-to-load-path (dirname (current-source-filename)))
>
> or something like that.  (We'd have to define current-source-filename as
> well, in terms of current-source-location.)
>
> What do folks think?  Is it work it?

Yes, I think so!  I think it will be a great help for uninstalled
experimentation.

I can think of a couple of plausible enhancements:

(1) factoring out any occurrences of "/x/.." and "/." in the directory
that results from the in-vicinity call

(2) only adding the directory to the load path if it isn't already
there.

But neither of those is crucial.

Of the possibilities above, I think I prefer

>   (add-to-load-path (dirname (current-source-filename)))

Thanks for thinking about this.

       Neil

Re: add-relative-load-path ?

[Andy Wingo]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

Hi Neil,

On Sat 14 Jan 2012 22:48, Neil Jerram <neil@ossau.homelinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
> Of the possibilities above, I think I prefer
>
>>   (add-to-load-path (dirname (current-source-filename)))

Done.  Actually I called it "current-filename", so it would be:

  (add-to-load-path (dirname (current-filename)))

Feedback is very welcome -- especially timely feedback; it would be nice
to release on Monday or so.  I'm attaching the patch (already committed)
to make it easy for you :)

Regards,

Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-add-current-filename-add-to-path-add-to-load-path.patch --]
[-- Type: text/x-diff, Size: 14310 bytes --]

From 925172cf529a89f0c5fd81720718971f9059fcfd Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@pobox.com>
Date: Sat, 21 Jan 2012 00:08:17 +0100
Subject: [PATCH] add current-filename, add-to-path, add-to-load-path

* module/ice-9/boot-9.scm (current-filename, add-to-path)
  (add-to-load-path): New syntaxen.

* doc/ref/api-evaluation.texi (Loading): Move load-path related
  procedures to a new section:
  (Load Paths): Hither.  Document add-to-path and add-to-load-path.

* doc/ref/api-debug.texi (Source Properties): Document
  current-source-location and current-filename.

* doc/ref/api-modules.texi:
* doc/ref/guile-invoke.texi:
* doc/ref/scheme-using.texi: Update @ref for Load Paths change.
---
 doc/ref/api-debug.texi      |   21 +++++++-
 doc/ref/api-evaluation.texi |  125 +++++++++++++++++++++++++++----------------
 doc/ref/api-modules.texi    |    2 +-
 doc/ref/guile-invoke.texi   |    2 +-
 doc/ref/scheme-using.texi   |    4 +-
 module/ice-9/boot-9.scm     |   21 +++++++
 6 files changed, 124 insertions(+), 51 deletions(-)

diff --git a/doc/ref/api-debug.texi b/doc/ref/api-debug.texi
index bdb6166..2083daa 100644
--- a/doc/ref/api-debug.texi
+++ b/doc/ref/api-debug.texi
@@ -1,6 +1,6 @@
 @c -*-texinfo-*-
 @c This is part of the GNU Guile Reference Manual.
-@c Copyright (C)  1996, 1997, 2000, 2001, 2002, 2003, 2004, 2007, 2010, 2011
+@c Copyright (C)  1996, 1997, 2000, 2001, 2002, 2003, 2004, 2007, 2010, 2011, 2012
 @c   Free Software Foundation, Inc.
 @c See the file guile.texi for copying conditions.
 
@@ -292,6 +292,25 @@ If the @code{positions} reader option is enabled, each parenthesized
 expression will have values set for the @code{filename}, @code{line} and
 @code{column} properties.
 
+Source properties are also associated with syntax objects.  Procedural
+macros can get at the source location of their input using the
+@code{syntax-source} accessor.  @xref{Syntax Transformer Helpers}, for
+more.
+
+Guile also defines a couple of convenience macros built on
+@code{syntax-source}:
+
+@deffn {Scheme Syntax} current-source-location
+Expands to the source properties corresponding to the location of the
+@code{(current-source-location)} form.
+@end deffn
+
+@deffn {Scheme Syntax} current-filename
+Expands to the current filename: the filename that the
+@code{(current-filename)} form appears in.  Expands to @code{#f} if this
+information is unavailable.
+@end deffn
+
 If you're stuck with defmacros (@pxref{Defmacros}), and want to preserve
 source information, the following helper function might be useful to
 you:
diff --git a/doc/ref/api-evaluation.texi b/doc/ref/api-evaluation.texi
index 2e48dcb..ed3b88c 100644
--- a/doc/ref/api-evaluation.texi
+++ b/doc/ref/api-evaluation.texi
@@ -17,6 +17,7 @@ loading, evaluating, and compiling Scheme code at run time.
 * Fly Evaluation::              Procedures for on the fly evaluation.
 * Compilation::                 How to compile Scheme files and procedures.
 * Loading::                     Loading Scheme code from file.
+* Load Paths::                  Where Guile looks for code.
 * Character Encoding of Source Files:: Loading non-ASCII Scheme code from file.
 * Delayed Evaluation::          Postponing evaluation until it is needed.
 @end menu
@@ -711,7 +712,7 @@ useful compilation warnings.  It can be customized from @file{~/.guile}.
 @rnindex load
 @deffn {Scheme Procedure} load filename [reader]
 Load @var{filename} and evaluate its contents in the top-level
-environment.  The load paths are not searched.
+environment.
 
 @var{reader} if provided should be either @code{#f}, or a procedure with
 the signature @code{(lambda (port) @dots{})} which reads the next
@@ -730,29 +731,21 @@ documentation for @code{%load-hook} later in this section.
 @end deffn
 
 @deffn {Scheme Procedure} load-compiled filename
-Load the compiled file named @var{filename}. The load paths are not
-searched.
+Load the compiled file named @var{filename}.
 
 Compiling a source file (@pxref{Read/Load/Eval/Compile}) and then
 calling @code{load-compiled} on the resulting file is equivalent to
 calling @code{load} on the source file.
 @end deffn
 
-@deffn {Scheme Procedure} load-from-path filename
-Similar to @code{load}, but searches for @var{filename} in the load
-paths. Preferentially loads a compiled version of the file, if it is
-available and up-to-date.
-@end deffn
-
 @deffn {Scheme Procedure} primitive-load filename
 @deffnx {C Function} scm_primitive_load (filename)
-Load the file named @var{filename} and evaluate its contents in
-the top-level environment. The load paths are not searched;
-@var{filename} must either be a full pathname or be a pathname
-relative to the current directory.  If the  variable
-@code{%load-hook} is defined, it should be bound to a procedure
-that will be called before any code is loaded.  See the
-documentation for @code{%load-hook} later in this section.
+Load the file named @var{filename} and evaluate its contents in the
+top-level environment.  @var{filename} must either be a full pathname or
+be a pathname relative to the current directory.  If the variable
+@code{%load-hook} is defined, it should be bound to a procedure that
+will be called before any code is loaded.  See the documentation for
+@code{%load-hook} later in this section.
 @end deffn
 
 @deftypefn {C Function} SCM scm_c_primitive_load (const char *filename)
@@ -760,33 +753,6 @@ documentation for @code{%load-hook} later in this section.
 @code{SCM}.
 @end deftypefn
 
-@deffn {Scheme Procedure} primitive-load-path filename [exception-on-not-found]
-@deffnx {C Function} scm_primitive_load_path (filename)
-Search @code{%load-path} for the file named @var{filename} and
-load it into the top-level environment.  If @var{filename} is a
-relative pathname and is not found in the list of search paths,
-an error is signalled. Preferentially loads a compiled version of the
-file, if it is available and up-to-date.
-
-By default or if @var{exception-on-not-found} is true, an exception is
-raised if @var{filename} is not found.  If @var{exception-on-not-found}
-is @code{#f} and @var{filename} is not found, no exception is raised and
-@code{#f} is returned.  For compatibility with Guile 1.8 and earlier,
-the C function takes only one argument, which can be either a string
-(the file name) or an argument list.
-@end deffn
-
-@deffn {Scheme Procedure} %search-load-path filename
-@deffnx {C Function} scm_sys_search_load_path (filename)
-Search @code{%load-path} for the file named @var{filename},
-which must be readable by the current user.  If @var{filename}
-is found in the list of paths to search or is an absolute
-pathname, return its full pathname.  Otherwise, return
-@code{#f}.  Filenames may have any of the optional extensions
-in the @code{%load-extensions} list; @code{%search-load-path}
-will try each extension automatically.
-@end deffn
-
 @defvar current-reader
 @code{current-reader} holds the read procedure that is currently being
 used by the above loading procedures to read expressions (from the file
@@ -814,9 +780,9 @@ change occurs at the right time.
 @defvar %load-hook
 A procedure to be called @code{(%load-hook @var{filename})} whenever a
 file is loaded, or @code{#f} for no such call.  @code{%load-hook} is
-used by all of the above loading functions (@code{load},
-@code{load-path}, @code{primitive-load} and
-@code{primitive-load-path}).
+used by all of the loading functions (@code{load} and
+@code{primitive-load}, and @code{load-path} and
+@code{primitive-load-path} documented in the next section).
 
 For example an application can set this to show what's loaded,
 
@@ -834,6 +800,72 @@ Return the current-load-port.
 The load port is used internally by @code{primitive-load}.
 @end deffn
 
+@node Load Paths
+@subsection Load Paths
+
+The procedure in the previous section look for Scheme code in the file
+system at specific location.  Guile also has some procedures to search
+the load path for code.
+
+For more on the @code{%load-path} variable, @xref{Build Config}.
+
+@deffn {Scheme Procedure} load-from-path filename
+Similar to @code{load}, but searches for @var{filename} in the load
+paths. Preferentially loads a compiled version of the file, if it is
+available and up-to-date.
+@end deffn
+
+A user can extend the load path by calling @code{add-to-load-path}.
+
+@deffn {Scheme Syntax} add-to-load-path dir
+Add @var{dir} to the load path.
+
+For example, a script might include this form to add the directory that
+it is in to the load path:
+
+@example
+(add-to-load-path (dirname (current-filename)))
+@end example
+@end deffn
+
+It's better to use @code{add-to-load-path} than to modify
+@code{%load-path} directly, because @code{add-to-load-path} takes care
+of modifying the path both at compile-time and at run-time.
+
+There is a more general version for use with other paths, like
+@code{%load-compiled-path}:
+
+@deffn {Scheme Syntax} add-to-path path dir
+Add @var{dir} to @var{path}.
+@end deffn
+
+@deffn {Scheme Procedure} primitive-load-path filename [exception-on-not-found]
+@deffnx {C Function} scm_primitive_load_path (filename)
+Search @code{%load-path} for the file named @var{filename} and
+load it into the top-level environment.  If @var{filename} is a
+relative pathname and is not found in the list of search paths,
+an error is signalled. Preferentially loads a compiled version of the
+file, if it is available and up-to-date.
+
+By default or if @var{exception-on-not-found} is true, an exception is
+raised if @var{filename} is not found.  If @var{exception-on-not-found}
+is @code{#f} and @var{filename} is not found, no exception is raised and
+@code{#f} is returned.  For compatibility with Guile 1.8 and earlier,
+the C function takes only one argument, which can be either a string
+(the file name) or an argument list.
+@end deffn
+
+@deffn {Scheme Procedure} %search-load-path filename
+@deffnx {C Function} scm_sys_search_load_path (filename)
+Search @code{%load-path} for the file named @var{filename},
+which must be readable by the current user.  If @var{filename}
+is found in the list of paths to search or is an absolute
+pathname, return its full pathname.  Otherwise, return
+@code{#f}.  Filenames may have any of the optional extensions
+in the @code{%load-extensions} list; @code{%search-load-path}
+will try each extension automatically.
+@end deffn
+
 @defvar %load-extensions
 A list of default file extensions for files containing Scheme code.
 @code{%search-load-path} tries each of these extensions when looking for
@@ -841,6 +873,7 @@ a file to load.  By default, @code{%load-extensions} is bound to the
 list @code{("" ".scm")}.
 @end defvar
 
+
 @node Character Encoding of Source Files
 @subsection Character Encoding of Source Files
 
diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index 9830cfd..3c96c2a 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -468,7 +468,7 @@ the @code{%load-path} (@pxref{Build Config}).  For each directory in
 @code{%load-path}, Guile will try to find the file name, concatenated
 with the extensions from @code{%load-extensions}.  By default, this will
 cause Guile to @code{stat} @file{ice-9/popen.scm}, and then
-@file{ice-9/popen}.  @xref{Loading}, for more on
+@file{ice-9/popen}.  @xref{Load Paths}, for more on
 @code{primitive-load-path}.
 
 If a corresponding compiled @file{.go} file is found in the
diff --git a/doc/ref/guile-invoke.texi b/doc/ref/guile-invoke.texi
index ccb5301..08c1698 100644
--- a/doc/ref/guile-invoke.texi
+++ b/doc/ref/guile-invoke.texi
@@ -73,7 +73,7 @@ the user's @file{.guile} file.
 
 @item -x @var{extension}
 Add @var{extension} to the front of Guile's load extension list
-(@pxref{Loading, @code{%load-extensions}}).  The specified extensions
+(@pxref{Load Paths, @code{%load-extensions}}).  The specified extensions
 are tried in the order given on the command line, and before the default
 load extensions.  Extensions added here are @emph{not} in effect during
 execution of the user's @file{.guile} file.
diff --git a/doc/ref/scheme-using.texi b/doc/ref/scheme-using.texi
index 73e1a5d..07096bb 100644
--- a/doc/ref/scheme-using.texi
+++ b/doc/ref/scheme-using.texi
@@ -750,8 +750,8 @@ The first thing to do is to install your Scheme files where Guile can
 find them.  When Guile goes to find a Scheme file, it will search a
 @dfn{load path} to find the file: first in Guile's own path, then in
 paths for @dfn{site packages}.  A site package is any Scheme code that
-is installed and not part of Guile itself.  @xref{Loading}, for more on
-load paths.
+is installed and not part of Guile itself.  @xref{Load Paths}, for more
+on load paths.
 
 There are several site paths, for historical reasons, but the one that
 should generally be used can be obtained by invoking the
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index 86ca875..3e43b8c 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -512,6 +512,18 @@ If there is no handler at all, Guile prints an error and then exits."
        (with-syntax ((s (datum->syntax x (syntax-source x))))
          #''s)))))
 
+;; We provide this accessor out of convenience.  current-line and
+;; current-column aren't so interesting, because they distort what they
+;; are measuring; better to use syntax-source from a macro.
+;;
+(define-syntax current-filename
+  (lambda (x)
+    "A macro that expands to the current filename: the filename that
+the (current-filename) form appears in.  Expands to #f if this
+information is unavailable."
+    (and=> (syntax-source x)
+           (lambda (s) (assq-ref s 'filename)))))
+
 (define-syntax-rule (define-once sym val)
   (define sym
     (if (module-locally-bound? (current-module) 'sym) sym val)))
@@ -1390,6 +1402,15 @@ VALUE."
   (start-stack 'load-stack
                (primitive-load-path name)))
 
+(define-syntax-rule (add-to-path path elt)
+  "Add ELT to PATH, at compile-time and at run-time."
+  (eval-when (compile load eval)
+    (set! path (cons elt path))))
+
+(define-syntax-rule (add-to-load-path elt)
+  "Add ELT to Guile's load path, at compile-time and at run-time."
+  (add-to-path %load-path elt))
+
 (define %load-verbosely #f)
 (define (assert-load-verbosity v) (set! %load-verbosely v))
 
-- 
1.7.8.3


[-- Attachment #3: Type: text/plain, Size: 26 bytes --]


-- 
http://wingolog.org/

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Neil,
>
> On Sat 14 Jan 2012 22:48, Neil Jerram <neil@ossau.homelinux.net> writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>> Of the possibilities above, I think I prefer
>>
>>>   (add-to-load-path (dirname (current-source-filename)))
>
> Done.  Actually I called it "current-filename", so it would be:
>
>   (add-to-load-path (dirname (current-filename)))
>
> Feedback is very welcome -- especially timely feedback; it would be nice
> to release on Monday or so.  I'm attaching the patch (already committed)
> to make it easy for you :)

Thanks!

The patch works for me, although there are a couple of points that still
make it a bit fiddly to use in practice.  It might be possible to
improve the first of those points, but I don't think anything can be
done about the second.

Thing 1 is that (current-filename) can return a relative filename, or a
filename with a "./" in its middle:

1.1: With a script called "affiche", with "#! /usr/bin/guile -s" and
which I invoke from the shell as "./affiche", (current-filename) gives
"/home/neil/q/SW/ossaulib/scripts/./affiche".  So if I do (dirname
(dirname (current-filename)), intending to get the parent directory
"/home/neil/q/SW/ossaulib", I actually get
"/home/neil/q/SW/ossaulib/scripts".

1.2: If I encapsulate the load-path logic in a separate file called
"setup-load-path.scm", and take advantage of the fact that (include
"setup-load-path.scm") will find that file in the same directory as
"affiche", (current-filename) gives just "setup-load-path.scm", and
(dirname ...) on that won't give a useful result.

Both problems are solved by adding in a canonicalize-path call.  Would
there be any downside from putting that inside current-filename, so that
current-filename always returns a canonical file name?

Alternatively, I think the use of canonicalize-path should be added into
the example in the manual.

Thing 2 is that it remains slightly inelegant to cater for both 1.8 and
2.0.  I think the minimal complete solution is to write

(cond-expand (guile-2 (include "setup-load-path.scm"))
             (else (load "setup-load-path.scm")))

at top level in every uninstalled script, and then something like

(cond-expand (guile-2
	      (add-to-load-path
	       (dirname
		(dirname
		 (canonicalize-path (current-filename))))))
	     (else
              ;; Less elegant code for 1.8...
	      (let* ((bindir (dirname (car (command-line))))
		     (absdir (cond ((string=? bindir ".")
				    (getcwd))
				   ((string-match "^/" bindir)
				    bindir)
				   (else
				    (in-vicinity (getcwd) bindir)))))
		(set! %load-path (cons (in-vicinity absdir "..")
				       %load-path)))))

in setup-load-path.scm.

But without a time machine I don't think anything can be done to make
either of those fragments more concise.

I also had just one comment on the doc:

> @@ -814,9 +780,9 @@ change occurs at the right time.
>  @defvar %load-hook
>  A procedure to be called @code{(%load-hook @var{filename})} whenever a
>  file is loaded, or @code{#f} for no such call.  @code{%load-hook} is
> -used by all of the above loading functions (@code{load},
> -@code{load-path}, @code{primitive-load} and
> -@code{primitive-load-path}).
> +used by all of the loading functions (@code{load} and
> +@code{primitive-load}, and @code{load-path} and
> +@code{primitive-load-path} documented in the next section).

[...]

> +@deffn {Scheme Procedure} load-from-path filename

Is it 'load-path' or 'load-from-path'?

Regards,
        Neil

Re: add-relative-load-path ?

[Andy Wingo]

Hi Neil,

Thanks for the feedback!

On Sun 22 Jan 2012 00:17, Neil Jerram <neil@ossau.homelinux.net> writes:

> Thing 1 is that (current-filename) can return a relative filename, or a
> filename with a "./" in its middle
[...]
>
> Would there be any downside from putting [canonicalize-path] inside
> current-filename, so that current-filename always returns a canonical
> file name?

No, and I think that is the right thing to do in this case, because it
avoids embedding assumptions about the current working directory into
compiled .go files.  I have made this change.

> Thing 2 is that it remains slightly inelegant to cater for both 1.8 and
> 2.0.  I think the minimal complete solution is to write
>
> (cond-expand (guile-2 (include "setup-load-path.scm"))
>              (else (load "setup-load-path.scm")))
>
> at top level in every uninstalled script, and then something like
>
> (cond-expand (guile-2
> 	      (add-to-load-path
> 	       (dirname
> 		(dirname
> 		 (canonicalize-path (current-filename))))))
> 	     (else
>               ;; Less elegant code for 1.8...
> 	      (let* ((bindir (dirname (car (command-line))))
> 		     (absdir (cond ((string=? bindir ".")
> 				    (getcwd))
> 				   ((string-match "^/" bindir)
> 				    bindir)
> 				   (else
> 				    (in-vicinity (getcwd) bindir)))))
> 		(set! %load-path (cons (in-vicinity absdir "..")
> 				       %load-path)))))
>
> in setup-load-path.scm.
>
> But without a time machine I don't think anything can be done to make
> either of those fragments more concise.

Well, you could instead do:

  (cond-expand ((not guile-2) (load "guile-2.0-compat.scm")))

  (add-to-load-path (dirname (dirname (current-filename))))

Then in guile-2.0-compat.scm you have shims to make guile 1.8 offer a
2.0 interface (in this case, current-filename and add-to-load-path).

>> +@code{primitive-load}, and @code{load-path} and
>
> Is it 'load-path' or 'load-from-path'?

load-from-path.  Fixed!

Thanks,

Andy
-- 
http://wingolog.org/

Re: add-relative-load-path ?

[Ludovic Courtès]

Hello!

Thanks for working on it.  :-)

Andy Wingo <wingo@pobox.com> skribis:

>   (add-to-load-path (dirname (dirname (current-filename))))

What about calling it ‘current-file-name’ instead?

Ludo’.

Re: add-relative-load-path ?

[Andy Wingo]

Hi,

On Mon 23 Jan 2012 16:45, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>>   (add-to-load-path (dirname (dirname (current-filename))))
>
> What about calling it ‘current-file-name’ instead?

  > (apropos "filename")
  (guile): set-module-filename!	#<procedure 1546f20 at ice-9/boot-9.scm:1712:2 (module val)>
  (guile): module-filename	#<procedure 1546fa0 at ice-9/boot-9.scm:1712:2 (module)>
  (guile): current-filename
  (guile): set-port-filename!	#<procedure set-port-filename! (_ _)>
  (guile): port-filename	#<procedure port-filename (_)>
  (ice-9 readline): filename-completion-function	#<procedure filename-completion-function (_ _)>
  > (apropos "file-name")
  > 

Though I am responsible for three of those, I think I was just following
established convention.

Andy
-- 
http://wingolog.org/

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi,
>
> On Mon 23 Jan 2012 16:45, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>>   (add-to-load-path (dirname (dirname (current-filename))))
>>
>> What about calling it ‘current-file-name’ instead?

I sympathise with that too, although I know I was inconsistent in my own
last email in this thread.

>   > (apropos "filename")
>   (guile): set-module-filename!	#<procedure 1546f20 at ice-9/boot-9.scm:1712:2 (module val)>
>   (guile): module-filename	#<procedure 1546fa0 at ice-9/boot-9.scm:1712:2 (module)>
>   (guile): current-filename
>   (guile): set-port-filename!	#<procedure set-port-filename! (_ _)>
>   (guile): port-filename	#<procedure port-filename (_)>
>   (ice-9 readline): filename-completion-function	#<procedure filename-completion-function (_ _)>
>   > (apropos "file-name")
>   > 
>
> Though I am responsible for three of those, I think I was just following
> established convention.

Hmm, tricky to argue with that though.

        Neil

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Neil,
>
> Thanks for the feedback!
>
> On Sun 22 Jan 2012 00:17, Neil Jerram <neil@ossau.homelinux.net> writes:
>
>> Thing 1 is that (current-filename) can return a relative filename, or a
>> filename with a "./" in its middle
> [...]
>>
>> Would there be any downside from putting [canonicalize-path] inside
>> current-filename, so that current-filename always returns a canonical
>> file name?
>
> No, and I think that is the right thing to do in this case, because it
> avoids embedding assumptions about the current working directory into
> compiled .go files.  I have made this change.

Thanks.

>> Thing 2 is that it remains slightly inelegant to cater for both 1.8 and
>> 2.0.  I think the minimal complete solution is to write
>>
>> (cond-expand (guile-2 (include "setup-load-path.scm"))
>>              (else (load "setup-load-path.scm")))
>>
>> at top level in every uninstalled script, and then something like
>>
>> (cond-expand (guile-2
>> 	      (add-to-load-path
>> 	       (dirname
>> 		(dirname
>> 		 (canonicalize-path (current-filename))))))
>> 	     (else
>>               ;; Less elegant code for 1.8...
>> 	      (let* ((bindir (dirname (car (command-line))))
>> 		     (absdir (cond ((string=? bindir ".")
>> 				    (getcwd))
>> 				   ((string-match "^/" bindir)
>> 				    bindir)
>> 				   (else
>> 				    (in-vicinity (getcwd) bindir)))))
>> 		(set! %load-path (cons (in-vicinity absdir "..")
>> 				       %load-path)))))
>>
>> in setup-load-path.scm.
>>
>> But without a time machine I don't think anything can be done to make
>> either of those fragments more concise.
>
> Well, you could instead do:
>
>   (cond-expand ((not guile-2) (load "guile-2.0-compat.scm")))

Well it seems it has to be

  (cond-expand (guile-2)
    	       (else (load "guile-2.0-compat.scm")))

because cond-expand errors if no clause is satisfied.

>   (add-to-load-path (dirname (dirname (current-filename))))
>
> Then in guile-2.0-compat.scm you have shims to make guile 1.8 offer a
> 2.0 interface (in this case, current-filename and add-to-load-path).

But yes, indeed that is nicer, and it obviously generalises to other
compatibility issues too.  Thanks for the idea!

Regards,
        Neil

Re: add-relative-load-path ?

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

>> What about calling it ‘current-file-name’ instead?
>
>   > (apropos "filename")
>   (guile): set-module-filename!	#<procedure 1546f20 at ice-9/boot-9.scm:1712:2 (module val)>
>   (guile): module-filename	#<procedure 1546fa0 at ice-9/boot-9.scm:1712:2 (module)>
>   (guile): current-filename
>   (guile): set-port-filename!	#<procedure set-port-filename! (_ _)>
>   (guile): port-filename	#<procedure port-filename (_)>
>   (ice-9 readline): filename-completion-function	#<procedure filename-completion-function (_ _)>
>   > (apropos "file-name")
>   > 
>
> Though I am responsible for three of those, I think I was just following
> established convention.

Hmm, OK then.

Ludo’.

Re: add-relative-load-path ?

[Andy Wingo]

On Wed 25 Jan 2012 13:42, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>>> What about calling it ‘current-file-name’ instead?
>>
>>   > (apropos "filename")
>>   (guile): set-module-filename!	#<procedure 1546f20 at ice-9/boot-9.scm:1712:2 (module val)>
>>   (guile): module-filename	#<procedure 1546fa0 at ice-9/boot-9.scm:1712:2 (module)>
>>   (guile): current-filename
>>   (guile): set-port-filename!	#<procedure set-port-filename! (_ _)>
>>   (guile): port-filename	#<procedure port-filename (_)>
>>   (ice-9 readline): filename-completion-function	#<procedure filename-completion-function (_ _)>
>>   > (apropos "file-name")
>>   > 
>>
>> Though I am responsible for three of those, I think I was just following
>> established convention.
>
> Hmm, OK then.

We can still change it if it's the right thing, but we would probably
need to do the same with the other interfaces (with the deprecation
dance).

Note that there's also the instance of 'filename in alists, like in
source properties.  We probably wouldn't be able to change those.

Andy
-- 
http://wingolog.org/

Re: add-relative-load-path ?

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Wed 25 Jan 2012 13:42, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>>> What about calling it ‘current-file-name’ instead?
>>>
>>>   > (apropos "filename")
>>>   (guile): set-module-filename!	#<procedure 1546f20 at ice-9/boot-9.scm:1712:2 (module val)>
>>>   (guile): module-filename	#<procedure 1546fa0 at ice-9/boot-9.scm:1712:2 (module)>
>>>   (guile): current-filename
>>>   (guile): set-port-filename!	#<procedure set-port-filename! (_ _)>
>>>   (guile): port-filename	#<procedure port-filename (_)>
>>>   (ice-9 readline): filename-completion-function	#<procedure filename-completion-function (_ _)>
>>>   > (apropos "file-name")
>>>   > 
>>>
>>> Though I am responsible for three of those, I think I was just following
>>> established convention.
>>
>> Hmm, OK then.
>
> We can still change it if it's the right thing, but we would probably
> need to do the same with the other interfaces (with the deprecation
> dance).

Right.  Or we could keep both, for those that already existed?  (Just
like some software packages have both “color” and “colour” in their
API.)

> Note that there's also the instance of 'filename in alists, like in
> source properties.  We probably wouldn't be able to change those.

Yes, this one cannot be changed.

Ludo’.

Re: add-relative-load-path ?

[Andy Wingo]

On Wed 25 Jan 2012 21:41, ludo@gnu.org (Ludovic Courtès) writes:

>>>>> What about calling it ‘current-file-name’ instead?
>>>>
>> We can still change it if it's the right thing, but we would probably
>> need to do the same with the other interfaces (with the deprecation
>> dance).
>
> Right.  Or we could keep both, for those that already existed?  (Just
> like some software packages have both “color” and “colour” in their
> API.)

To me that does not make sense.  If we prefer one, then we deprecate the
other.  IMO anyway :)  I have no preference here, except overall
consistency.

Andy
-- 
http://wingolog.org/

Re: add-relative-load-path ? - scm_add_load_path too?

[Ian Hulin]

Hi Andy, Ludo,

I've just seen the add-load-path scheme function in the new git
documentation.

Please, please, pretty please can we have a scm_add_load_path API
equivalent callable from C/C++? The LilyPond initialization code
currently does disgusting things like faking
(eval (set! %load-path cons ( <blah> %load-path ) ) )

a call such as

(scm_add_load_path (scm_from_locale_string ("<blah") );

would look far more civilized, and  I'd be able to take out the
current hack, complete with the comments containing shudders of disgust.

Cheers,

Ian Hulin

On 08/01/12 15:14, Andy Wingo wrote:
> Hi all,
> 
> In the following thread:
> 
> http://thread.gmane.org/gmane.lisp.guile.user/8298/focus=8403
> 
> there was a concern that it's difficult to set up the load path
> for simple one-off scripts.
> 
> I had a proposal that we add something like this:
> 
> (define-syntax add-relative-load-path (lambda (x) (syntax-case x
> () ((_ path) (string? (syntax->datum #'path)) (let* ((src
> (syntax-source #'x)) (current-file (or (and src (assq-ref src
> 'filename)) (error "Could not determine current file name"))) 
> (vicinity (dirname (canonicalize-path current-file))) (path-elt
> (in-vicinity vicinity (syntax->datum #'path)))) #`(eval-when
> (compile load eval) (set! %load-path (cons #,path-elt
> %load-path))))))))
> 
> Then in your script you would (add-relative-load-path ".").
> 
> Maybe we need an `add-to-load-path' form that handles the
> eval-when, actually, so it would be
> 
> (add-to-load-path (dirname (current-source-filename)))
> 
> or something like that.  (We'd have to define
> current-source-filename as well, in terms of
> current-source-location.)
> 
> What do folks think?  Is it work it?
> 
> Andy

Re: add-relative-load-path ? - scm_add_load_path too?

[Mark H Weaver]

Hi Ian,

Ian Hulin <ian@hulin.org.uk> writes:
> I've just seen the add-load-path scheme function in the new git
> documentation.
>
> Please, please, pretty please can we have a scm_add_load_path API
> equivalent callable from C/C++? The LilyPond initialization code
> currently does disgusting things like faking
> (eval (set! %load-path cons ( <blah> %load-path ) ) )

I took a look at the relevant Lilypond code:

  string s = "(set! %load-path (cons \"" + dir + "\" %load-path))";
  scm_c_eval_string (s.c_str ());

and indeed this isn't very nice.  I can suggest a couple of alternatives
that are much nicer.

Probably the easiest option here is to simply prepend the desired
directories onto the GUILE_LOAD_PATH environment variable before calling
scm_boot_guile.  Its contents will automatically be prepended to
%load-path during Guile initialiation.  The nice thing about this method
is that it will work with older versions of Guile as well, at least as
far back as Guile 1.4.

Barring that, the nicer (and more robust) way to prepend to any list is
as follows:

  SCM var = scm_c_lookup ("%load-path");
  scm_variable_set_x (var, scm_cons (scm_from_locale_string (dir),
                                     scm_variable_ref (var)));

Finally, although I don't recommend it in this case, if you really want
to build an expression to evaluate, it is much more robust to build list
structures instead of strings.  In this case:

  scm_primitive_eval
    (scm_list_3 (scm_from_locale_symbol ("set!"),
                 scm_from_locale_symbol ("%load-path"),
                 scm_list_3 (scm_from_locale_symbol ("cons"),
                             scm_from_locale_string (dir),
                             scm_from_locale_symbol ("%load-path"))));

All of these suggestions should work with Guile 1.8 as well as 2.0.x.
Hope this helps.

    Regards,
      Mark

Re: add-relative-load-path ? - scm_add_load_path too?

[Mark H Weaver]

Replying to myself...

> Probably the easiest option here is to simply prepend the desired
> directories onto the GUILE_LOAD_PATH environment variable before calling
> scm_boot_guile.

On second thought, this is probably not a good idea, because you don't
want this setting to propagate to other subprocesses.  This is probably
the best thing:

>   SCM var = scm_c_lookup ("%load-path");
>   scm_variable_set_x (var, scm_cons (scm_from_locale_string (dir),
>                                      scm_variable_ref (var)));

Does that work for you?

    Mark

Re: add-relative-load-path ? - scm_add_load_path too?

[Ian Hulin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark,
On 31/01/12 16:10, Mark H Weaver wrote:
> Replying to myself...
> 
>> Probably the easiest option here is to simply prepend the
>> desired directories onto the GUILE_LOAD_PATH environment variable
>> before calling scm_boot_guile.
> 
> On second thought, this is probably not a good idea, because you
> don't want this setting to propagate to other subprocesses.  This
> is probably the best thing:
> 
>> SCM var = scm_c_lookup ("%load-path"); scm_variable_set_x (var,
>> scm_cons (scm_from_locale_string (dir), scm_variable_ref
>> (var)));
> 
> Does that work for you?
Yup, I've been able to turn it into a more general-purpose routine so
I can similarly prefix %load-compiled-path.

Thanks for the tips.

Cheers,

Ian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPKcslAAoJEBqidDirZqASwAwH/344eRUPqVP4kb405MfEIGNy
TcK6P+1BOFKCh5O6Kz6mYkGszi+OCqB/DNHAGR37vqTCm5Kbo7fbR1tVLulPGB3w
vdPsA4xTe0IzDI/jdmIb4B+cJ1aM+MlvokBZLafyCesF8/nYWi934NCbK0ze+aZY
jZoF1rzr2tDore8hGRam2p/zaN9rv7iY2FiuMAmjIsLVOqXu05TiSF5k6q2NNr1x
xf8hzjzR6TnjFnFQC4wMPcbct9bHPOpJx9HEdakHsGx7ECh8pMtam3EyuHlMr38u
DZ5v0LyjT85hOSTf+6hys9jscx65pz/ZdiInL6FDe7vHy0a8uawoOY2i6bC+mTE=
=TVBM
-----END PGP SIGNATURE-----