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. 🙂

@bozhidar What kind of 🕰️ would you be able to spend on it next quarter?

I’ll be aiming for about a week per month.

What's the best way for community to help you be more productive?

Help with some of the tasks. 😉

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

But that's one vote from me

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

Are you going to focus on clj integration?

Maybe I'm a minority in that but it's not a high priority for me :)

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.

Sounds good to me. I'm excited you get paid to work on this :)

> I don’t think you’re sold on it but I think the double dispatch for cljc isn’t a good idea

I’m ambivalent on the subject. Probably this should be configurable.

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

Yeah I would love if I could "cider lite" and just get convenient wrap of a repl

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.

Oh I thought you always had nRepl protocol in the way

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.

Ah yeah ;)

Shadow has that and I could just adopt it I guess

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 think shadow just uses nREPL normally.

But it has its own cljs middleware instead of piggieback.

Uhm ok

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.

@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 cljc buffer, I think cider-eval-buffer always sends to the clj repl

when I’m in a cljs buffer though, the commands all send to the cljs repl (when having both clj and cljs open)

but there are others

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.

I like the former better for sure

Evaluating always in the two repls?

@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.

That’s at least how I think of it.

(sorry for the @, I forgot about the time offset)

@arrdem No worries. I’m in Mexico. 😉

I see we’re in the same TZ now. 😄

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.

I guess most people would just use 1.

@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?

Just aggregate all the responses to a single REPL 😉