This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (10)
- # boot (134)
- # cider (29)
- # clara (2)
- # cljs-dev (10)
- # cljsjs (2)
- # cljsrn (13)
- # clojure (76)
- # clojure-india (4)
- # clojure-ireland (1)
- # clojure-russia (20)
- # clojure-spec (11)
- # clojure-uk (7)
- # clojurescript (88)
- # core-async (5)
- # core-logic (3)
- # cursive (17)
- # datascript (5)
- # datomic (123)
- # hoplon (8)
- # klipse (6)
- # lambdaisland (2)
- # leiningen (4)
- # luminus (2)
- # off-topic (23)
- # om (23)
- # om-next (1)
- # onyx (20)
- # pedestal (2)
- # perun (2)
- # re-frame (11)
- # ring-swagger (3)
- # untangled (12)
@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
@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/
@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.
@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).
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
Also important to note is that the new socket repl can handle sessions itself
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?
@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?
@richiardiandrea Not sure what you mean. The new socket repl doesn't really have a notion of a session.
@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.
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.
But I have to hand it to the socket repl - it's
eval-only model is conceptually simpler than using middleware for sure.
@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
Alex wrote this prototype after a discussion we've had regarding the deficiencies of the baseline socket repl server
(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 🙂 )
@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