This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-29
Channels
- # beginners (42)
- # boot (12)
- # cider (3)
- # cljs-dev (277)
- # cljsrn (44)
- # clojure (127)
- # clojure-austin (9)
- # clojure-austria (1)
- # clojure-brasil (14)
- # clojure-canada (1)
- # clojure-dev (22)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (24)
- # clojure-spec (33)
- # clojure-taiwan (1)
- # clojure-uk (21)
- # clojure-ukraine (8)
- # clojurescript (134)
- # core-async (41)
- # core-logic (8)
- # cursive (1)
- # datomic (3)
- # ethereum (1)
- # events (4)
- # funcool (1)
- # leiningen (12)
- # off-topic (21)
- # om (19)
- # onyx (45)
- # overtone (1)
- # parinfer (2)
- # pedestal (3)
- # proton (2)
- # re-frame (103)
- # reagent (48)
- # test-check (27)
- # untangled (51)
- # vim (3)
I'm just learning async
, and I expect the following to print "hi"
, why does it not, and return a channel only?
go returns a channel no matter what, and reading and writing the same channel in a go block is not supported
I don't understand that question (or does it refer to an example you haven't shared yet?)
never mind, I fail at slack UI
no worries 🙂
the second example has putting and taking in one go
block...
right, I think the buffer either fixes the read/write in one block issue, or works accidentally and the read/write is not officially supported - I'll see if I can find out which
ah, thanks for your help, and I'm ok if you don't figure it out, sounds like a lot of work 😉
I'm going between haskell, clojure, and python right now, and noticing a lot of interesting patterns in each about their little quirks, haha
(esp in how they compare to each other)
oh! - I think I know what it is. >! does not return until the data is consumed
so in the first example, it parks, and the consume that would follow can't run
the buffer prevents that behavior
so I should say, >! only returns if there is room in the channel's buffer, which means that if there is no buffer, it doesn't return until the message is consumed
which is impossible in the original example
doesn't >!
return immediately always?
(`>!!` blocks, no?)
no, >! parks
so it blocks the rest of the code in that go block (but it doesn't block the thread - the thread works on other go blocks if available)
, >!! blocks the thread itself
https://clojure.github.io/core.async/#clojure.core.async/>! "Will park if no buffer space is available."
if I don't declare a buffer size, how big is it? I assumed infinite...
ah. k, this could explain some of my confusion...
but how about this example, how can a buffer size of 0 accomplish anything?
(let [c (chan)]
(go (while true (println (<! c))))
(for [_ (range 10)] (go (>! c (rand-int 1000)))))
I mean, the previous prints 10 random digits... why would that work with a buffer of 0?
because >! only parks the go block it is inside
you don't need any buffering for any of that to work
that won't work if you don't consume the return value of the let, by the way, because for is lazy. The normal thing would be to use doseq instead of for there
the Print step of the REPL consumes it, so it accidentally works, but only when doing it interactively
josh.freckleton: parking is telling core.async that the go block you are in can be ignored until your operation is ready to complete
ah, that's why I can't swap the 2 lines in my latter example, but I can if I use doseq
... gotcha.
also, (dotimes [_ 10] ...)
is identical to (doseq [_ (range 10)] ...)
except it's more efficient because it doesn't need to create a lazy-seq
(the efficiency is minor, but dotimes is still nicer)
ah, thanks! ya, doseq
wan't part of my repertoire since most of my code to-date has been pure (side-effect-free), at least I try to. But now that I'm getting into async
, gotta flip my mind back to imperative.
big thanks @noisesmith!
(PS wow, async
makes trivial some complex ideas that i've tried to build ad-hoc in other languages)