This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (154)
- # announcements (1)
- # babashka (8)
- # beginners (28)
- # bristol-clojurians (3)
- # calva (131)
- # cider (43)
- # clj-kondo (14)
- # clojure (135)
- # clojure-europe (1)
- # clojure-italy (7)
- # clojure-madison (1)
- # clojure-nl (6)
- # clojure-spec (8)
- # clojure-uk (90)
- # clojurescript (47)
- # core-async (9)
- # cryogen (4)
- # cursive (12)
- # datomic (9)
- # emacs (7)
- # fulcro (5)
- # graalvm (56)
- # joker (4)
- # juxt (1)
- # leiningen (6)
- # off-topic (62)
- # pathom (4)
- # pedestal (2)
- # reagent (2)
- # reitit (5)
- # ring (2)
- # schema (4)
- # shadow-cljs (133)
- # sql (38)
- # tools-deps (10)
- # vim (28)
(defrecord Foo  clojure.lang.IDeref (deref [x] x) ) (Foo.) ;; => ;; 2. Unhandled clojure.lang.ExceptionInfo ;; ;; 1. Caused by java.lang.IllegalArgumentException ;; Multiple methods in multimethod 'simple-dispatch' match dispatch value: class ;; scratch.Foo -> interface clojure.lang.IDeref and interface ;; clojure.lang.IPersistentMap, and neither is preferred
I traced this error down and turned out to be
cider.nrepl.print-method extending clojure's print-method to IDeref, causing conflict when trying to print an object which supports both interfaces
Should cider-nrepl be doing this in the first place? The solution seems to be overriding print-method for each concrete type to favor one implementation over the other
@qythium Seems to me we simply need to be explicit about the preferred print-method in such cases and all will be good.
Ah okay, like this?
(prefer-method print-method clojure.lang.IPersistentMap clojure.lang.IDeref)
Would that belong in cider-nrepl? (It seems a little iffy monkey-patching clojure.core like that, I wasn't previously aware that Cider was doing these extensions)
@qythium Yeah, exactly. Well, hacks are never pleasant, but from time to time we had to do some of them “for the greater good”. 🙂 It’s not like everything in core is ideal.
In this case we simply wanted to render certain values in an easier to understand fashion, which is unlikely to ever be changed upstream.
I guess few people would argue that
#object[clojure.core$_PLUS_ 0x4e648e99 \"clojure.core$_PLUS_@4e648e99\"] doesn’t read as nice as
Btw, the feature is CIDER can be disabled via a dynamic variable, and I think you’re the first person to ever run into issues with it.
Yeah, I ran into it with the library
thi.ng.color, which uses records that implement IDeref
which... does not seem a very sensible thing to do, I think it was in order to abuse the
Thoughts on enabling the
"-XX:-OmitStackTraceInFastThrow" jvm option by default when jacking in with clojure-cli?
Lein enables it on startup: https://github.com/technomancy/leiningen/commit/110e2a14e96ae88fad486365962106fac3eedd8d
Without it stacktraces would start getting mysteriously omitted after a long-running session, causing the cider-stacktrace buffer to throw elisp-side errors
(Specifically in the
cider-stacktrace-render-frame function which expects a stacktrace frame)
Not sure about this. If Lein already sets this internally I guess there’s some reason. What’s this flag supposed to do exactly?
See the convo a while ago on the #clojure channel, apparently it prevents the JVM from optimizing away stacktraces
i'm hesitant to change the defaults of tools like that. that would be infuriating to find the reason something didn't work as expected
@qythium Perhaps we should just document this in the manual. I guess many people will come across it this way.
If I have a line like this in my REPL output, it breaks indentation of all my repl lines because the closing
] is escaped by the
Is there some way to have CIDER ignore repl output for formatting purposes?
INFO: Initializing c3p0-0.9.5.4 [built 23-March-2019 23:00:48 -0700; debug? true; trace: 10]
That’s a constant pain where I work too. The logs are enormous and not structured. I always ensure to clear the repl with the short cuts before working in the repl
@dpsutton one thought would be to put
;; at the beginning of every output line
At some point I wanted to be able to redirect logs to dedicated buffers, but I dropped this idea. I don’t recall why exactly.
I just remember when I started working on it I realized it didn’t make as much sense as I thought it would.
i think i discouraged you because it would require a custom logger logic (thresholds, etc) in CIDER itself
You can still enable this behaviour if disable the output redirecting done by
Btw, keep in mind this server buffer exists only when you’ve jacked-in, which was part of the original problem.
Calva and intellij do this thing where the entry area is a text box below the log buffer, and I've always found that arrangement awkward
I guess, if `*out*` was redirected, but not the repl results, this wouldn't be a problem
My current "solution" is
C-M-u and then replacing the unpatched opening delimiters
There’s no problem to redirect output out of the REPL, but this would be unnatural for something like