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
Whoops, geiser-user@ doesn't exist. But geiser-users@ supposedly does.
I meant to send this email there, so I will try again. Email follows:

Chris Marusich <***@gmail.com> writes:

> 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:
>
> ;; 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,

On Sat, Dec 16 2017, Chris Marusich wrote:

> Whoops, geiser-user@ doesn't exist. But geiser-users@ supposedly does.
> I meant to send this email there, so I will try again. Email follows:
>
> Chris Marusich <***@gmail.com> writes:
>
>> 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.

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
On Sat 16 Dec 2017 08:55, Chris Marusich <***@gmail.com> writes:

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

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!

Andy Wingo <***@igalia.com> writes:

> 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?

Yes, I double-checked: even when the files are compiled, it doesn't seem
to work for me.

"Jose A. Ortega Ruiz" <***@gnu.org> writes:

> 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
On Mon, Dec 18 2017, Andy Wingo wrote:

> On Sat 16 Dec 2017 08:55, Chris Marusich <***@gmail.com> writes:
>
>> * 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.
>
> It appears to be a Geiser problem and not a Guile problem:

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

On Sat 27 Jan 2018 17:41, "Jose A. Ortega Ruiz" <***@gnu.org> writes:

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

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
On Mon, Jan 29 2018, Andy Wingo wrote:

> Hi!
>
> Great to hear from you jao :)

likewise :)

> On Sat 27 Jan 2018 17:41, "Jose A. Ortega Ruiz" <***@gnu.org> writes:
>
>> 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:
>
> 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.

> 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?

> 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
On Mon 29 Jan 2018 18:52, "Jose A. Ortega Ruiz" <***@gnu.org> writes:

> 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
On Tue, Jan 30 2018, Andy Wingo wrote:

> On Mon 29 Jan 2018 18:52, "Jose A. Ortega Ruiz" <***@gnu.org> writes:
>
>> 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))

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