This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # beginners (30)
- # boot (7)
- # cider (52)
- # clara (91)
- # cljs-dev (33)
- # cljsjs (1)
- # clojure (447)
- # clojure-brasil (3)
- # clojure-dev (16)
- # clojure-dusseldorf (5)
- # clojure-filipino (1)
- # clojure-italy (29)
- # clojure-sanfrancisco (5)
- # clojure-spec (62)
- # clojure-uk (37)
- # clojurescript (145)
- # clojurewerkz (1)
- # code-reviews (12)
- # community-development (157)
- # cursive (5)
- # datascript (1)
- # datomic (27)
- # editors (42)
- # emacs (5)
- # fulcro (31)
- # hoplon (2)
- # jobs (2)
- # keechma (1)
- # lumo (31)
- # off-topic (2)
- # om (1)
- # onyx (13)
- # parinfer (8)
- # re-frame (13)
- # reagent (32)
- # remote-jobs (4)
- # shadow-cljs (103)
- # spacemacs (15)
- # specter (10)
- # sql (1)
- # tools-deps (35)
- # unrepl (13)
re switching cljs/clj for cljc files, CIDER by default evaluates the code to both connections. i don't like this feature at all
How important is a debugger to you guys? There is another extension that has that, but I have never gotten it to work. Right now focusing on the interactive programming for this extension.
@pez FWIW, I haven't used a (traditional/step) debugger in any language for maybe three decades.
@dpsutton When you send a file, it just sends it to the currently selected REPL, whichever that is.
It’s particularly useful because the Cursive code isn’t pure Clojure, but I use it for pure Clojure code too (although less)
@cfleming: I'll have to consider adding debugger support, I guess. Do you know what the dependency requirements are for Cursive's debugger?
Well, Cursive just uses IntelliJ’s one, but that dependency comes for free because I’m building on IntelliJ. It uses JDI/JDPA under the hood.
Cursive doesn’t have a built-in CLJS REPL right now, just a clojure.main one that you can use to bootstrap a CLJS one. That rules out a lot of the nice functionality that the CLJ REPL has, like interactive test integration, pretty printing of results etc.
I think your best approach would be to integrate the CIDER debugger into Code. Writing a JDPA client from something not running on the JVM is going to be really painful.
The CIDER one arguably works better than Cursive’s for pure-Clojure code since it’s not line based, but doesn’t work at all for e.g. stepping into Java deps.
I see, in my case the user has to start the CLJ REPL and then bootstrap the CLJS one on top of that. Then the extension finds the respective sessions using CIDER.
It’s not that JDPA is bad, but writing a client without using JDI (the Java client on top of the socket protocol) is likely to be a ton of work.
If you decide to investigate going down that road, I recommend watching my talk on the Cursive debugger, I talk a lot about the various pitfalls of line-based debugging with Clojure code.
A problem my extension suffers from badly right now is that it only reports when all tests are run, which does not work for the project I am working in right now. That and I need to implement the rerun test Cider feature.
It is, I just need to figure out how to get the results out as they come in. Haven't investigated it much yet.
I do mark any test failures in the editor, though. 😄 So running namespace tests is still very productive. I run both the tests in namespace and any conventionally named test namespace. Not sure how Emacs does that. The reason I am even using VS Code is that my little machine does not cope well with Emacs, so it is hard for me to try things out there.
I’ve started on LSP server for clojure https://github.com/snoe/clojure-lsp if anyone is interested.
You may be interested in speaking to @U05224H0W who started to explore this already a while back.
@snoe I am! I'm pretty new to the concept of LSPs though, can you share what use cases you see for a Clojure one?
@cfleming: So given that I might be able to use that Java debugger somehow. From a user perspective, which one do you think is to prefer? (I understand that stepping into Java deps must be extra convenient for you. 😄)