Fork me on GitHub
Yuner Bekir10:12:36

Can I start 2 projects in 2 seperate repls with the same vscode instance?


Yes. REPL sessions are local to each VS Code Window. So open each project in a separate window and you should be good.

Yuner Bekir10:12:01

By instance I meant window, sorry for the wrong phrasing.


Alright. Then no. 😃

Marc O'Morain12:12:50

Calva currently has four ways of running tests: • Run All Tests (No evaluation, runs all tests) • Run Tests for Current Namespace (Evaluates the current file, finds a matching -test file if one exists, runs tests in both files). • Run Current Test (Evaluates the current file, finds the var under the cursor, and tests that var) • Run Failing Tests Again (Evaluates current file, calls the cider-nrepl restest op, When we add test explorer, there will be some more ways to run tests: You will be able to run all tests, or chose some test(s) to run from the tree-view. This allow you to run tests for a namespace or var. What should the behaviour be for evaluating files in these cases? Let’s say someone’s editor is in src/foo.clj (namespace foo) and they click on the “Run Test” button for namespace bar. What should be evaluated?


For a namespace it makes sense that the file is loaded, I think. (Or evaluate the whole file, tbh I am not completely sure what the difference is in results.)


It could also be argued that nothing should be evaluated. And that whatever is loaded in the REPL is what is run.


So, maybe a setting, Load current namespace and test namespace when running tests defaulting to false.

Marc O'Morain12:12:25

The current behaviour of Run Current Test is nice IMO - with my cursor on a form I can press ^⌥CT to run the test, regardless of the state of the REPL

Marc O'Morain12:12:41

I’d like our behaviour to be the least surprising option. I don’t know what that is though.


Yes, running the test regardless of the state of the REPL makes sense. The question is what to run. 😃 Today we load the file for all run test commands. Which, iirc means we run whatever is saved on disk. I think that could surprise some people and be what others expect. I’m usually not one to suggest settings, but here I wonder if it is not the best way. Then at least someone who is surprised by the defaults can influence the behaviour.

Marc O'Morain13:12:05

is there a way to “save” the Jack In command for a workspace? Currently, ever time I Jack In, I have to flip through the options to choose the REPL type, and then launch. I’d like to save this setting per-workspace so that I can Jack In with a single command, without a prompt.


You can get it down to one prompt using a custom REPL command sequence: (And if you squint you can regard ctrl+alt+c ctrl+alt+j enter as a single keyboard shortcut chord. 😄).

👍 1
Marc O'Morain15:12:54

Thanks :thumbsup:


Hi, anyone having issues with calva together with the Live Share extension? Use Liveshare v1.0.5196 and Calva v2.0.229. Files are edited randomly, adding brackets and adding new functions.

Jonas Hinrichs15:12:57

here is two short clips of it. Only the cursor position was changed. No other keys were pressed


Awful! Have you been using them together before and it has stopped working now, or is it the first try? I’m not a LiveShare user, maybe @UGNFXV1FA has some idea what could be going on?

Jonas Hinrichs15:12:52

it worked two weeks ago 🙂

Jonas Hinrichs15:12:04

If we disable calva then there are no random changes happening


Very strange. Afaik we haven’t changed anything in Calva that should influence this. Can you try with an earlier version of LiveShare?


And please file an issue on Github so we can track this and collect more info and such.


If you file the issue from VS Code (the Help menu) it will attach some system info that could be useful.

Jonas Hinrichs15:12:40

Problem seems to be on version 2.0.226 It works fine on 225 even with different versions of live share

Simon Opheim15:12:18

Created an issue on Github now. (#1434)


Yeah very awful indeed. I've also experienced this the last couple of weeks, but I've been so busy that I didn't get around to reporting it 😞 My hunch is this is a side-effect of some other change, but who knows. Like @U0ETXRFEW said, there were no changes to the live share part itself AFAIK.


Seems @UKFSJSM38 understands what the problem is. Thanks for the reporting! And don’t feel bad about not reporting @UGNFXV1FA. We’re all a bit too busy with other things at times!


Since latest clojure-lsp already return edits on code-actions, my suggestion is revert the PR @brandon.ringe opened to fix code actions as this is not needed anymore, right @brandon.ringe? and that should fix the issue


Do you think the change I made alone, without the edits update on clojure-lsp caused the issue? Or is it both of them combined that’s causing the issue?


yeah, I think both combined that causes the issue 😅

bringe18:12:28 Here’s the PR. Anyone, feel free to revert it, as I’m in the early part of my work day and won’t be getting to it for several hours.


But I’ll do it tonight if no one else does by then


If the issue is only affecting live shares, I think the issue is not that big, so I'd go with a safer approach of testing with caution

👍 1

Releasing it now. 😃


What was the fix @U0ETXRFEW? Did the revert of @brandon.ringe’s PR fixed the live share issue?


No, I’m sorry for spreading false information. Not releasing any fix for this. I’ll let you who understand the issue better sort that out.

👍 1

no problem, I'm just afraid of reverting that PR and introducing again the "Code actions not working" issue 😅 , I think bringe will confirm that for us later

👍 1

> Since latest clojure-lsp already return edits on code-actions This doesn’t seem to be the case. With latest (`2021.12.01-12.28.16`), codeAction/resolve requests still return a command and not an edit.


@UKFSJSM38 Did you release that change?


Calva version 2.0.231 was released and reverts the change that was likely the culprit. Can you verify that the issue is no longer present with Live Share, @U01TBJT2K5E and @U02GKV56HGC?

Jonas Hinrichs07:12:12

And we couldnt find any problems! Great job! 👍


Awesome. Great job, @brandon.ringe and @UKFSJSM38!

👍 2

@brandon.ringe you are right, I didn't release that change yet facepalm So, we are back to code actions not working but now we don't have this liveshare issue, right?


@brandon.ringe can you test later if the clojure-lsp master fixes the code action not working on calva?


so I can release a clojure-lsp version


> So, we are back to code actions not working but now we don’t have this liveshare issue, right? Correct, but I’d rather a convenience feature not work than an issue that makes Calva unusable with Live Share, for now. > can you test later if the clojure-lsp master fixes the code action not working on calva? I might not have time to test it today, sorry. If I do, I will, but I’m pretty busy.


no problem, If I have the time I can test it tonight


Is it something I can test? Just give me some info and I’ll do it now.


Just compile clojure-lsp from master and test it code actions are working again from calva dev branch


How do I test code actions? 😃 Is that the cmd+. thing?


I’ll have to test it later. Family needs food now. But I’ll do it later tonight unless someone else has beaten me to it.


So, I am not a frequent user of code actions, and I am not sure what to expect. Take this report for what it is. I am using Calva from latest dev and clojure-lsp from master and I don’t think it works. I think I could get cycle privacy to do its thing briefly, but then that stopped working as well. Mostly, if I have a saved file, any code action I try, leaves the file in saved mode (so not “dirtied” as it would be if something was edited).


that was the issue we were trying to solve @U0ETXRFEW, thanks for the test

👍 1

so it seems the issue keeps happening even if clojure-lsp is returning the edits on resolveCodeAction @brandon.ringe :thinking_face:


I can try to debug it later today if I have time


I might have tried in a project where things are not properly configured. I notice that not even refactor->rename works. Let me try in a more reasonable project…


yeah, all code actions should work, a easy test is try cycle to map on a list or set or vector


or cycle-privacy


I remember that only one was working, all the other ones not


OK, so now tried in a not-so-broken project where refactor->rename works. But no code actions want to do anything at all.


For me calva from dev + master clojure-lsp fixed the code actions issue

🎉 2

I'll test published calva now


Published calva works too :man-shrugging:


testing with latest clojure-lsp now, not master one


Yeah, it doesn't work with latest clojure-lsp, so what will fix it is indeed the next clojure-lsp release :) c/c @U0ETXRFEW @brandon.ringe


I should release this week


I noticed that on version 2.0.229 the find definition to external deps stoped working @brandon.ringe 😅


We tried to fix the find-definition inside deps and we actually broke the find definition to the deps 😂


it works on 2.0.229 but it doesn't on 2.0.229 or 2.0.230


Uh oh. Can you fix or revert?


I'm trying to understand what happened and if it's easy to fix, but I'm not finding anything, probably I'll do the revert :/


I didn't find anything, for some reason only the first textDocument/definition request is done with success and the others not, maybe we should revert and do a fix release?

👍 1
Herman Nurlygayanov15:12:44

I've just tried 2.0.233, 2.0.227 and I can't even f12 to clojure.string. I'm pretty sure I was able to jump to definitions easily before today.


Yeah, we should probably revert @UKFSJSM38 if you think that change was the cause, even if we don’t yet understand why.