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

Already on GitHub? Sign in to your account

Setting *print-level* in :repl-options :init causes syntax errors with lein repl :headless and nrepl load-file #952

mjwillson opened this Issue Jan 23, 2013 · 10 comments


5 participants

The issue shows up for me when using nrepl.el to start a lein repl :headless. The repl starts up OK, but trying to load files in the repl triggers mysterious syntax errors which (by process of elimination) go away if I remove (set! *print-length* 10) (set! *print-level* 5) from :repl-options :init in my .lein/profiles.clj.

It seems that the code to be evaluated is being truncated by the print-level setting.

The issue showed up after upgrading from 2.0.0-preview10 to the 2.0.0 release.

I initially reported this for reply, who had a similar issue in the past: trptcolin/reply#99 .

The conclusion there was that it's most likely leiningen's fault, possibly due to this commit: d576345 which was made to fix another :repl-options :init related issue I reported here: #788

The issue is only reproducible for me by loading files in the repl (e.g. via nrepl-load-file in nrepl.el). This appears to be sending a "load-file" command to nrepl rather than say an "eval" command.


kingtim commented Jan 23, 2013

Can you give some more details on the errors you are getting and provide some steps to repro?

Sure. The errors I'm seeing are syntax errors, e.g. this one:

RuntimeException Unmatched delimiter: )
    clojure.lang.Util.runtimeException (Util.java:170)
    clojure.lang.LispReader$UnmatchedDelimiterReader.invoke (LispReader.java:1087)

I've also seen

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: ... in this context, compiling:(NO_SOURCE_PATH:1)
 at clojure.lang.Compiler.analyze (Compiler.java:6281)
    clojure.lang.Compiler.analyze (Compiler.java:6223)
    clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:5618)

and others, although if my hunch is correct they'll probably vary depending on the actual code you're trying to evaluate (which got truncated somehow). Note that this is essentially the same error I get from trying to read-string and eval on output from print-level/length-constrained pprint like "(#)" or "(...)"

I've not been able to replicate by evaluating snippets of code or lines of input in nrepl, only by running nrepl-load-file or nrepl-load-current-buffer in nrepl.el. These seem to be sending some kind of special "load-file" command to nrepl -- the relevant lines of code here: https://github.com/kingtim/nrepl.el/blob/master/nrepl.el#L894 in nrepl-send-load-file.

To replicate, try lein 2.0.0 with a ~/.lein/profiles.clj of:

  {:init (do (set! *print-length* 1)
               (set! *print-level* 1))}}}

And try loading a file in emacs with nrepl.el via nrepl-load-file or nrepl-load-current-buffer (C-c C-k) in a clojure project with a file in it with some syntax deeper than one level deep! Apologies I'm not sure how to replicate without emacs, but I don't think nrepl.el is at fault since the issue showed up after upgrading leiningen.



kingtim commented Jan 23, 2013

Great thanks. That should give me enough to go on.


trptcolin commented Jan 23, 2013

This might be a tools.nrepl issue - REPLy doesn't use the load-file op, but I can imagine a line like this one or this one needing to have these vars re-bound. @cemerick - I can make some time to look into that in tools.nrepl in the next day or so, if you concur.

Thanks for the input from everyone! Half the problem with these toolchain issues seems to be tracking down which of about 5 different libraries is responsible :)


cemerick commented Jan 25, 2013

@trptcolin Yup, that's exactly what's needed. Patch welcome, or you can open an issue.


trptcolin commented Jan 28, 2013

@cemerick I had a rough time getting this reproduced via nREPL test cases. I'll see if I can get set up with Emacs / nrepl.el sometime soon, but feel free to beat me to it if you have time first.


technomancy commented Mar 21, 2013

Sorry; not sure I follow entirely; is this a bug in nREPL rather than Leiningen?


trptcolin commented Mar 21, 2013

We're pretty sure it's nREPL, yeah - I still haven't gotten around to getting nrepl.el set up to reproduce a fix locally.


trptcolin commented Mar 21, 2013

Closing this, moving discussion to http://dev.clojure.org/jira/browse/NREPL-41

@trptcolin trptcolin closed this Mar 21, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment