Fork me on GitHub

How come orchard libs don't get added to the classpath along with cider-nrepl?


eg. I'm trying to override a multimethod of orchard.inspect/inspect-value from the REPL to get more useful displays in the Cider inspector


ah.. I was looking at cider-nrepl's deps.edn file instead of project.clj


which uses mranderson to inline all its deps 👀


maybe there's an argument to not inline the orchard deps? Those have a very small chance of colliding with the project's deps


yeah, I was wondering why I couldn't sesman-link my local cider-nrepl project and eval the ns forms


turns out all the orchard namespaces are renamed to eg.`cider.nrepl.inlined-deps.orchard.v0v5v5.orchard.misc`


The inspector could really benefit from some sort of interface to choose and display the most salient keys of a large map upfront :thinking_face:


What form of interface? Some configuration of preferred keys? I guess that will be pretty simple to do.


Yeah, although I don't know what would be the best place for that to go


an elisp var that's passed as an argument to the :inspect op?


or a dynamic clj var in cider.nrepl.* or orchard.* namespace?


eg. a summary like this isn't very helpful


I actually use orchard in my projects for miscellaneous tooling. Please keep inlining it.

👍 1

@dominicm Just curious, are you using a significantly older version of orchard that's incompatible with the cider-nrepl dep? I've never had to deal with conflicting deps on the JVM before, so not sure what effect not-inlining would produce


I might be using a significantly older version one day, I don't want to have to change code if I have to debug an unrelated issue on an old project.


I guess there's an inherent tension between these different uses of the library, unless there's a portable way of doing the following in a project's dev namespace:

(ns my.cider-helpers
   [cider.nrepl.inlined-deps.orchard.v0v5v5.orchard.inspect :as orchard.inspect]

;; human-readable display of Things in the cider-inspector buffer
(defmethod orchard.inspect/inspect my.awesome.library.Thing
  [inspector obj]
  (-> inspector
    (orchard.inspect/render-labeled-value "Frobble" (map str (.zork obj)))))
Without similarly requiring code changes (to the v0v5v5) for every user who jacks in with a different version of cider-nrepl


The only solution is to not make breaking changes, and orchard is too young to promise that.


My perspective is having just dug into the inspector code and finding that it was easily user-extendable via the orchard.inspect/inspect multimethod, which would open up lots of possibilities eg. for user-friendly representations of domain objects like in REBL


However due to inlining one would actually have to refer to the cider.nrepl.inlined-deps.orchard.v0v5v5.orchard.inspect namespace, which would break every time cider-nrepl bumps the version number


Btw, keep in mind there’s one more problem with not inlining orchard - currently it still has one dependency that needs to be eliminated - dynapath. It’s used only to add some resource jars to the classpath, so probably we will move this to cider-nrepl at some point.


Alternatively - you can build a version of cider-nrepl without inlined deps and just locally override the one you downloaded from clojars.


Does cider do something weird with ns ?


When using overlay eval ?


If I eval this in order from top to bottom:

(ns foo)
(ns bar)


And then I eval the first *ns* it shows foo, if I go eval the second *ns* it shows bar.


As if it is automatically looking above the line I am evaling for the first ns it finds and executing the ns call before evaling the line


If I execute the second *ns* but with (ns bar) commented out for example, it shows foo again


evaling sends the namespace of the file


  id                             "750"
  op                             "eval"
  session                        "9eac7398-98da-4943-9188-413884151cbc"
  time-stamp                     "2020-01-08 11:53:58.559066000"
  code                           "*ns*"
  column                         1
  file                           "/Users/dan/projects/aclaimant/acl/src/aclaimant/services/cor..."
  line                           78
  nrepl.middleware.print/print   "cider.nrepl.pprint/pr"
  nrepl.middleware.print/quota   1048576
  nrepl.middleware.print/stream? nil
  ns                             "foo"


Hum, interesting, so when doing buffer eval, it always eval in the context of the first ns found


above your form


To add a bit of details - that’s coming from clojure-mode, as CIDER just uses its mechanism for ns detection. To me this behavior seems pretty reasonable, but I guess I’m biased. 🙂


If you set the ns as a buffer local for some buffer that’s going to take precedence over any ns form in the buffer.


There's an emacs buffer local var for ns ?


And that would be used instead?


And ya, I think its reasonable, but surprising when you don't know and have code that does funky stuff with ns 😛 like using it in a do and wondering why its not changing *ns*


And is that eval also inside its own thread ?


Or more, I've always wondered how cider-interrupt worked


There’s one session thread that’s re-used for all evaluations until you interrupt an evaluation.


Awesome! Will read up on it


Btw, @didibus why do you think the current behaviour is weird? To me it stands to reason that the closes ns form should be the effective ns.

👍 1

More that it is surprising, because its doing implicit things that aren't standard REPL behavior. I normally expect that what happens to the REPL are the forms I send to it, in the order I send them in. In this case, its like implicitly sending another form prior, switching the ns. I can see how that's a convenient feature most of the time. But in my case, I was wrapping the ns call inside a do and I had a macro that switches ns and back and all that. And as I was trying to test my code, I thought somehow it didn't work, but then realized it does work if run in the repl buffer or with lein run, but just not when using the overlay eval.


Now I know that it does that, so it won't be a problem.


if your repl ns is foo and you're in the buffer for bar you need inline results to be evaluated in terms of bar, not whatever ns is in your repl


its a convenient feature almost all of the time

☝️ 1

I mean, need is a strong word. It's a good default I totally agree. I actually think it's cool that cider does that. Since that's what I want 99% of the time. In fact, I used to use CounterClockWise before coming to Cider a while back, and CounterClockWise was much more standard REPL based. So all evals would always be in the context of the REPL, And I got used to doing buffer eval instead of eval last-sexpr specifically because of this


But like all "magic", when it doesn't work, you waste a lot of time wondering what the hell is going on 😛 Unless you know about the magic and what it does under the hood.


Anyways, thanks all. I have no complaints, just needed to be educated on the feature.


yeah. agreed on that