Fork me on GitHub
#calva
<
2022-06-20
>
seancorfield18:06:04

When I first switched over to Calva, I was using plain nrepl and that worked just fine. When I got a compilation error, there was minimal/no stacktrace, just the error message, which made the output window easy to read. However, @pez cautioned me that some parts of Calva wouldn't work properly unless I also had the CIDER middleware in play so last week I decided to give that ago. I haven't noticed any new functionality yet but now when I get a compilation error, I get a big ol' stacktrace making the output window really hard to read because now I have to scroll back in it to see what the actual error was (I normally keep the output window shrunk down to just a few lines). I'll put a typical stacktrace I see in a thread but wondered if I'm doing something wrong / don't have things setup properly since this seems very noisy and quite a nuisance to have so much extra "junk" in the stacktrace?

seancorfield18:06:11

clojure.lang.Compiler/analyze (Compiler.java:6825)
clojure.lang.Compiler$InvokeExpr/parse (Compiler.java:3832)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7126)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/access$300 (Compiler.java:38)
clojure.lang.Compiler$LetExpr$Parser/parse (Compiler.java:6401)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7124)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$BodyExpr$Parser/parse (Compiler.java:6137)
clojure.lang.Compiler$TryExpr$Parser/parse (Compiler.java:2326)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7124)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$BodyExpr$Parser/parse (Compiler.java:6137)
clojure.lang.Compiler$FnMethod/parse (Compiler.java:5479)
clojure.lang.Compiler$FnExpr/parse (Compiler.java:4041)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7122)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$InvokeExpr/parse (Compiler.java:3832)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7126)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$TryExpr$Parser/parse (Compiler.java:2297)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7124)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$BodyExpr$Parser/parse (Compiler.java:6135)
clojure.lang.Compiler$LetExpr$Parser/parse (Compiler.java:6453)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7124)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$BodyExpr$Parser/parse (Compiler.java:6135)
clojure.lang.Compiler$LetExpr$Parser/parse (Compiler.java:6453)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7124)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$BodyExpr$Parser/parse (Compiler.java:6137)
clojure.lang.Compiler$FnMethod/parse (Compiler.java:5479)
clojure.lang.Compiler$FnExpr/parse (Compiler.java:4041)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7122)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7112)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler$MapExpr/parse (Compiler.java:3116)
clojure.lang.Compiler/analyze (Compiler.java:6814)
clojure.lang.Compiler$DefExpr$Parser/parse (Compiler.java:594)
clojure.lang.Compiler/analyzeSeq (Compiler.java:7124)
clojure.lang.Compiler/analyze (Compiler.java:6806)
clojure.lang.Compiler/eval (Compiler.java:7198)
clojure.lang.Compiler/load (Compiler.java:7653)
ws.site.interface-test/eval52018 (dev.clj:1)
clojure.lang.Compiler/eval (Compiler.java:7194)
clojure.core/eval (core.clj:3215)
clojure.core/eval (core.clj:3211)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.core/apply (core.clj:667)
clojure.core/with-bindings* (core.clj:1990)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.main/repl (main.clj:437)
clojure.main/repl (main.clj:458)
clojure.main/repl (main.clj:368)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:84)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:56)
nrepl.middleware.interruptible-eval/interruptible-eval (interruptible_eval.clj:152)
nrepl.middleware.session/session-exec (session.clj:218)
nrepl.middleware.session/session-exec (session.clj:217)
java.lang.Thread/run (Thread.java:833)
clj꞉ws.site.interface-test꞉> 

seancorfield18:06:16

The bit that is missing from that is the very top of the output, that actually has useful information in it:

; Evaluating file: interface_test.clj
; Syntax error compiling at (components/site/test/ws/site/interface_test.clj:46:27).
; No such var: sut/as-site
; Evaluation of file interface_test.clj failed: class clojure.lang.Compiler$CompilerException

pez18:06:45

I don't think I've seen this problem. Anyone else experienced it? <!subteam^S03BGSAUPTQ|@calva-team>?

Brandon Stubbs18:06:01

How do you keep the output window shrunk to just a few lines?

pez18:06:46

What I do is that I split the view horizontally.

Brandon Stubbs18:06:25

Ok so not actually removing older lines from the output window

seancorfield19:06:42

Yeah, I just resize the output window down to about five lines. My editor layout is explorer etc sidebar (narrow), text editor window (wide), and then Portal + Calva output split horizontally with Portal taking up most of that part.

❤️ 1
Brandon Stubbs19:06:05

Thank You! runs off to check out Portal!

seancorfield19:06:44

I'm running the nREPL -main from inside my :dev/repl alias which actually starts it up from my dev.clj script (essentially a "user" script that is loaded to start up my dev env -- customizes Portal/logging, starts whatever REPL is approprirate based on what's on my classpath).

seancorfield19:06:43

Since I haven't run into any real breakages with Calva without CIDER, I may just revert to that, but I was hoping I was just missing some config that would have Calva/CIDER trim all that noise out of the stacktrace...

bringe20:06:16

I’ve actually just seen this recently but could not reproduce when I just tried (I tried in both a deps.edn and shadow project).

bringe20:06:27

I’ll keep an eye out for it

bringe23:06:39

Just had this happen to me again. I was loading a file in a work project and there was a syntax error during compilation of one of its dependencies. This produced a long stack trace in the output window.

bringe23:06:25

This may just be happening when loading files. I can reproduce this by putting a . at the top level of a file and loading it.

seancorfield23:06:58

Yeah, I'm doing ctrl+alt+c enter when I see this error -- which is load file under the hood, right?

Lukas Domagala23:06:09

yes it’s the same command. I’m getting the same long traces if a ns dependency wasn’t loaded, but I thought this was by design 🙂

seancorfield23:06:15

I haven't checked whether I can trigger it through other eval commands.

Lukas Domagala23:06:04

seems to be different behavior. adding a . like bringe it gives the long one, but just selecting everything and running “eval selection” produces a collapsed trace

1
seancorfield23:06:25

Does Calva's "load file" logic just need to be wrapped in the same sort of error handling as other eval commands?

Lukas Domagala23:06:28

as an aside: shouldn’t the load file thing also load the dependency namespaces? I have to often load those by hand first, which is weird.

seancorfield23:06:50

I wouldn't expect load-file to reload a namespace that is already loaded...?

seancorfield23:06:31

If I haven't loaded some of those transitive ns deps, when I "load file", they do get loaded/compiled.

Lukas Domagala23:06:17

not reload, that would be hard to keep track of. I mean when I start a fresh REPL I often have to load “leaf” namespaces before loading main ones, otherwise it complains that the leafs don’t exist

seancorfield23:06:03

But if you've changed those nses, you would need to eval them first for the changes to be picked up in another file you're loading -- but that's what I would expect (and why I eval every change as I make it -- except where I'm doing a widespread refactoring/renaming via the editor... but then I go into each ns that was updated and load the file into the REPL).

seancorfield23:06:21

@U02EMBDU2JU Interesting... I've never seen that behavior.

bringe23:06:34

@U02EMBDU2JU I’ve seen that behavior sometimes. I don’t know what causes it. Usually the leaf deps are loaded when I load-file.

Lukas Domagala23:06:30

So I just looked at the load file command and the “problem” is that it’s using the nrepl “load-file” op, which behaves differently than normal eval

Lukas Domagala23:06:45

although we do the stacktrace handling ourself on error, so we could change it to behave the same

Lukas Domagala23:06:40

plus interestingly I just kind of answered my own question: the “not loaded ns” thing is an nrepl problem, not a calva problem

seancorfield23:06:24

I sorted of expected it to call clojure.core/load-file under the hood -- I guess it does something nREPL-specific?

Lukas Domagala23:06:22

it’s this one: https://github.com/Cyrik/calva/blob/nrepl-lsp-provider-merge/src/nrepl/index.ts#L446 not sure what nrepl does in that op. haven’t looked at nrepl source too much

Lukas Domagala23:06:55

but you can see that we call it here: https://github.com/Cyrik/calva/blob/nrepl-lsp-provider-merge/src/evaluate.ts#L422 and do the stacktrace print right after on exceptions

bringe00:06:07

Issue welcome 😃

seancorfield01:06:28

@U9A1RLFNV I don't know what repo to create an issue against for this. @U02EMBDU2JU was linking to his own fork of Calva (and an LSP-related branch at that).

bringe01:06:11

An issue in Calva’s repo would be good. I just mean an issue for making the error output look the same for loading a file as for evaluating code.

1
seancorfield04:06:08

Thanks @U9A1RLFNV -- I really appreciate that and look forward to the next release of Calva 🙂

❤️ 1
simple_smile 1
pez05:06:24

Great spotting, @U9A1RLFNV!

🚀 1
Lukas Domagala08:06:27

nice work, @U9A1RLFNV. I need to delete my fork so I don’t accidentally link to it 😅

😄 1
Stefan T01:06:42

I see the leaf-dependency loading issue regularly when evaluating test namespaces.

Stefan T01:06:14

The current approach of eval-on-save is actually pretty problematic in some cases. If you evaluate a ns that defines an interface that can really mess things up, forcing you to go through and manually evaluate dependent namespaces.

seancorfield04:06:25

Yeah, I wouldn't trust eval-on-save. I eval top-level forms with every change -- even without saving files -- but I save at random points where my code my not even be vaguely correct.