Hey guys, I have a problem connecting to the repl using cider on spaceemacs. I've just started with emacs so I am kinda confused and didn't know where to write, so here I am. Any ideas why connection to the repl is not established?

Have you used either the cider-jack-in or cider-jack-in-clojurescript commands?

cider-jack-in

the repl server is started but no connection has been made. When I close the spacemacs, he's asking me, whether or not I want to kill other processes too, showing me to the repl-server which I've created but didn't connect to

Sorry for bothering, wanting to tell that this was a code problem. I tried to start it in intellij and got the same problem, but a more descriptive error

This piece of code: (doseq [_ (range (Integer/parseInt (read-line)))] ... ) got me a

[{:type clojure.lang.Compiler$CompilerException
   :message java.lang.NumberFormatException: null, compiling:(test_project/core.clj:215:1)
   :at [clojure.lang.Compiler load Compiler.java 7526]}

You’re feeding parseInt something that isn’t an integer.

@gonewest818 what do you mean by that? I didn't have a chance to give the input. I just wrote the code and wanted to start repl. I didn't provide any input, or did I get you wrong?

what's at line 215 of test_project/core.clj?

Now I've already changed the code, being doing some stuff, now I have regex in my code, and I once again can not start the repl Error message:

[{:type clojure.lang.Compiler$CompilerException
   :message java.lang.NullPointerException, compiling:(test_project/core.clj:217:1)
   :at [clojure.lang.Compiler load Compiler.java 7526]}
  {:type java.lang.NullPointerException
   :message nil
   :at [java.util.regex.Matcher getTextLength Matcher.java 1283]}]

(let [[n k] (->> (clojure.string/split (read-line) #" ")
                 (map #(Integer/parseInt %)))
... )

@denisgrebennicov if you're having problems starting a repl, it generally means that you have code that's throwing errors at compile time rather than run time. Generally this means you have code as a def or just directly in the body that you'd be better off putting behind a defn

…it would be kind of awesome if cider handled this situation a little better.

hmmmm... I guess you are right 😅

i run into it frequently, and it seems a great opportunity to show a useful error message.

I believe that whenever I've run into this case, an error message has been printed in the *Messages* buffer

hm yeah maybe that’s enough--just tried it and i see a big stack trace in the minibuffer, and i can go to messages to see more. though it is very easy to accidentally clear the message from the minibuffer (any keypress), and be left with no indication that an error occurred unless you happen to have *Messages* open.

or...you just get so used to the cider eco system that you know where to go look when a repl fails to load. So yeah, some improvement in user friendliness in these situations could definitely be had

I’m a super newbie but I struggle to think what you could really do other than maybe have the error in the minibuffer just say “Your repl has had a bad problem and will not go to space today. See *Messages* for more information.”

there isn’t a good place to stick a “modal” (thank the maker) in an emacs session

maybe throwing it into a new attention grabbing buffer, like is what happens with the *cider-repl <project>* buffer?

i mean, cider pops open a nice buffer with an error message and stack trace when there’s a runtime error, right?

@wiseman you are indeed a wise man