This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-19
Channels
- # aleph (1)
- # announcements (3)
- # aws (1)
- # beginners (95)
- # calva (15)
- # clojars (4)
- # clojure (84)
- # clojure-android (3)
- # clojure-austin (1)
- # clojure-chicago (1)
- # clojure-dev (66)
- # clojure-europe (3)
- # clojure-italy (15)
- # clojure-nl (13)
- # clojure-uk (33)
- # clojuredesign-podcast (9)
- # clojurescript (6)
- # cursive (68)
- # data-science (4)
- # datavis (1)
- # datomic (13)
- # emacs (4)
- # fulcro (2)
- # jobs (4)
- # jobs-discuss (89)
- # luminus (23)
- # nrepl (6)
- # off-topic (2)
- # onyx (2)
- # pathom (4)
- # pedestal (11)
- # re-frame (9)
- # reagent (8)
- # reitit (5)
- # shadow-cljs (131)
- # spacemacs (13)
- # sql (8)
- # vim (8)
- # xtdb (7)
- # yada (4)
it seems like with latest clojure cursive and java 11 I’m getting a lot more errors like this
Syntax error (ClassCastException) compiling at (src/specify_it/bst_spec.clj:301:1).
class java.lang.String cannot be cast to class java.lang.Number (java.lang.String and java.lang.Number are in module java.base of loader 'bootstrap')
which tries to tell me my error is at the call site rather than giving me the trace and line number where the class cast exception actually happened(pst *e) solves it, but I just don’t remember having to do that for every single exception in the past
Can you give a code example where this is happening?
Also, which Clojure version?
1.10 or 1.10.1?
(defn report! []
(doseq [[property measurements] @labels]
(println (str property ":"))
(doseq [[measurement labels] measurements]
(println (str "\t" measurement ":"))
(let [total (apply + (vals labels))]
(doseq [[label num] labels]
(println (str "\t\t" label ":" (* 100 (/ (double num) total) "%"))))))))
=> #'specify-it.bst-spec/report!
(report!)
:prop-measure:
:presence:
Syntax error (ClassCastException) compiling at (src/specify_it/bst_spec.clj:291:1).
class java.lang.String cannot be cast to class java.lang.Number (java.lang.String and java.lang.Number are in module java.base of loader 'bootstrap')
I did pull in all of sean corfield’s .clojure/deps.edn but it seems like 100% of that is scoped under aliases so none of it should be being used
and pst says?
(pst *e)
Note: The following stack trace applies to the reader or compiler, your code was not executed.
CompilerException Syntax error compiling at (/Users/bfabry/Code/specify-it/src/specify_it/bst_spec.clj:290:1). #:clojure.error{:phase :compile-syntax-check, :line 290, :column 1, :source "/Users/bfabry/Code/specify-it/src/specify_it/bst_spec.clj"}
clojure.lang.Compiler.load (Compiler.java:7648)
user/eval11188 (form-init5824827466414742383.clj:1)
user/eval11188 (form-init5824827466414742383.clj:1)
clojure.lang.Compiler.eval (Compiler.java:7177)
clojure.lang.Compiler.eval (Compiler.java:7132)
clojure.core/eval (core.clj:3214)
clojure.core/eval (core.clj:3210)
clojure.main/repl/read-eval-print--9086/fn--9089 (main.clj:437)
clojure.main/repl/read-eval-print--9086 (main.clj:437)
clojure.main/repl/fn--9095 (main.clj:458)
clojure.main/repl (main.clj:458)
clojure.main/repl (main.clj:368)
Caused by:
ClassCastException class java.lang.String cannot be cast to class java.lang.Number (java.lang.String and java.lang.Number are in module java.base of loader 'bootstrap')
clojure.lang.Numbers.multiply (Numbers.java:3845)
specify-it.bst-spec/report! (bst_spec.clj:289)
specify-it.bst-spec/report! (bst_spec.clj:282)
specify-it.bst-spec/eval11192 (bst_spec.clj:290)
specify-it.bst-spec/eval11192 (bst_spec.clj:290)
clojure.lang.Compiler.eval (Compiler.java:7177)
clojure.lang.Compiler.load (Compiler.java:7636)
user/eval11188 (form-init5824827466414742383.clj:1)
=> nil
so the bug is in the misplaced "%"
should be outside the *
so it is reporting the proper error location
and the class cast error is the right error
the confusing part is the phase reporting (syntax error based on being in :compile-syntax-check)
yeah I put the bug in on purpose to demonstrate. the location is also incorrect (though my example is bad), but line 291 is the location of the (report!) call not the location of the println
I think this may be a missing phase declaration at clojure.lang.Compiler.load (Compiler.java:7648) - it will just take the default, which is compilation here, but we're in a load so that doesn't necessarily make sense. I'm not entirely sure why there is a load here though, so that's the part puzzling me.
new cursive didn’t help. so intellij ultimate 2019.1.3, cursive latest eap just for the record
that may be something Cursive is doing behind the scenes (namely, what is in form-init5824827466414742383.clj) - seems like that is maybe a temp wrapper around your actual (report!)
call, and that's what is walking this path in the first place
like I suspect if you just did this with clj
at the repl, you would not see that and it would not report as a compiler error
yeah, none of that is important
this is about Clojure error reporting and what Cursive is causing to be evaluated
yeah figured, it’s just one of the major differences for my setup from a few years ago. yeah clj repl works fine.
actually no I’m wrong about that. same thing in clj…. I was just confused by different reporting styles. I think I know what this is
what do you see in clj?
I have a call to “run all the stuff” at the bottom of the file. because the failure then happens during initial file load the namespace never gets marked as loaded
so you see the error when you require in clj?
yes. removing that line when I get the exception it gives me the line number where it originates
seems like you should see same kind of thing in Cursive too then, unless you loaded successfully, then modified, then ran the repl command in Cursive
the difference is in clj it’s obvious that the ns isn’t properly loaded. in cursive where I can send individual forms etc successfully not so much
in any case, I'd like to hear more from Colin about what is in the form-init...clj so I can see whether there is something more to do in the Compiler error reporting during load
actually… cursive is still doing it even after restarting the repl, loading the file successfully and sending the form that throws a runtime error afterwards. and it’s still calling it a syntax error
Connecting to local nREPL server...
Clojure 1.10.1
nREPL server started on port 64285 on host 127.0.0.1
Loading src/specify_it/bst_spec.clj... done
(check-props)
*snip*
:prop-measure:
:presence:
Syntax error (ClassCastException) compiling at (src/specify_it/bst_spec.clj:301:1).
class java.lang.String cannot be cast to class java.lang.Number (java.lang.String and java.lang.Number are in module java.base of loader 'bootstrap')
yeah, Cursive is doing something else - whatever user/eval11188 (form-init5824827466414742383.clj:1)
is, that's neither you nor Clojure
possibly, Cursive should unroll one layer of exception before printing, or it might be solvable by not stamping this particular wrapper as a compiler phase
like if you did (-> *e .getCause Throwable->map clojure.main/ex-triage clojure.main/ex-str println)
that would probably match what you see in clj
it’s such a weird experience coming back to clojure and all the error’s only being two lines. I thought something was way more deeply wrong for a while 😅 but yeah it seems like there’s just an extra stack layer on top showing up
well Cursive has for a long time printed both way too much (unnecessary stack trace) and entirely the wrong thing (the top level, not the root cause). lots of progress being made on this and I'm glad to see it.
but there is some "contract negotiation" occurring here between Clojure and tooling that will take a bit of time to shake out
Cursive is better, lein is better (when using Clojure 1.10.1), clj is better (1.10 and more improvements in 1.10.1)
I will spend a little more time on this later and log something for Clojure (assuming that makes sense)
thanks Alex. I haven’t been using clojure in a while but I’ve been following the improvements and they seem like great steps
do you guys know if there is something we can do to speed up editing on large files? in my project I have a file that contains pretty much all the specs, currently it has 1700 lines, trying to paste anything on it gets really slow, is there anything I can do to make it faster?
Hmm, that doesn’t seem that big. I have to run now, but I’ll get a CPU snapshot from you later to see if that sheds any light on the problem.
yeah, one operation that gets particularly slow is doing sexp over multiple lines, today I did multi-line selection with 18 items on it and run Wrap with ()
, that took about a minute to run
Ok, I think the formatting code might be the problem there, someone else reported something similar.
@U066U8JQJ Do you only see extreme slowdowns when using multiple cursors?
no, the regular editing gets quite slow on this file
its a file containing a lot of spec definitions
Is there anything I can do to improve the experience of using the REPL inside Cursive + IdeaVim
? The vim bindings don't work but the "readline-style" bindings don't work either (⌃N, ⌃P, ⌃F, ⌃B, etc.). Instead I can only navigate user the arrow keys.
This seems to be a Cursive-specific issue, because the readline-style bindings work if I'm using IdeaVim and am working in the terminal window.
Looks like the issue is that, unlike in the terminal window, in the REPL window I'm in vim insert mode. Per the Cursive issue tracker, hitting Ctrl-C will put you into normal mode, so you can move around: https://github.com/cursive-ide/cursive/issues/647 TBH, if there were some way to disable ideavim in the REPL that would be nice.
Turning structural editing off doesn't change anything for me. I'm running an older version of IDEA though (2017.3), so maybe that's the problem?
Is there any way to change the color of the rainbow parens? The dark blue ones are hard to see in dark mode.
Preferences > Editor > Color Scheme > Clojure > Rainbow parens level 1-9 The preview window there even has an example showing them in action
Awesome, I looked all over for that and didn't find it, thanks much!
Looks like the issue is that, unlike in the terminal window, in the REPL window I'm in vim insert mode. Per the Cursive issue tracker, hitting Ctrl-C will put you into normal mode, so you can move around: https://github.com/cursive-ide/cursive/issues/647 TBH, if there were some way to disable ideavim in the REPL that would be nice.
@alexmiller I don’t have time to reproduce this right now, but the unexpected load could be the one discussed here: https://github.com/cursive-ide/cursive/issues/2113