This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-19
Channels
- # adventofcode (18)
- # announcements (1)
- # babashka (153)
- # beginners (73)
- # bristol-clojurians (4)
- # calva (1)
- # cider (6)
- # clj-kondo (38)
- # clojure (154)
- # clojure-dev (12)
- # clojure-europe (7)
- # clojure-finland (11)
- # clojure-nl (70)
- # clojure-spec (13)
- # clojure-uk (101)
- # clojuredesign-podcast (2)
- # clojurescript (15)
- # core-async (30)
- # cryogen (1)
- # cursive (5)
- # devops (1)
- # duct (4)
- # figwheel-main (1)
- # fulcro (19)
- # jobs (12)
- # kaocha (17)
- # luminus (2)
- # malli (8)
- # music (5)
- # nrepl (13)
- # off-topic (20)
- # overtone (3)
- # re-frame (7)
- # reagent (38)
- # shadow-cljs (13)
- # specter (3)
- # tools-deps (6)
- # vim (7)
What is the best way to read from a channel till a certain condition is met (e.g., 2000 elements taken)?
@erwinrooijakkers before its gone have a read of this post https://clojurians.slack.com/archives/C05423W6H/p1576240660002300
The pipe go-loop is taking from one channel and puts on the other until either channel is closed. The first put of 0
closes the second channel, but it is technically successful (the put succeeded with no items), so pipe iterates one more time, takes 1
and then encounters the closed channel and quits, but the 1
is already out of the source channel.
Great explanation, thanks! When I tried this variant I got non deterministic results: https://clojurians.slack.com/archives/C05423W6H/p1576247793020000?thread_ts=1576243305.010900&cid=C05423W6H
It’s a race between your take and the internal pipe take. One of you will get the 1
and become a funk king.
Makes sense, which means that race condition is also present in the original example given by @U66G3SGP5. Adding a few log/locking/println statements in my version did the trick to reveal the race condition.
Of course there’s a race condition there, that is intentional, after creating pipe I read from source of that pipe directly. The point of that snippet wasn’t to show working code, it was to show an additional item was read from the source channel
Thanks I saw that one yes
But have had no time to test yet
I really want 2000 messages and only then continue
transducer that does (take 2000)
Would be perfect
I’ll check this evening 🙂
Thanks!
playing with core.async:
(def c (async/chan (async/buffer 0) x))
(future (async/>!! c 1))
(async/<!! c) ;; returns 1
I know you're supposed to have an actual non empty buffer for xform to work, but I was suprised we didnt' get an early throw in that case (at channel creation time)
(async/chan 0) will throw
prob just an oversight that (async/buffer 0) doesn't (far more common to create fixed buffers directly in chan)
yeah, that's just badly placed assertion, will fix
unbuffered != buffer 0