This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-14
Channels
- # aleph (3)
- # announcements (16)
- # aws (6)
- # babashka (10)
- # beginners (28)
- # cider (1)
- # clj-kondo (14)
- # cljdoc (2)
- # cljs-dev (27)
- # cljsrn (7)
- # clojure (78)
- # clojure-europe (2)
- # clojurescript (14)
- # conjure (6)
- # core-async (2)
- # fulcro (5)
- # helix (7)
- # jobs (1)
- # lgbtq (1)
- # malli (12)
- # missionary (1)
- # nbb (10)
- # pathom (1)
- # portal (12)
- # protojure (1)
- # re-frame (41)
- # react (2)
- # reitit (1)
- # reveal (1)
- # shadow-cljs (72)
- # sql (11)
- # tools-deps (8)
- # vim (1)
- # xtdb (4)
In case anyone here is interested in #tools-build but not in the minutiae of #tools-deps and/or the CLI itself, Alex created a channel to talk about build.clj
etc 🙂
Am gonna make a lib for PREPL to enable cancellation of long running form evaluation. Anyone know of previous work on this?
I’ll check it out. Was thinking specifically about work on prepls but maybe that will inspire too :) thanks
here are the tricks that nrepl does https://github.com/nrepl/nrepl/blob/master/src/clojure/nrepl/middleware/session.clj#L158-L180, probably there's more to read then those highlighted lines :)
Thanks @viesti. What’s not clear to me is how state is retained after cancellation. So probably I don’t understand how state is shared across the thread pool.
can't do interrupt with one prepl alone anyways, need a second connection since the first one is eval'ing and not reading
also interrupts on the JVM are kinda tricky, almost nothing is actually checking the interrupt flag
With io-prepl the prepl is attached to a socket. One can close the socket and clone state
what do you mean by cloning then? the JVM doesn't exit when you intterupt the thread so all state is preserved? no need to clone anything?
in theory the initial prepl just needs to sound out a message "hey I'm starting to eval, this is my thread id"
and over the other connection you can then later send an eval to kill that thread if you want
depending on how the kill actually happened the first connection might just loop again and let you eval again
FWIW, that's pretty much what I do in an editor plugin I'm making, and it works well. I just call .interrupt
on the eval thread, so it won't help you if you do things like eval (range)
, but for me, at least, it's enough to be able to cancel a deref etc.
more likely though the kill makes the thread unusable so you might as well kill that socket
what state? 😛 clojure vars are global, they don't care about threads. they'll continue to exist as long as the JVM lives
reading around nrepl, it does some things to resurrect thread bindings https://github.com/nrepl/nrepl/blob/master/src/clojure/nrepl/middleware/session.clj#L136-L156
io-prepl gets its own blocking thread so most of the stuff nrepl does you don't need
yes, somehow I didn't think to do the obvious thing of just pushing the evalled state on an atom
what eval'd state? 😛 (def my-state "thing")
you can access directly over the other connection, no work needed
the thread-bindings are also pretty much nrepl specific since it keeps all its own state in there. prepl is prettty much stateless so you probably won't need it
it should die once it fails to write to the socket? otherwise yes, (range)
itself never checks the interrupt flag and happily keeps going
oh .. nevermind just checked. it uses pr-str
so it stops once it runs out of memory 😉
this reminds me of unrepl by cgrand https://github.com/Unrepl/unrepl/blob/master/SPEC.md#ellipsis-or-elisions
thinking *print-length*
, but for interrupt (might not work nice work arbitrary data)
so yeah @viesti I'll give binding to a tuneable *print-length*
a go. I'm already using a mix of core.async and futures so that the read part of the repl is not blocking ie the cancellation can occur immediately
correction the *print-length*
thing makes no difference… it just let me wait for the task to get killed, which - good news - it does get killed ,,,, just takes a while
so I’m gonna play with the core.async
option as a replacement for directly using pr-str
urgh, no luck … maybe I just don’t have enough core.async
chops. It works even if sub-optimally, so I’m going to move on until my frustration abates 🙂
I've been trying to read the https://clojure.org/reference/transducers, and finally something dawned on me that I've been reading wrong. It first defines a reducing function and thereafter defines a transducer in terms of reducing function. It says a reducing function is a function like you pass to reduce
and it gives a signature whatever, input -> whatever. But that's wrong I definitely do not give reduce
a pair whose first component is a whatever
and and whose second component is an input -> whatever
. Finally I realized that what it means to say is (whatever,input)->whatever
not whatever,(input->whatever)
. Am I the only person who was confused because of the lack of parentheses?
I guess I just chose to read it like (whatever, input)->whatever
because it says that they talk about a reducing function - and thats how I know reducing functions 😄
is omission of the parens common notation in modern literature?
Im not very familiar with this kind of notation but I think ive seen it before without parens. I too think its confusing though.
Is there any practical difference between using an implicit namespaced keyword such as ::bar and explicitly stating out the namespace such as :foo/bar? I am mostly interested in the refactoring perspective.
After read they are the identical keyword in the runtime, so it’s really more about managing what you write in your code. :: is of course shorter but can lead to surprises if you copy paste code or change the name of the namespace containing it
Thanks. I just learned the trick of ::ns/keyword where ns is some imported ns name. Given this, I will go with the ::keyword pattern, and access it in other ns with the ::ns/keyword way.
I've made a script here to "normalize" those double-colon keywords: https://github.com/babashka/babashka/blob/master/examples/README.md#normalize-keywordsclj