geiser-xref-callers does not seem to work

geiser-xref-callers does not seem to work

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: geiser-xref-callers does not seem to work

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]

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 <cmmarusich@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: geiser-xref-callers does not seem to work

[Jose A. Ortega Ruiz]

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 <cmmarusich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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."

Re: geiser-xref-callers does not seem to work

[Andy Wingo]

On Sat 16 Dec 2017 08:55, Chris Marusich <cmmarusich@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:

    wingo@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

Re: geiser-xref-callers does not seem to work

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hi,

Thank you for the quick response!

Andy Wingo <wingo@igalia.com> writes:

> It appears to be a Geiser problem and not a Guile problem:
>
>     wingo@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" <jao@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: geiser-xref-callers does not seem to work

[Jose A. Ortega Ruiz]

On Mon, Dec 18 2017, Andy Wingo wrote:

> On Sat 16 Dec 2017 08:55, Chris Marusich <cmmarusich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

Re: geiser-xref-callers does not seem to work

[Andy Wingo]

Hi!

Great to hear from you jao :)

On Sat 27 Jan 2018 17:41, "Jose A. Ortega Ruiz" <jao-mXXj517/zsQ@public.gmane.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

Re: geiser-xref-callers does not seem to work

[Jose A. Ortega Ruiz]

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" <jao-mXXj517/zsQ@public.gmane.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)

Re: geiser-xref-callers does not seem to work

[Andy Wingo]

On Mon 29 Jan 2018 18:52, "Jose A. Ortega Ruiz" <jao-mXXj517/zsQ@public.gmane.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

Re: [Geiser-users] geiser-xref-callers does not seem to work

[Jose A. Ortega Ruiz]

On Tue, Jan 30 2018, Andy Wingo wrote:

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