Fork me on GitHub
#calva
<
2023-10-02
>
vemv15:10:52

👋 there's been many improvements in cider-nrepl (and its base libs orchard, haystack, logjam, compliment) since last summer. (Feel free to check out their changelogs) I'm now looking at the next batch of improvements and I'd like to know, which would benefit Calva the most? Any suggestion is welcome e.g.: • features • bugfixes • things that may be annoyances that have to be worked around One that most certainly will be worked on is https://github.com/clojure-emacs/cider-nrepl/issues/555, which I see has a @pez comment. How is the cljs testing experience with calva nowadays?

pez15:10:46

Thanks for reaching out! ❤️ I’ll definitely have a look at that changelog. And figure about what Calva would benefit from going forward. I hope other Calva users and <!subteam^S03BGSAUPTQ> do the same! Making the test ops work for CLojureScript would be wonderful. The testing experience in Calva is that people either use the REPL, possibly with some custom REPL command snippets on top, or an external test runner (I use the shadow-cljs runner). It’s fine, but having it integrated in VS Code is of course a different level.

vemv16:10:24

That's useful input! Looking forward to some more calva cider (also, TIL shadow-cljs has a runner)

seancorfield17:10:49

As a Calva user, I don't use Calva's built-in test running stuff. I have three hotkeys bound to: • Run tests in the current ns • Run tests in test ns associated with the current (src) ns • Run the "current" test -- the one that my cursor is in The result of the eval is the summary hash map, so I can see in Portal at a glance how many tests ran/passed/failed/errored. The first use case is one that Calva supports directly but I'm not sure about the other two and I'm not sure what output they would produce using the built-in testing stuff. My evals are a tap> of the ns about to be tested, a require of the test ns, and then a clojure.test/run-tests call. I don't know how that compares to Calva/CIDER?

Cora (she/her)17:10:53

a great question, always, is which users to optimize for (without hurting the others, of course)

👍 1
vemv17:10:37

@U04V70XH6 It compares simply in that it's an integrated experience, i.e. you have some UI affordances, you don't context-switch to some other app (or a second-class corner of the editor, e.g the Emacs minibuffer or wherever your evals go) As of lately CIDER also has fail-fast (a very common feature tbf) and improved inference from src to test (mixture of runtime- and source analysis). Other than that, no flashy features are provided. Well, we also print basic diffs (provided by data.diff, not as readable as deep-diff's), for data where diffing makes sense. And we print a hierarchy of timing info (all, per-ns, per-var).

seancorfield17:10:43

@pez I just searched the command palette for calva test and didn't find anything -- what should I be looking for, for Calva's testing commands?

seancorfield17:10:56

(duh! I hadn't started my REPL -- and I actually have had coffee this morning!)

pez17:10:32

I was just about to ask if you had. 😀

seancorfield17:10:49

OK, so I guess my "problem" with the built-in stuff is that the results only show in Calva's output window which I pretty much never open, so they're not routed through the normal eval middleware -- and so Portal's middleware doesn't see them?

vemv18:10:25

> OK, so I guess my "problem" with the built-in stuff is that the results only show in Calva's output window which I pretty much never open Does it not integrate with the file tree, something like that? I believe LSP provides some sort of "test framework" interface such that if you comply with the interface, users will get the same affordances across languages

pez18:10:19

Calva integrates with the VS Code test explorer, and also populates the Problems sink, which makes failed tests show in the file explorer, as well as in the editors (and the Problems pane). There’s some info about this here: https://calva.io/test-runner/

1
vemv18:10:32

That would seem like a strong incentive to make it work for cljs :)

seancorfield18:10:48

@pez How exactly does ctrl+alt+c t work under the hood in terms of nREPL? I have an instrumented version of the Portal middleware in place and I see the eval of load-file when I run tests (which I didn't expect) but I don't see any other nREPL ops flowing through the middleware?

seancorfield18:10:03

I see this in the Calva output window:

; Running tests for the following namespaces:
;   ws.configuration.impl
;   ws.configuration.impl-test
; 7 tests finished, all passing :+1:, ns: 1, vars: 2

seancorfield18:10:45

(I'm trying to figure out if I can get Portal to intercept and handle the testing stuff so I can get it all unified)

pez19:10:10

Calva send the test-var-query op and iterates through the response from that to print results and update Problems and the Test Explorer. See the nrepl message log for what’s in the request and the response.

pez19:10:19

Could it be that Portal should tap in to this exchange in order for it to pick things up?

seancorfield19:10:24

The only :op values Portal's m/w sees are debug-instrumented-defs and eval -- I don't see the test-var-query op flow through.

seancorfield19:10:43

Maybe I need to tweak more parts of the m/w code (I'm not too familiar with nrepl stuff... yet).

seancorfield19:10:00

Oh, it looks like multiple places in the code test the op and I only updated one... just a sec...

seancorfield19:10:42

Meh, that change wasn't enough. I'll have to chat with @U1G869VNV about it, I suspect.

seancorfield19:10:47

I would I even see the nrepl message log?

seancorfield19:10:55

I see clojuredocs-lookup ops as well. No test-var-query op tho'...

pez19:10:49

I see this running the tests in a project with two tests:

-> sent
{
  op: 'test-var-query',
  id: '28',
  session: '600472a3-1bb2-42d4-a0b6-3cd6d4942717',
  'var-query': { 'test?': true }
}

<- received
{
  'gen-input': [],
  id: '28',
  results: { 'pez.taplet-test': { 'let>': [Array], 'let>l': [Array] } },
  session: '600472a3-1bb2-42d4-a0b6-3cd6d4942717',
  summary: { error: 0, fail: 0, ns: 1, pass: 11, test: 11, var: 2 },
  'testing-ns': 'pez.taplet-test'
}

<- received
{
  id: '28',
  session: '600472a3-1bb2-42d4-a0b6-3cd6d4942717',
  status: [ 'done' ]
}

djblue19:10:06

Looks like you need to opt-in via calva.useTestExplorer: true

seancorfield19:10:25

Yay! 🙂 I still don't see those test ops reported from the Portal middleware (I added a tap> of every op)

pez19:10:01

Yes, it’s opt-in. We’ve never taken it out of the experimental phase. If a test fails you get stuff like this:

seancorfield19:10:10

OK... @U1G869VNV Shall I take the convo to #C0185BFLLSE to figure out what's needed to hook this into Portal as well?

👍 1
djblue19:10:27

btw is there a reason that test-var-query is an op?

vemv19:10:47

Many things are a distinct op... clients are thin and diverse, they just should say "do X for me" and cider-nrepl does it (thin as in, thin requests, no big thing to evaled)

👍 1
seancorfield20:10:51

(working with Chris and getting better results with my local modified Portal code now!)

djblue20:10:06

I think with something like https://github.com/clojure-emacs/cider-nrepl/pull/822, both middleware should be able to transparently work together 👌

metal 2
seancorfield21:10:21

@U45T93RA6 ☝️:skin-tone-2: This PR would be very helpful in terms of moving this integration forward.

djblue00:10:21

Anyone have any idea why calling clojure.test/report in the test would cause Exception in thread "nREPL-session-4121d9cc-d3aa-4b81-b97c-5d2d763eaf0e" java.lang.IllegalArgumentException: No implementation of method: :send of protocol: #'nrepl.transport/Transport found for class: nil ?

djblue00:10:50

cider.nrepl.middleware.test -> clojure.test -> nrepl.middleware.print -> No implementation of method: :send of protocol: #'nrepl.transport/Transport found for class: n is roughly the stacktrace.