This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-26
Channels
- # announcements (6)
- # beginners (328)
- # boot (2)
- # cider (72)
- # clara (6)
- # cljdoc (4)
- # cljsrn (5)
- # clojure (78)
- # clojure-europe (3)
- # clojure-italy (22)
- # clojure-nl (4)
- # clojure-spec (3)
- # clojure-uk (114)
- # clojurescript (22)
- # clojurex (54)
- # copenhagen-clojurians (1)
- # core-async (20)
- # cursive (8)
- # data-science (1)
- # datomic (22)
- # duct (11)
- # emacs (32)
- # events (1)
- # figwheel (2)
- # fulcro (18)
- # graalvm (53)
- # graphql (39)
- # luminus (6)
- # nrepl (6)
- # off-topic (53)
- # om (1)
- # re-frame (8)
- # reagent (19)
- # reitit (3)
- # shadow-cljs (28)
- # spacemacs (10)
- # sql (37)
- # tools-deps (33)
- # vim (9)
- # xtdb (6)
When handling values from a channel, is it correct that when the channel closes the value will be nil? And, is it common to have to cover that case for each go block? For example if I have a go-loop and a channel i’m consuming returns nil I would stop recuring that loop?
@colinkahn also common to use some?
as the predicate so that you can send any value including false
over the channel (but not nil
)
the channel already rejects nil
values when putting them in -- you shouldn't try to duplicate this "in userspace"
gotcha, and even with the filter
it’ll still emit nil
upon close, if I understand correctly
no, your code would just be stopped indefinitely reading nils
and probably pegging the CPU
or maybe I misunderstood you: the channel keeps making nils as fast as you ask for them, filter would just drop them all before other code sees them
right
I'm not sure how impactful it is. But the timer's skiplist in cljs is just a simple linked list not a skip list. https://clojure.atlassian.net/projects/ASYNC/issues/ASYNC-228. Would appreciate someone chiming in if they think this is major or not (while people are in here chatting)
on the other hand there is take-while which stops after some condition is met, but I wouldn't recommend treating IO like channel ops as if they were lazy collections