Discussion:
geiser-xref-callers does not seem to work
(too old to reply)
Chris Marusich
2017-12-16 07:55:59 UTC
Permalink
Raw Message
Hi,

It seems that geiser-xref-callers does not work for me. I believe I've
configured Geiser correctly, since other commands like
geiser-edit-symbol-at-point and geiser-doc-symbol-at-point do work in
some cases.

Here is a specific example where it fails for me:

* Clone the Guix Git repository (for commit
9e111db4535b3cd5729e37294ae51d95240334b4 if you want to be precise):

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

* Configure Geiser for Guix as described in Guix's manual ((guix) The
Perfect Setup).

* Open gnu/system/vm.scm in the Guix source tree, and run
switch-to-geiser-module for the (gnu system vm) module.

* Place point on symbol expression->derivation-in-linux-vm on line 203
(in the definition of the iso9660-image procedure), and press "C-c <".

When I do this, I receive the following message in the minibuffer:

No callers found for ’expression->derivation-in-linux-vm’

And yet, if I run "M-x rgrep" on the same symbol, there are obviously
many call sites:

./gnu/system/vm.scm:68: #:export (expression->derivation-in-linux-vm
./gnu/system/vm.scm:105:(define* (expression->derivation-in-linux-vm name exp
./gnu/system/vm.scm:203: (expression->derivation-in-linux-vm
./gnu/system/vm.scm:274: (expression->derivation-in-linux-vm

What might the problem be? When I run "M-x geiser-doc-symbol-at-point"
on this symbol, it also claims that there is no documentation
available. I feel like maybe I've misconfigured something, but I don't
know what.

Here are the Geiser-specific things I've added to my ~/.emacs file:

--8<---------------cut here---------------start------------->8---
;; Tell geiser where guix checkout lives
(with-eval-after-load 'geiser-guile
(add-to-list 'geiser-guile-load-path "~/guix"))

(add-hook 'geiser-repl-mode-hook 'enable-paredit-mode)

;; Keybind customizations
(add-hook 'geiser-mode-hook
(lambda ()
(local-set-key (kbd "C-c m") 'switch-to-geiser-module)))
(add-hook 'geiser-mode-hook
(lambda ()
(local-set-key (kbd "C-c i") 'geiser-repl-import-module)))
--8<---------------cut here---------------end--------------->8---
--
Chris
Chris Marusich
2017-12-16 08:38:23 UTC
Permalink
Raw Message
Post by Chris Marusich
Hi,
It seems that geiser-xref-callers does not work for me. I believe I've
configured Geiser correctly, since other commands like
geiser-edit-symbol-at-point and geiser-doc-symbol-at-point do work in
some cases.
* Clone the Guix Git repository (for commit
git clone https://git.savannah.gnu.org/git/guix.git
* Configure Geiser for Guix as described in Guix's manual ((guix) The
Perfect Setup).
* Open gnu/system/vm.scm in the Guix source tree, and run
switch-to-geiser-module for the (gnu system vm) module.
* Place point on symbol expression->derivation-in-linux-vm on line 203
(in the definition of the iso9660-image procedure), and press "C-c <".
No callers found for ’expression->derivation-in-linux-vm’
And yet, if I run "M-x rgrep" on the same symbol, there are obviously
./gnu/system/vm.scm:68: #:export (expression->derivation-in-linux-vm
./gnu/system/vm.scm:105:(define* (expression->derivation-in-linux-vm name exp
./gnu/system/vm.scm:203: (expression->derivation-in-linux-vm
./gnu/system/vm.scm:274: (expression->derivation-in-linux-vm
What might the problem be? When I run "M-x geiser-doc-symbol-at-point"
on this symbol, it also claims that there is no documentation
available. I feel like maybe I've misconfigured something, but I don't
know what.
;; Tell geiser where guix checkout lives
(with-eval-after-load 'geiser-guile
(add-to-list 'geiser-guile-load-path "~/guix"))
(add-hook 'geiser-repl-mode-hook 'enable-paredit-mode)
;; Keybind customizations
(add-hook 'geiser-mode-hook
(lambda ()
(local-set-key (kbd "C-c m") 'switch-to-geiser-module)))
(add-hook 'geiser-mode-hook
(lambda ()
(local-set-key (kbd "C-c i") 'geiser-repl-import-module)))
--
Chris
Jose A. Ortega Ruiz
2017-12-16 18:45:45 UTC
Permalink
Raw Message
Hi Chris,
Post by Chris Marusich
Hi,
It seems that geiser-xref-callers does not work for me. I believe I've
configured Geiser correctly, since other commands like
geiser-edit-symbol-at-point and geiser-doc-symbol-at-point do work in
some cases.
* Clone the Guix Git repository (for commit
git clone https://git.savannah.gnu.org/git/guix.git
* Configure Geiser for Guix as described in Guix's manual ((guix) The
Perfect Setup).
* Open gnu/system/vm.scm in the Guix source tree, and run
switch-to-geiser-module for the (gnu system vm) module.
For geiser's functionality to be active, the module's has to be loaded in
the running guile session. Opening the file or switching to the module
without evaluation won't make available any of its definitions to the
running process. Have you tried compiling/loading the module? A quick
way of accomplishing that is with C-c C-k when you're in vm.scm.

jao
--
A student came to the master and asked, for the master was one of them
who knew such things: "Does Emacs have the Buddha nature?" The master
contemplated this for some time, and answered: "I don't see why not,
it has about everything else."
Andy Wingo
2017-12-18 09:34:14 UTC
Permalink
Raw Message
Post by Chris Marusich
* Place point on symbol expression->derivation-in-linux-vm on line 203
(in the definition of the iso9660-image procedure), and press "C-c <".
No callers found for ’expression->derivation-in-linux-vm’
And yet, if I run "M-x rgrep" on the same symbol, there are obviously
./gnu/system/vm.scm:68: #:export (expression->derivation-in-linux-vm
./gnu/system/vm.scm:105:(define* (expression->derivation-in-linux-vm name exp
./gnu/system/vm.scm:203: (expression->derivation-in-linux-vm
./gnu/system/vm.scm:274: (expression->derivation-in-linux-vm
What might the problem be? When I run "M-x geiser-doc-symbol-at-point"
on this symbol, it also claims that there is no documentation
available. I feel like maybe I've misconfigured something, but I don't
know what.
It appears to be a Geiser problem and not a Guile problem:

***@rusty:~/src/guix$ ./pre-inst-env guile
GNU Guile 2.2.2
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (gnu system vm))
scheme@(guile-user)> expression->derivation-in-linux-vm
$1 = #<procedure expression->derivation-in-linux-vm (name exp #:key system linux initrd qemu env-vars guile-for-build single-file-output? make-disk-image? references-graphs memory-size disk-image-format disk-image-size)>
scheme@(guile-user)> (use-modules (system xref))
scheme@(guile-user)> (procedure-callers $1)
ERROR: In procedure scm-error:
ERROR: expected a variable, symbol, or (modname . sym) #<procedure expression->derivation-in-linux-vm (name exp #:key system linux initrd qemu env-vars guile-for-build single-file-output? make-disk-image? references-graphs memory-size disk-image-format disk-image-size)>

Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,q
scheme@(guile-user)> (procedure-callers '((gnu system vm) . expression->derivation-in-linux-vm))
$2 = (((gnu system vm) #<procedure qemu-image (#:key name system qemu disk-image-size disk-image-format file-system-type file-system-label file-system-uuid os-drv bootcfg-drv bootloader register-closures? inputs copy-inputs?)> #<procedure iso9660-image (#:key name file-system-label file-system-uuid system qemu os-drv bootcfg-drv bootloader register-closures? inputs)>))

I assume your Scheme files are indeed compiled?

Andy
Chris Marusich
2017-12-19 07:47:14 UTC
Permalink
Raw Message
Hi,

Thank you for the quick response!
Post by Andy Wingo
GNU Guile 2.2.2
Copyright (C) 1995-2017 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
$1 = #<procedure expression->derivation-in-linux-vm (name exp
#:key system linux initrd qemu env-vars guile-for-build
single-file-output? make-disk-image? references-graphs memory-size
disk-image-format disk-image-size)>
ERROR: expected a variable, symbol, or (modname . sym) #<procedure
expression->derivation-in-linux-vm (name exp #:key system linux initrd
qemu env-vars guile-for-build single-file-output? make-disk-image?
references-graphs memory-size disk-image-format disk-image-size)>
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
$2 = (((gnu system vm) #<procedure qemu-image (#:key name system
qemu disk-image-size disk-image-format file-system-type
file-system-label file-system-uuid os-drv bootcfg-drv bootloader
register-closures? inputs copy-inputs?)> #<procedure iso9660-image
(#:key name file-system-label file-system-uuid system qemu os-drv
bootcfg-drv bootloader register-closures? inputs)>))
I assume your Scheme files are indeed compiled?
Yes, I double-checked: even when the files are compiled, it doesn't seem
to work for me.
Post by Andy Wingo
For geiser's functionality to be active, the module's has to be loaded in
the running guile session. Opening the file or switching to the module
without evaluation won't make available any of its definitions to the
running process. Have you tried compiling/loading the module? A quick
way of accomplishing that is with C-c C-k when you're in vm.scm.
Since the files are already compiled, is this necessary? Either way, I
tried running C-c C-k (which is bound to geiser-compile-current-buffer),
and the problem still occurred.

Is this feature working for anyone else?
--
Chris
Jose A. Ortega Ruiz
2018-01-27 16:41:41 UTC
Permalink
Raw Message
Post by Chris Marusich
* Place point on symbol expression->derivation-in-linux-vm on line 203
(in the definition of the iso9660-image procedure), and press "C-c <".
No callers found for ’expression->derivation-in-linux-vm’
And yet, if I run "M-x rgrep" on the same symbol, there are obviously
./gnu/system/vm.scm:68: #:export (expression->derivation-in-linux-vm
./gnu/system/vm.scm:105:(define* (expression->derivation-in-linux-vm name exp
./gnu/system/vm.scm:203: (expression->derivation-in-linux-vm
./gnu/system/vm.scm:274: (expression->derivation-in-linux-vm
What might the problem be? When I run "M-x geiser-doc-symbol-at-point"
on this symbol, it also claims that there is no documentation
available. I feel like maybe I've misconfigured something, but I don't
know what.
hmmm, i was investigating this. the cause geiser fails is that, in the
process of looking for other things, it's not able to find
`program-arities', exported by (system vm program). i am not sure why:

~$ guile
GNU Guile 2.2.3
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (system vm program))
scheme@(guile-user)> program-arity
$1 = #<procedure program-arity (prog ip)>
scheme@(guile-user)> program-arities
ERROR: Unbound variable: program-arities

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

Any idea what might be wrong?

jao
--
Have a place for everything and keep the thing somewhere else; this is
not advice, it is merely custom. -- Mark Twain
Andy Wingo
2018-01-29 08:53:04 UTC
Permalink
Raw Message
Hi!

Great to hear from you jao :)
Post by Jose A. Ortega Ruiz
hmmm, i was investigating this. the cause geiser fails is that, in the
process of looking for other things, it's not able to find
Weird. Apologies for this, the function just doesn't exist. While
program-arity exists and calls it, program-arity itself isn't called. I
think this is detritus of refactoring :(

The facility that Guile uses now for arities is find-program-arity from
(system vm debug). It takes an address as an argument. Pass
(program-code prog) if you know you have a program. The issue is that
with Guile 2.2 there is code that doesn't necessarily have a
corresponding program object. For example a function defined in a local
context whose callers can be enumerated by the compiler can be called by
label instead of by value, and in that case the "closure" of the
function can be specialized to be e.g. a vector instead of a closure
object. So while you always have an address, you don't always have a
program object.

Relatedly, you ask about program-module. This one is sadly no longer
available. I suspect it is not coming back either :/ I think you have
to fall back on mapping procedures to files, and files to modules.

You might find a look to (system vm debug) to be useful for Geiser
purposes. Note also that the interface to local variables and stack
frames changed slightly too; see (system vm frame).

Cheers,

Andy
Jose A. Ortega Ruiz
2018-01-29 17:52:12 UTC
Permalink
Raw Message
Post by Andy Wingo
Hi!
Great to hear from you jao :)
likewise :)
Post by Andy Wingo
Post by Jose A. Ortega Ruiz
hmmm, i was investigating this. the cause geiser fails is that, in the
process of looking for other things, it's not able to find
Weird. Apologies for this, the function just doesn't exist. While
program-arity exists and calls it, program-arity itself isn't called. I
think this is detritus of refactoring :(
The facility that Guile uses now for arities is find-program-arity from
(system vm debug). It takes an address as an argument. Pass
(program-code prog) if you know you have a program. The issue is that
with Guile 2.2 there is code that doesn't necessarily have a
corresponding program object. For example a function defined in a local
context whose callers can be enumerated by the compiler can be called by
label instead of by value, and in that case the "closure" of the
function can be specialized to be e.g. a vector instead of a closure
object. So while you always have an address, you don't always have a
program object.
makes sense, i think i can work from there.
Post by Andy Wingo
Relatedly, you ask about program-module. This one is sadly no longer
available. I suspect it is not coming back either :/ I think you have
to fall back on mapping procedures to files, and files to modules.
i've figured out how to find the filename for a procedure, but i'm
missing what is probably the easier part: give the latter, how do i get
hold of the module object?
Post by Andy Wingo
You might find a look to (system vm debug) to be useful for Geiser
purposes. Note also that the interface to local variables and stack
frames changed slightly too; see (system vm frame).
yes, i'm reviewing all this. i suspect some other geiser functionality
might have been affected by all this. thanks for the update!

cheers,
jao
--
A ship in port is safe; but that is not what ships are built
for. -Grace Hopper (1906-1992)
Andy Wingo
2018-01-30 08:09:37 UTC
Permalink
Raw Message
Post by Jose A. Ortega Ruiz
i've figured out how to find the filename for a procedure, but i'm
missing what is probably the easier part: give the latter, how do i get
hold of the module object?
On the one side there's no 100% reliable way. E.g. some files don't
declare what module they're in, and so if they are loaded (e.g. via
"include") from within some other module, then they inherit the current
module from the caller.

However there is the very common case in which each file defines a
module -- there, I would actually go about this in the other way. Walk
the module tree and record source file names that map to modules.
However like source-procedures, probably Guile should bake this facility
into (system xref). Anyway here is a procedure that will do it:

;; Return hash table mapping filename to list of modules defined in that
;; file.
(define (compute-source->module-mapping)
(let ((ret (make-hash-table)))
(define (record-module m)
(let ((f (module-filename m)))
(hash-set! ret f (cons m (hash-ref ret f '())))))
(define (visit-module m)
(record-module m)
(hash-for-each (lambda (k v) (visit-module v))
(module-submodules m)))
(visit-module (resolve-module '() #f))
ret))

Cheers,

Andy
Jose A. Ortega Ruiz
2018-01-30 22:55:15 UTC
Permalink
Raw Message
Post by Andy Wingo
Post by Jose A. Ortega Ruiz
i've figured out how to find the filename for a procedure, but i'm
missing what is probably the easier part: give the latter, how do i get
hold of the module object?
On the one side there's no 100% reliable way. E.g. some files don't
declare what module they're in, and so if they are loaded (e.g. via
"include") from within some other module, then they inherit the current
module from the caller.
However there is the very common case in which each file defines a
module -- there, I would actually go about this in the other way. Walk
the module tree and record source file names that map to modules.
However like source-procedures, probably Guile should bake this facility
;; Return hash table mapping filename to list of modules defined in that
;; file.
(define (compute-source->module-mapping)
(let ((ret (make-hash-table)))
(define (record-module m)
(let ((f (module-filename m)))
(hash-set! ret f (cons m (hash-ref ret f '())))))
(define (visit-module m)
(record-module m)
(hash-for-each (lambda (k v) (visit-module v))
(module-submodules m)))
(visit-module (resolve-module '() #f))
ret))
Thanks, this is working for me! And replacing program-arities was
trivial given the new debug utilities.

Chris, as a result, xref is working for me too in the latest geiser in
git: please give it a try when you can, and thanks for your patience :)

Cheers,
jao
--
Patriotism is a kind of religion; it is the egg from which wars are
hatched. -Guy de Maupassant, short story writer and novelist (1850-1893)
Loading...