Eval behaving differently than `cpp` and friends with Piggieback

[jgdavey]

This one is going to be hard to replicate without my specific setup, because I'm trying to update some of the tooling around boot and the ClojureScript repl with weasel, so I've got a bunch of WIP jars.

I'm in a .cljs file, with an active Piggieback/weasel connection. :Eval and cq work as expected, but cp does not. I'm not sure how to pull more information out of the error here, but when I cpp a form, I get:

fireplace.vim: Something went wrong: {'status': ['done'], 'id': 'fireplace-pearl-1432658372-19',
'session': ['2dd3b525-c03f-411d-9d8d-e2f50a696d55']}

As you can see, there is neither an ex nor a value in the response. I am using cider-nrepl, and bleeding edge versions of everything. However, I'm surprised by the differing behavior.

Any clue on how to debug this better?

[tpope]

You can check fireplace#message({'op': 'eval', 'code': '...'}) and see if the response makes sense.

[jgdavey]

:echo fireplace#message({'op': 'eval', 'code': '(+ 1 1)'})

[{'id': 'fireplace-pearl-1432658372-131', 'session': '8b937c6b-f5d8-497b-8d81-6a6c73c86e1d', 'ns': 'cljs.user', 'value': '2'}, {'status': ['done'], 'id': 'fireplace-pearl-1432658372-131', 'session': '8b937c6b-f5d8-497b-8d81-6a6c73c86e1d'}]

It seems to be sending back an vector of two maps: the first one contains the value, but I'm not sure what the second one is supposed to be telling me. Perhaps some ClojureScript repl noise?

Either way, it seems the FireplacePrint family all rely on the fact that the last element is the one to print.

[jgdavey]

I've tracked it down to the repl message being too long for the browser to handle, which led me to this line: https://github.com/tpope/vim-fireplace/blob/master/plugin/fireplace.vim#L917

How is it that padding the form with newlines and spaces makes it the innermost form to be evaluated? Removing the beginning/trailing newlines before sending the eval op fixes the issue for cpp and related.

[tpope]

The whitespace padding is clever trick to fix the line numbers in stack traces, a technique I've since seen endorsed by Chas himself. I'm confused why this is an issue for the browser. Is it using a GET request for a clearly not safe/idempotent action?

[jgdavey]

Clever! That makes sense.

It seems the code to be eval-ed never even makes it to the browser. I can't recreate this using the stock ClojureScript browser REPL, so it's gotta be an issue in Weasel itself.

I'm closing this issue and directing my efforts that way. Thanks for helping me track it down.

[english]

I seem to be having the same issue, however this is with the stock ClojureScript (v0.0-3308) browser REPL. :Eval (+ 1 1) works fine, as does cqq then (+ 1 1)<CR>. With the cursor on the expression, cpp gives an error:

fireplace.vim: Something went wrong: {'status': ['done'], 'id': 'fireplace-Jamies-MacBook-Pro.local-1435084066-26', 'session': ['67f016fc-3098-49dc-8e50-c73fd3a174a6']}

@jgdavey Were you able to resolve your issue? Which version of the cljs browser repl were you successfully using cpp with?

[bbatsov]

The whitespace padding is clever trick to fix the line numbers in stack traces, a technique I've since seen endorsed by Chas himself. I'm confused why this is an issue for the browser. Is it using a GET request for a clearly not safe/idempotent action?

Btw, Chas no longer endorses this and we dropped it from CIDER. See https://github.com/clojure-emacs/cider/issues/1088

[kul]

I am hitting this too and also happen to have a boot setup. This seems to happen with cpp only and cqc then expression seems to work fine. I am on latest version of everything. clj 1.7.0, cider 0.9.1, cljs 3308, weasel 0.7.0 etc.

K and ]d are also throwing errors

java.lang.RuntimeException: Unable to resolve symbol: symbol in this context
Error detected while processing function <SNR>86_Doc..fireplace#info..fireplace#evalparse:
line   12:
E605: Exception not caught: Clojure: class clojure.lang.Compiler$CompilerException

[danielbraun]

Any news? Experiencing this with Piggieback - cpp works on the top form, but :Eval fails.