GNU bug report logs - #55464
(current-filename) is #f when guix pull'ing

Previous Next

To reply to this bug, email your comments to 55464 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Attila Lendvai <attila <at> lendvai.name>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: (current-filename) is #f when guix pull'ing
Date: Mon, 16 May 2022 21:04:10 +0000

the actual context where i'm encountering this is a package definition where i want to load some hashes from a file relative the to the .scm file:

(define-public foo
  (let ((hashes
    (with-input-from-file
        (string-append (dirname (current-filename))
                       "/foo.hashes")
      read)))
    (package ...)))

this works fine in a `./pre-inst-env build foo`, but i think there's something special in how `guix pull` compiles the scm files, and (c-f) expands to #f. guix pull works, but afterwards:

$ guix system --on-error=backtrace reconfigure --allow-downgrades /etc/guix/config.scm
guix system: error: failed to load '/etc/guix/config.scm':
guix-crypto/packages/ethereum.scm:47:36: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f

In ice-9/boot-9.scm:
   222:29 19 (map1 (((gnu)) ((gnu system)) ((gnu system #)) ((# …)) …))
   222:29 18 (map1 (((gnu system)) ((gnu system file-systems)) (#) …))
   222:29 17 (map1 (((gnu system file-systems)) ((oop goops)) ((…)) …))
   222:29 16 (map1 (((oop goops)) ((shepherd service)) ((nongnu …)) …))
   222:29 15 (map1 (((shepherd service)) ((nongnu packages linux)) …))
   222:29 14 (map1 (((nongnu packages linux)) ((guix-crypto # #)) # …))
   222:17 13 (map1 (((guix-crypto packages ethereum)) ((# # #)) (#) …))
  3936:31 12 (_ ((guix-crypto packages ethereum)))
  3327:17 11 (resolve-interface (guix-crypto packages ethereum) # _ # …)
In ice-9/threads.scm:
    390:8 10 (_ _)
In ice-9/boot-9.scm:
  3253:13  9 (_)
In ice-9/threads.scm:
    390:8  8 (_ _)
In ice-9/boot-9.scm:
  3544:20  7 (_)
   2836:4  6 (save-module-excursion #<procedure 7f056144d810 at ice-…>)
  3564:26  5 (_)
In unknown file:
           4 (primitive-load-path "guix-crypto/packages/ethereum" #<…>)
In guix-crypto/packages/ethereum.scm:
    47:36  3 (_)
In unknown file:
           2 (dirname #f)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1780:13  0 (_ #<&compound-exception components: (#<&assertion-fail…>)

i would be happy to avoid using (c-f), but i failed to find a way in Guile's module reflection API.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“People who have never gone to school have never developed negative attitudes toward exploring their world.”
	— Grace Llewellyn

Message #8 received at 55464 <at> debbugs.gnu.org (full text, mbox):

From: Attila Lendvai <attila <at> lendvai.name>
To: "55464 <at> debbugs.gnu.org" <55464 <at> debbugs.gnu.org>
Subject: alternative way
Date: Tue, 17 May 2022 00:09:03 +0000

as Ludovic kindly pointed out on IRC, i can use this instead:

(module-filename (current-module))

unfortunately, this returns a relative path, which is only useful using (search-path %load-path ...), which introduces some uncertainty about what actually gets loaded depending on the runtime value of %load-path... :|

therefore, i decided to read the file at macroexpand-time. after some struggle with hygienic macros:

(define-syntax read-module-relative-file
  (lambda (syn)
    (syntax-case syn ()
      ((_ filename)
       (with-syntax
           ;; Read the file at compile time and macroexpand to the first form.
           ((form (%read-module-relative-file (current-module)
                                              (syntax->datum #'filename))))
         #''form)))))

(define (%read-module-relative-file module filename)
  (with-input-from-file
      (or (search-path %load-path
                       (string-append (dirname (module-filename module))
                                      "/" filename))
          (error "%read-module-relative-file failed for" filename))
    read))

not beautiful, but works.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is just as difficult and dangerous to try to free a people that wants to remain servile as it is to enslave a people that wants to remain free.”
	— Niccolò Machiavelli (1469–1527)

Message #11 received at 55464 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Attila Lendvai <attila <at> lendvai.name>
Cc: 55464 <at> debbugs.gnu.org
Subject: Re: bug#55464: (current-filename) is #f when guix pull'ing
Date: Wed, 18 May 2022 11:14:13 +0200

Hi,

Attila Lendvai <attila <at> lendvai.name> skribis:

> the actual context where i'm encountering this is a package definition where i want to load some hashes from a file relative the to the .scm file:
>
> (define-public foo
>   (let ((hashes
>     (with-input-from-file
>         (string-append (dirname (current-filename))
>                        "/foo.hashes")
>       read)))
>     (package ...)))

Not fully answering your question, but if “foo.hashes” contains hashes
for origins and similar, you could make “foo.hashes” contain something
like:

  (list (base32 …) …)

and, in the .scm, write:

  (include "foo.hashes")

The ‘include’ directive includes the file at macro-expansion time,
similar to #include in C.

Back to the original issue, I suppose ‘current-filename’ return #f when
this .scm is first loaded, before it’s compiled.  Anyway, it’s probably
best to load it at macro-expansion time as you suggested.

HTH,
Ludo’.

Message #14 received at 55464 <at> debbugs.gnu.org (full text, mbox):

From: Attila Lendvai <attila <at> lendvai.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 55464 <at> debbugs.gnu.org
Subject: Re: bug#55464: (current-filename) is #f when guix pull'ing
Date: Thu, 19 May 2022 13:32:55 +0000

[Message part 1 (text/plain, inline)]

> > (define-public foo
> > (let ((hashes
> > (with-input-from-file
> > (string-append (dirname (current-filename))
> > "/foo.hashes")
> > read)))
> > (package ...)))
>
>
> Not fully answering your question, but if “foo.hashes” contains hashes
> for origins and similar, you could make “foo.hashes” contain something
> like:
>
> (list (base32 …) …)
>
> and, in the .scm, write:
>
> (include "foo.hashes")
>
> The ‘include’ directive includes the file at macro-expansion time,
> similar to #include in C.


i did find guile's INCLUDE and tried to use it, but it also didn't work when guix pull'ing it. see the attached, now abandoned commit.

IIRC the issue is that the implementation of INCLUDE tries to load the file relative to the cwd, but cwd is not changed by the code that is driving the compilation when guix pull'ing the code. (does each thread has its own cwd at all...?)

it works when i build it using `./pre-inst-env guix build foo`. i briefly tried to analyse what's the difference between the two situations, but i ran out of steam.

it is the same reason i need to call READ like below in my current implementation:

(define (%read-module-relative-file module filename)
  (with-input-from-file
      (or (search-path
           %load-path
           (string-append (dirname (module-filename module))
                          "/" filename))
          (error "%read-module-relative-file failed for" filename))
    read))


...which is not beautiful.


> Back to the original issue, I suppose ‘current-filename’ return #f when
> this .scm is first loaded, before it’s compiled. Anyway, it’s probably
> best to load it at macro-expansion time as you suggested.


is my analysis is correct, namely that cwd is not (always?) changed at macroexpand time, and thus the implementation of INCLUDE is broken for relative paths? is this a bug to be fixed in guile? if so, shall i try to add a test case for this somewhere?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom.”
	— Isaac Asimov (1920–1992)

[use-guile-include.patch (text/x-patch, attachment)]

Message #17 received at 55464 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Attila Lendvai <attila <at> lendvai.name>
Cc: 55464 <at> debbugs.gnu.org
Subject: Re: bug#55464: (current-filename) is #f when guix pull'ing
Date: Sat, 21 May 2022 18:39:08 +0200

Hi,

Attila Lendvai <attila <at> lendvai.name> skribis:

> is my analysis is correct, namely that cwd is not (always?) changed at macroexpand time, and thus the implementation of INCLUDE is broken for relative paths? is this a bug to be fixed in guile? if so, shall i try to add a test case for this somewhere?

‘include’ does all its work at macro-expansion time.  It’s documented
like so (info "(guile) Local Inclusion"):

 -- Scheme Syntax: include file-name
     Open FILE-NAME, at expansion-time, and read the Scheme forms that
     it contains, splicing them into the location of the ‘include’,
     within a ‘begin’.

     If FILE-NAME is a relative path, it is searched for relative to the
     path that contains the file that the ‘include’ form appears in.

And I believe that’s what it does—see ‘psyntax.scm’ for the actual code.

Now, if source location info were to be missing, it wouldn’t be able to
work for relative file names because it wouldn’t know the name of the
source file that contains the ‘include’ form.

HTH!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.