`julia-snail` fails

[orialb]

Trying to run julia-snail fails when called for the first time with but works on the second time (if I kill the REPL + julia-process buffer it fails again).
Here is the debug trace:

Debugger entered--Lisp error: (file-error "make client process failed" "Connection refused" :name "julia-process" :buffer #<buffer *julia* process> :host "localhost" :service 10011 :nowait nil :tls-parameters nil)
  make-network-process(:name "julia-process" :buffer #<buffer *julia* process> :host "localhost" :service 10011 :nowait nil :tls-parameters nil)
  open-network-stream("julia-process" #<buffer *julia* process> "localhost" 10011)
  julia-snail--repl-enable()
  julia-snail-repl-mode()
  julia-snail()

My system info:

• Mac OS 10.14.6 (mojave)
• Emacs:

GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, 
NS appkit-1671.20 Version 10.14.3 (Build 18D109)) of 2019-09-02

• Julia:

Julia Version 1.3.1
Commit 2d5741174c (2019-12-30 21:36 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin18.6.0)
  CPU: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, broadwell)

• I am using Spacemacs (develop branch) but I don't think it has anything to do with this.

[gcv]

Could you please try this with your firewall disabled? Maybe disconnect your machine from the network first for security.

[orialb]

this happens with the firewall disabled.

[orialb]

Not sure if it is relevant info, but if I first run JuliaSnail.start() in a separate terminal, julia-snail seems to work.

[gcv]

Interesting. Does the JuliaSnail.start(...) line appear in the Emacs-embedded REPL after you run julia-snail?

[orialb]

I think I solved this by increasing the wait time in:

julia-snail/julia-snail.el

Line 279 in 33fe6d0

(julia-snail--wait-while (not (string-equal "julia>" (current-word))) 20 5000))))

from 5000 to 50000. After this change it seems to be working.

Does the JuliaSnail.start(...) line appear in the Emacs-embedded REPL after you run julia-snail?

yes

[gcv]

Oh wow. Thanks! Can you try reverting the change I made earlier in 33fe6d0 and see if your increased timeout still works?

[orialb]

Sorry I referenced the wrong line in the comment above, I increased the timeout limit exactly in the same line you added in the latest commit, i.e I made the change in:

julia-snail/julia-snail.el

Line 242 in 33fe6d0

(julia-snail--wait-while (not (string-equal "julia>" (current-word))) 20 5000)

[gcv]

Got it, thanks. I just pushed ed7a4bf with bumped timeouts.

This is surprising, since you and I have exactly the same CPU and OS combination! Different Emacs builds though.

[orialb]

Great, I'll keep playing with this package :)

[tpapp]

I still have a problem with the first julia-snail: instead of erroring, it just keeps doing nothing and blocks the Emacs process (I get the hourglass). C-g interrupts it, and the second time it takes me to a Julia inferior process with

julia> JuliaSnail.start(10011);

in the prompt.

Let me know if I should open a separate issue. I am using the latest 20200310.2223 from MELPA, Emacs 26.3, Ubuntu 20.04.

[orialb]

I think I solved this by increasing the wait time

Sorry, I made a stupid mistake, I think increasing the wait time didn't solve it for me as well.

Not sure if it is relevant info, but if I first run JuliaSnail.start() in a separate terminal, julia-snail seems to work.

Apparently the JuliaSnail server was still running in a separate terminal (outside of emacs) all this time I was testing things although I thought I killed it. :|
Once I properly killed it I am back to the original problem, so maybe it is better to decrease back the timeout limit in order to not cause emacs to hang as the solution is probably somewhere else.

Sorry for leading you in the wrong direction.

[orialb]

I did a further check, I still think the problem is that the open-network-stream call somehow runs before the JuliaSnail server is up. I noted that the REPL buffer with the JuliaSnail.start command is already generated during the first call to julia-snail.

If after the first call to julia-snail, I evaluate (open-network-stream "julia-process" nil "localhost" julia-snail-port) it seems to be able to connect (at least it doesn't error).

Maybe julia-snail--wait-while is not working as expected? I did an experiment replacing

julia-snail/julia-snail.el

Line 242 in 33fe6d0

(julia-snail--wait-while (not (string-equal "julia>" (current-word))) 20 5000)

with (sleep-for 5), and in this case it seems to work.

[gcv]

Maybe the terminal behaves differently for you than it does for me. julia-snail--wait-while in the code snippet above looks at the terminal buffer and waits for the julia> prompt to appear, and treats that as a signal that the Snail server started properly. If the string "julia>" does not appear in the terminal (vterm) buffer and the cursor is not positioned after it, then yeah, nothing will work. It should look like this almost instantaneously:

The screenshot is of an Emacs vterm Julia Snail REPL window immediately after calling julia-snail. The prompt highlighted in red must be there. If there's a display problem, or if the cursor position does not match the screenshot, I'd like to know about it. That will point to a vterm problem. If it looks like this but the network connection fails, that would point to a different problem.

@tpapp, you wrote that the terminal hangs with julia> JuliaSnail.start(10011);. Does this mean that a subsequent julia> prompt does not appear?

[orialb]

This is what I get when using (sleep-for 5):

This is what I get with julia-snail--wait-while when I switch to the *julia* vterm buffer after it errors:

if the string "julia>" does not appear in the terminal (vterm) buffer and the cursor is not positioned after it, then yeah, nothing will work.

but in this case wouldn't julia-snail--wait-while just wait until the maxtime is reached and then try to connect to the server?
If I put there (julia-snail--wait-while (not (eq 0 1)) 20 5000) it also works, so maybe the problem actually is that "julia>" appears before the server is up so it is not a good enough signal to wait for.