ClojureScript: C-x C-e does not print results nor exceptions

[danskarda]

Cider stopped to print results of eval last expression from ClojureScript buffer.

Emacs just prints "nil" in the minibuffer. The result of evaluation is not printed in repl buffer. The only workaround is to use (prn ...). Same applies to JS exceptions (they are lost). Clojure evaluation works fine.

Setup: latest cider / cider-nrepl. Latest release of ClojureScript and piggieback. I tried different backends (austin with chrome, cljs-noderepl etc)

There are many dependencies which can go wrong. At this point I am not able to point my finger on exact cause. I try to investigate the issue over weekend.

[danskarda]

I found the root cause. I have a fix for piggieback, but I am not 100% happy with the solution. It smells more like a workaround than a solution and can result in some performance problems. Final solution should be coordinated between cider, nrepl and piggieback.

Some time ago cider stopped to use nrepl eval. It uses load-file instead. There were probably some good reasons for that in Clojure, but in ClojureScript load-file does not return value of last expression (as Clojure does).

Piggieback's load file uses cljs.repl/load-stream. The function uses doseq so the last value is lost. This can be fixed using map+last. However the fix will not solve the problem completely. Plain evaluate-form uses .toString, so objects are returned as [Object object].

One could patch load-stream to use print last expression using pr-str. Unfortunatelly there is a catch. ClojureScript def does return a value. For huge objects pr-str can be very expensive. If I patch piggieback on cljs.repl to pr-str last expression, C-x C-k (load current buffer) can block repl for very very very long time if the last expression was (def x (make-something-big)).

I think the core problem is that eval API in nrepl was not suitable for all use-cases in cider. So cider started to use load-file for both eval and load-file. I guess it was a workaround. It was faster to implement than to change nrepl eval API (and possibly breake other apps).

Solutions:

1. reimplement load-stream in piggieback to print last expressions (and break loading of namespaces, where the last value is a large data structure)
2. use eval to evaluate one expression and load-file to load files and namespaces. This would probably require changes in tools.nrepl, so it fits all cider use cases. In the long run it would probably help other apps as well.

What do you think? (sorry for long post)

/cc @cemerick @bbatsov

[bbatsov]

Some time ago cider stopped to use nrepl eval. It uses load-file instead. There were probably some good reasons for that in Clojure, but in ClojureScript load-file does not return value of last expression (as Clojure does).

This sounds like a bug to me.

I think the core problem is that eval API in nrepl was not suitable for all use-cases in cider. So cider started to use load-file for both eval and load-file. I guess it was a workaround. It was faster to implement than to change nrepl eval API (and possibly breake other apps).

See NREPL-59. Using eval is not really an option as outlined there and load-file should in theory work fine for both Clojure and ClojureScript code.

use eval to evaluate one expression and load-file to load files and namespaces. This would probably require changes in tools.nrepl, so it fits all cider use cases. In the long run it would probably help other apps as well.

Doubt this is going to happen, so I think option 1 is the only realistic solution.

[bbatsov]

One could patch load-stream to use print last expression using pr-str. Unfortunatelly there is a catch. ClojureScript def does return a value. For huge objects pr-str can be very expensive. If I patch piggieback on cljs.repl to pr-str last expression, C-x C-k (load current buffer) can block repl for very very very long time if the last expression was (def x (make-something-big)).

Yeah, I get this, but it seems to me that having consistent behaviour in both Clojure and ClojureScript is important. I doubt that this would be significant problem in practice.

[bbatsov]

@cemerick Any thoughts on this?

[danskarda]

One last thing I forgot to wrote. In ClojureScript, load-file is slower than eval (austin + piggieback + chrome). You can notice the difference between working in repl (eval, instantaneous) and buffer (load-file, 1-2secs). Looks similar to issue #861 (though the reason will be CLJS specific).

It seems that load-file brings in as many problems as it is trying to address :(

[bbatsov]

@danskarda In #861 using in-ns instead of ns in the generated file to eval solves the speed problem. Does this improve performance for ClojureScript as well?

[danskarda]

@bbatsov There is no in-ns in ClojureScript. It is implemented as a special form. Special forms are interpreted in cljs.repl/repl and available only to repl (and indirectly to eval op). It is not available to cljs.repl/evaluate-form nor load-file op.

I think I could change it piggieback, but I feel like navigating inside a labyrinth. You patch one thing and many other things backfire on you. Not good. But I will try.

[danskarda]

@bbatsov Support of in-ns during loading was not hard at the end. I tested it with recent cider and after change in cider--dummy-file-contents it is indeed faster than original ns.

Unfortunately this fix will not be available to 0.8 users until @cemerick makes new piggieback release and you change ns to in-ns.

ps: I just saw your video from Clojure/conj on youtube. Great talk! thumbs up Will the unsession also be available?

[bbatsov]

Unfortunately this fix will not be available to 0.8 users until @cemerick makes new piggieback release and you change ns to in-ns.

I'll do the CIDER change immediately after the new piggieback is out (and I'll cut a bugfix release).

Will the unsession also be available?

They didn't record the unsessions.