Fork me on GitHub

@denik That has your fix, out now ^^^

🙏 4

@cfleming I’m fairly certain I was seeing that issue with that exact form, but I can only replicate when I do:

{:foo (sequence (comp (take 10)
                      (map (fn [i]
                             (when (= i 9)
                               (throw (RuntimeException.))))))


the CLI repl says:

{:foo (sequence (comp (take 10)
                      (map (fn [i]
                             (when (= i 9)
                               (throw (RuntimeException.))))))
Error printing return value at user/eval345$fn (NO_SOURCE_FILE:3).
{:foo (user=>


(the thing that tipped me off was the {:foo ( partial form there at the bottom)


Ugh, I think I know what I did. My very first example had take 100 and I threw on the 90th element. It must have started printing. I pruned it down for clarity, and I must not have checked it properly after I did that.

Roman Liutikov15:12:05

@cfleming is it safe to update to IDEA 2019.3?

Roman Liutikov15:12:42

I’ve seen Cursive release notes with support for 2019.3, but IDEA still warns about Cursive being uncompatible


I updated to 2019.3 yesterday and everything has been working as expected.


I'm using 2019.3 with 1.9.0 (well, 1.9.1-eap1 since this morning) and it's grand


I updated to 1.9.1-eap1-2019.3 today and noticed that links in my exceptions now ask me to choose a "target file". This did not happen before and is likely a regression. In the below screenshot you can see Cursive asking me this. The 3 files shown do have a namespace with final portion of the namespace matching "metric-query". Cursive seems to not be taking into account the rest of the namespace though.


Is that in the REPL or in an execution toolwindow (e.g. after executing a script or something)?


In the REPL


Hmm, that’s worrying, I’ll see if I can reproduce that.


after upgrading to IntelliJ 2019.3 and the latest Cursive build (including EPA), my colleagues and i discovered that running our nREPLs configured with a deps.edn alias does not execute the alias's :main-opts [ ... ] instructions. has anyone else run into this problem?

1️⃣ 4

I don’t think this has ever worked. The problem is that Cursive starts the REPL and executes a script which starts the REPL server, and :main-opts would probably interfere with that. What do you need to do?


Hey Collin, it did work before. :) We used it to start a web server for local development. The project is an ions project..


^ this. we were providing two comma-separated aliases - the first one to include extra-deps for development in the REPL, and the final alias to fire up a development web server using something like :main-opts ["-m" "server"]. the outcome used to be: • nREPL starts up • web server main function is called from the last alias • REPL is then available with all extra deps


Connecting to local nREPL server...
nREPL server started on port 52301 on host localhost - 
Clojure 1.10.1
19-12-12 10:52:49 local INFO [server:12] - Local server started on port 8080
(+ 1 2 3)
=> 6


Ok, I’ll check this out.


thanks very much!


I just looked at this, and I can’t reproduce it. I just added a :main-opts ["-m" "server"] to a test deps project, and I see that added to the command line. You can check whether that’s happening by looking at the command line string which is usually the second line in the REPL output. It’s usually folded, but just copy it and paste it into a text editor to see the whole thing.


Hi Collin, it seems it works if we choose the clojure.main option on the Clojure REPL run configuration.. The main difference is that there is a -i form-initxxxxxxxxxxxxxx.clj argument on the command line: • works: java … -classpath … clojure.main -m server • doesn’t work: java … -classpath … clojure.main -i form-initxxxxxxxxxxxxxx.clj -m server