Fork me on GitHub
#calva
<
2021-05-04
>
pez06:05:33

Update on Getting Started REPL problems for some Windows users: @borkdude has figured out a plan for us working around it, so we should probably soon have it working. And Oracle has acknowledged the bug, so there is hope at that end of things as well: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8266473

🎉 6
Jakub Holý09:05:16

Hello! I wonder if there is a more effective way connecting to babashka nrepl then I currently have: 1. start the nrepl: bb --nrepl-server 1667 2. Calva: Ctrl-Alt-C Ctrl-Alt-C (connect to running repl) 3. Enter to select the Generic 4. Type the port, 1667 At least is there e.g. a way to get Calva to remember the last port I used (if there is not nrepl file or similar)? Thank you!!!

pez09:05:15

Hello! You might get away with placing an .nrepl-port file in the directory where you start babashka with the content 1667.

👍 3
pez09:05:56

Also, you can avoid typing 1667 once by skipping it on the bb command line. It is the default.

Tomas Brejla12:05:04

Hi. Recently I happen to be the one person who sometimes experience strange issues 🙂. Few days ago I managed to be running a code+calva session, where there was this "Initializing clojure-lsp" message in bottom status line of the editor, but it never actually finished. I didn't really mind as I was able to work on that specific project for literally days without restarting (and with that "Initializing" message still being shown). Of course things like code-completion etc behaved in a bit limited way, but I didn't really mind. I restarted the editor today and it worked just fine, Initialization succesfully finished in a while. The project is a combination of lein project.clj backend & shadow-cljs frontend. If I remember correctly, I was trying to look for ".lsp" folder in that "initialization forever" scenario and it simply wasn't there at all. I was hoping to find some logs there, but the folder didn't exist. Today, after the succesful initialization, I can see that the folder is now present (and has todays creation time/date). If it ever happens again (I am pretty sure it wont 😄) , are there any specific logs to check?

ericdallo12:05:14

You can check clojure-lsp.out log, that usually is logged in /tmp folder

👍 3
ericdallo12:05:27

There is a :log-path setting that you can point to any folder you want (like /tmp/clojure-lsp.out): https://clojure-lsp.github.io/clojure-lsp/settings/

ericdallo12:05:53

@U9A1RLFNV It'd be nice if Calva had some log window on vscode for that log (not sure the correct name for that), for that work, I think Calva would need to pass on initialization options the path for the log via the log-path and use its content on a vscode window(not sure about this step)

pez13:05:52

There is a log in the Output pane: Clojure Language Client containing stuff like

[Trace - 3:13:05 PM] Sending notification 'workspace/didChangeWatchedFiles'.
[Trace - 3:13:08 PM] Sending notification 'textDocument/didChange'.
[Trace - 3:13:08 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 3:13:08 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Is that what you refer to @UKFSJSM38?

ericdallo13:05:29

Hum, not realy, this looks a Calva LSP log, not the clojure-lsp one, where we could find exceptions, info/warn/error logs

ericdallo13:05:06

Maybe rename that one to Clojure Language client and have a new one Clojure Language server

pez13:05:07

I have observed the behaviour too, actually. Didn’t think about it much then because it was in a Calva debug session and I thought I might have provoked it by my frequent restarts of the session (yeah, that’s how non-Clojure-coding works 😄 ).

kstehn14:05:36

😅 same for me i tried my take on to start multiple lsp for each open project and thought i destroyed something so after a few hours of trying to understand and debugging i gave up

bringe19:05:16

@UKFSJSM38 That's an interesting idea. I created this issue and tagged you in it: https://github.com/BetterThanTomorrow/calva/issues/1166

thanks 3