This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-08
Channels
- # alda (1)
- # announcements (18)
- # babashka (101)
- # beginners (110)
- # calva (17)
- # cider (53)
- # clara (18)
- # clj-kondo (26)
- # cljdoc (6)
- # clojure (152)
- # clojure-europe (9)
- # clojure-portugal (4)
- # clojure-spec (20)
- # clojure-survey (7)
- # clojure-sweden (10)
- # clojure-uk (10)
- # clojured (1)
- # clojurescript (29)
- # core-async (7)
- # cursive (4)
- # datomic (11)
- # defnpodcast (2)
- # dirac (1)
- # emacs (13)
- # events (2)
- # figwheel-main (1)
- # fulcro (1)
- # jobs (14)
- # jobs-discuss (17)
- # leiningen (2)
- # malli (1)
- # off-topic (74)
- # overtone (1)
- # pedestal (4)
- # planck (2)
- # re-frame (7)
- # reitit (4)
- # remote-jobs (4)
- # shadow-cljs (78)
- # slack-help (3)
- # spacemacs (56)
- # test-check (3)
- # tools-deps (6)
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
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.
I actually use orchard in my projects for miscellaneous tooling. Please keep inlining it.
@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
(:require
[cider.nrepl.inlined-deps.orchard.v0v5v5.orchard.inspect :as orchard.inspect]
[my.awesome.library]))
;; 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-nreplThe 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.
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
(:require
[cider.nrepl.inlined-deps.orchard.v0v5v5.orchard.inspect :as orchard.inspect]
[my.awesome.library]))
;; 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-nreplAlternatively - you can build a version of cider-nrepl
without inlined deps and just locally override the one you downloaded from clojars.
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
(-->
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
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.
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*
There’s one session thread that’s re-used for all evaluations until you interrupt an evaluation.
I wrote a blog post about this here https://metaredux.com/posts/2019/12/20/userstanding-nrepl-sessions.html
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.
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.
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
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.