This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-17
Channels
- # adventofcode (3)
- # announcements (1)
- # babashka (25)
- # beginners (55)
- # calva (12)
- # cider (40)
- # clj-kondo (13)
- # clojure-australia (2)
- # clojure-dev (11)
- # clojure-europe (67)
- # clojure-france (6)
- # clojure-nl (16)
- # clojure-uk (9)
- # clojuredesign-podcast (9)
- # clojurescript (17)
- # conjure (7)
- # cursive (3)
- # datomic (3)
- # emacs (8)
- # figwheel-main (7)
- # fulcro (21)
- # google-cloud (21)
- # graphql (8)
- # helix (1)
- # honeysql (32)
- # instaparse (2)
- # jobs (2)
- # jobs-discuss (2)
- # meander (80)
- # mount (1)
- # off-topic (25)
- # pathom (31)
- # polylith (1)
- # rdf (24)
- # re-frame (21)
- # reagent (29)
- # releases (1)
- # remote-jobs (1)
- # shadow-cljs (16)
- # slack-help (6)
- # sql (5)
- # tools-deps (23)
- # uncomplicate (2)
- # wasm (2)
- # xtdb (4)
@hiredman in the clojure.main repl you can override eval
to e.g. add a wrapper that submitted code somewhere central for tooling, but that doesn't seem possible with prepl - eval is hardcoded so any envelope would have to be added by the submitter, not the REPL receiver
@seancorfield note that interrupted eval in nREPL relies on Thread#stop which is deprecated and not even available anymore in newer VMs like GraalVM (this is why bb doesn’t support this in its REPLs)
As far as I have seen, every REPL that supports interruptable eval uses Thread#stop today. I have only confirmed with nREPL 0.6.0 with Lein 2.9.3 and unrepl / unravel, but there really is no other mechanism that can be used to stop a thread that is in a "ignore the world" infinite loop, i.e. that doesn't use the recommended method of avoiding Thread#stop because it checks for some global variable change or similar thing in its inner loops.
It makes perfect sense to me that Thread#stop is deprecated -- not trying to argue against deprecating it. It makes sense why people decide to use it anyway.
(well, many of them without knowing they are using it, perhaps)
Thread#stop is still available in JDK 15, FYI -- I haven't checked JDK 16.
Yeah, @hiredman pointed that out in a thread to me, and I think he did a quick check and that's how they all work -- because it's all there is on the JVM right now (unless your compiled code includes collaborative checks on a global "abort" flag). He also shared some code with me that made me feel a bit better about building something very simple and prepl-based that might provide the sort of minimal almost-no-code REPL that I'd like to see (but, frankly, at this point I doubt anyone is going to unseat nREPL).
the jvm tooling interface (I guess what jvm agents use?) has an optional command to kill threads too https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#StopThread which it says is like Thread.stop, but I don't see a bunch of "Keep Out" signs posted all around it
Probably they figured that if you read that, you will read the docs for Thread#stop, too. I would guess there are a lot of potential 'here be dragons' methods in tooling interfaces besides that issue.