This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-27
Channels
- # babashka (35)
- # beginners (85)
- # cider (14)
- # clojure (115)
- # clojure-europe (15)
- # clojure-norway (2)
- # clojure-portugal (9)
- # clojure-uk (3)
- # clojurescript (28)
- # conjure (35)
- # data-science (10)
- # datomic (4)
- # graalvm (28)
- # holy-lambda (7)
- # hyperfiddle (2)
- # jobs (2)
- # joker (4)
- # malli (9)
- # meander (6)
- # nbb (6)
- # off-topic (23)
- # pathom (3)
- # remote-jobs (1)
- # shadow-cljs (158)
- # sql (15)
- # tools-deps (35)
- # vim (5)
(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?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?
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.
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!)]}
It strongly seems like :repl-options {:init-ns user
:timeout 120000}
is the culprit. Oh no!yeah so you add “env/dev/clj” to the classpath which presumably contains a user.clj file and that blows up
exactly!@
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
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.
@U45T93RA6 Ooh, thanks. This project.clj
is actually straight from creating a new app with Luminus framework.
Much useful! I created https://github.com/luminus-framework/luminus-template/pull/566 accordingly :)