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

(wrong-number-of-arguments (4 . 4) 0) #46

Closed manuel-uberti closed 7 years ago

manuel-uberti commented 7 years ago

Hi,

first of all thanks for this checker.

I just started a new project, using the Luminus template. After CIDER is up and running with C-c M-j, upon editing a .clj file I keep getting this error:

Debugger entered--Lisp error: (wrong-number-of-arguments (4 . 4) 0)
  #[1028 "\301\303\304\305\302\300$\"\207" [clojure-cider-eastwood #[128 "\301\302\300#\207" [[cl-struct-flycheck-syntax-check #<buffer home.clj> clojure-cider-eastwood "22" "/home/manuel/projects/mallory/src/clj/mallory/routes/"] apply flycheck-report-buffer-checker-status] 5 "\n\n(fn &rest ARGS)"] #[257 "\300\301\"\207" [format "(do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-ew '%s))"] 4 "\n\n(fn NS)"] errored format "Form %s of checker %s failed: %s"] 11 "\n\n(fn BUFFER EX ROOTEX SESS)"]()
  #[257 "\307\310\"\307\311\"\307\312\"\307\313\"\307\314\"\307\315\"\307\316\"\317\300!\2038

Some extra info that might help to debug the issue:

pnf commented 7 years ago

Could you show me the result of running the (do (require ... ) form straight from the REPL?

On Feb 19, 2017, at 9:34 AM, Manuel Uberti notifications@github.com wrote:

Hi,

first of all thanks for this checker.

I just started a new project, using the Luminus template. After CIDER is up and running with C-c M-j, upon editing a .clj file I keep getting this error:

Debugger entered--Lisp error: (wrong-number-of-arguments (4 . 4) 0)

[1028 "\301\303\304\305\302\300��$\"\207" [clojure-cider-eastwood #[128 "\301\302\300�#\207" [[cl-struct-flycheck-syntax-check # clojure-cider-eastwood "22" "/home/manuel/projects/mallory/src/clj/mallory/routes/"] apply flycheck-report-buffer-checker-status] 5 "\n\n(fn &rest ARGS)"] #[257 "\300\301�\"\207" [format "(do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-ew '%s))"] 4 "\n\n(fn NS)"] errored format "Form %s of checker %s failed: %s"] 11 "\n\n(fn BUFFER EX ROOTEX SESS)"]()

[257 "\307�\310\"\307�\311\"\307�\312\"\307�\313\"\307�\314\"\307��\315\"\307��\316\"\317\300!\2038

Some extra info that might help to debug the issue:

OS: Debian Jessie Emacs version: GNU Emacs 26.0.50 (build 1, x86_64-debian-linux-gnu, GTK+ Version 3.14.5) of 2017-02-18 (commit 861ff2b) CIDER version: CIDER 0.15.0snapshot (package: 20170129.1941) flycheck-clojure-dep-version: 0.1.7 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

manuel-uberti commented 7 years ago

This is what I get:

user> (do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-ew '%s))

;; => "[]"

Restarted Emacs, and after C-c M-j I now get:

user> (do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-ew '%s))
FileNotFoundException Could not locate squiggly_clojure/core__init.class or squiggly_clojure/core.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.  clojure.lang.RT.load (RT.java:456)

Complete stacktrace:


1. Unhandled java.io.FileNotFoundException
   Could not locate squiggly_clojure/core__init.class or
   squiggly_clojure/core.clj on classpath. Please check that namespaces with
   dashes use underscores in the Clojure file name.

                   RT.java:  456  clojure.lang.RT/load
                   RT.java:  419  clojure.lang.RT/load
                  core.clj: 5893  clojure.core/load/fn
                  core.clj: 5892  clojure.core/load
                  core.clj: 5876  clojure.core/load
               RestFn.java:  408  clojure.lang.RestFn/invoke
                  core.clj: 5697  clojure.core/load-one
                  core.clj: 5692  clojure.core/load-one
                  core.clj: 5737  clojure.core/load-lib/fn
                  core.clj: 5736  clojure.core/load-lib
                  core.clj: 5717  clojure.core/load-lib
               RestFn.java:  142  clojure.lang.RestFn/applyTo
                  core.clj:  648  clojure.core/apply
                  core.clj: 5774  clojure.core/load-libs
                  core.clj: 5758  clojure.core/load-libs
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  648  clojure.core/apply
                  core.clj: 5796  clojure.core/require
                  core.clj: 5796  clojure.core/require
               RestFn.java:  408  clojure.lang.RestFn/invoke
                      REPL:   10  user/eval44021
                      REPL:   10  user/eval44021
             Compiler.java: 6927  clojure.lang.Compiler/eval
             Compiler.java: 6916  clojure.lang.Compiler/eval
             Compiler.java: 6890  clojure.lang.Compiler/eval
                  core.clj: 3105  clojure.core/eval
                  core.clj: 3101  clojure.core/eval
                  main.clj:  240  clojure.main/repl/read-eval-print/fn
                  main.clj:  240  clojure.main/repl/read-eval-print
                  main.clj:  258  clojure.main/repl/fn
                  main.clj:  258  clojure.main/repl
                  main.clj:  174  clojure.main/repl
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  646  clojure.core/apply
                  core.clj:  641  clojure.core/apply
                regrow.clj:   18  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  646  clojure.core/apply
                  core.clj: 1881  clojure.core/with-bindings*
                  core.clj: 1881  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   85  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   55  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  222  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
    interruptible_eval.clj:  190  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
                  AFn.java:   22  clojure.lang.AFn/run
   ThreadPoolExecutor.java: 1142  java.util.concurrent.ThreadPoolExecutor/runWorker
   ThreadPoolExecutor.java:  617  java.util.concurrent.ThreadPoolExecutor$Worker/run
               Thread.java:  745  java.lang.Thread/run
pnf commented 7 years ago

Well, that's (your first, pre-edited response) what we expect, so the problem has to be in the transmission of this boring result back to emacs. Out of curiosity, did you get a "things will break" warning when cider started? What I'm beginning to suspect is a conflict between the dependencies of the latest cider-nrepl snapshot and those of core.async.

On Feb 19, 2017, at 12:37 PM, Manuel Uberti notifications@github.com wrote:

This is what I get:

user> (do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-ew '%s))

;; => "[]" ― You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

manuel-uberti commented 7 years ago

No, no issue with CIDER. Neither in the *Messages* buffer, nor in the REPL.

pnf commented 7 years ago

Ok. I won't have access to a real computer for a few hours, but in the mean time, a few more questions.

  1. Definitely no message when cider starts about a mismatched cider-nrepl version? I ask because others have reported this.
  2. Are you setting the dependencies in a profile or via jack-in? Whichever it is, can you try the other one?

On Feb 19, 2017, at 12:58 PM, Manuel Uberti notifications@github.com wrote:

No, no issue with CIDER. Neither in the Messages buffer, nor in the REPL.

― You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

anujsrc commented 7 years ago

@pnf - I am also facing the same issue. If we add the squiggly dependency in ~/.lein/profiles.clj as mentioned in https://github.com/clojure-emacs/squiggly-clojure/issues/29 and https://github.com/clojure-emacs/squiggly-clojure/issues/39, the checker error goes way but I start getting the CIDER warning as mentioned here- https://github.com/clojure-emacs/cider/issues/1728 - It does say things may break as you pointed out.

manuel-uberti commented 7 years ago

@pnf

  1. Yes, no message at all about the mismatched cider-nrepl version
  2. I am setting the dependencies via jack-in. If I try the other way, I get the same behaviour as @anujsrc.
pnf commented 7 years ago

I have been completely unsuccessful determining how cider determines what version of cider-nrepl is being used. (@bbatsov can you give me some pointers?) In any case, we clearly are using the correct one, as confirmed both by the lein deps :tree output and looking at cider.nrepl.version/version directly from the REPL. @manuel-uberti, @anujsrc - Other than the CIDER warning, do you see anything - regular CIDER or squiggly functionality - actually breaking? My experience is that the wrong-number-of-arguments error from squiggly and the things may break warning from cider are orthogonal: i.e. squiggly breaks only when I didn't get the warning. One slight improvement I can make is to push the org.clojure/clojure dependency up to "1.8.0". When I do that, then (with a fresh lein new luminous project): (1) The behavior with injected dependencies fromcider-jack-in and with explicit dependencies in the :repl profile is identical; both result in the breakage warning, but no evident breakage. (2) A whole bunch of lein with-profile repl deps :tree inconsistency go away; I'm left with a few relating only to luminous, and an internal inconsistency within the core.typed dependency tree on tools.reader. By adding toos.reader to the exclusions for acyclic/squiggly-clojure, we can remove that last inconsistency warning, but it does not, as I'd hoped, somehow cause the "things may break" warning to go away. Later today, I'll push a squiggly "0.1.8" jar that depends on clojure "1.8.0" and modify the .el. to inject that dependency, along with the reader exclusion. There may be up to a day before the new elisp hits melpa, so there may be a period where you have to modify flycheck-clojure-dep-version manually.

pnf commented 7 years ago

Updated flycheck-clojure.el is on github ready for pick-up by melpa; the new jar, version "0.1.8" is up on clojars. Following @mrroman's discovery that the mismatched version warning only occurs with versions of core.typed 0.3.26 and later, I reverted the squiggly dependency to 0.3.25. I also brought this up on the core.typed google group, as the cider error can be reproduced without involving squiggly at all. At this point, I believe that the README, the sample project, the clojar and the .el are all in sync, and you should no longer see either things breaking or a warning that they will. (Well, things will break eventually, but hopefully not in the way we've been discussing.)

pnf commented 7 years ago

Per #45, the version mismatch error has something to do with AOT jars from core.typed, by explicitly depending on "0.3.32" :classifier "slim". So, yet another version tick today. Now to squiggly 0.1.9-SNAPSHOT. (So I can rashly push out further updates without having to change the version as often.)

anujsrc commented 7 years ago

Thanks @pnf - I will pull the SNAPSHOT tomorrow and give it a try.

manuel-uberti commented 7 years ago

Thanks for your effort @pnf, but I am still getting the same error message. I upgraded flycheck-clojure, jacked-in with C-c M-j and at every edit in a .clj file I get the message.

pnf commented 7 years ago

Are you using the latest .el, which injects 0.1.9-SNAPSHOT? If so, there's something in your environment that that I don't understand. I am testing on a new luminous project, with no profile set.

On Feb 22, 2017, at 12:21 AM, Manuel Uberti notifications@github.com wrote:

Thanks for your effort @pnf, but I am still getting the same error message. I upgraded flycheck-clojure, jacked-in with C-c M-j and at every edit in a .clj file I get the message.

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

manuel-uberti commented 7 years ago

Yes, latest version with 0.1.9-SNAPSHOT. I'll try again on a new luminus project later and report back.

pnf commented 7 years ago

You see exactly this?

Starting nREPL server via /home/pnf/bin/lein update-in :dependencies conj \[acyclic/squiggly-clojure\ \"
0.1.9-SNAPSHOT\"\ \:exclusions\ \[org.clojure/tools.reader\]\] -- update-in :dependencies conj \[org.clo
jure/tools.nrepl\ \"0.2.12\"\ \:exclusions\ \[org.clojure/clojure\]\] -- update-in :plugins conj \[refac
tor-nrepl\ \"2.3.0-SNAPSHOT\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.15.0-SNAPSHOT\"\] --
 repl :headless...
manuel-uberti commented 7 years ago

No, actually I got this:

Starting nREPL server via /home/manuel/bin/lein update-in :dependencies conj \[org.clojure/tools.nrepl\ \"0.2.12\"\ \:exclusions\ \[org.clojure/clojure\]\] -- update-in :plugins conj \[refactor-nrepl\ \"2.3.0-SNAPSHOT\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.15.0-SNAPSHOT\"\] -- repl :headless...
pnf commented 7 years ago

This doesn't mention squiggly at all. Are you sure you have the latest .el from github and have executed flycheck-clojure-setup?

On Feb 22, 2017, at 2:12 PM, Manuel Uberti notifications@github.com wrote:

No, actually I got this:

Starting nREPL server via /home/manuel/bin/lein update-in :dependencies conj [org.clojure/tools.nrepl\ \"0.2.12\"\ \:exclusions\ [org.clojure/clojure]] -- update-in :plugins conj [refactor-nrepl\ \"2.3.0-SNAPSHOT\"] -- update-in :plugins conj [cider/cider-nrepl\ \"0.15.0-SNAPSHOT\"] -- repl :headless... ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

manuel-uberti commented 7 years ago

Yes.

flycheck-clojure-dep-version is a variable defined in ‘flycheck-clojure.el’.
Its value is "0.1.9-SNAPSHOT"

And in *Messages*:

error in process filter: Wrong number of arguments: (4 . 4), 0 [2 times]
Error from syntax checker clojure-cider-eastwood: Done with no errors
pnf commented 7 years ago

That variable is defined when the .el is eval'd. It's the -setup function that adds it to the cider injection list. If you don't see the dependency in the lein parameters, then either -setup wasn't run, or you have some other problem. In either case, the squiggly jars won't be on your class path, so it would be surprising if anything worked.

On Feb 23, 2017, at 12:21 AM, Manuel Uberti notifications@github.com wrote:

Yes.

flycheck-clojure-dep-version is a variable defined in ‘flycheck-clojure.el’. Its value is "0.1.9-SNAPSHOT" And in Messages:

error in process filter: Wrong number of arguments: (4 . 4), 0 [2 times] Error from syntax checker clojure-cider-eastwood: Done with no errors ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

manuel-uberti commented 7 years ago

This is weird, because if I completely disable flycheck-clojure I'm not getting the error. I'll check again my setup.

pnf commented 7 years ago

It sort of makes sense. If we're somehow evaluating flycheck-clojure functions without having the classes available, something terrible will happen.

On Feb 23, 2017, at 8:10 AM, Manuel Uberti notifications@github.com wrote:

This is weird, because if I completely disable flycheck-clojure I'm not getting the error. I'll check again my setup.

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

manuel-uberti commented 7 years ago

This is my config:

(use-package flycheck-clojure           ; Setup Flycheck for Clojure
  :ensure t
  :defer t
  :after flycheck
  :config (flycheck-clojure-setup))

I'll try running flycheck-clojure-setup withouth waiting for Flycheck to be loaded and see if it makes any difference.

manuel-uberti commented 7 years ago

Nothing changed. My setup now:

(eval-after-load 'flycheck '(flycheck-clojure-setup))

Error message:

Starting nREPL server via /home/manuel/bin/lein update-in :dependencies conj \[org.clojure/tools.nrepl\ \"0.2.12\"\ \:exclusions\ \[org.clojure/clojure\]\] -- update-in :plugins conj \[refactor-nrepl\ \"2.3.0-SNAPSHOT\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.15.0-SNAPSHOT\"\] -- repl :headless...
pnf commented 7 years ago

The injection occurs at https://github.com/clojure-emacs/squiggly-clojure/blob/master/elisp/flycheck-clojure/flycheck-clojure.el#L196 You can examine cider-jack-in-dependencies directly.

manuel-uberti commented 7 years ago

I eval'd flycheck-clojure-setup via M-x, now I get the injection. This is what Flycheck is reporting in a .clj buffer:

core.typed:There was previously an unrecoverable internal error while loading core.typed. Please restart your process. (clojure-cider-typed)
pnf commented 7 years ago

Officially, you're on your own for issues with individual linters. However, I suspect you'll want to turn off core.typed here, unless you're actually using it in the project. You should probably test out a few bona-fide Eastwood and Kibit solecisms to make sure they're being highlighted.

manuel-uberti commented 7 years ago

Ok great. Let's consider this closed then.

Thank you for the patience and the support.

pnf commented 7 years ago

You're very welcome.

manuel-uberti commented 7 years ago

This fixed it.