clojure-emacs / squiggly-clojure

Flycheck checker for Clojure, using eastwood and core.typed.
GNU General Public License v3.0
204 stars 25 forks source link

reload of function or code is not working. #40

Closed EricGebhart closed 8 years ago

EricGebhart commented 8 years ago

This is a very strange problem. I have looked through the nrepl messages, I have run the squiggly code in the repl. It looks fine. But when squiggly nrepl messages happen a stacktrace always results afterwards. Disabling squiggly in emacs causes everything to work fine. Except that there is no more squiggly.

There is much more information in the README.

There is a simple repo to reproduce this problem.

https://github.com/EricGebhart/cascalog-check

EricGebhart commented 8 years ago

If there is something I can break on or debug I'd be happy to do so. Currently there are no errors to catch so debug-on-error does nothing. It took a while to get this far. I can finally get some work done without squiggly. But it would be nice to have it back.

EricGebhart commented 8 years ago

Squiggly seems be somehow interfering with cider's load. making a change, requires the code to be saved and reloaded before the non-changed function works without a stack trace. Doing two reloads in a row where the first one prompts to save also works. I have also added a minimalist .emacs which replicates the problem.

pnf commented 8 years ago

I cloned your repo and, I believe, followed the instructions, but I am unable to reproduce the problem. As you suggested, it was necessary to load core.clj a few times initially to make the FlowException message go away. Then I added (defn t [x] x) without problems. Reloading caused no problems either. To verify squiggling, I changed it to (defn t [x] (+ 1 2) x) and got the two expected suggestions. Purposely introducing an error by changing defn to def, I reloaded got the expected clojure stack trace. I restored the defn, reloaded, got the FlowException, reloaded, and everything was back to normal. I have not been able to cause an unexpected stack trace.

pnf commented 8 years ago

I should note that I am using a local clone of cider, fully up to date with origin as of ten minutes ago.

EricGebhart commented 8 years ago

It seems you have reproduced it perfectly. For me the FlowException shows as a stacktrace. Either way the error shouldn't be there. There is no reason for the FlowException. If I turn off squiggly, the Exceptions go away. I also shouldn't have to reload the whole file to get rid of the flow exception in code that hasn't changed.

Turn off squiggly and compare the behavior. There won't be any Flow Exceptions and you won't have to reload the code again and again.

Squiggly does seem to be working, in that I get recommendations and so forth. But when I turn squiggly off the exceptions go away. Adding and loading a function works fine, no reloading of the file is necessary.

I'm not convinced it's squiggly, but I don't know where to look. It's suspicious that when I turn off squiggly the behavior changes for the better albeit without squiggly which I really like.

pnf commented 8 years ago

Ok. I for some reason thought you were talking about an emacs stacktrace. I wasn't sure exactly what you meant by "turn off squiggly", but I turned off flycheck entirely, which certainly means that nothing in the squiggly namespace will run unless you run it manually. I've found I can reproduce the FlowException by running the eastwood check manually, i.e.

(cats foo-catv) ;; (["foo" [3 100 8 12] true])
(eastwood.lint/lint {:source-paths ["src"], :namespaces ['cascalog-check.core], :continue-on-exception true, :exclude-linters [:unlimited-use]})
(cats foo-catv) ;; throws
;; reload manually
(cats foo-catv) ;; (["foo" [3 100 8 12] true])

Read https://github.com/jonase/eastwood#running-eastwood-in-a-repl, which outlines how Eastwood evals forms based on your source code and warns that "Eastwood bugs, especially in the portion up to generating new forms to be evaluated, could lead to incorrect Clojure code being loaded into a running JVM." I don't know too much about Cascalog, but I'm under the impression that it makes extensive use of macros, which would be just the thing to "confuse" code analyzers.

Unless I'm missing something, this issue should probably be migrated to Eastwood. While the official response might be that you shouldn't be count on support for "experimental" support of in-repl use, @jonase might be interested in getting to the bottom of this

EricGebhart commented 8 years ago

OK. Thank you for your time and effort. It would have taken me a while to get any further than I did.

Cascalog does have a lot of macros. I've seen eastwood have problems with other cascalog files, but as far as I know, it hasn't been crashing. It sometimes gives false squigglys. I will continue there.

Thank you for writing flycheck-clojure. I really like having it.

pnf commented 8 years ago

np. I'm glad I could help. My day job does not involve Clojure, and it's really gratifying to be able to contribute something apparently useful to the community without actually writing very much code!