Is it possible to call a remote julia REPL via TRAMP?

[aramirezreyes]

Hi!

I'm not sure if this is supported but I think it is not.
I would like to have the option to call a remote julia via TRAMP (or not), something like:

(setq julia-repl-executable-records
      '((default "julia")                  ; in the executable path
        (master "/ssh:remotehost:~/bin/julia"))) ; in the remote host.

Is this possible? Super hard to implement?

[gdkrmr]

ess has a really cool functionality called ess-remote which basically turns any process buffer into an ess session. I.e. you can start your R process however you like (via ssh or some other complex setup) and call remote-ess on the buffer.

[wraith1995]

@aramirezreyes I tried this and it doesn't work. However, looking at something like tramp-termp.el,, I get the sense that it might not be that hard to implement. I might want this feature someday so I might take a stab at it if no one else does.

[atteson]

I'd love to see this. Motivated by your tramp-term comment, I've experimented with the following:

(make-term "test" "ssh" nil "user@host" "julia")

which brings up a responsive julia process but there are issues:

1. julia doesn't seem to provide input prompts, even when passed the interactive option. This happens running from a directly not within emacs as well.
2. The colors don't appear. Again, this persists even if I pass the color option to julia.

[tpapp]

Sorry I somehow missed this issue. I will look into it, it should be possible via ssh.

[atteson]

The solution, thanks to tkluck on another thread I posted about fixing the issue for ssh, is to use the "-t" option. This works well:

(make-term "test" "ssh" nil "-t" "user@hostname" "julia")

I'm going to wrap that in some simple clothes use it for now.

[arjunv27]

Running in a docker container with:

(make-term "julia" "docker" nil "exec" "-it" "ijulia" "julia")

[tpapp]

I find that specifying an executable as

ssh -t host /path/to/julia

works fine.

I am leaving this issue open so that I don't forget adding it to the README.

[dwinkler1]

I think I am misunderstanding the last comment. Assume valid user me at remote host myhost. I am doing the following:

(use-package julia-repl
:ensure t
:init (require 'julia-repl)
:config
 ; for remote repl:
 ; ssh -t host /path/to/julia

 (setq julia-repl-executable-records
 '(
 (default "julia")                  ; in the executable path
 (remote "ssh -t me@myhost /usr/bin/julia")))
)

now I open a julia file, select remote via C-c C-v and try to execute a line and get the following error:

Process julia-remote exited abnormally with code 127
..: 1: [: ssh: unexpected operator
..: 1: exec: ssh -t me@myhost /usr/bin/julia: not found

And the *Warnings* buffer shows this:

Warning (emacs): could not capture basedir for Julia executable ssh -t me@myhost /usr/bin/julia

Just pasting the ssh command in a terminal works. Any ideas what I am doing wrong?

[dwinkler1]

I hacked something together that works for me at least. Maybe it is helpful to others:

(defun remotejl ()
(interactive)
(make-term "julia-ssh" "ssh" nil "-t" "me@myhost" "julia")
(funcall-interactively 'julia-repl-prompt-set-inferior-buffer-name-suffix '(ssh))
)

[solna86]

I am leaving this issue open so that I don't forget adding it to the README.

It would be nice to document this workflow on the README, @tpapp.

Perhaps it would also be possible to let users start an ansi-term or a vterm, ssh to a remote machine, start julia (all manually), and then turn this into a julia-repl?

[tpapp]

PRs to the docs (README) are welcome.

[solna86]

PRs to the docs (README) are welcome.

I have not been able to get this working smoothly, but if anyone can lend me a hand, I am happy to summarize everything as a PR for the README.

[Sbozzolo]

A quick workaround for the vterm backend: (setq vterm-tramp-shells '(("ssh" "julia"))).

A better solution would be to extend the julia-repl--make-buffer to locally bind vterm-tramp-shell to the correct value for the correct TRAMP method.

(One would also have to strip the paths from the ssh:XXX part when activating envs, sending paths)