Fork me on GitHub
#cursive
<
2020-08-11
>
jysandy07:08:14

I have a clj + cljs project with both a Leiningen project.clj for the backend code and a shadow-cljs.edn for the frontend. I exported a pom.xml using shadow-cljs, but importing that seems to break dependency resolution using Leiningen since a module can only be managed by one build tool at a time. Is there a workaround for this besides integrating shadow-cljs with Lein completely?

jysandy07:08:00

Both the project.clj and the shadow-cljs.edn are sitting in the same project root.

jysandy07:08:52

If moving the Lein project to use deps will help, I’m open to exploring that.

thheller09:08:26

@jysandy probably best to configure your CLJS dependencies in project.clj and then make shadow-cljs use that too. less of a hassle overall to just have one place to declare dependencies. if you don't mind copying you can also just copy your CLJS dependencies to project.clj under the :dev profile or so that Cursive can find it but still actually use shadow-cljs.edn for CLJS deps

salam18:08:37

there seems to a bug with the way cursive evaluates calls to clojure.core/pr and clojure.core/print. i used a few expressions to compare the behavior of cursive's repl client to that of clojure's built-in repl client. both clients are connected to the same clojure socket repl server. the results are shown in the following screenshots. is there any github issue tracking this bug?

Alex Miller (Clojure team)18:08:04

pr and print don't force a flush

Alex Miller (Clojure team)18:08:05

you may be observing some independent difference in when the output stream is flushed

cfleming03:08:30

Actually I based Cursive’s socket REPL code on prepl, and prepl has the same bug:

~> telnet 127.0.0.1 5555
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
(+ 1 2)
{:tag :ret, :val "3", :ns "user", :ms 17, :form "(+ 1 2)"}
(pr 1 2 3)
{:tag :ret, :val "nil", :ns "user", :ms 3, :form "(pr 1 2 3)"}
(prn 1 2 3)
{:tag :out, :val "1 2 31 2 3\n"}
{:tag :ret, :val "nil", :ns "user", :ms 1, :form "(prn 1 2 3)"}

cfleming03:08:11

I can’t figure out the right place to fix this for the moment, but I’m looking into it.

cfleming03:08:17

(binding [*out* out, *flush-on-newline* true, *print-readably* true]
  (locking lock
    (prn (if (#{:ret :tap} (:tag m))
           (try
             (assoc m :val (valf (:val m)))
             (catch Throwable ex
               (assoc m :val (ex->data ex :print-eval-result)
                        :exception true)))
           m))))

cfleming03:08:48

Here, the *flush-on-newline* doesn’t seem to work, even though prn is used.

cfleming03:08:48

Actually, I lie, I was getting my streams confused. *out* needs to be flushed before calling out-fn with :tag :ret or :tag :error if any eval might have output anything.

cfleming03:08:59

I have this fixed for Cursive.

salam04:08:12

Thank you very much, Colin! I really appreciate the time you’ve taken out of your busy schedule to fix this. 🙂

cfleming05:08:24

No worries, sorry it took so long to get to! I’ll try to get an EAP out with this shortly.

👍 3
salam18:08:10

yeah, that's what i figured (when the output stream gets flushed) and was a little hesitant to call this a bug. however, i believe, i was bitten by this a few times in some other contexts in the past (i vaguely remember one of them being clojure.test).

salam20:08:17

ah, after hours of sifting through the clojurians slack log, i finally found what it was. i was wrong, it wasn't clojure.test, it was expound. here is the problem we ran into: https://clojurians-log.clojureverse.org/cursive/2020-06-09/1591730202.130400

salam20:08:05

> i'm curious how everybody's experience with using a remote socket repl with cursive is. we've been having problems with this set-up. one particular problem that we had today was that the cursive repl client wouldn't show the output from expound. that is if you evaluate (expound/expound string? 42), all you get in the repl client output is nil. am i missing something?

salam20:08:48

here is, i believe, how this difference manifests itself as a bug in cursive's repl client:

salam20:08:40

and that was very confusing back then...