unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59256: Emacs-guix tab-completion returns gexp error
@ 2022-11-13 22:16 Joshua Hecker via Bug reports for GNU Guix
  2022-11-26 20:45 ` Joshua Hecker via Bug reports for GNU Guix
  2022-12-15 13:01 ` calcium via Bug reports for GNU Guix
  0 siblings, 2 replies; 7+ messages in thread
From: Joshua Hecker via Bug reports for GNU Guix @ 2022-11-13 22:16 UTC (permalink / raw)
  To: 59256

To Guix,

Emacs-guix tab-completion or M-x guix-command returns:

Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
/home/crono/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:177:7: Unknown # object: "#~"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(emacs-guix) [1]>

It seems to me that the repl doesnt have the gexp module loaded? I have
tried changing the guix-load-path and guix-compiled-load-path for
emacs. As well as loading the gexp module in both the emacs-guix and
internal repl.

For the "is this reproducible" question just in case:
https://logs.guix.gnu.org/guix/2022-11-08.log#204945
https://logs.guix.gnu.org/guix/2022-11-13.log#195613

Thank you,
-Joshua




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#59256: Emacs-guix tab-completion returns gexp error
  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
  2022-12-15 13:01 ` calcium via Bug reports for GNU Guix
  1 sibling, 1 reply; 7+ messages in thread
From: Joshua Hecker via Bug reports for GNU Guix @ 2022-11-26 20:45 UTC (permalink / raw)
  To: Joshua Hecker, 59256

To Guix,

Just following up for the record, turning (setq guix-repl-use-server
nil) does fix the reading issue. For whats it worth at least we can
safely say it with how sockets (at least in for guile) handle gexp.
I will investigate further with do time.

stay safe,
-Joshua




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#59256: Emacs-guix tab-completion returns gexp error
  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
@ 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
  1 sibling, 1 reply; 7+ messages in thread
From: calcium via Bug reports for GNU Guix @ 2022-12-15 13:01 UTC (permalink / raw)
  To: 59256

The problem can be tracked back from elisp procedure `guix-pcomplete-search-in-help` in guix-pcomplete.el to `guix-help-string` in guix-misc.el, to this problematic code :
```
(guix-eval-read "(help-string )")
```

The procedure help-string exists, as can be seen below :
```
(guix-eval-read
  "(begin
   (use-modules (ice-9 format))
   (format #f \"~s\"
    help-string))") ;; => "#<procedure help-string commands>"
```

but the object that `(help-string)` returns seems incompatible with guile's own repl/shell ....

The solution might be to just change the `help-string` procedure to return another kind of object, or to fix guile's repl/shell for that kind of object.






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#59256: Emacs-guix tab-completion returns gexp error
  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
  0 siblings, 0 replies; 7+ messages in thread
From: Joshua Hecker via Bug reports for GNU Guix @ 2023-01-02  7:29 UTC (permalink / raw)
  To: calcium, 59256

calcium <calcium@disroot.org> writes:

> The problem can be tracked back from elisp procedure
> `guix-pcomplete-search-in-help` in guix-pcomplete.el to
> `guix-help-string` in guix-misc.el, to this problematic code :
>
> ```
> (guix-eval-read "(help-string )")
> ```
>
>
> The procedure help-string exists, as can be seen below :
>
> ```
> (guix-eval-read
>   "(begin
>    (use-modules (ice-9 format))
>    (format #f \"~s\"
>     help-string))") ;; => "#<procedure help-string commands>"
> ```
>
> but the object that `(help-string)` returns seems incompatible with guile's own repl/shell ....
>
> The solution might be to just change the `help-string` procedure to
> return another kind of object, or to fix guile's repl/shell for that
> kind of object.

Im certain it's not anyone procedure, but rather the internal repl being in a
socket file. I dont know how guile is handling sockets, but guile
(socketed) cant read '#' for some reason.

The next step might be going to the guile mailing list and getting some
answers there, cause guile has nil for documentation and I have come up
empty handed in looking for any answers for guile socket files. Either way, I
think emacs-guix is important enough to get this fix, so will do.

Stay safe,
-Joshua




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#59256: Emacs-guix tab-completion returns gexp error
  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
  0 siblings, 1 reply; 7+ messages in thread
From: Maxime Devos @ 2023-01-03 22:25 UTC (permalink / raw)
  To: Joshua Hecker, 59256


[-- Attachment #1.1.1: Type: text/plain, Size: 2822 bytes --]

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

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

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#59256: Emacs-guix tab-completion returns gexp error
  2023-01-03 22:25   ` Maxime Devos
@ 2023-03-22  6:10     ` Joshua Hecker via Bug reports for GNU Guix
  2023-04-05 12:36       ` Maxime Devos
  0 siblings, 1 reply; 7+ messages in thread
From: Joshua Hecker via Bug reports for GNU Guix @ 2023-03-22  6:10 UTC (permalink / raw)
  To: Maxime Devos, 59256

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
 




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#59256: Emacs-guix tab-completion returns gexp error
  2023-03-22  6:10     ` Joshua Hecker via Bug reports for GNU Guix
@ 2023-04-05 12:36       ` Maxime Devos
  0 siblings, 0 replies; 7+ messages in thread
From: Maxime Devos @ 2023-04-05 12:36 UTC (permalink / raw)
  To: Joshua Hecker, 59256


[-- Attachment #1.1.1: Type: text/plain, Size: 128 bytes --]

Op 22-03-2023 om 07:10 schreef Joshua Hecker:
> [...]

I'm not involved in Guix development anymore.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-04-05 12:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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