Fork me on GitHub

I don't know if this is the right channel to post this but I am seeing a 100% usage by the clojure-lsp server started by calva. Is this normal?


clojure-lsp works quite hard while it starts, but after that it should be pretty calm...


and it caches for next runs, unless you change your deps file


Did something change in the 'Show Previous REPL History Entry' function? Keybinding is still the same but I am not getting my history. Instead it sporadically shows something from yesterday or earlier. Is there some cache that could be causing this? If so, where can I delete it? I am already checking if its another extension causing this.


Can you try with v2.0.235 (the previous version)? I know we did something with the history in 236.


will do that now

🙏 1

v.2.0.235 fixed it


I see... Can you have a look at this, @U02EMBDU2JU? Or whoever of us gets to it first. But I can't until tonight Swedish time (and it is morning now 😃).

Lukas Domagala09:01:28

I'll have a look

Lukas Domagala11:01:25

Found it. I broke it while refactoring… I’ll post a PR in a bit

❤️ 1

Some other key combinations arent working either, but some are.


Can you elaborate? ”some” is a tad vague 😃


yea sorry, a command like slurp and barf forward backward etc works just fine, but rewrap isnt working and so are other commands. its random. ill try an earlier version of calva first


I doubt 235 fixed this too, but I am curious!


Yes it did, fixed atleast the ones I tried to use and the ones I use frequently


Cant get this one to work tho, but hadnt tried it before I noticed other ones didnt work either. (its set to ctrl+alt+c n by default btw. To sync the Output/REPL window namespace with the current file before switching, use the *Switch Namespace of the Output/REPL Window to Current Namespace* command, ctrl+alt+c alt+n.


Tried it now. That command seems to not work at all. Please report as an issue.


Please also report the two other issues (history and keyboard shortcuts).. Mention that it works in 235. It'll make it easier for others to choose what to do.


separate issues?


Yes, it makes it easier to discover and also if some issue is harder to kill than some other it gives flexibility in releasing.


Also is extra satisfying if we manage to smash several bugs quickly. 😃


Totally appreciate that you took your time to help me with this, @U02CX2V8PJN!


Sure no problem, loving Calva! 🙂

❤️ 1
calva 1
Lukas Domagala12:01:05

@U02CX2V8PJN I can’t reproduce rewrap not working @U0ETXRFEW can you?


Actually I can't...


Ill have a look when I have time this afternoon


To see if I can reproduce (again)


didnt have time yet, ill try tomorrow


Note to self: We urgently need to add some integration smoke tests to guard from at least some regressions.


I'm thinking we should add this to the end-to-end setup we have (badly? named integration-tests) where we currently only check that the extension starts.


Any clue as to why I get a StackOverflowError when trying to access and atom created by at-at in the Calva VSCode REPL and not in the leinigen repl? Calva repl in vscode: @(:jobs-ref @(:pool-atom scheduler/scheduler)) ; Error printing return value (StackOverflowError) at clojure.lang.RestFn/applyTo ( ; null lein repl :connect to calva repl: @(:jobs-ref @(:pool-atom scheduler/scheduler)) {1N #<RecurringJob id: 1, created-at: Thu 10:33:06s, ms-period: 3600000, initial-delay: 180000, desc: "name redacted", scheduled? true>, 2N #<RecurringJob id: 2, created-at: Thu 10:33:07s, ms-period: 30000, initial-delay: 0, desc: "Outbound message retry handler", scheduled? true>, 3N #<RecurringJob id: 3, created-at: Thu 10:33:07s, ms-period: 7200000, initial-delay: 300000, desc: "name redacted", scheduled? true>, 4N #<RecurringJob id: 4, created-at: Thu 10:33:07s, ms-period: 3600000, initial-delay: 120000, desc: "name redacted", scheduled? true>, 5N #<RecurringJob id: 5, created-at: Thu 10:33:07s, ms-period: 1800000, initial-delay: 600000, desc: "name redacted", scheduled? true>}

Lukas Domagala10:01:46

might be calva’s pretty printer? do you have a non default one set?


Dont think so. Just tried turning pprint off and it gives me the output without stackoverflowerror


This is the when expression: { "key": "ctrl+alt+c p", "command": "calva.togglePrettyPrint", "when": "calva:connected && calva:keybindingsEnabled && editorLangId == 'clojure'" }


right, could be an issue with the atom

Lukas Domagala10:01:24

heres the doc for custom pretty printing i mean:


When I do this the repl output prints about 5000+ lines :rolling_on_the_floor_laughing: (clojure.pprint/pprint @(:jobs-ref @(:pool-atom scheduler/scheduler)))


Infinite recursion

Lukas Domagala10:01:20

"calva.prettyPrintingOptions": {
        "enabled": true,
        "width": 80,
        "maxLength": 100,
        "printEngine": "calva"
try this with engine calva and try it with pprint. “calva” is special because the result needs to get back into vscode before formating, so it might blow up more or less, depending on the values


trying now


Works now with pprint enabled and your settings. Gives a plain printing response. ; Plain printing, b/c pprint failed. (Invalid symbol: id:.)


much better then just a stackoverflowerror

Lukas Domagala10:01:26

You're welcome!


Saves me opening a terminal to connect to the repl :rolling_on_the_floor_laughing: and switching windows 😶

Lukas Domagala10:01:45

btw if you could create a ticket with a small repro snippet we might be able to fix this for the default printer


We should consider making calva the default pretty printer.

👍 1
💯 1
Lukas Domagala10:01:52

I’d also like zprint to be the default server printer, but I think we would have to harden the deps injection before we do that, or manage to fail back into pprint when zprint is missing


And (for someone having the time in some future) since that is client side zprint, we would open up possibilities for us to let people use whatever zprint config they fancy. zprint is pretty configurable. 😃


ill create an issue

🙌 1

There is actually code in Calva (or maybe in some branch) that injects zprint dependencies. But I think we would need to go for side-loading if we really want to ensure it.

Lukas Domagala10:01:14

very much not on topic: I always had problems finding enough stuff to work on, now I have the exact opposite problem 🙂


That's what Calva does for ya!

Lukas Domagala10:01:33

the zprint is already being injected in the main branch, but it’s hard to communicate that you can’t just change the setting but also need to restart repl and so on

Lukas Domagala10:01:54

> That’s what Calva does for ya! It’s omni-trace for me. Because of it I’ve worked on calva, orchard, oz, portal, clojure-lsp and soon clj-kondo 🙂


I can relate!


Purposely crashed my VSCode for you to create an issue with reproduction steps lol.

🙌 1
gratitude 1

When I have several deps.edn files in the same project (e.g. polylith-projects) I have to be careful to have the right file open when I jack-in. Is there a way to congifure Calva to always pick the root one?


Unfortunately there isn't. We should fix this. Currently we track it in this issue:


Ok, great to know!


I would also would like to configure the jackin question to remember my choice of babashla/deps/lein etc. Maybe the same solution could work for both problems?


Please elaborate a bit on that idea. 😃


I'm asking because currently jack-in does remember this choice, but obviously not in a way that you would like.


Aha 🙂 I think it does pre-select the last alternative, but I would like it to skip the question.


A “Remember my choice and don’t ask again” kind of thing

Lukas Domagala16:01:22

I think you can get that with a custom connect sequence, but I’ve been to lazy to write them for my projects 🙂


Not for the project type, I think, @U02EMBDU2JU. The sequence will place itself as a project type. 😃

Lukas Domagala16:01:33

ah ok. then it makes even more sense to have an option to skip all that. so many things to build! 🙂


I usually say no to options. Less to build. 😃


For this one I think I want to build it. I even have it in some branch like that. Because Calva used to just skip the question if there was a connect sequence there, and when I removed that behaviour I also had a branch where I made it optional. Don't remember why I choose to skip it. Probably because ”if I build less, I have less to maintain”.


I would actually like to configure it in something that is checked in. That is, I would like to be able to tell my coworkers to clone a project and jack-in, without having them confused by additional questions.


But as with any such magic, it can be hard to understand where to change it later, so I understand the current decisision to ask every time.


We could consider a command like ”Jack-in like last time” (not finished copy).


It seems to me the repl ignores the redefinition of builtin core functions. For example, given

(ns app.exceptions
  (:refer-clojure :exclude [throw]))

(defn throw [msg & args]
  (println msg))
and execute the following in the repl
(throw 3)
It gives:
; Execution error (ClassCastException) at app.exceptions/eval29285 (REPL:7).
; class java.lang.Long cannot be cast to class java.lang.Throwable (java.lang.Long and java.lang.Throwable are in module java.base of loader 'bootstrap')


Hmm, that might be a #clojure thing? throw is a special form. It seems like clj-kondo knows about this and does not warn about the redefinition (because that is not happening).


Right. Throw is a special form


And also you can't redefine Clojure core functions because they are compiled. Can't remember the exact term


I can under special form is a different case.


But for functions, they shall be able to be redefined though. While AOT might come into play in this case.

Alex Miller (Clojure team)16:01:08

direct linking doesn't prevent redefinition

Alex Miller (Clojure team)16:01:16

new code compiled after redefinition will see changes, just anything already compiled with direct linking won't see them. so if you change +, that's fine - new code will see your redefinition, but code inside clojure core will not (as it's AOT compiled with direct linking)

🙏 1

Good to learn this. Is direct linking enabled for all compiled code regardless being in clojure.core or not ?


Maybe clojure-lsp semantic tokens should treat special forms special, @UKFSJSM38?

Alex Miller (Clojure team)16:01:51

@UGC0NEP4Y no, direct linking is off by default


what do you mean @U0ETXRFEW? you mean color throw as a macro?


we rely on kondo analysis for semantic tokens, for this one clj-kondo tells that throw is a var-usage just like others, it doesn't add the :macro true to the analysis which would make us coloring differently

Alex Miller (Clojure team)16:01:08

@UGC0NEP4Y direct linking is really intended to be used "at the end" when you compile an application into an uber jar or something - you'll get smaller compiled code, faster load times, and faster execution (but you lose some dynamicity). Clojure core is kind of a special case because it's always "at the bottom".


@UKFSJSM38 That's how it is colored the jiffy just before the semantic tokens get hold of it. 😃 Goes for if and some other forms as well. Probably kondo should say :special-form: true for this one. It's what cider-nrepl says. And it adds :macro true for those special forms that are also macros.


yes, makes sense to me, WDYT @U04V15CAJ?


sorry, what?


I like that direct linking is off by default. Just blurting that out. 😃


@U04V15CAJ the special forms get colored as functions by clojure-lsp. Kondo can help by informing about the specialness.


yeah, it could add that to the analysis output


kondo already does that for if/when because they are macros, but not for throw

Lukas Domagala16:01:38

@UGC0NEP4Y interestingly some things are not direct linked in clojure core, like conj. ran into this here:


throw is not a macro but a special form


yes, the point is that clj-kondo could send a info saying that is a special form


so clojure-lsp can color like macros or other color users would choose


issue welcome

👍 1

if is also a special form. And looks like a regular function in Calva.


yeah, I can repro that as well :thinking_face:

Alex Miller (Clojure team)16:01:55

@U02EMBDU2JU conj is direct linked, so that doesn't make sense to me (you won't see direct linking when a function is used as a HOF though)

Alex Miller (Clojure team)16:01:45

oh, the example there is reverse, which indeed is using conj as a HOF. something like select-keys is an example where direct linking would happen

Lukas Domagala16:01:26

@U064X3EF3 ah you are right, I miss remembered. sorry for spreading missinformation

Alex Miller (Clojure team)16:01:42

Everything in Clojure that is pre compiled (which is almost everything, but not quite), and that is not marked as ^:dynamic or ^:redef will be direct linked


Have I broken something on my system? I can't jack into any REPLs all of a sudden on Ubuntu. Have been away from this machine for a week or two. > clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.9.0"},cider/cider-nrepl {:mvn/version,"0.27.4"}}}' -M -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]" > Missing required argument for "-M ALIASES" > Jack-in process exited. Status: 1


My deps.edn for this project (that used to work).

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}
        vlaaad/remote-repl {:mvn/version "1.1"}}
  :remote-repl {:extra-deps {vlaaad/remote-repl {:mvn/version "1.1"}}}
  :reveal {:extra-deps {vlaaad/reveal {:mvn/version "1.0.130"}}}
  :test {:extra-paths ["test"]
         :extra-deps {org.clojure/test.check {:mvn/version "1.0.0"}}}
  {:extra-deps {com.cognitect/test-runner
                {:git/url ""
                 :sha "b6b3193fcc42659d7e46ecd1884a228993441182"}}
   :main-opts ["-m" "cognitect.test-runner"
               "-d" "test"]}
  :uberjar {:extra-deps {seancorfield/depstar {:mvn/version "1.1.128"}}
            :main-opts ["-m" "hf.depstar.uberjar" "maze-solver.jar"
                        "-C" "-m" "exfn.maze-solver"]}}}


Tried a few other projects that I also knew worked (e.g. this years advent of code project) and I'm getting same error.


My clojure is 1.10.1 I can create a repl via the command line

(base) [18:32]: stuart@stuart-Z87M-D3H:~$ clj
Clojure 1.10.1
user=> (+ 1 1)


Stripped the deps.edn down to just

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}}
Same error.


We have recently changed code around this. Maybe we broke something. Are you selecting any aliases?


I can start the "Getting Started" repl


What I see


went back to v2.0.225 and it works


I'll find the version where it stops working


2.0.231 works 2.0.232 doesnt work. I can't jack in with this version onward


Any debug / logs or anything I can give you to help ?


I’m afk. What does the changelog for 232 say?


Ok, the problem was at my end. I was on CLojure 1.10.1, I upgraded to 1.10.3 and now it all works.


So maybe the change in 2.0.232 to add the -M isn't supported in 1.10.1


I see. Now I feel a bit slow. 😃 But now I get it, at least. Indeed, we were a bit too quick to make that change. In 235 we added an option to stay with -A, for people working in projects that haven't upgraded.


Don't confuse Clojure versions with CLI versions.


Check what clojure -version says -- I expect you upgraded the CLI @U013YN3T4DA to fix this? Because your CLI version was too old.


The version of Clojure (the language) is independent of the version of the CLI (the command-line tool). The latter just happens to specify a default version of Clojure if your deps.edn doesn't do so explicitly (which I would always strongly recommend doing). You can run any version of Clojure with any version of the CLI (since they are independent).