unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Joshua Hecker via Bug reports for GNU Guix <bug-guix@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>, 59256@debbugs.gnu.org
Subject: bug#59256: Emacs-guix tab-completion returns gexp error
Date: Wed, 22 Mar 2023 01:10:14 -0500	[thread overview]
Message-ID: <874jqde2pl.fsf@mailbox.org> (raw)
In-Reply-To: <fb3497d7-50c2-e32e-5894-4a9f2d83cd86@telenet.be> (Maxime Devos's message of "Tue, 3 Jan 2023 23:25:46 +0100")

Maxime Devos <maximedevos@telenet.be> writes:

Sorry for getting back to you so late, life got in the way, work and
setting up my POWER9 machine :). But I still hope you can provide some
wisdom.

> I've heard about something about Guile sockets and REPLs, so I've
> investigated a bit and I think I found a Guix bug instead of a Guile
> bug (and is unrelated to sockets or REPLs):

Im glad you found something different happening behind the scenes. I
only came to that conclusion because I loaded my own [default] geiser
repl with emacs-guix mode, and comparing that to the emacs-guix repl
that loads automatically.

> In the error message, there is a mention of "#~". Perhaps somehow, no
> hash extension (not sure about terminology) for G-exps installed?
> This is confirmed by:
>
> scheme@(emacs-guix) [2]> (fluid-ref* %read-hash-procedures 0)
> $24 = ((#\. . #<procedure 7fbac9e323d0 at ice-9/boot-9.scm:2251:18 (c
> port)>))
>
> It's also not a matter of some parametrisation:
>
> scheme@(emacs-guix) [2]> (fluid-ref* %read-hash-procedures 1)
> $25 = ()
> scheme@(emacs-guix) [2]> (fluid-ref* %read-hash-procedures 2)
> $26 = ()
>
> How does this happen? (after all, (guix scripts deploy) imports (guix gexp))
>
> Going by the backtrace I get:
>
> [...]
> In guix/ui.scm:
>    2263:7 17 (run-guix . _)
> In ice-9/boot-9.scm:
>   1747:15 16 (with-exception-handler #<procedure 7fbac4ead6c0 at
>   ice-9/boot-9.scm:1831:7 (exn)> _ #:unwind? _ #:unwind-for-type _)
> In guix/ui.scm:
>   2184:20 15 (show-guix-help)
> In srfi/srfi-1.scm:
>    691:23 14 (filter-map #<procedure source-file-command (file)> _ . _)
> In ice-9/ports.scm:
>    433:17 13 (call-with-input-file _ _ #:binary _ #:encoding _
>    #:guess-encoding _)
> In guix/ui.scm:
>   2109:16 12 (_ #<input:
>   /home/antipode/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm
>   22>)
> In ice-9/read.scm:
>    734:20 11 (%read #<input:
>    /home/antipode/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm
>    22> #<procedure 7fbac42c5280 at ice-9/read.scm:862:8 (line column
>   datum)> _)
>     210:5 10 (read-parenthesized #\))
> [...]
>
> That is, one of the earliest things that happen, is that (guix ui)
> reads the file "(guix scripts deploy)" -- it doesn't do the reflection
> equivalent of (use-module ...) which will run the imports before
> reading the rest of the code.
>
> As such, the hash extension isn't installed even though it is required
> to read the file and even though the required module (guix gexp) is
> listed in the imports!
>
> To fix this, I propose modifying 'source-file-command' in (guix ui),
> by adding a clause to
>
>         (match (read port)
>           (('define-command _ ('synopsis synopsis)
>              _ ...)
>            (command command-name synopsis 'main))
>           (('define-command _
>              ('category category) ('synopsis synopsis)
>              _ ...)
>            (command command-name synopsis category))
>           ((? eof-object?)
>            #f)
>           (_
>            (loop)))))))
>
> which recognises (define-module [...] #:use-module MODULE ...),
> and if MODULE is (guix gexp) or (srfi srfi-88), then does
> (resolve-module 'MODULE #:ensure #false) before continuing with
> (loop).
>
> (Untested!)

Very cool that you found this. I would love to test this out, is there
any formal way to apply this and have emacs point to the test guix?
Sorry for novice questions, any info to do the work would be much appreciated.

Stay safe,
-Joshua
 




  reply	other threads:[~2023-03-22  6:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13 22:16 bug#59256: Emacs-guix tab-completion returns gexp error Joshua Hecker via Bug reports for GNU Guix
2022-11-26 20:45 ` Joshua Hecker via Bug reports for GNU Guix
2023-01-03 22:25   ` Maxime Devos
2023-03-22  6:10     ` Joshua Hecker via Bug reports for GNU Guix [this message]
2023-04-05 12:36       ` Maxime Devos
2022-12-15 13:01 ` calcium via Bug reports for GNU Guix
2023-01-02  7:29   ` Joshua Hecker via Bug reports for GNU Guix

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://guix.gnu.org/

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

  git send-email \
    --in-reply-to=874jqde2pl.fsf@mailbox.org \
    --to=bug-guix@gnu.org \
    --cc=59256@debbugs.gnu.org \
    --cc=joshua0609@mailbox.org \
    --cc=maximedevos@telenet.be \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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