This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-12
Channels
- # beginners (49)
- # boot (2)
- # cider (62)
- # clara (3)
- # cljdoc (5)
- # cljs-dev (7)
- # cljsrn (2)
- # clojure (68)
- # clojure-spec (23)
- # clojure-uk (4)
- # clojurescript (172)
- # conf-proposals (8)
- # core-async (1)
- # cursive (1)
- # datomic (12)
- # duct (1)
- # figwheel (22)
- # figwheel-main (11)
- # fulcro (23)
- # hoplon (9)
- # jobs-discuss (13)
- # lambdaisland (3)
- # lein-figwheel (119)
- # off-topic (43)
- # onyx (1)
- # re-frame (18)
- # ring (1)
- # shadow-cljs (120)
- # tools-deps (4)
@bbrinck I not quite sure what you want to configure and how you want to do it. Generally you can configure certain things on a per-project basis using .dir-locals.el, and potentially you can have an on-connect hook that loads some file after you’ve connected.
If i'm starting a Figwheel Main project from CIDER, and Figwheel Main fails to start due to a syntax error, CIDER is unable to start CLJS REPL and does try not recover afterwards.
Now nREPL is running, but I don't see a way to deal with it beyond killing and starting anew.
@U07HVGQJ3 yes figwheel.main is vulnerable to your initial build failing
There should maybe be a cider command that sends the figwheel-main (or others) forms over the same connection - maybe there is already but haven't investigated the new API in depth enough
How to force the repl to show user.ns=>
?
The context:
The figwheel-main
prints the info about compilation to the repl. After the message repl does not return to user.ns=>
while it should. Is there a way to somehow send a request to repl which triggers the cider user.ns=>
?
Getting this error suddenly on a project I've been working on for weeks while trying to jack in:
[nREPL] Starting server via /usr/local/bin/clojure -Sdeps '{:deps {org.clojure/tools.nrepl {:mvn/version "0.2.13"} com.billpiel/sayid {:mvn/version "0.0.16"} refactor-nrepl {:mvn/version "2.4.0-SNAPSHOT"} cider/cider-nrepl {:mvn/version "0.18.0-SNAPSHOT"}}}' -e '(require (quote cider-nrepl.main)) (cider-nrepl.main/init ["com.billpiel.sayid.nrepl-middleware/wrap-sayid", "refactor-nrepl.middleware/wrap-refactor", "cider.nrepl/cider-middleware"])'...
error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: Exception in thread "main" java.io.FileNotFoundException: Could not locate nrepl/server__init.class or nrepl/server.clj on classpath., compiling:(cider_nrepl/main.clj:5:1)
that said, you're going to run into issues with sayid and refactor-nrepl. I think there is a new release of refactor-nrepl and I think there is an unaccepted PR to fix sayid
if you don't feel like mucking about with that i think you can go back to cider 0.17.0 or you can play the update game and see what happens
This is probably the third time that I've sat down to work only to find my Clojure environment completely broken
Putting `(setq sayid-inject-dependencies-at-jack-in nil) in your dotspacemacs/user-config is all that is required now as far as I can tell (under spacemacs develop branch).
@pauld thanks, what does that do exactly? I'm eager to find a way to "freeze" spacemacs to stop it constantly changing out from under me.
Every google turns up mountains of Github issues of people requesting the same, but to no avail
Someone else gave me that tip, but I think it just prevents the broken say-id package from pulling in it's obsolete dependencies.
As far as spacemacs breaking, I don't have a good solution. It seem more of an issue with using MELPA. You can switch to MELPA stable - that may help.
@pauld ah I see, thanks. Yeah I've read lots of discussion around MELPA on Github, but it doesn't seem to be moving anywhere. I've tried every "workaround" for using MELPA stable I can find and none of them seem to work anymore.
yeah there's also a way of using melpa stable for particular packages if I recall correctly
So far it's been sayid that has broken things for me twice, but I've learned 2 trick on how to disable it now
I think it's just that spacemacs clojure layer uses sayid. Sayid would have broken regular emacs users too if they were using it - I think.
It's more a problem of cider and some of the plug-ins or related packages in the ecosystem.
Bummer...this might be the straw that breaks the camel's back for me as far as using spacemacs goes. Think I'll switch to something with a proper package manager.
Sure, maybe the "emacs ecosystem" is more accurate. I really need to be confident that I can start the REPL and work day-to-day...need my editor to be rock solid.
My very idealistic view on this is that emacs is notoriously THE hacking editor, so I would say that you kind of need to be prepared for some breakage and, if time allows it, try to help with the fix/fix it yourself. I have choosen emacs because I like to hack on it
I enjoy not to be productive for some time and help other fella in the meantime 😄
I can empathize with that though. I like sharpening my tools as well, but sometimes I really want to sit down and try an idea, only to find that emacs won't boot
yeah well, that happens to me as well, but the fix is usually a small tweak
(or maybe now I now how to take cider and nrepl 😄 )
Another way to see it is that I so hate to get stuck that I have always preferred to dig into the problem...
Well, for what is worth - the big changes are more or less behind us, so we should be looking at a period of much improved stability down the road. But I have to say again that I find it amusing that people tracking CIDER’s development branch expect it to be super stable - it’s called “development branch” for a reason. 😉
0.18 experienced an unusual amount of massive changes, but this should certainly make things much more stable down the road.
Obviously we don’t plan to do another nREPL migration or another connection management rewrite ever again. 🙂
If it were possible to not track CIDER's development branch, I'd definitely be doing so. I haven't found a way as of yet.
And, of course, if Spacemacs stuck just to bundling CIDER without any extensions almost no one would have experienced any nREPL-related breakages. CIDER’s ecosystem is outside the control of any single person, so coordinated updates between many packages can be painful.
@cjsauer Stop using Spacemacs, install it from MELPA Stable, end of story. It’s as simple as that. 🙂 (and it’s documented in the manual).
Anyways, at this point it’s pointless to go back to 0.17. There are no more changes planned for 0.18. I think it’s in a decent shape and it will be promoted to the new stable in the next couple of days most likely.