This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-18
Channels
- # aws (1)
- # babashka (35)
- # beginners (52)
- # biff (4)
- # calva (55)
- # cider (19)
- # clojure (54)
- # clojure-dev (3)
- # clojure-europe (23)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojure-uk (2)
- # clojurescript (9)
- # code-reviews (3)
- # datahike (1)
- # fulcro (1)
- # funcool (4)
- # graalvm (21)
- # gratitude (2)
- # java (5)
- # jobs (2)
- # joyride (1)
- # kaocha (13)
- # malli (2)
- # off-topic (22)
- # other-languages (11)
- # pathom (4)
- # re-frame (35)
- # reagent (3)
- # reitit (3)
- # releases (2)
- # remote-jobs (1)
- # rum (1)
- # shadow-cljs (42)
- # sql (18)
- # tools-deps (72)
- # web-security (6)
- # xtdb (15)
Is there a way to keep Calva from truncating long REPL output? To repro, you can eval (repeat 500 "abc")
. Mine prints the first 50 (one on each line), then cuts off the rest of the seq with ...)
. I'm working with some large data structures atm and would like to avoid this.
It seem to be a law of physics that as soon as you ask a question, you find the answer yourself 🙂. It's a pprint issue. settings.json
-> calva.prettyPrintingOptions
-> maxLength
For one-off situations, you could also just disable pprint. There is a command Toggle Pretty Printing ...
, or click on pprint
in the statusbar.
Opened an issue because I can't rename anything in calva. I can't even rename simple variables like this This has happened out of nowhere, even if I restart my computer, and it's pretty egregious. I can't rename any symbol names. We're talking functions as simple as this.
(defn add-one [val]
(+ val 1))
Can't rename val
Deleted .lsp and .clj-kondo in my project directoryUsually classpath issues, check https://clojure-lsp.io/troubleshooting/#some-features-are-not-working
Why do I not get docstring popup in a babashka .clj file with a babashka repl connected?
@U0522TWDA which version of Calva are you using?
Version: 2.0.319 And yes, in a non-bb project the docstring works
will try
@UKFSJSM38 I have a folder with a single test_helper.clj
containing
#!/usr/bin/env bb
(compare 1 2)
I open the folder in calva the-folder$ code .
and do Jack-in for Babashka and mouse over the compare
so probably the project root is wrong, making clojure-lsp not run bb print-deps
to build the classpath
check https://clojure-lsp.io/settings/#classpath-scan for more info
true. If I echo '{}' > bb.edn
and restart code then the docstring shows up.
Now I know about this hack and my babashka-ing will be much more pleasant 🙂 Thank you for your help!
there is no way clojure-lsp know your project is a valid bb one if there is no bb.edn
present
Glad it works!
Well, perhaps Calva could tell it it is, when I start a bb repl there? @U0ETXRFEW
unfortunately is not that easy, the classpath discovery on clojure-lsp is done enterely on server, we would need to receive some flag and make things harder, for now having a simple bb.edn seems fine enough
I often make one off babashka scripts, without bothering with dedicated directories or extra files. But I can have one script directory for developing them with a dummy bb.edn…
If we wrote out an empty bb.edn before starting LSP, and then deleted it, would everything work as expected in this scenario?
I guess you would also need to tell lsp to re-start its work after you write it?
You can restart LSP with Calva Clojure LSP: Restart the Clojure LSP Server
command from the command pallet.
I was talking about maybe Calva being a bit smarter. Unsure whether everything (including non-lsp features) works correctly if we delete the bb.edn after LSP is started.
If the file would need to be permanent, we might as well leave that to the user to add necessary files to their projects. But if we only need it while starting LSP, that sounds like a nice (fairly lightweight) feature: Calva could recognize a bb file with no bb.edn as needing a bb.edn next to it long enough to start LSP.
@U0ETXRFEW, would that work? I'm sure @U0522TWDA would be happy to write up an Issue for it (and maybe a PR too? @U0522TWDA 🙏 ).
Perhaps calva could just flesh a large "RTFM!" when starting bb project repl in a å folder without bb.edn?
Which docs? Not bashaska, right? For babashka, bb.edn is only required for certain features. If the user doesn't need those features, why should they be forced to add one to get editor support? On the surface, the answer is obvious: "because we rely on Clojure LSP, which doesn't support that, and adding that support to LSP is too much work for too little gain". But if we have a way to provide that support with a little minor trickery at the editor level, that seems like a good thing to me. It doesn't seem that magical to me. It is the same solution the user would use, except without leaving that otherwise useless file laying around on their filesystem.
yes, clojure-lsp docs Yeah, I can see how convenient, it may worth it, I hope it doesn't make things more complex or make it harder to debug issues like this one
> I hope it doesn't make things more complex or make it harder to debug issues like this one Agreed on the concern it could turn out overly complex. But if @U0ETXRFEW agrees, I think it is certainly worth at least taking a look at. It would definitely make debugging this particular issue easier, since in this scenario everything would "just work". 😄
I like the idea. Calva knows you are connecting to a babashka REPL 1. sees that the bb.edn file is lacking 2. creates it 3. restarts clojure-lsp 4. deletes it Magic, but maybe that is fine?
Just careful with the delete in the case the user has changed the file...
The delete would only happen in the case Calva created the file. It would not be there long enough for the user to change anything unless they went out of the way to have an unsaved bb.edn file open to quickly save during LSP startup. @U0522TWDA Please file an issue on https://github.com/BetterThanTomorrow/calva/issues describing your initial concern that led to this conversation (that LSP features don't work on bb files without bb.edn). And if you feel up to it, I know @U0ETXRFEW is always happy to look at pull requests.
The idea to tie it to jacking in to a bb repl seems nice, for limiting the scope of when to check for this. We would need to ensure that LSP restart is running concurrently to connecting to the repl, or jacking in will become painfully slow in this scenario.
Is there any way to use Calva test-runner for testing multiple environments at once? i.e. Clojure, ClojureScript, and Bababshka, and perhaps multiple versions
Code in cljc files is written to run in multiple environments. Looking to run tests for that code in all envrionments intended to be supported. Would be great if that can happen all at once through the Calva test runner while working in the editor.
I'm guessing if you don't understand the question, you probably haven't thought about it yourself already, and thus unlikely to be currently supported. 😄
Since Calva's eval works by running tests in a connected REPL, you'd need both a cljs and a clj REPL active. But you couldn't have "all" environments (like multiple versions of Clojure, or with different aliases to control behavior) because you can only have two REPLs I think.
I didn't understand the question, because I've never heard this referred to as environments. 😃
And, yes, Only clj
and cljs
sessions supported, really. Calva cheats when connected to a Babashka or nbb or Joyride REPL and uses the clj
session for that.
What I do for cljc files is that I configure a test build in shadow-cljs to autorun tests. Then use Calva's test runner for Clojure. (In fact, I mostly work with ClojureScript, and use shadow's test runner, so am not a heavy user of Calva's test runner at all. (Which is funny, because the test runner is the reason Calva was created in the first place.)
> (Which is funny, because the test runner is the reason Calva was created in the first place.) That is funny.
I don't use Calva's test runner either 🙂 I use clojure.test
with a bit of code wrapped around it.
That makes me double down on a thought I had when I first started using Calva: Instead of having its own test runner, Calva should aim toward finding a user-friendly way to report results from whatever test runner(s) the user chooses to configure for the project. I don't know how complicated that would get if test runners are not designed with separate reporters in mind. But that seems like the ideal direction.
clojure.test
doesn't really support multiple reporters very well -- it's why, for example, humane-test-output doesn't play well with lein test
(it's really kind of amazing how poor clojure.test
is for something that we have all come to rely on so heavily! 🙂 🙂 )
Does this mean no people are hurt during the use of clojure.test
? Humane -sorry but its helpful to see the many different test methods.