Fork me on GitHub
#cider
<
2022-07-27
>
Jeongsoo Lee17:07:55

(Cross-posted from #clojure) If I have a clojure project with compilation errors such as failing to macroexpand, and want to load it in an nREPL instance in CIDER, nREPL fails to start (of course!) with the message like:

error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: Exception in thread "main" Syntax error macroexpanding at (chulsooboardv2/handler.clj:1:1).
In this case, I have to debug this project without a REPL, which is painful. Just like Emacs started with malformed init.el, I would like a rudimentary REPL instance running that can be used to inspect the issue. Is there a way to achieve this?

dpsutton17:07:54

I don’t remember the middleware loading code on your behalf during startup. Do you use any profiles when starting up? or have anything in user.clj that does anything wonky?

Jeongsoo Lee17:07:23

I have fixed the issue itself just now: It was caused by an outdated symbol referring to a renamed namespace in an ns macro. The nREPL instance was started via M-x cider-jack-in-clj. I guess this triggers lein repl , which in turn triggers firing up an nREPL instance.

dpsutton17:07:00

ah. well then running clojure didn’t tell you anything interesting

dpsutton17:07:17

does your project.clj have some startup namespace in its config?

Jeongsoo Lee17:07:53

Oops, although it does not contain any startup namespaces, the dev profile was declared as:

:project/dev  {:jvm-opts ["-Dconf=dev-config.edn"]
                  :dependencies [[org.clojure/tools.namespace "1.2.0"]
                                 [pjstadig/humane-test-output "0.11.0"]
                                 [prone "2021-04-23"]
                                 [ring/ring-devel "1.9.5"]
                                 [ring/ring-mock "0.4.0"]]
                  :plugins      [[com.jakemccrary/lein-test-refresh "0.24.1"]
                                 [jonase/eastwood "0.3.5"]
                                 [cider/cider-nrepl "0.28.4"]]
                  :source-paths ["env/dev/clj"]
                  :resource-paths ["env/dev/resources"]
                  :repl-options {:init-ns user
                                 :timeout 120000}
                  :injections [(require 'pjstadig.humane-test-output)
                               (pjstadig.humane-test-output/activate!)]}

Jeongsoo Lee17:07:40

It strongly seems like                  :repl-options {:init-ns user
                                 :timeout 120000}
is the culprit. Oh no!

dpsutton17:07:41

yeah so you add “env/dev/clj” to the classpath which presumably contains a user.clj file and that blows up

dpsutton17:07:07

setting an init-ns to user doesn’t do anything since that’s the default. I think just having a user.clj on the classpath is what is killing you

Jeongsoo Lee17:07:56

Ah, I think I get it. at {classpath}/env/dev/clj/user.clj, the ns macro at the top requires the core.clj of my entire application, and requiring that core.clj triggered an require chain down the dependency tree which finally triggered loading the file with the problematic namespace.

👍 1
vemv17:07:38

btw, that Eastwood is far behind 1.2.4 , you might want to check out what it finds now

Jeongsoo Lee17:07:58

@U45T93RA6 Ooh, thanks. This project.clj is actually straight from creating a new app with Luminus framework.

👀 1