This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-04
Channels
- # 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 #function[clojure.core/+]
. 😄
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 @
syntax
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
https://blog.jakubholy.net/2014/05/19/clojurejava-prevent-exceptions-with-trace-missing/
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 ;
INFO: Initializing c3p0-0.9.5.4 [built 23-March-2019 23:00:48 -0700; debug? true; trace: 10]
Is there some way to have CIDER ignore repl output for formatting purposes?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 cider-nrepl
Btw, keep in mind this server buffer exists only when you’ve jacked-in, which was part of the original problem.
One thing I like about Cider/Slime is that they look like a real repl
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