Remote REPLs with julia-repl in emacs

Tooling
,
1

I’m having difficulty using julia-repl to run a remote REPL with tramp in emacs. I like julia-repl better than ESS because it uses the emacs term which allows use of the package manager, etc. in the REPL. However, it seems that julia-repl uses the emacs function make-term which uses start-process (instead of start-file-process) which, it seems, doesn’t allow one to change the default-directory variable. Has anyone managed to solve this?

I don’t see an easy way to change julia-repl to fix this. I think the emacs builtin file term.el would have to change.

2 Likes
2

See this issue for julia-repl which suggests it’s not currently possible. If any comint-based solution works fine for you and you don’t mind some un-anchored elisp code floating around, you could use the inferior-julia improvements I hacked together (I plan to clean it up and package it eventually); it has support for package manager, help, and shell modes.

1 Like
3

This should actually be possible via ssh, I just need to think about how to implement this nicely.

2 Likes
4

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.

2 Likes
5

Yes, eventually I plan to make ssh work nice with julia-repl; it’s just that at the moment I am focusing on integrating libvterm. Making a terminal is actuallly trivial; ssh takes the place of the Julia executable and then the arguments are just appended to the command line.

It’s the user interface that is the tricky part and I want to think a bit about making that robust, so that one can reattach to an existing process (tmux, screen).

4 Likes
6

I’ve been using dtach with R processes for a similar setup. I open the file via TRAMP, start a shell, reattach the process and run ess-remote. I’m sure this can somehow be automated in emacs lisp but I’m terrible at that. If someone could point me in the right direction I could try to put something together for julia-repl.

1 Like
7

I’ve been experimenting recently with adding remote support to julia-snail (see discussion here ).

I have been using the code in this branch (on my fork, it is not part of julia-snail yet) for the last week and it has been working quite well so far. In addition to the REPL one can get code completion when working on the remote TRAMP files.
It is all still experimental and rough, the code can definitely be improved and cleaned, but it is already usable for real work for me. If anyone wants to give it a try I’m happy to add some explanation of how to set it up.

2 Likes
8

I’m working on getting a similar setup working – is there anyway you can elaborate on where this line goes/what it means for someone just getting into emacs (but familiar with ssh etc.)?

9

Unfortunately, I ended up going a different direction. I can’t remember if that worked for me or not.

10

Basically,

  1. set up passwordless remote login on somehost with the Julia executable available at /path/julia,
  2. make sure that from the command line (outside Emacs)
    ssh -t somehost /path/julia
    works,
  3. add an executable record as
    (remote "ssh -t somehost /path/julia")

and select it.

I will add it to the README at some point.

2 Likes
11

Thanks Tamas – it was #3 that was my hangup, but I don’t know why it didn’t occur to treat this as running a different executable (eg version of julia). I’ll give this a try!

12

Somehow it looks like this isn’t quite parsing correctly. I’m getting an error like:

..: line 0: [: too many arguments
..: /path/to/juliafile/ssh -t somehost /path/julia: No such file or directory
..: line 0: exec: /path/to/juliafile/ssh -t somehost /path/julia: cannot execute: No such file or directory

Process julia-remote exited abnormally with code 126

I’ve also made sure to confirm that other executable records are working properly on my local machine, as described in the docs. Any advice would be appreciated!

13

I think that will be the make-term calling convention — I will look into it later; please kindly open an issue so that it does not get lost.

In the meantime, you can also try the experimental vterm backend:

which should work.

1 Like