That diff tool will be super useful. Xmas bonus

(Not so serious) Are bugs ever non-annoying?

@UDF11HLKC Some are much more annoying than others.

hi colin, sorry if I've missed this, but I don't understand how to use the diff. I read through the post in google groups and when I run this

(cursive/diff (meta #'defn) (meta #'let) :title "Metadata")

i'm guessing i need to require something, i'm jiust not sure what

@U027433844C How did you start your repl?

via intellij

just created a local lein repl

as in i host from within cursive rather than connecting into an existing socket repl

And it’s just a Clojure REPL, you’re not booting into a CLJS one or anything like that?

In the meantime, you can use the tagged-literal workaround described in the email. The diff function is literally just:

(defn diff [left right & {:keys [title]}]
  (tagged-literal 'cursive/diff (cond-> {:left left :right right}
                                  title (assoc :title title))))

just a normal clj repl yea

oh i didn't get the email

No, I mean in the Google Groups post - if you’re on the mailing list you get that as an email.

oh i see

2021-12-23 14:13:06,137 [20995681]  ERROR -      #cursive.repl.socket-repl - Exception 'java.lang.Throwable: Error handling REPL response
java.lang.IllegalArgumentException: No implementation of method: :out of protocol: #'cursive.repl/Handler found for class: nil
 at clojure.core$_cache_protocol_fn.invokeStatic (core_deftype.clj:584)
    clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:576)
    cursive.repl$fn__1555$G__1527__1564.invoke (repl.clj:91)
    cursive.repl.socket_repl$handler.invokeStatic (socket_repl.clj:62)
    cursive.repl.socket_repl$handler.invoke (socket_repl.clj:46)
    cursive.repl.socket_repl$read_loop$fn__4218$fn__4219.invoke (socket_repl.clj:113)
    cursive.repl.socket_repl$read_loop$fn__4218.invoke (socket_repl.clj:110)
    cursive.repl.socket_repl$read_loop.invokeStatic (socket_repl.clj:103)
    cursive.repl.socket_repl$read_loop.invoke (socket_repl.clj:70)
    cursive.repl.socket_repl$start_session$reify__4245.run (socket_repl.clj:181)
    com.intellij.openapi.application.impl.ApplicationImpl$1.run (ApplicationImpl.java:263)
    java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
    java.util.concurrent.FutureTask.run (FutureTask.java:264)
    java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
    java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
    java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run (Executors.java:668)
    java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run (Executors.java:665)
    java.security.AccessController.doPrivileged (AccessController.java:-2)
    java.util.concurrent.Executors$PrivilegedThreadFactory$1.run (Executors.java:665)
    java.lang.Thread.run (Thread.java:829)
' was reported 6220 times 
2021-12-23 14:14:05,916 [21055460]  ERROR -                  #cursive.repl - Exception 'java.lang.Throwable: Error handling response
java.lang.IllegalArgumentException: No implementation of method: :out of protocol: #'cursive.repl/Handler found for class: nil
 at clojure.core$_cache_protocol_fn.invokeStatic (core_deftype.clj:584)
    clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:576)
    cursive.repl$fn__1555$G__1527__1564.invoke (repl.clj:91)
    cursive.repl.socket_repl$handler.invokeStatic (socket_repl.clj:62)
    cursive.repl.socket_repl$handler.invoke (socket_repl.clj:46)
    cursive.repl.socket_repl$read_loop$fn__4218$fn__4219.invoke (socket_repl.clj:113)
    cursive.repl.socket_repl$read_loop$fn__4218.invoke (socket_repl.clj:110)
    cursive.repl.socket_repl$read_loop.invokeStatic (socket_repl.clj:103)
    cursive.repl.socket_repl$read_loop.invoke (socket_repl.clj:70)
    cursive.repl.socket_repl$start_session$reify__4245.run (socket_repl.clj:181)
    com.intellij.openapi.application.impl.ApplicationImpl$1.run (ApplicationImpl.java:263)
    java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
    java.util.concurrent.FutureTask.run (FutureTask.java:264)
    java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
    java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
    java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run (Executors.java:668)
    java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run (Executors.java:665)
    java.security.AccessController.doPrivileged (AccessController.java:-2)
    java.util.concurrent.Executors$PrivilegedThreadFactory$1.run (Executors.java:665)
    java.lang.Thread.run (Thread.java:829)
' was reported 6220 times

Hi, sorry it took me a while to get to this. So I understand the mechanics of what’s going on, but I can’t understand how you’d get into that state. Briefly, when using the socket REPL, Cursive creates a handler for each evaluation which handles the response. This handler is usually discarded when the eval is done, but you seem to be receiving a response for an eval after that has happened. Are you doing anything like printing on background threads, or anything like that? Is there any particular situation which provokes this?

> Are you doing anything like printing on background threads, or anything like that? the only suspect in the code that’s close to this is a core.async go-loop that calls a function that prints out logs. what’s odd, though, is that i don’t get the same error message when i run the same code in nREPL.

Yeah, I’d expect that. The nREPL protocol is different, and allows multiple parallel executions, so it assigns an ID to each eval and Cursive associates that with the corresponding handler. I could do the same with the socket protocol, it’s not a difficult change.