(wrong-number-of-arguments (4 . 4) 0)
Closed this issue · 29 comments
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:
- 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
(commit861ff2b
) - CIDER version:
CIDER 0.15.0snapshot (package: 20170129.1941)
- Flycheck version:
Flycheck version: 31snapshot (package: 20170212.1015)
flycheck-clojure-dep-version
:0.1.7
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
No, no issue with CIDER. Neither in the *Messages*
buffer, nor in the REPL.
@pnf - I am also facing the same issue. If we add the squiggly dependency in ~/.lein/profiles.clj as mentioned in #29 and #39, the checker error goes way but I start getting the CIDER warning as mentioned here- clojure-emacs/cider#1728 - It does say things may break as you pointed out.
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.
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.)
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.)
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.
Yes, latest version with 0.1.9-SNAPSHOT. I'll try again on a new luminus project later and report back.
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...
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...
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
This is weird, because if I completely disable flycheck-clojure
I'm not getting the error. I'll check again my setup.
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.
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...
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.
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)
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.
Ok great. Let's consider this closed then.
Thank you for the patience and the support.
You're very welcome.
This fixed it.