This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-20
Channels
- # announcements (5)
- # asami (7)
- # babashka-sci-dev (36)
- # beginners (50)
- # calva (47)
- # cider (1)
- # clj-kondo (19)
- # clojure (33)
- # clojure-europe (25)
- # clojure-nl (2)
- # clojure-uk (4)
- # clojurescript (26)
- # conjure (2)
- # cursive (5)
- # datalog (6)
- # fulcro (5)
- # graalvm (12)
- # leiningen (1)
- # malli (30)
- # off-topic (5)
- # rdf (4)
- # ring (11)
- # shadow-cljs (55)
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?
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꞉>
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
I don't think I've seen this problem. Anyone else experienced it? <!subteam^S03BGSAUPTQ|@calva-team>?
How do you keep the output window shrunk to just a few lines?
Ok so not actually removing older lines from the output window
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.
Thank You! runs off to check out Portal!
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).
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...
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).
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.
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.
Yeah, I'm doing ctrl+alt+c enter
when I see this error -- which is load file under the hood, right?
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 🙂
I haven't checked whether I can trigger it through other eval commands.
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
Does Calva's "load file" logic just need to be wrapped in the same sort of error handling as other eval commands?
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.
I wouldn't expect load-file
to reload a namespace that is already loaded...?
If I haven't loaded some of those transitive ns deps, when I "load file", they do get loaded/compiled.
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
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).
@U02EMBDU2JU Interesting... I've never seen that behavior.
@U02EMBDU2JU I’ve seen that behavior sometimes. I don’t know what causes it. Usually the leaf deps are loaded when I load-file.
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
although we do the stacktrace handling ourself on error, so we could change it to behave the same
Sounds good.
plus interestingly I just kind of answered my own question: the “not loaded ns” thing is an nrepl problem, not a calva problem
I sorted of expected it to call clojure.core/load-file
under the hood -- I guess it does something nREPL-specific?
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
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
@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).
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.
Thanks @U9A1RLFNV -- I really appreciate that and look forward to the next release of Calva 🙂
nice work, @U9A1RLFNV. I need to delete my fork so I don’t accidentally link to it 😅
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.
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.