Fork me on GitHub
#cider
<
2017-01-22
>
qqq00:01:05

@bozhidar : (completely serious); I see the donate buttons on the github cider page. However, have you guys considered a "per screencast kickstarter" ? Something like, people donate $1000 to this project, we will make a screen cast showing off feature XYZ -- I suspect it would not be hard to. get 100 ppl to each donate $10.00 This way, you guys get more funding to build cider, and personally, I'd be happy spending $10 to get a cider screencast instead of a movie ticket

practicalli-johnny10:01:47

@qqq I am creating screencasts of cider features as part of my Spacemacs for Clojure development workshop, still early days and need to improve quality, but over next few weeks should get better & quicker to produce. https://practicalli.github.io/spacemacs/

bozhidar11:01:19

@qqq I've thought about this and hopefully we'd get there eventually. Hopefully in a couple of months I'll be able to finally get to this.

bozhidar11:01:44

@dpsutton The tooling session is meant for users who want to build commands themselves by simply evaluating some code. It's a remnant of the old days of CIDER before we were using nREPL middleware. If you evaluate some code to get completion candidates or do macroexpansion in the eval session that would interfere with it (e.g. messing up with *1 and friends). I'm assuming very few people are using this tooling session, so I've been thinking for a while about killing it (and maybe coming up with some different solution to this problem).

bozhidar11:01:15

CIDER never uses the tooling session directly (all commands that were using it were switch to middleware years go), the functionality was retained here just for the same of people who might prefer to just evaluate something as opposed to writing a middleware. You can see this approach still in projects like monroe and inf-clojure.

richiardiandrea16:01:19

Also important to note is that the new socket repl can handle sessions itself

jfntn16:01:42

I was also wondering if it'd be possible to rearchitect the middleware stack into a bunch of dedicated tooling sessions. It seems like the middlewares could then act as independent services that don't risk breaking everybody else?

jfntn16:01:42

@bozhidar: was reading the old socket repl threads on the clojure mailing list recently and you didn't seem convinced at the time by the whole streaming model. Is my perception correct? And if so have you changed your mind at all since then?

bozhidar16:01:38

@richiardiandrea Not sure what you mean. The new socket repl doesn't really have a notion of a session.

dpsutton16:01:51

thanks for the background of the tooling session by the way

bozhidar16:01:02

@jfntn The middleware itself has nothing to do with sessions. You just dispatch nREPL requests over some session to some middleware. We use just one, but we could have used many sessions.

bozhidar16:01:27

As for the socket repl - I've lost any interest in trying to support it in CIDER as I don't see any benefits coming out from this. We'll still need some notion of sessions, we'll still need some libraries providing the tooling code. In the end of the day we'll have to build something on top of it, to make it useful for tooling authors. Seems to me it wasn't well thought out - it's handy if you want to quickly inspect some remote process, but doesn't provide anything useful to tooling authors. The only upside I can see is that it might make supporting cljs easier, but if someone spent some time polishing nREPL and piggieback the results might be the same.

bozhidar16:01:25

But I have to hand it to the socket repl - it's eval-only model is conceptually simpler than using middleware for sure.

richiardiandrea16:01:27

@bozhidar ah, I read it here under "server state": http://dev.clojure.org/display/design/Socket+Server+REPL but I have actually never used it myself 😀 so you might be totally right

bozhidar17:01:05

Alex wrote this prototype after a discussion we've had regarding the deficiencies of the baseline socket repl server

bozhidar17:01:27

Btw, I remember one other problem that's Emacs specific - dealing with EDN. Obviously that's not an issue when you're client is written in Java or JavaScript, but it's a big issue for Emacs. There's just one EDN parser for Emacs and I have no idea how well this thing actually works.

bozhidar17:01:05

(my main concern is that edn.el uses a library that hasn't been updated in 7 years and is hosted only on EW - https://www.emacswiki.org/emacs/peg.el; that's never good 🙂 )

richiardiandrea17:01:44

@bozhidar got it, yes also that doc is a design doc so I am not really sure what ended up on core. Oh peg yeah...I have a checkout for it in my emacs ..lol

dpsutton17:01:03

@bozhidar can you give a link to the edn parser?

dpsutton17:01:31

haha of course its him

bozhidar17:01:34

I guess it was created for clj-refactor.el

bozhidar17:01:52

I opted not to use it in CIDER because of the peg.el dependency

dpsutton17:01:53

i'm amazed at how productive people are

bozhidar17:01:02

90% of the cool Emacs Lisp libraries are created by 90 people 😄

dpsutton17:01:15

i follow emacs-devel a little and its amazing to see the whole list appreciate him. i think he dove into the bug tracker real hard