This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (20)
- # aleph (25)
- # announcements (4)
- # babashka (117)
- # beginners (150)
- # calva (4)
- # cider (9)
- # clj-on-windows (2)
- # clojure (9)
- # clojure-europe (4)
- # clojure-italy (3)
- # clojuredesign-podcast (18)
- # clojurescript (16)
- # conjure (1)
- # core-async (35)
- # cursive (13)
- # datalevin (6)
- # datomic (6)
- # fulcro (8)
- # hyperfiddle (5)
- # malli (8)
- # nextjournal (4)
- # off-topic (51)
- # pathom (4)
- # reagent (21)
- # sci (14)
- # shadow-cljs (22)
- # specter (3)
- # testing (22)
- # tools-deps (8)
- # xtdb (7)
What's the reason reduce is implemented as a function in core.async and not by the reduce interface or protocol?
Jo I thought I can call
deref on a channel but I can't. didn't Rich mention this in a talk?
But deref shouldn't change the reference. You're just looking at it. Looking is free. Take mutates the channel
I see that makes sense. I wanted to use the timeout arg for deref. But I can do it with
timeout . Or use future I guess.
The use case is doing work with a timeout
I've had a week of "how do I-s" turning into "what are you trying to do" So, what are you trying to do? Are you already building something with core async?
I have events and like to handle them async with a timeout. Doesn't matter so much if 1 piece of work fails it's more important that it keeps handling incoming stuff. I'm using a library that puts the events on a channel so there is core.async there. It's something like 1/second
Even when you time something out, you can leak resources because you didn't cancel the process. You take stuff out of a channel, then process it with a timeout?
I believe this was talked about at some point long ago but I don't think it has ever been implemented/released
you need a few things. For each of those, implement a cancellation mechanism, you need it anyway to avoid resource leaks. Then you can implement a uniform interface which times the task out and cancels it
I've used that "pattern" when I need to keep processing things, and at the same time each event can have a timeout, retry, etc
like putting the channels returned by
go into a channel? What can I then do with that?
It really depends on the use case and the specifics 🙂 I can write a wall of text here but it might only make it more confusing; Just a tool to keep in mind that is available, which might not be obvious, aka the fact that you can put channels on channels
I'd like to pass a control channel that stops a go-loop when I put :stop, alternatively when I close the channel. What is the usual pattern? If I do
<! from the control channel it will park right? So is there always some
alt going on?
doing this now
(a/go-loop  (a/alt! control :stop (a/timeout 300) (do (prn "loop") (recur)))) (a/>!! control :stop)
Then you should utilize the fact that taking from a closed channel returns nil. Instead of a signalling channel close the input
This lends itself to a very nice pattern of automatically cascading shutdown if you build everything with little workers
is it fine to have such a loop recuring forever when the channel closes or should it check nil?
(loop  (let [data (a/<!! event-ch)] (when-not (= data :disconnect) (recur))))
Yeah, if the loop becomes infinite I believe you'll hog a thread from the thread pool (not good)
(loop  (let [a b] ... (recur))) is not different to
(loop [a b] ... (recur b)) . And of course there is go-loop