This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-04
Channels
- # admin-announcements (14)
- # aleph (3)
- # beginners (75)
- # boot (95)
- # carry (4)
- # cider (23)
- # clojure (39)
- # clojure-android (3)
- # clojure-brasil (2)
- # clojure-dev (17)
- # clojure-gamedev (1)
- # clojure-mexico (12)
- # clojure-poland (12)
- # clojure-romania (1)
- # clojure-russia (10)
- # clojure-spec (8)
- # clojure-uk (36)
- # clojurescript (34)
- # core-async (4)
- # datomic (40)
- # emacs (1)
- # events (7)
- # hoplon (119)
- # instaparse (52)
- # keechma (71)
- # mount (4)
- # off-topic (9)
- # om (4)
- # onyx (3)
- # other-languages (23)
- # protorepl (3)
- # re-frame (9)
- # reagent (26)
- # rethinkdb (5)
- # spacemacs (2)
- # testing (1)
- # yada (1)
@andrewhr that’s pretty reasonable, could even be implemented as a general function that takes an input channel, creates an intermediary channel with a sliding buffer, and output channel, runs a pair of go loops that do the counting, and returns the output channel. Not sure about the performance implications of adding two intermediary channels like that.
I may just have producer check (pos? (count (.buf c)))
before putting onto the channel with a (sliding-buffer 1)
, and assume if that expr is true, then 1 message will be dropped
That’s not thread safe IIRC, but will probably be good enough for an estimate
@danielcompton: yup, there's a possibility that a take happens between checking buf size and putting onto it, but totally good enough for estimate. Thanks everyone for the thoughts!