With cljr-warn-on-eval = nil, the project seems to be eval'd at repl start which causes problems

pangloss commented 3 years ago

Expected behavior

As soon as I start the REPL using cider-jack-in with Clojure, I expect to be able to be able to begin using the repl without problems.

Actual behavior

When customized with cljr-warn-on-eval set to nil, it seems that the project is automatically evaluated when the repl connects. If I run cider-load-buffer immediately after the repl starts, I'll usually get a random failures (probably due to a race condition?) somewhere in the project or its dependencies, leading to the repl env being in a bad state.

Steps to reproduce the problem

With cljr-warn-on-eval set to nil, open a project, for instance master branch of https://github.com/sicmutils/sicmutils, and go to a file, for instance src/sicmutils/simplify/rules.cljc, run cider-jack-in-clj, then when the "[nREPL] Direct connection to localhost:49525 established" appears, run cider-load-buffer.

For me, the above fails reliably as long as I run cider-load-buffer immediately, which is what I normally always do when I start up the repl. Other projects also fail the same way, so it is not at all tied to the sicmutils project, which was just a convenient example.

Environment & Version information

clj-refactor.el version information

clj-refactor 2.5.1, refactor-nrepl is unreachable

CIDER version information

;; CIDER 1.1.0snapshot, nREPL 0.8.3
;; Clojure 1.10.2, Java 16

Leiningen or Boot version

  {:extra-deps {compliment/compliment         {:mvn/version "0.3.11"}
                criterium/criterium           {:mvn/version "0.4.6"}
                nrepl/nrepl                   {:mvn/version "0.8.3"}
                cider/cider-nrepl             {:mvn/version "0.25.11"}
                refactor-nrepl/refactor-nrepl {:mvn/version "2.5.1"}
                com.gfredericks/debug-repl    {:mvn/version "0.0.12"}
                com.billpiel/sayid            {:mvn/version "0.1.0"}}

Emacs version

"GNU Emacs 27.2 (build 1, arm-apple-darwin20.3.0, Carbon Version 164 AppKit 2022.3)\n of 2021-03-28" Doom Emacs

Operating system

Current MacOS on M1

expez commented 3 years ago

Hi

You can do:

(setq cljr-eagerly-build-asts-on-startup nil)

The downside of this is that the AST will be built on-demand and so the first use of e.g. find-symbol will be slow.

pangloss commented 3 years ago

I'll try that. But why would this issue only be manifesting when warn on eval is disabled?

expez commented 3 years ago

why would this issue only be manifesting when warn on eval is disabled?

If that setting is you on no eval happens without a prompt. In particular the building of the AST, that gets triggered to run in the background, when the REPL first starts up won't occur.

pangloss commented 3 years ago

Thanks, that did fix the issue even with warn on eval disabled.

I think it would be better if cljr-eagerly-build-asts-on-startup were disabled by default. For me the eager loading was an unexpected side effect and it took some time to figure out what was going on and then track down the cause of the weird random load errors I got to that setting change.

Anyway that's my 2 cents. My problem is resolved but I'll let you close issue if you want. Thanks again for your quick response!

expez commented 3 years ago

Thanks for the feedback. You're the first to report this particular error, so I think we'll hold off a little bit on changing the default. Maybe we made a mistake picking that default, but it's been like that for years so if we change it now most of our users won't get the behavior they're used to. Rock <---- cljr maintainers ----> hard place 😄

clojure-emacs / clj-refactor.el