Fork me on GitHub

I have calva installed in VSCode. I am Just trying to do a REPL jack-in using `ctrl+alt+c ctrl+alt+j`. (This has worked many times in the past.) Then I get this error: `Unable to resolve filesystem provider with relative file path 'd:\work\projects\formula/.calva/output-window/.clj-kondo'` (`d:\work\projects\formula` is my project folder, I don't see a .calva folder created there though.) I tried restarting VSCode/machine, moving project location, creating new fresh project, etc and nothing works. What is wrong and what can I do? I'm not sure if this is a VSCode issue or something related to Calva.


Any idea on this error?


@dumrat This error was posted two messages before you as well


Yep, got it. Thanks


@borkdude Happens in 2.0.129 also fyi


it seems Calva is appending a unix style path to a Windows style path


Why does Calva sets Ctrl+W for expanding selection? There is already a shortcut for that in vsc, and default meaning for Ctrl+W to close the tab is pretty widespread


Hello. See this issue: for a short discussion on this.


And please voice any other concerns you may have there. I'm not sure yet if changing it makes sense, but maybe setting different shortcuts per OS is the way to go. This gets into a larger change, however, as this might be appropriate for other shortcuts as well.


Yes, on the general issue of shortcuts we should probably consider making more per-OS exceptions.


As for why it is ctrl+w, it is for legacy reasons. That was what was (is actually) used by the original Paredit extension.


Just to post here again, if anyone is having issues with jack-in, please install version 2.0.126 until we fix. I think the issue is only happening for Windows users now, but if you see otherwise, let us know. I'm looking into the issue now, and hopefully someone with a windows machine can test the vsix when it's ready.


Ok, it's pretty hard for me to fix this blindly, as I don't have easy access to Windows. Can anyone here that uses Windows debug this issue? I've pinged @slack1038 and @stefan.van.den.oord in this issue as well to see if they can help: I've also added some info in that issue to point anyone who can look into it in the right direction. Your efforts would be much appreciated 🙏 . CC @pez


Seems like @nikolaev.andrey and @dumrat could be of assistance when debugging this.


I can help with that on Monday. I am on a screens 'detox' this weekend.


I've downgraded calva to 2.0.126, and jack-in seems to work, but now I'm getting a "clj-kondo was not found on the classpath. Debugger decorations will not be enabled. More details:" warning. I've reinstalled clj-kondo (and calva), and restarted VSCode, but the error persists. Any ideas?


@fadrian, don't worry about that. It is not an error really. Just Calva making some unnecessary noice. 😃


OK. thanks, but I'm not seeing any issues from clj-kondo, when the last time it loaded I had three issues outstanding and I know I haven't fixed them.


Never mind. For some reason, it seems to be working now.


clj-kondo is involved in different ways. The linting is quite loosely coupled, just Calva bundling the clj-kondo extension. But we are also using clj-kondo internally to figure things out about the code. That message you get there leaks about this implementation detail. And confuses. We should fix that too. So many things to fix! 😄


Understood (and my sympathies for the normal state of things 😀). I have another issue, this time with the stepper. It seems when I'm debugging and try to "step into" a different function (whether in the same or a different file), the location icon displays a green outline (rather than the solid yellow location icon that appears when the stepper is working) and the debugger control shows a pause icon instead of a run icon and then looks like it hangs. The step icons are disabled at that point, and though the disconnect and restart icons are operable, what I really want is stepping into a function to work. Does stepping actually work correctly?


It does in my experience. Do you have some kind of lazy infinite seq somewhere in the code being stepped over? If you have something like (map + (range)) somewhere then that (range) will hang up the debugger because it tries to evaluate it.


In this case you can set the dynamic var *print-length* to some finite value (smaller is better) and it should work. If this is not your situation, if you can provide a screen recording in an issue that would be great.


I checked and I do return a lazy sequence from a map, but I've set *print-length* to 5 and it still shows the same behavior.


I'll try to get a screen recording.