This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-12
Channels
- # adventofcode (135)
- # announcements (1)
- # beginners (192)
- # boot (5)
- # calva (130)
- # cider (42)
- # cljdoc (4)
- # cljs-dev (6)
- # cljsrn (3)
- # clojure (222)
- # clojure-europe (2)
- # clojure-greece (5)
- # clojure-italy (24)
- # clojure-nl (23)
- # clojure-russia (1)
- # clojure-spec (6)
- # clojure-uk (67)
- # clojurescript (35)
- # cursive (39)
- # datomic (61)
- # emacs (17)
- # figwheel (3)
- # figwheel-main (2)
- # fulcro (12)
- # hyperfiddle (10)
- # juxt (3)
- # leiningen (10)
- # nrepl (35)
- # off-topic (34)
- # onyx (3)
- # pathom (6)
- # quil (5)
- # re-frame (29)
- # reitit (6)
- # ring (1)
- # ring-swagger (8)
- # shadow-cljs (37)
- # spacemacs (9)
- # sql (9)
- # tools-deps (24)
- # unrepl (1)
- # vim (1)
@cgrand Looks good to me. The only thing that’s a bit of a problem is that moving the default executor will break cider-nrepl, as there was a bit of code using this implementation detail directly, but that’s not a big deal.
I guess it would also be nice to document the new behavior accordingly, although that’d be mostly for us - I highly doubt that anyone relied on the implementation details of the execution.
One more somewhat related thing is the handling of output that we discussed could be improved if we have one thread per session, but I guess this can be done later.
@dchelimsky The new Lein 2.8.2 is out! 🙂
Thanks for letting me know!
@bozhidar another breaking change is that the configurable excutor to interruptible-eval is ignored — is it used in practice?
Having worked on thread management, I’m now wondering if I missed a documentation on the execution model (not the implementation).
My understanding:
• msgs from different session are concurrent
• :eval
msgs for a given session are serialized
• non-`:eval` msgs for a given session are... concurrent?
> @bozhidar another breaking change is that the configurable excutor to interruptible-eval is ignored — is it used in practice?
It’s used directly in the test-runner - https://github.com/clojure-emacs/cider-nrepl/blob/7d2ed83b3a57f3883f4a9edd7f6cf83a8d0888b0/src/cider/nrepl/middleware/test.clj#L358
> Having worked on thread management, I’m now wondering if I missed a documentation on the execution model (not the implementation).
The difference between the behavior of eval and non-eval messages was a big argument in favour of moving most of the client functionality to middlewares, as if they constantly evaled some messages to get things like completion candidates that could impact performance negatively.
execution model: thanks for the background; what about serializing execution on session+op
? (I don’t have an actual plan, just questioning the statu quo)
This will need to be reworked https://github.com/clojure-emacs/cider-nrepl/blob/7d2ed83b3a57f3883f4a9edd7f6cf83a8d0888b0/src/cider/nrepl/middleware/test.clj#L274-L287
> execution model: thanks for the background; what about serializing execution on session+op
? (I don’t have an actual plan, just questioning the statu quo)
I guess it depends on the op - most ops don’t really affect the global state, so it’s fine to run them concurrently. I don’t see a need for serializing individual ops, unless something in the implementation of the op requires it - e.g. I can imagine multiple refresh ops running in parallel might be a bad idea, but I also wonder if that’s something people encounter in practice.
Perhaps there could be some flag to force ops to be serialized to make sure they’re safely applied?
Ah, got it. I’ve been wondering from time to time if we should allow the usage of non-cloned sessions at all. I don’t really see any value in them, but I might be missing something.
> This will need to be reworked https://github.com/clojure-emacs/cider-nrepl/blob/7d2ed83b3a57f3883f4a9edd7f6cf83a8d0888b0/src/cider/nrepl/middleware/test.clj#L274-L287
I’ve created a PR for #16 https://github.com/nrepl/nrepl/pull/98
Thanks for letting me know!