Non-deterministic compilation errors on startup

[malcolmsparks]

Expected behavior

(dev) should work without errors

Actual behavior

(dev) sometimes yields errors.

See clj-commons/byte-streams#25

A sample:

** <2016-11-27 Sun 10:57>: Started repl from shell
(dev): ok
(go): ok
(reset): ok
** <2016-11-27 Sun 11:00>: Started repl from emacs/cider
(dev): ok
(go):
   Error in server model: [nil [nil [nil (named [nil nil nil nil nil
   [nil (named (not (matches-some-precondition? false)) "Matched")]
   nil nil nil nil nil nil nil] "Matched")] nil]]
   {:error [nil [nil [nil (named [nil nil nil nil nil [nil (named (not (matches-some-precondition? false)) "Matched")] nil nil nil nil nil nil nil] "Matched")] nil]]}

                  core.clj: 4617  clojure.core/ex-info
                  core.clj: 4617  clojure.core/ex-info
                vhosts.clj:   52  bidi.vhosts/vhosts-model
                vhosts.clj:   49  bidi.vhosts/vhosts-model
               RestFn.java:  137  clojure.lang.RestFn/applyTo
** <2016-11-27 Sun 11:02> Started repl from shell, this time src/yada
(dev) ok
(go) ok
(reset) ok

** <2016-11-27 Sun 11:03> started from emacs
worked


** <2016-11-27 Sun 12:05> started from emacs, same error as <2016-11-27 Sun 11:00>

** <2016-11-27 Sun 12:40> started from emacs
user> (dev)
CompilerException java.lang.RuntimeException: No such var: s/defschema, compiling:(phonebook/schema.clj:4:1)
user>

** <2016-11-27 Sun 12:41> started from emacs, from a non-dropbox clone (yada2)
user> (dev)
CompilerException java.lang.RuntimeException: No such var: charset/charset, compiling:(yada/body.clj:43:30)
user>


** <2016-11-27 Sun 12:42> Stopped dropbox

** <2016-11-27 Sun 12:42> started from emacs, from a non-dropbox clone (yada2)
user> (dev)
CompilerException java.lang.RuntimeException: No such var: charset/charset, compiling:(yada/body.clj:43:30)
user>


** <2016-11-27 Sun> started from shell - all ok

** <2016-11-27 Sun 12:47> started from shell - all ok

** <2016-11-27 Sun 12:49> started from shell - all ok

** <2016-11-27 Sun 15:00> started from shell - all ok

** <2016-11-27 Sun 15:07> started from shell in headless mode, connected via shell, still ok

Steps to reproduce the problem

$ git clone git@github.com:juxt/yada

Ensure [refactor-nrepl "2.2.0"] is in your .lein/profiles.clj

Using emacs, CIDER 0.14.0, clojure-jack-in
Type (dev) from the REPL

Environment & Version information

clj-refactor.el and refactor-nrepl version information

2.2.0

CIDER version information

0.14.0

Include here the version string displayed when
CIDER's REPL is launched. Here's an example:

;; Connected to nREPL server - nrepl://localhost:39071
;; CIDER 0.14.0 (Berlin), nREPL 0.2.12
;; Clojure 1.8.0, Java 1.8.0_112

Leiningen or Boot version

2.7.1

Emacs version

25.1.1

Operating system

Arch Linux - kernel version 4.8.11-1-ARCH x86_64

[expez]

Can you try running our snapshot elisp and removing any mention of refactor-nrepl from your profile? Our middleware dep is injected automagically, just like for CIDER, in the latest snapshot and that might give you a more favorable ordering.

[benedekfazekas]

/cc @SevereOverfl0w

played with this a bit. I can only reproduce the problem if I run (dev) while the ASTs are being built. This is a know problem, see #134.

At this point I can only offer a workaround to enable clj-refactor for yada. Set

;; feel free to eval the project on startup
(setq cljr-warn-on-eval nil)

This enables building and caching ASTs at start up. Note that cljr-eagerly-build-asts-on-startup needs to be t (it is t by default so it should not be changed to nil).

Also if you set cljr--debug-mode to t there will be a message when the AST generation is finished: "AST index updated". After this message (dev) and (go) should work without any problems.

Please also note that these variables can be set on a per project basis: http://endlessparentheses.com/a-quick-guide-to-directory-local-variables.html

If you are interested in the context, reasons etc of this problem more details available on #134.

[malcolmsparks]

That's really helpful, thanks. I'll try the workaround - I don't mind the extra wait for the ASTs.

As an aside, I was chatting about this issue with @bbatsov last night (in person, we were both at f(by) in Minsk), and he suggested it was due to the AST building.

[expez]

Feel free to re-open if the workaround doesn't work, but I'm closing this for now as there isn't much we can do about AST generation since that's delegated to tools.analyzer.

Long term we're hoping to find a more robust solution, but for the time being none of us has the time to write a new analyzer.