Fork me on GitHub
#cider
<
2018-04-26
>
bozhidar00:04:34

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

❤️ 12
xiongtx01:04:34

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

bozhidar02:04:51

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

dpsutton02:04:02

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

bozhidar02:04:02

Help with some of the tasks. 😉

bozhidar02:04:40

Lots of the things are relatively simple, so I think many people can help with those.

bozhidar02:04:07

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

dpsutton03:04:03

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

dpsutton03:04:08

But that's one vote from me

dpsutton03:04:10

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

dpsutton03:04:27

Are you going to focus on clj integration?

dpsutton03:04:00

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

bozhidar03:04:41

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.

dpsutton03:04:53

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

bozhidar03:04:49

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

bozhidar03:04:18

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

richiardiandrea03:04:07

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 🙂

dpsutton03:04:05

Just seems to simplify the code so much. Else everything has to work on all connections

dpsutton03:04:49

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

dpsutton03:04:19

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

richiardiandrea03:04:00

Lumo for me has been a game changer, a fast REPL startup - scheme fast - seems nothing but changes lives 😃

bozhidar03:04:47

Well, CIDER actually works without any middleware as well, but the experience there is pretty basic.

richiardiandrea03:04:25

Oh I thought you always had nRepl protocol in the way

bozhidar03:04:26

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.

richiardiandrea03:04:32

Shadow has that and I could just adopt it I guess

bozhidar03:04:34

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.

bozhidar03:04:57

I think shadow just uses nREPL normally.

bozhidar03:04:21

But it has its own cljs middleware instead of piggieback.

bozhidar14:04:28

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.

richiardiandrea15:04:49

This feels sensible. I was wondering whether you should also specify the transport layer (http/socket) and the protocol (nRepl/chars/prepl)

mikerod14:04:32

@bozhidar so if in a cljs file and do something like cider-repl-set-ns it’d still know to use the cljs connection?

mikerod15:04:21

I don’t know enough about what static/dynamic dispatch means I guess. Just trying to understand how it affects these sorts of behaviors

bozhidar15:04:28

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.

mikerod15:04:38

Cider seemed to be able to run various commands in the “repl I expect” fairly often as it is

mikerod15:04:00

When I’m in a cljc buffer, I think cider-eval-buffer always sends to the clj repl

mikerod15:04:16

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

mikerod15:04:18

but there are others

bozhidar17:04:53

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.

bozhidar17:04:18

It seems better to just be able to quickly toggle between a clj/cljs connection in the context of a cljc buffer.

richiardiandrea19:04:03

I like the former better for sure

bozhidar19:04:12

Evaluating always in the two repls?

richiardiandrea20:04:59

Sorry the second, former latter always confuses me :)

richiardiandrea20:04:19

So the switch of context to be precise

arrdem20:04:55

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

arrdem20:04:26

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

bozhidar20:04:33

I see. So you’re basically proposing that instead a default connection in the group, we should have “target connections” or something like this.

arrdem20:04:50

That’s at least how I think of it.

arrdem20:04:10

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

bozhidar20:04:10

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

bozhidar20:04:28

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

dpsutton20:04:59

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

dominicm20:04:24

@arrdem I've come to the policy that @ is always fine, most use do not disturb in slack

dpsutton20:04:55

But I don't have the same use case as arrdem. Maybe I would feel different if I had that use case

bozhidar20:04:35

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

bozhidar20:04:51

I guess most people would just use 1.

arrdem20:04:56

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

arrdem20:04:18

Just aggregate all the responses to a single REPL 😉