Fork me on GitHub
#cursive
<
2019-07-19
>
bfabry15:07:07

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

bfabry15:07:26

there’s no macros in use here so syntax error is particularly confusing

bfabry15:07:46

(pst *e) solves it, but I just don’t remember having to do that for every single exception in the past

Alex Miller (Clojure team)15:07:59

Can you give a code example where this is happening?

Alex Miller (Clojure team)15:07:32

Also, which Clojure version?

bfabry16:07:15

(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')

bfabry16:07:33

using run configuration of nrepl, deps, no aliases

bfabry16:07:36

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

bfabry16:07:14

(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

bfabry16:07:32

just noticed there’s a cursive version bump I can do. let me try that

Alex Miller (Clojure team)16:07:16

so the bug is in the misplaced "%"

Alex Miller (Clojure team)16:07:37

should be outside the *

Alex Miller (Clojure team)16:07:14

so it is reporting the proper error location

Alex Miller (Clojure team)16:07:24

and the class cast error is the right error

Alex Miller (Clojure team)16:07:49

the confusing part is the phase reporting (syntax error based on being in :compile-syntax-check)

bfabry16:07:05

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

Alex Miller (Clojure team)16:07:28

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.

bfabry16:07:42

new cursive didn’t help. so intellij ultimate 2019.1.3, cursive latest eap just for the record

Alex Miller (Clojure team)16:07:15

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

Alex Miller (Clojure team)16:07:45

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

bfabry16:07:50

same deal switching to java 1.8

Alex Miller (Clojure team)16:07:57

yeah, none of that is important

Alex Miller (Clojure team)16:07:05

this is about Clojure error reporting and what Cursive is causing to be evaluated

bfabry16:07:56

yeah figured, it’s just one of the major differences for my setup from a few years ago. yeah clj repl works fine.

bfabry16:07:19

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

Alex Miller (Clojure team)16:07:30

what do you see in clj?

bfabry16:07:45

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

bfabry16:07:49

and so everything is broke

Alex Miller (Clojure team)16:07:35

so you see the error when you require in clj?

bfabry16:07:34

yes. removing that line when I get the exception it gives me the line number where it originates

Alex Miller (Clojure team)16:07:37

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

bfabry16:07:53

I think that’s what’s happened

bfabry16:07:16

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

Alex Miller (Clojure team)16:07:48

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

bfabry16:07:33

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

bfabry16:07:08

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')

Alex Miller (Clojure team)16:07:18

yeah, Cursive is doing something else - whatever user/eval11188 (form-init5824827466414742383.clj:1) is, that's neither you nor Clojure

Alex Miller (Clojure team)16:07:59

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

Alex Miller (Clojure team)16:07:51

like if you did (-> *e .getCause Throwable->map clojure.main/ex-triage clojure.main/ex-str println)

Alex Miller (Clojure team)16:07:48

that would probably match what you see in clj

bfabry16:07:47

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

Alex Miller (Clojure team)16:07:04

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.

Alex Miller (Clojure team)16:07:00

but there is some "contract negotiation" occurring here between Clojure and tooling that will take a bit of time to shake out

Alex Miller (Clojure team)16:07:13

Cursive is better, lein is better (when using Clojure 1.10.1), clj is better (1.10 and more improvements in 1.10.1)

Alex Miller (Clojure team)17:07:54

I will spend a little more time on this later and log something for Clojure (assuming that makes sense)

bfabry17:07:36

thanks Alex. I haven’t been using clojure in a while but I’ve been following the improvements and they seem like great steps

wilkerlucio20:07:42

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?

cfleming22:07:10

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.

wilkerlucio22:07:43

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

cfleming00:07:38

Ok, I think the formatting code might be the problem there, someone else reported something similar.

cfleming23:07:47

@U066U8JQJ Do you only see extreme slowdowns when using multiple cursors?

wilkerlucio23:07:07

no, the regular editing gets quite slow on this file

wilkerlucio23:07:18

its a file containing a lot of spec definitions

bfabry21:07:33

for a lot of different reasons my answer is: split it up into smaller files

csd21:07:12

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.

csd22:07:00

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.

bfabry21:07:22

Tried turning structural editing off?

csd21:07:56

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?

manutter5121:07:30

Is there any way to change the color of the rainbow parens? The dark blue ones are hard to see in dark mode.

jffry21:07:46

Preferences > Editor > Color Scheme > Clojure > Rainbow parens level 1-9 The preview window there even has an example showing them in action

manutter5123:07:59

Awesome, I looked all over for that and didn't find it, thanks much!

cfleming22:07:33

@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