Clojurians
#dirac
<
2016-05-26
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

frank06:05:18

I can't seem to get any of the (dirac! commands to work :disappointed:

frank06:05:40

nvm it works now :simple_smile:

frank07:05:13

After running (dirac! :join), trying to eval anything gives me an error like this:

dirac.lib.nrepl-tunnel-server    | [NREPLTunnelServer#1 of [NREPLTunnel#1]] Received an error from client [WebSocketServerClient#1] :
                                   |  {:err
                                   |  "Unable to unserialize forwarded nREPL message:\n {:ns \"frontend.core\", :file \"*cider-repl localhost*\", :op \"eval\", :column 15, :line 54, :pprint-fn #function[cider.nrepl.middleware.pprint/wrap-pprint-fn/fn--24400/fn--24402], :id \"15\", :code \"1\\n\"}",
                                   |  :op :error,
                                   |  :id "01100e8b-53ed-4680-a514-83c9458097fc"}

frank07:05:41

I'm seeing this in both cider and the lein repl

frank07:05:00

I'm guessing this is because of the cider-nrepl middleware?

danielcompton09:05:54

Removing all other middleware is a good first step

frank13:05:28

:confused:

frank13:05:30

that did work!

frank13:05:37

most emacs users have cider-nrepl middleware in their ~/.lein/profiles.clj though, so it would be hard to convince my team to remove it :disappointed:

darwin14:05:23

@frank: I’m pretty sure we will figure a way how to make it work

darwin15:05:30

ok, looking at the code, the whole problem is that the message is unserialisable on client side because of that :pprint-fn key, not sure why they include this key there in a form which is not portable background info: when you switch your session into joined dirac session (meaning joined to some “source” session), I send all incoming nrepl messages (e.g. “eval" requests) to your joined session to client-side to be processed by Dirac devtools, is can implement the nrepl message directly if appropriate or send it back to the “source” session for actual processing. In any case I need to unserialise the message on client side to look at the operation and act appropriately.

frank15:05:16

can the key be ignored?

darwin15:05:41

yes, we can easily make a hack to accommodate your case, but I would like to think about it more and find more general solution

frank15:05:00

:thumbsup:

frank15:05:28

dissoc all vals that aren't strings?

darwin15:05:37

I use read-string on client side, maybe I could use some other function which would skip unserializable keys or something, I don’t want to implement some nrepl message transformation on server side, if possible

darwin15:05:48

cannot do dissoc prior parsing it

darwin15:05:03

I get a string and I need to parse it on client side

darwin15:05:52

btw that error logging could tell you more about the problem, it gets logged into Dirac’s console (the console you can open from Dirac DevTools window)

frank15:05:32

ah ok I didn't look there

darwin15:05:18

would be nice to look there to confirm my theory, I don’t really have cider stuff set up and running

frank15:05:01

I think all that's needed is to add something like [cider/cider-nrepl "0.11.0"] to :plugins in project.clj and the issue should reveal itself in the lein repl

darwin15:05:42

ok, will try it

frank15:05:07

but I will try too :slightly_smiling_face:

frank15:05:08

@darwin: I didn't see it in my dirac window

frank15:05:41

sounds like it

darwin15:05:22

I’m looking into cljs.reader/reader and clojure.edn/reader, not clear if any of them will be able to parse the message and somehow skip unparseable bits

darwin15:05:54

as I said I would like to solve it on client-side if possible

darwin15:05:02

or maybe even cljs.tools.reader?

frank15:05:56

ahh I think I understand what you've been saying now

darwin15:05:55

looking at the docs of cljs.reader/read-string and it does not thow by default, just silently returns nil, so that is why we are not getting that error log

darwin15:05:39

throwing can be enabled, that would be an improvement, but that would not solve our problem at hand

darwin15:05:42

@frank: I was able to reproduce the issue, just looking at the devtools console and that read-string really throws: https://dl.dropboxusercontent.com/u/559047/hmm-throws.png note that “troubles unserializing message"

darwin15:05:00

you were probably looking at wrong console.

frank15:05:03

hm I didn't see that

frank15:05:11

oh yeah I was looking at dirac console

darwin15:05:23

this is console of the devtools window, not the console of your app’s page window

frank15:05:53

I keep forgetting I can do that

darwin15:05:09

I have there more messages because I’m running the dev build, maybe yours would look different

darwin15:05:09

I will be able to fix it on client side, at least with tools.reader, we can specify our own "tag parsers"

darwin15:05:30

so I will be able to parse it and turn all unknown tags to nil values

darwin15:05:04

also a workaround for you could be to exclude wrap-pprint-fn middleware: https://github.com/clojure-emacs/cider-nrepl#via-leiningen

darwin15:05:52

btw. that :plugins approach didn’t work for me, I had to go :dependencies route and cofigure :repl-options myself

darwin16:05:27

for some reason adding just cider-nrepl as plugin didn’t work with my project configuration somehow

darwin22:05:49

@frank: realized that on nrepl (server) side checking for this makes more sense, but after implementing it on client side, so I kept both: https://github.com/binaryage/dirac/commit/e98d8b92877a62c828fffad392e57c26e0693650 https://github.com/binaryage/dirac/commit/7b4b4e1f76a6a21c598015b3050350b29ce621bc