This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-01
Channels
- # announcements (21)
- # architecture (6)
- # aws (18)
- # babashka (14)
- # beginners (231)
- # boot (1)
- # calva (2)
- # chlorine-clover (22)
- # cider (34)
- # clara (16)
- # clj-kondo (53)
- # cljdoc (5)
- # cljs-dev (22)
- # cljsrn (3)
- # clojure (283)
- # clojure-europe (24)
- # clojure-italy (9)
- # clojure-nl (5)
- # clojure-spec (5)
- # clojure-uk (57)
- # clojurescript (14)
- # core-typed (8)
- # cursive (4)
- # data-science (7)
- # datomic (41)
- # docker (24)
- # duct (2)
- # emacs (2)
- # exercism (29)
- # fulcro (96)
- # graalvm (4)
- # jobs-discuss (1)
- # kaocha (53)
- # lambdaisland (20)
- # malli (5)
- # nrepl (4)
- # observability (7)
- # off-topic (40)
- # pathom (44)
- # pedestal (8)
- # re-frame (19)
- # shadow-cljs (58)
- # spacemacs (2)
- # sql (9)
- # tools-deps (15)
- # vim (3)
- # yada (10)
Hi! I'm working on improving the nREPL support in Arcadia (https://github.com/arcadia-unity/Arcadia), which uses clojure CLR. A particular issue I'm facing is that CIDER sometimes wants to know about the classpath, and since Arcadia's nREPL implementation does not have a classpath (it's not even Java), we can't implement the "classpath" op, so CIDER seems to resort to its own workaround (https://github.com/clojure-emacs/cider/blob/4cc4280677e6eeb16cd55d9865c0ea9f9d141af3/cider-client.el#L517).
This ends up making thigs worse. Sometimes emacs will only ask for this once, and when the op fails it will query the minibuffer for a "Lisp Expression: ". However (and this is where things really get bad), sometimes when browsing specific files, emacs will start to spam Arcadia's nREPL server in a seemingly infinite loop asking for the classpath using cider-fallback-eval:classpath
This latter case makes emacs freeze completely, loosing all unsaved work and forcing me to restart.
In any case, what I'm looking for is a way to workaround this issue. Why does cider need to know about the classpath so badly that if the classpath op is not supported it will try to do its own version? Moreover: How is the classpath used? Even if C#/CLR have no notion of a classpath, perhaps we could return something useful and take this as an opportunity to make cider work even better in CLR. I'm assuming cider is using the classpath op to gather info about the location of files (perhaps to handle jump-to-definition in the doc view? That'd be particularly interesting to have).
Finally: Is this cider-fallback-eval:classpath
"spam" (sending several queries per second) intended at all? Perhaps there's a bug somewhere in the implementation? I think this can be reproduced by opening a file in clojure mode that does not have an ns
declaration on top (for example, an edn config file)
> This ends up making thigs worse. Sometimes emacs will only ask for this once, and when the op fails it will query the minibuffer for a “Lisp Expression: “. However (and this is where things really get bad), sometimes when browsing specific files, emacs will start to spam Arcadia’s nREPL server in a seemingly infinite loop asking for the classpath using cider-fallback-eval:classpath Yeah, I’m aware of this problem. That’s going to be easy to fix, provided there’s some way for CIDER to understand its not talking a Clojure endpoint. Is Arcadia’s nREPL server standalone? I recall in the past there was only some middleware that was proxying evaluations outside of nREPL. Has this changed?
I was thinking we can add a bit more data to the describe
op in this case, and this would make it easy for CIDER to do things conditionally based on the server’s implementation.
> In any case, what I’m looking for is a way to workaround this issue. Why does cider need to know about the classpath so badly that if the classpath op is not supported it will try to do its own version? Moreover: How is the classpath used? Even if C#/CLR have no notion of a classpath, perhaps we could return something useful and take this as an opportunity to make cider work even better in CLR. I’m assuming cider is using the classpath op to gather info about the location of files (perhaps to handle jump-to-definition in the doc view? That’d be particularly interesting to have). The classpath is mostly used to map logical connections in CIDER to projects. Let me dig the relevant code for you.
Ah, I see we also use it to infer the expected ns, which is probably causing the bigger issue you’ve observed.
Check out https://github.com/clojure-emacs/cider/blob/93ff91a1d79ba3094a50a7b01700b02d720e14b8/cider-connection.el#L463 and https://github.com/clojure-emacs/cider/blob/4cc4280677e6eeb16cd55d9865c0ea9f9d141af3/cider-client.el#L141
At any rate - I don’t think it will be hard to solve this. I’d love for CIDER to support well different nREPL servers/languages. This wasn’t a priority so far mostly because it seemed there was not much interest there.
> I was thinking we can add a bit more data to the describe
op in this case, and this would make it easy for CIDER to do things conditionally based on the server’s implementation.
Adding more data to the describe op would be really simple from our side. What should we add to the describe op that would make sense? I'm not very familiar with the nREPL protocol myself
> Is Arcadia’s nREPL server standalone? I recall in the past there was only some middleware that was proxying evaluations outside of nREPL. Has this changed?
There's currently a (more or less) complete nREPL server implemented in C#: https://github.com/arcadia-unity/Arcadia/blob/268bed0fc9dc5143870259d88a142d60ae8b7f9d/Editor/NRepl.cs#L291
> Ah, I see we also use it to infer the expected ns, which is probably causing the bigger issue you’ve observed. That makes sense. Probably some piece of code needs to know about the expected ns, and since our nrepl server is crashing and returning an error, things get messy...
/Users/bozhidar/projects/nrepl/test/clojure
/Users/bozhidar/projects/nrepl/src/clojure
/Users/bozhidar/projects/nrepl/dev-resources
/Users/bozhidar/projects/nrepl/resources
/Users/bozhidar/projects/nrepl/target/classes
/Users/bozhidar/.m2/repository/cider/cider-nrepl/0.24.0/cider-nrepl-0.24.0.jar
/Users/bozhidar/.m2/repository/nrepl/nrepl/0.6.0/nrepl-0.6.0.jar
/Users/bozhidar/.m2/repository/clojure-complete/clojure-complete/0.2.5/clojure-complete-0.2.5.jar
/Users/bozhidar/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar
/Users/bozhidar/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar
/Users/bozhidar/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar
> Probably some piece of code needs to know about the expected ns, and since our nrepl server is crashing and returning an error, things get messy... Yep, that’d be my guess.
As you can imagine the expected ns functionality relies mostly on the paths for the source dirs the expected ns can be derived from those.
> Is there something similar in CLR that you can return? There definitely is! I was wondering about the specific format. I'm guessing this should be a string containing an edn-formatted list of strings?
Just to confirm I got this right. Let's say I have a namespace called my.great.ns
, which is in file "/home/username/Project/src/my/great/ns.clj", the classpath entry should be "/home/username/Project/src/", right?
> There definitely is! I was wondering about the specific format. I’m guessing this should be a string containing an edn-formatted list of strings?
It should be a sequence of strings. All sequences are represented as lists in bencode.
I run cider-test-run-project-tests . and the tests failed. I edited the file, rerun cider-test-run-project-tests
@i if you change the code of your tests, then you will need to evaluate the new code for the CIDER test runner. You could evaluate the deftest
function as soon as you change it, or evaluate the whole test buffer.
Spacemacs provides wrapper functions around the cider-test-run-*
functions which include a call to cider-load-buffer
so you could take the same approach.