Fork me on GitHub
#cider
<
2019-12-04
>
yuhan06:12: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

yuhan06:12:31

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

yuhan06:12:33

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

bozhidar08:12:44

@qythium Seems to me we simply need to be explicit about the preferred print-method in such cases and all will be good.

yuhan10:12:50

Ah okay, like this?

(prefer-method print-method
  clojure.lang.IPersistentMap
  clojure.lang.IDeref)

yuhan10:12:07

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)

bozhidar10:12:07

@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.

bozhidar10:12:16

In this case we simply wanted to render certain values in an easier to understand fashion, which is unlikely to ever be changed upstream.

bozhidar10:12:36

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/+]. 😄

👍 8
bozhidar10:12:21

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.

yuhan10:12:37

Yeah, I ran into it with the library thi.ng.color, which uses records that implement IDeref

yuhan11:12:40

which... does not seem a very sensible thing to do, I think it was in order to abuse the @ syntax

yuhan15:12:49

Thoughts on enabling the "-XX:-OmitStackTraceInFastThrow" jvm option by default when jacking in with clojure-cli?

yuhan15:12:40

Without it stacktraces would start getting mysteriously omitted after a long-running session, causing the cider-stacktrace buffer to throw elisp-side errors

yuhan15:12:39

(Specifically in the cider-stacktrace-render-frame function which expects a stacktrace frame)

dpsutton15:12:28

tools gonna tool

dpsutton15:12:36

we don't mess with lein, don't think we should with clj

bozhidar16:12:37

Not sure about this. If Lein already sets this internally I guess there’s some reason. What’s this flag supposed to do exactly?

yuhan16:12:58

See the convo a while ago on the #clojure channel, apparently it prevents the JVM from optimizing away stacktraces

yuhan16:12:58

For a long time I thought it was a Cider bug and would just restart the repl

dpsutton17:12:15

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

dominicm18:12:24

Users can set it by themselves

bozhidar18:12:06

@qythium Perhaps we should just document this in the manual. I guess many people will come across it this way.

fiddlerwoaroof19:12:23

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?

dpsutton20:12:49

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

fiddlerwoaroof21:12:21

@dpsutton one thought would be to put ;; at the beginning of every output line

dpsutton22:12:56

but then your actual logs are gross

bozhidar22:12:58

You can always turn off font-locking in the REPL. It’s a compromise, of course.

bozhidar22:12:31

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.

dpsutton22:12:50

they used to go to the server process buffer right?

bozhidar22:12:00

I just remember when I started working on it I realized it didn’t make as much sense as I thought it would.

dpsutton22:12:14

i think i discouraged you because it would require a custom logger logic (thresholds, etc) in CIDER itself

bozhidar22:12:34

Yeah, they used to go there due to an output capture issue.

bozhidar22:12:30

You can still enable this behaviour if disable the output redirecting done by cider-nrepl

bozhidar22:12:10

Btw, keep in mind this server buffer exists only when you’ve jacked-in, which was part of the original problem.

fiddlerwoaroof22:12:07

One thing I like about Cider/Slime is that they look like a real repl

fiddlerwoaroof22:12:43

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

fiddlerwoaroof22:12:43

I guess, if `*out*` was redirected, but not the repl results, this wouldn't be a problem

fiddlerwoaroof22:12:59

My current "solution" is C-M-u and then replacing the unpatched opening delimiters

bozhidar23:12:02

There’s no problem to redirect output out of the REPL, but this would be unnatural for something like println.