Can't start cljs REPL: Unable to resolve symbol: run in this context

Question

Can't start cljs REPL: Unable to resolve symbol: run in this context

conan opened this issue 9 years ago · 13 comments

I can't start a cljs REPL at the moment, I get an error when running the (run) command:

CompilerException java.lang.RuntimeException: Unable to resolve symbol: run in this context, compiling:(C:\Users\conan\.IntelliJIdea14\system\tmp\form-init5027235878919357881.clj:1:1)

I'm in my project-name.server namespace. I've tried in a Ubuntu VM, but also in Intellij on Windows, where I get this additional error when the REPL starts:

#<CompilerException java.lang.RuntimeException: No such var: piggieback/cljs-eval

That looks pretty suspicious to me! Here are my relevant dependencies:

[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-3165"]

and my dev dependencies:

[[figwheel "0.2.5"]
 [figwheel-sidecar "0.2.5"]
 [com.cemerick/piggieback "0.2.0"]
 [org.clojure/tools.nrepl "0.2.10"]
 [weasel "0.6.0"]]

I get this problem in the chestnut-created project I'm working on, but also if I do a lein new chestnut and try to run it in there, so maybe it's a question for them?

Answer 1 · 2015-04-09T10:38:08.000Z

What is run?

Have you added the :repl-options configuration as described in the README?

Answer 2 · 2015-04-09T10:46:43.000Z

I have:

:repl-options {:init-ns          my-project.server
               :nrepl-middleware [cemerick.piggieback/wrap-cljs-repl]}

Answer 3 · 2015-04-09T10:51:35.000Z

Oh sorry, (run) must be a chestnut or figwheel thing. I'm new to this way of doing things and I'm not really sure where each bit comes from. Let me see if I can find it.

Answer 4 · 2015-04-09T10:55:03.000Z

OK, (run) appears to be a chestnut function, which in turn calls figwheel's autobuild, so maybe I should head over there?

Answer 5 · 2015-04-09T11:20:06.000Z

Just ran lein ancient to get everything to the latest verison, including plugins, and tried again. Here's the error (sorry for the long stacktrace):

#<CompilerException java.lang.IllegalStateException: var: #'clojure.tools.nrepl.middleware.interruptible-eval/queue-eval is not public, compiling:(cemerick/piggieback.clj:239:3)>
Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: cemerick.piggieback/wrap-cljs-repl in this context, compiling:(/tmp/form-init1725484804681408194.clj:1:2636)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.access$100(Compiler.java:38)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6050)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
        at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217)
        at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.eval(Compiler.java:6700)
        at clojure.lang.Compiler.eval(Compiler.java:6693)
        at clojure.lang.Compiler.eval(Compiler.java:6693)
        at clojure.lang.Compiler.load(Compiler.java:7130)
        at clojure.lang.Compiler.loadFile(Compiler.java:7086)
        at clojure.main$load_script.invoke(main.clj:274)
        at clojure.main$init_opt.invoke(main.clj:279)
        at clojure.main$initialize.invoke(main.clj:307)
        at clojure.main$null_opt.invoke(main.clj:342)
        at clojure.main$main.doInvoke(main.clj:420)
        at clojure.lang.RestFn.invoke(RestFn.java:421)
        at clojure.lang.Var.invoke(Var.java:383)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.Var.applyTo(Var.java:700)
        at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve var: cemerick.piggieback/wrap-cljs-repl in this context
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:659)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
        ... 34 more
Exception in thread "Thread-3" clojure.lang.ExceptionInfo: Subprocess failed {:exit-code 1}
        at clojure.core$ex_info.invoke(core.clj:4403)
        at leiningen.core.eval$fn__6725.invoke(eval.clj:236)
        at clojure.lang.MultiFn.invoke(MultiFn.java:231)
        at leiningen.core.eval$eval_in_project.invoke(eval.clj:337)
        at leiningen.repl$server$fn__10717.invoke(repl.clj:241)
        at clojure.lang.AFn.applyToHelper(AFn.java:152)
        at clojure.lang.AFn.applyTo(AFn.java:144)
        at clojure.core$apply.invoke(core.clj:624)
        at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1862)
        at clojure.lang.RestFn.invoke(RestFn.java:425)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.RestFn.applyTo(RestFn.java:132)
        at clojure.core$apply.invoke(core.clj:628)
        at clojure.core$bound_fn_STAR_$fn__4140.doInvoke(core.clj:1884)
        at clojure.lang.RestFn.invoke(RestFn.java:397)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.lang.Thread.run(Thread.java:745)
REPL server launch timed out.

Answer 6 · 2015-04-09T11:22:52.000Z

Are you using trampoline? (See #34)

Answer 7 · 2015-04-09T11:32:26.000Z

Make sure your dependency on tools.nrepl is in the :dev profile, otherwise leiningen will override it.

Answer 8 · 2015-04-09T11:52:59.000Z

@cemerick I don't think there's any trampoline involved. I'm looking at chestnut projects, and chestnut uses figwheel, which fires up using leiningen in a new jvm, and weasel, which is built to work with piggieback.

@cichli Thanks, I'd removed that by mistake. Adding it back in gets me back to the first error I had:

#<CompilerException java.lang.RuntimeException: No such var: piggieback/cljs-eval, compiling:(my_project/dev.clj:22:5)>

That namespace requires [cemerick.piggieback :as piggieback], and it calls the cljs-eval function, I guess that's a problem because that function seems to have disappeared.

Answer 9 · 2015-04-09T11:56:09.000Z

Oh! I didn't even notice your mention of cljs-eval. That's from piggieback 0.1.x. Somehow, you're getting the old stuff. Do a lein deps :tree and find out where it's coming from.

Answer 10 · 2015-04-09T11:56:26.000Z

Looks like the cljs-eval call was removed from Chestnut in this commit anyway - can you try removing that line (its only intention is to change the initial namespace of the CLJS REPL) and also updating the call to cljs-repl to remove the :repl-env bit? The signature of cljs-repl changed so it just takes the REPL env as its first arg rather than as a kwarg.

Answer 11 · 2015-04-09T12:10:55.000Z

Thanks, that seems to solve that particular problem. It seems however that chestnut has moved to a different approach, and so maybe what my legacy chestnut project is trying to do doesn't make sense with the latest code. My motivation for this was to solve 3-4 minute compilation times of cljs code, even when using figwheel's auto-reload, and I was hoping that later dependencies might address the problem. I'll close this issue as it doesn't seem like a piggieback problem.

Answer 12 · 2015-04-09T12:12:56.000Z

Thanks for your help though!

Answer 13 · 2017-01-07T18:07:46.000Z

FYI -- after a lein ancient pass on metasoarous/datsys I ran into the clojure.tools.nrepl.middleware.interruptible-eval/queue-eval is not public issue discussed above; all other things being equal, it was caused by (and could be resolved by reverting) an update of core.typed from 0.3.23 to 0.3.28.

Haven't yet tracked through the difference in dependency chains to find the root cause of that -- core.typed was pulling in a different tools.analyzer and some other potentially-suspicious-looking items, but since the project was no longer using core.typed it could just be pulled out.