Closed bbatsov closed 5 years ago
wrt docs: That sounds good, I will add that.
wrt patching transport.clj
:
Everything works fine as a normal uberjar. nrepl itself isn't the problem.
When trying to build the Graal native image with the 25ms startup time, Graal does something weird with the bytecode produced by locking
that fails when trying to lock on an object closed over by a fn, so I patched it to lock on a global var instead. This issue (or at least this error) comes up frequently when using Graal with Clojure, so I had to patch tools.cli as well. Hopefully the next release of Graal will fix it.
lein repl
is somehow injecting a different version of nrepl - I don't understand how - so then I can't run the repl for development. I get No such var: nrepl.transport/uri-scheme
. That's why I need the older leiningen, which uses tools.nrepl version so they do not conflict. I could use the same version of nrepl as leiningen, but that seems brittle and like it would mask the issue.
It's possible that I could patch nrepl to use agents instead of locking for serializing calls to .write, but having the extra threads just to write seems icky.
lein repl is somehow injecting a different version of nrepl - I don't understand how - so then I can't run the repl for development. I get No such var: nrepl.transport/uri-scheme. That's why I need the older leiningen, which uses tools.nrepl version so they do not conflict. I could use the same version of nrepl as leiningen, but that seems brittle and like it would mask the issue.
When do you get this? I'm pretty certain that should be working with nREPL 0.5.3 and Lein 2.8.3.
[jfelice@C02X421DJHD4 rep(develop)]$ lein version
Leiningen 2.8.3 on Java 1.8.0_192 GraalVM 1.0.0-rc10
[jfelice@C02X421DJHD4 rep(develop)]$ lein repl
Reflection warning, nrepl/middleware/interruptible_eval.clj:125:43 - reference to field getCause can't be resolved.
Reflection warning, nrepl/middleware/load_file.clj:87:43 - reference to field recv on java.lang.Object can't be resolved.
Reflection warning, nrepl/middleware/load_file.clj:88:51 - call to method recv on java.lang.Object can't be resolved (no such method).
Reflection warning, nrepl/middleware/load_file.clj:93:32 - call to method send on java.lang.Object can't be resolved (no such method).
Reflection warning, nrepl/server.clj:135:25 - reference to field getLocalPort can't be resolved.
Exception in thread "main" Syntax error compiling at (/private/var/folders/pq/k0s7p0bx7lz9nn1sk5h3nzymty834y/T/form-init9107981317154113190.clj:1:2804).
at clojure.lang.Compiler.analyze(Compiler.java:6808)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3820)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7108)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7108)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7108)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6118)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7106)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2829)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7106)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7094)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6118)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6436)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7106)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6745)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6120)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5467)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4029)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7104)
at clojure.lang.Compiler.analyze(Compiler.java:6789)
at clojure.lang.Compiler.eval(Compiler.java:7173)
at clojure.lang.Compiler.eval(Compiler.java:7166)
at clojure.lang.Compiler.eval(Compiler.java:7166)
at clojure.lang.Compiler.load(Compiler.java:7635)
at clojure.lang.Compiler.loadFile(Compiler.java:7573)
at clojure.main$load_script.invokeStatic(main.clj:452)
at clojure.main$init_opt.invokeStatic(main.clj:454)
at clojure.main$init_opt.invoke(main.clj:454)
at clojure.main$initialize.invokeStatic(main.clj:485)
at clojure.main$null_opt.invokeStatic(main.clj:519)
at clojure.main$null_opt.invoke(main.clj:516)
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)
Caused by: java.lang.RuntimeException: No such var: nrepl.transport/uri-scheme
at clojure.lang.Util.runtimeException(Util.java:221)
at clojure.lang.Compiler.resolveIn(Compiler.java:7387)
at clojure.lang.Compiler.resolve(Compiler.java:7357)
at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7318)
at clojure.lang.Compiler.analyze(Compiler.java:6768)
... 49 more
I'm using 0.5.1
though... somehow with lein repl
, I'm getting a different version side-loaded. (If I could tell lein repl
which version to use, that would be great! I haven't been able to find any options that it would honor.)
Do you have something in profiles? Or project.clj? Or some dep pulling the older nREPL version?
0.5.1 doesn't have this var, it was added only in 0.5.3. But 0.5.3 is hard dependency of Lein 2.8.3, which really puzzles me.
(If I could tell lein repl which version to use, that would be great!
Adding an nREPL dep to your :repl
profile should do this, btw.
@bbatsov right... OK, let's back up :) ...
I have 0.5.1 as a project dependency for rep, and I have copied transport.clj
from 0.5.1 into my source directory and changed it to make it work with Graal. lein repl
is loading 0.5.3, but since my hacked 0.5.1 transport.clj
is on my source path, it overrides just the transport.clj from 0.5.3, hence the exception above. (my 0.5.1 doesn't have uri-scheme, 0.5.3 does have it, and presumably nrepl.core or something calls transport/uri-scheme
).
I could upgrade my hacked transport.clj
to 0.5.3's version, and this would work, since the versions would match. The problem, though, is this is brittle because it means that I'm running my tests with a version of nrepl that's coming from somewhere I don't control, even though builds use the version I specify. The next time lein repl
decides to use a new version, it would break.
I've just tried adding :profiles {:repl {:dependencies [[nrepl/nrepl "0.5.1"']]}}
to my project.clj
and I still get the exception. I've also tried lein pprint
to show me what profile is adding nrepl 0.5.3, and it doesn't show me 0.5.3 anywhere. Which I take to mean that the version to side-load is hard-coded somewhere in leiningen.
If leiningen is somehow enforcing that 0.5.3 is the minimum version (instead of the precise version), and otherwise project dependencies used, that would be neat. I could upgrade the project to 0.5.3 and not worry about things not working later.
(Note: just upgraded it to 0.5.3, but I think I need to pin leiningen to 2.8.3 now, right?)
After reading the docs I can suggest a couple of things:
rep
by shelling out to itBtw, I was puzzled about the lein remark and the fact you had to patch transport.clj - doesn't this work fine with Lein 2.8.3 and nREPL 0.5.3 that's bundled there?