That's clever!
Just a bummer I have to feed everything to the chan in a collection for cat
to work. Guess I could add a map transducer which converts non-collections
into collections.
keskiviikko 11. lokakuuta 2017 15.25.24 UTC+3 tbc++ kirjoitti:
>
> If you want to simply keep some messages in
If you want to simply keep some messages in order, then a cat transducer
will do the trick just fine:
;; need a buffer or buffer size to get to the transducer param
(def c (chan 20 cat))
(async/onto-chan c [1])
(async/>!! c [2 3 4])
(async/close! c)
(
wrote:
> If you don't want to split at th
If you don't want to split at the consumer I would recommend adding another
channel, and piping it with a cat xform as mentioned above.
On Oct 11, 2017 3:28 AM, "JokkeB" wrote:
> Thanks. I'm not interested in reading the messages as pairs, I just need
> to make sure nothing gets in between them.
Thanks. I'm not interested in reading the messages as pairs, I just need to
make sure nothing gets in between them. I think I'll choose some way to
merge the messages, for example just a vector like you suggested, and then
have the end consumer recognise and split the vector. I guess splitting t
I think simply wrapping the two values in a vector is the only thing that's
needed in this case. Simply do a put like (>!! ch [my-val-1 my-val-2]) and
take from the channel from another place. If my-val-1 and my-val-2 are not
immediately available, you can have a separate mechanism (atoms, (loop
So, at the point where you need 2 things to be consecutive, wrap them up in
a vector so they're one thing. `(partition-all 2)` will return a transducer
xform that chunks up your message stream by 2
https://clojuredocs.org/clojure.core/partition-all, and if you need to undo
it you can do so with the
Thanks for the response. That's what I suspected.
How does partition help me in this case? I can't see any way of using it.
How about onto-chan, would that be deterministic? Or any other function?
tiistai 10. lokakuuta 2017 17.33.22 UTC+3 Gary Trakhman kirjoitti:
>
> I think a core assumption is
I think a core assumption is that all writes can yield control at any time
to other worker go processes. I wouldn't rely on the consecutive behavior
even if it were true, nondeterminism is a good assumption with core.async.
If you need that particular guarantee, consider a call to partition?
On T
I'm wondering about a case when using async:
I have a channel where I write from multiple threads. One of the sources is
a go-loop with a timeout, so each second I write something to the channel.
If I do two consecutive writes inside the go block, can another thread
write between the two writes
