This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (7)
- # beginners (73)
- # boot (4)
- # cider (48)
- # cljsjs (7)
- # cljsrn (27)
- # clojure (206)
- # clojure-boston (2)
- # clojure-italy (21)
- # clojure-nl (8)
- # clojure-spec (7)
- # clojure-uk (94)
- # clojurescript (126)
- # clojutre (7)
- # core-async (3)
- # cursive (7)
- # data-science (1)
- # datascript (4)
- # datomic (6)
- # duct (1)
- # emacs (19)
- # figwheel (1)
- # fulcro (31)
- # graphql (13)
- # jobs (5)
- # jobs-discuss (42)
- # keechma (4)
- # leiningen (10)
- # luminus (3)
- # mount (2)
- # nyc (3)
- # off-topic (37)
- # om-next (3)
- # onyx (45)
- # pedestal (2)
- # re-frame (4)
- # reagent (2)
- # reitit (16)
- # shadow-cljs (118)
- # spacemacs (10)
- # tools-deps (8)
- # vim (20)
I had been leveraging
cider-cljs-lein-repl to trigger multiple figwheel builds, since it involved specifying the code to run. The switch to
cider-default-cljs-repl seems like a good choice, but is anyone aware of a good alternate strategy to trigger multiple figwheel builds?
cider-default-cljs-repl has a
custom option, but there's not a way to specify in advance the code to run; it always uses
read-from-minibuffer to ask the user.
Guess we sorted this out in #emacs, but generally it’s best to ask CIDER questions here. I don’t always read the other channel.
@eggsyntax Also feel free to educate me on what those builds are. Maybe we can just prompt the user to select a build when spinning a figwheel repl (we already do this for shadow-cljs).
My case may be somewhat rare -- I don't know how many folks have a project that includes multiple builds that have to be run simultaneously. We just have a couple of small peripheral projects that use the same codebase but with different builds. My suggestion would be to wait & see if other folks trip over the same problem, and only then consider adding build-selection.
The figwheel approach is that builds are specified as a vector, and if
figwheel-sidecar.repl-api/start-figwheel! is called without arguments (which is what CIDER does), whatever build appears first in that vector is the one that gets build. So it's really easy for people to control which figwheel build gets built by CIDER; it's just this offbeat case of wanting multiple builds that becomes an issue.
Yeah (but we almost never actually use those repls). TBH, all we need is for them to be built, but since we use figwheel instead of calling cljsbuild directly, specifying them as extra figwheel builds has been the simplest way to do it.
In fact I'm not sure those repls actually exist in any real way; I'd have to dig into what
start-figwheel! actually does to clarify that.
good thing you don't use those repls. I'm sure the dispatch mechanism would fail you in selecting which repl to evaluate code
any idea why using the latest cider or the latest stable cider and connecting to an nrepl running
[cider/cider-nrepl "0.15.1"] would be fine, but 0.16.0 would fail produce a repl with an op describe timeout?
For the master cider you certainly need 0.17-SNAPSHOT
cider-nrepl. Generally different cider/cider-nrepl version are incompatible, as there are often middleware changes in new versions.
Btw, I proposed to Chas to take over nREPL if he doesn’t have time for it anymore https://github.com/cemerick/nREPL/issues/21 Feel free to voice some support for this idea, as I really want us to restart the nREPL development. The real solutions to all big problems start at the very core. 🙂
I don’t have any objections to CIDER taking nREPL. I’ve chatted with Chas about it some recently and have commit on the python client - sounds like there are some architectural decisions he’s not happy with and it’s definitely not something he’s making time for anymore.
Would you want to have Chas move the repo for link score reasons or is there something preventing you / us just forking it into CIDER?
I think @dominicm already has some work on the Python nREPL client I’d like to take a poke at and try to get merged to whatever the new “official” owner is, even if that’s just the existing repo.
It may be worth a wire protocol breaking nREPL 3.0 change to at least include some version format information on the wire to support future changes better..
I agree with the point about emacs, that’s why nothing in
clojure-emacs is mentioning emacs anywhere. For me CIDER has has always been a cross-platform initiative, only the Emacs client happens to be Emacs-specific. 🙂
Anyways, I’m not opposed to hosting this somewhere else, but this move felt natural after what we did with piggieback recently.
Frankly, I dream of a vim-cider project one day. Seems fireplace is very far what I consider a proper Lisp programming environment. 🙂
> Would you want to have Chas move the repo for link score reasons or is there something preventing you / us just forking it into CIDER?
Link score and credibility. The project needs his blessing to succeed. And, of course, I don’t want to copy the tickets over. 🙂