Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc improvement ideas #1

Closed
bbatsov opened this issue Jan 3, 2019 · 8 comments
Closed

Doc improvement ideas #1

bbatsov opened this issue Jan 3, 2019 · 8 comments

Comments

@bbatsov
Copy link

bbatsov commented Jan 3, 2019

After reading the docs I can suggest a couple of things:

  • explain in more details that the client connects to the server every time, as that's not really apparent
  • explain a bit how editors can leverage rep by shelling out to it

Btw, 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?

@eraserhd
Copy link
Owner

eraserhd commented Jan 3, 2019

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.

@bbatsov
Copy link
Author

bbatsov commented Jan 3, 2019

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.

@eraserhd
Copy link
Owner

eraserhd commented Jan 3, 2019

[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

@eraserhd
Copy link
Owner

eraserhd commented Jan 3, 2019

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.)

@bbatsov
Copy link
Author

bbatsov commented Jan 3, 2019

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.

@bbatsov
Copy link
Author

bbatsov commented Jan 3, 2019

(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.

@eraserhd
Copy link
Owner

eraserhd commented Jan 3, 2019

@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.

@eraserhd
Copy link
Owner

eraserhd commented Jan 3, 2019

(Note: just upgraded it to 0.5.3, but I think I need to pin leiningen to 2.8.3 now, right?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants