Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix definition-source-for-emacs for case when source was categorized as :file-without-position #516

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

svetlyak40wt
Copy link
Contributor

This fix relates to SBCL and the case when definition relates to a function.

Here definition-source-for-emacs is called with name having string type:

(to-string obj))))))

In this case we have to use it as is instead of trying to call SYMBOL-NAME.

I've encounter this problem when attempted to setup logical pathname translations
to make SLY open local files when connected to the remote Lisp image.

Here is the Reddit discussion where everything begins:
https://www.reddit.com/r/Common_Lisp/comments/vc6hix/source_location_for_deployed_binary/

…as :file-without-position

This fix relates to SBCL and the case when definition relates to a function.

Here definition-source-for-emacs is called with name having string type:
https://github.com/joaotavora/sly/blob/b501b4335096fd4306c2c1eb86382b69e91c09e5/slynk/backend/sbcl.lisp#L872

In this case we have to use it as is instead of trying to call SYMBOL-NAME.

I've encounter this problem when attempted to setup logical pathname translations
to make SLY open local files when connected to the remote Lisp image.

Here is the Reddit discussion where everything begins:
https://www.reddit.com/r/Common_Lisp/comments/vc6hix/source_location_for_deployed_binary/
@joaotavora
Copy link
Owner

The patch looks harmless enough, but I can't understand from the long reddit thread what you are trying to do.

At any rate, if this patch is indeed fixing a bug in a real use case, it should likely be contributed to SLIME too, so let's hail its maintainer @luismbo here to see if he has anything to add.

@svetlyak40wt
Copy link
Contributor Author

Here is what I'm trying to do.

I have following setup:

  1. Application built in a docker and running inside kubernetes cluster
  2. It's sources on my local hard drive
  3. Emacs and SLY running locally

I want to use Lisp's logical pathnames to translate paths from remote machine to my local pathnames. (I know about sly-filename-translations but approach with logical pathnames seems more natural to me.

To accomplish this, I need to teach SLY to work with logical pathnames. Diff from this pull-requiest fixes a small issue, but it is not enough. I've experimented with this approach today and found that for making opening location from a stack trace, I need more changes to the SLYNK backend. Here is the draft: svetlyak40wt@35f601e).

I'll play with this approach a little to see if it can be convenient and probably will create an additional pull-request.

@svetlyak40wt
Copy link
Contributor Author

And one more. Idea of changes from svetlyak40wt@35f601e is following:

  1. application is compiled using logical pathnames like APP:src;*.*.
  2. when SLY connects to this application, it adds a logical pathname translation for host APP-LOCAL, pointing it to the local sources of the application.
  3. also, SLY registers mapping from APP to APP-LOCAL hostname in some internal variable *remote-to-local-hosts*.
  4. after that, when SLYNK sends some pathname to the SLY, it translates logical pathnames by changing APP host to APP-LOCAL and then applying TRANSLATE-LOGICAL-PATHNAME to it.
  5. SLY sees local pathname and opens the local file.

@svetlyak40wt
Copy link
Contributor Author

Probably I'm overcomplicating and there is more elegant solution for opening local files?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants