Clojurians Log v2

Our project is on Java 17 because we run on Datomic Cloud, which is the runtime it uses. I am using asdf to manage my Java versions, so it is possible to run the DAP and the project in different versions if that works and the Java 21 support is only for the DAP project runtime and it doesn't need any 21+ features in the nREPL runtime

clojure-dap is a standalone DAP server that talks to your project via nrepl. Not tried it but that doesn't sound like it cares what JVM your project is using.

IIRC no hard reasons, it's just what I was testing on and developing against 🤔 the only thing I can think of is that the CIDER debugger needed some features from newer JVMs to operate but I can't remember anything explicit.

I suspect it should really just say that it's developed and tested against a minimum version. As long as nREPL + CIDER and it's debug middleware can load in your JVM then the DAP server one just needs to support the relay / DAP server which talks to your app over nREPL. So it should be fine down to a very old JVM. I'll look at updating wording if so.

Should go down to Java 8+ technically since I'm depending on Clojure 1.12 and that has a minimum version. Although you can probably slap an older Clojure in there and it'd work fine too.

Yep it's not a specific JVM requirement AFAIK. Updated the docs to be wider, you just need a way for your editor to launch a Clojure process with Clojure DAP running as a library within it. Your editor can then talk to that server over DAP which talks to your nREPL to run debugging.

Are there any other requirements from the project side? I have setup an alias that does a :replace-deps since if I don't do replace deps and it extends the deps.edn in my project there is a Jackson XML error from jsonista

:nrepl {:extra-deps {nrepl/nrepl       {:mvn/version "1.7.0"}
                     cider/cider-nrepl {:mvn/version "0.62.1"}}
        :main-opts  ["-m" "nrepl.cmdline" "--middleware" "[cider.nrepl/cider-middleware]"]}
:clojure-dap {:replace-deps {uk.me.oli/clojure-dap {:mvn/version "RELEASE"}}
              :exec-fn clojure-dap.main/run}

This is correct, yes. The DAP side is a Clojure process that relays the DAP protocol over stdio to nREPL CIDER debugger commands. So you can start Clojure DAP with an entirely different tree of deps to your project, as long as your project exposes an nREPL server with CIDER middleware loaded.

Then your editor through config will invoke the desired script to start the Clojure DAP subprocess and communicate with the child.

From your DAP editor plugin perspective, it's running a script that speaks DAP in it's STD I/O and that's all it's aware of.

So it's editor -> editor dap plugin -> wrapper script -> Clojure DAP JVM process -> target nREPL

👍

that is what I thought from looking at both Conjure and Clojure-DAP

And the design of the wrapper script committed in the repo should hopefully mean others in your team could rely on that same setup.

That's the idea anyway

And OS specific shenanigans or tooling switches can go in there, whatever you need for your project

Still working through to get things to communicate, I got it starting but was having problem setting breakpoints and watching them get triggered when running tetsts

I am sure it is something in my local config (especially now), but wanted to check if there were some nuance I was missing

It's a bit fiddly I'm afraid, I've had it working pretty well but the nature of the DAP editor states of breakpoints as well as the CIDER breakpoints means you have two things that CAN get out of sync. Tried my best to keep it tidy but it's an inherently hard problem to glue two stateful protocols together.

It's not like the DAP relies on your adaptor to dictate the breakpoints declaratively, you sort of have to send stateful RPC things from what I remember which was a headache.

If the DAP in the editor thinks it set a break but the CIDER side didn't for whatever reason for example.

Needs some in anger use and bug reporting ideally!

I will keep playing with it

thanks for taking the problem on

Oh also not all dap clients are created equal. I remember one of the main ones I was trying to use in nvim was not standards compliant and I had to fudge around it I think? And I think the Helix one may have completely crashed after a completely normal interaction. It's not a widely tested and used thing it seems!

I was using the nvim-dap as per your README for neovim. I will continue to fiddle with it and if something jumps out as distinctly odd, I will report back 😄