TRAMP + CLJS + tools.dep project does not work.

[johanatan]

Expected behavior

CIDER starts and works properly with CLJS over tramp.

Actual behavior

CIDER does not start properly (with either 0.21.1 or 0.22.1 of nrepl) and the following stack trace is printed:

error in process sentinel: Could not start nREPL server: Exception in thread "main" java.lang.IllegalArgumentException: no conversion to symbol
	at clojure.core$symbol.invokeStatic(core.clj:596)
	at clojure.core$symbol.invoke(core.clj:589)
	at clojure.core$map$fn__5847$fn__5848.invoke(core.clj:2742)
	at clojure.lang.PersistentVector.reduce(PersistentVector.java:343)
	at clojure.core$transduce.invokeStatic(core.clj:6883)
	at clojure.core$into.invokeStatic(core.clj:6899)
	at clojure.core$into.invoke(core.clj:6887)
	at nrepl.cmdline$__GT_mw_list.invokeStatic(cmdline.clj:217)
	at nrepl.cmdline$__GT_mw_list.invoke(cmdline.clj:215)
	at nrepl.cmdline$build_handler.invokeStatic(cmdline.clj:226)
	at nrepl.cmdline$build_handler.invoke(cmdline.clj:219)
	at nrepl.cmdline$options__GT_handler.invokeStatic(cmdline.clj:295)
	at nrepl.cmdline$options__GT_handler.invoke(cmdline.clj:286)
	at nrepl.cmdline$server_opts.invokeStatic(cmdline.clj:343)
	at nrepl.cmdline$server_opts.invoke(cmdline.clj:331)
	at nrepl.cmdline$dispatch_commands.invokeStatic(cmdline.clj:432)
	at nrepl.cmdline$dispatch_commands.invoke(cmdline.clj:425)
	at nrepl.cmdline$_main.invokeStatic(cmdline.clj:448)
	at nrepl.cmdline$_main.doInvoke(cmdline.clj:443)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:705)
	at clojure.core$apply.invokeStatic(core.clj:665)
	at clojure.main$main_opt.invokeStatic(main.clj:491)
	at clojure.main$main_opt.invoke(main.clj:487)
	at clojure.main$main.invokeStatic(main.clj:598)
	at clojure.main$main.doInvoke(main.clj:561)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:705)
	at clojure.main.main(main.java:37)

Steps to reproduce the problem

1. Create a tools.deps project on a remote machine and use the following versions:

clojure -Sdeps '{:deps {nrepl {:mvn/version "0.6.0"} cider/piggieback {:mvn/version "0.4.1"} refactor-nrepl {:mvn/version "2.4.0"} cider/cider-nrepl {:mvn/version "0.22.1"}}}' -m nrepl.cmdline --middleware '["refactor-nrepl.middleware/wrap-refactor", "cider.nrepl/cider-middleware", "cider.piggieback/wrap-cljs-repl"]'

2. Make sure TRAMP can connect to the remote machine and open a source file from it.

3. Try cider-jack-in-cljs from a source file mapped into your editor process from the remote machine.

This is extremely important! Providing us with a reliable way to reproduce a problem will expedite its solution.

Environment & Version information

Spacemacs [email protected]

CIDER version information

0.22.1

Include here the version string displayed when CIDER's REPL is launched. Here's an example:

;; CIDER 0.12.0snapshot (package: 20160331.421), nREPL 0.2.12
;; Clojure 1.8.0, Java 1.8.0_31

Emacs version

25.1.1

Operating system

Mac OS X 10.14.6

[bbatsov]

Looks like nREPL commad-line interface got some unexpected param or something like this. Hopefully that won't be hard to debug.

[vemv]

I'm closing this one mainly because it's old and not too actionable.

Anyway, it seems to me that cider-jack-in* over a TRAMP session is not intended (or at least idiomatic) usage. Instead, start your clojure process from the remote machine, and cider-connect* to it.

Cheers - V

[johanatan]

That's a pretty lousy reason. It's old because nobody worked on it or fixed it. And it's quite actionable since there's a very clear deterministic set of repro steps.

And I do not consider either of those forms more "idiomatic" than the other. CTRL+S saves a file in Windows, so does "File|Save" from the menu with a mouse. Neither is more "idiomatic".

[vemv]

Hey there,

in order for the issue to be actionable, you'd have to, for instance, copy the exact command that CIDER produces (as found in *messages*) and paste it into the the issue description. Perhaps simply by observing that command or trying to run it yourself in the appropiate machine, you'd realise what's going on.

Other than that, cider-jack-in over a tramp machine probably has an ambiguous semantic. CIDER is not, AFAIK, a tool for starting remote processes.

If you tramp into a server, presumably that server already is running an nREPL session (as defined by whatever infra tools you chose to use), so you'd simply cider-connect to it.

If that does not make sense to you, please generously describe your use case.

Cheers - V

[johanatan]

Hey there,

in order for the issue to be actionable, you'd have to, for instance, copy the exact command that CIDER produces (as found in *messages*) and paste it into the the issue description. Perhaps simply by observing that command or trying to run it yourself in the appropiate machine, you'd realise what's going on.

That's not necessary. I gave the repro steps. Whomever wants to reproduce it could follow those and produce the data you want (if they were interested in fixing this).

Other than that, cider-jack-in over a tramp machine probably has an ambiguous semantic. CIDER is not, AFAIK, a tool for starting remote processes.

Tools do what tools do. If you want to argue that a tool shouldn't do x, y or z, you might want to put forward some kind of argument of substance beyond "CIDER is not a tool for that". In my opinion, it would be very useful if CIDER did start a remote process for a jack-in request against a remote file.

If you tramp into a server, presumably that server already is running an nREPL session (as defined by whatever infra tools you chose to use), so you'd simply cider-connect to it.

That's not so. TRAMP requires SSH (or one of a handful of other protocols). It has no relation whatsoever with nREPL.

If that does not make sense to you, please generously describe your use case.

The use case is simple. I have a file in Emacs opened via TRAMP. I want to quickly and easily start a process running the project containing that file so that I can debug it. It's exactly what a user would want to do with a file in that situation and it's exactly what jack-in is used for in all other file cases. That the file happens to be "remote" is not a concern the user should care about (or be forced to care about by some random OSS maintainer's sense of what is "appropriate" or "aesthetic").

[vemv]

We cannot proceed without at least some degree of respect, and debug data such as the one that was politely asked to you.