This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (20)
- # cider (59)
- # cljsrn (6)
- # clojars (7)
- # clojure (91)
- # clojure-boston (1)
- # clojure-dusseldorf (3)
- # clojure-finland (1)
- # clojure-italy (8)
- # clojure-losangeles (1)
- # clojure-nl (16)
- # clojure-spec (25)
- # clojure-uk (113)
- # clojurescript (126)
- # core-async (27)
- # cursive (5)
- # data-science (3)
- # datomic (22)
- # emacs (24)
- # fulcro (30)
- # garden (7)
- # graphql (7)
- # leiningen (3)
- # nginx (1)
- # off-topic (63)
- # onyx (13)
- # portkey (1)
- # re-frame (1)
- # reagent (28)
- # shadow-cljs (92)
- # tools-deps (1)
- # uncomplicate (1)
- # vim (24)
- # yada (8)
Thanks to @danielcompton and Clojurists Together for the support! I really appreciate it! I’ll do my best to push the needle in the right direction over the next 3 months. 🙂
Lots of the things are relatively simple, so I think many people can help with those.
Some ideas would be appreciated as well. I’ve been wondering how to fix the connection management and I still don’t have great ideas. My best one so far has been to kill the dynamic conn dispatch completely and start from scratch there. One thing is clear - the current approach sucks. 😄
I don't think you're sold on it but I think the double dispatch for cljc isn't a good idea
I've got a dispatch patch that I've been using that has made it better for me. I have had bad results with the last repl heuristic
clj as the command? I think I already added whatever I planned about it. Apart from this - the whole jack-in codebase needs to be cleaned up and simplified.
> I don’t think you’re sold on it but I think the double dispatch for cljc isn’t a good idea
I will follow this closely and help as well whenever I can. I have a dream, use cider against Lumo, even if it is basically just sending forms a-la
inf-clojure. Will see 🙂
Just seems to simplify the code so much. Else everything has to work on all connections
I'm also a little confused about things that have side effects. You wouldn't want those to run twice unless you really really meant it to
Lumo for me has been a game changer, a fast REPL startup - scheme fast - seems nothing but changes lives 😃
Well, CIDER actually works without any middleware as well, but the experience there is pretty basic.
For someone like this to happen all that’s needed is a pure cljs implementation of the nREPL protocol, which shouldn’t be hard IMO.
Yeah, nREPL is hard requirement, but the extra middleware is not. This means that something basic to replace the real nREPL can get you reasonably far.
I’ve been thinking about connections and I’m leaning towards changing things in the following manner: * the central object becomes a thingy called “connection-group”, which is basically a mapping of a project to a list of connections. Within a connection group there’s one default clojure and cljs connection which will be used to dispatch requests for this projects. You’ll have to explicitly decide which one is the default, but the last created connection for a project would become default normally. * this would mean the end of the current static and dynamic dispatch, also the end of dual dispatch for cljc files, which was probably misguided indeed.
This feels sensible. I was wondering whether you should also specify the transport layer (http/socket) and the protocol (nRepl/chars/prepl)
@bozhidar so if in a cljs file and do something like
cider-repl-set-ns it’d still know to use the cljs connection?
I don’t know enough about what static/dynamic dispatch means I guess. Just trying to understand how it affects these sorts of behaviors
In theory this should work even now. 😄 I don’t remember when was the last time I tried whether this is truly the case, though.
Cider seemed to be able to run various commands in the “repl I expect” fairly often as it is
when I’m in a cljs buffer though, the commands all send to the cljs repl (when having both clj and cljs open)
Well, the problems currently happen mostly when you have multiple repls for the same project (e.g. 2 clj repls, etc). For cljc we actually eval everything in both repls if available, but at this point I believe this was probably a mistake.
It seems better to just be able to quickly toggle between a clj/cljs connection in the context of a cljc buffer.
@bozhidar maybe my use case is weird, but if there’s a concept of connection groups it’d be nice to be able to send the same request to multiple REPLs in one go.
Eg if I just want to load-file, being able to tee that request to many targets would be nice - see programming against a remote nREPL
I see. So you’re basically proposing that instead a default connection in the group, we should have “target connections” or something like this.
I'm just thinking of the error handling across 4 repls. Keeping track of which one is in a busted state, which ones succeeded etc
@arrdem I've come to the policy that @ is always fine, most use do not disturb in slack
But I don't have the same use case as arrdem. Maybe I would feel different if I had that use case
@dpsutton Well, that’s the beauty of his idea - you either do it or not. You get to decide how many REPLs to use simultaneously.
@dpsutton argh yeah if one has an error and the others don’t that’s gnarly… but that’s the user’s problem not CIDER’s?