I think the problem isn't the name - it just isn't clear if a channel which
behaves unlike any other channel when closed can qualify as having channel
semantics.
On Thursday, October 29, 2015 at 2:10:43 PM UTC-7, Alex Miller wrote:
>
> We are not going to change the name - it is a channel with p
On Thursday, October 29, 2015 at 6:18:47 PM UTC-5, Derek Troy-West wrote:
>
>
> Understanding the limitations of analogies, does this new channel adhere
> to that concept of flow-state? Is it a conveyor-belt or a coat-hook?
>
I don't think it's exactly either of those (hey, analogies). A promis
On Thursday, October 29, 2015 at 5:35:17 PM UTC-5, Rangel Spasov wrote:
>
> I assume this is a pretty reliable way:
>
> (:require [clojure.core.async.impl.protocols :refer [closed?]])
>
> (closed? a-chan)
>
Being something under "impl", you should treat this as an implementation
detail subject t
Thanks Alex, I think I can sum up my confusion as: I thought channels were
single take, but understand now that is not necessarily the case.
In his 2013 Strange Loop talk Rich described first-class channels and the
subset of state that they expose:
"But I think what's really cool about first clas
I assume this is a pretty reliable way:
(:require [clojure.core.async.impl.protocols :refer [closed?]])
(closed? a-chan)
On Thursday, October 29, 2015 at 2:07:00 PM UTC-7, Lucas Bradstreet wrote:
>
> Fantastic release. I've been waiting for poll! and offer! for a while.
>
> What is the recommen
On Oct 29, 2015 4:10 PM, "Alex Miller"
>
> The buffer is not unbounded - it is of size 1.
Is it correct or reasonable to think of it as a constant channel?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@
>
> To be clear, I didn't mean that a channel is guaranteed to be closed,
> rather that previously I could count on the ability to drain a channel
> after I have chosen to close it. Closing a promise-chan which has received
> a value has no impact on later takes, it is indistinguishable from a
Fantastic release. I've been waiting for poll! and offer! for a while.
What is the recommended way to check whether a channel is closed?
Previously if the channel returned nil, then we know the channel is
closed, however with poll! we can't tell between the channel being
closed or just empty.
Tha
>
>
>
>> Secondly, I've perhaps mistakenly considered channels more as a conduit
>> between processes rather than a replacement for single assignment message
>> passing. I get the value of using a channel and the core.async state
>> machine for achieving promise-like semantics in a non-blocki
I'll take a look, thanks.
On Thursday, October 29, 2015 at 10:52:08 AM UTC-5, Marian Schubert wrote:
>
> Awesome!
>
> I did try it on our project and it failed at one location with:
> CompilerException java.lang.UnsupportedOperationException: Can only recur
> from tail position
>
> Minimal exampl
Awesome!
I did try it on our project and it failed at one location with:
CompilerException java.lang.UnsupportedOperationException: Can only recur
from tail position
Minimal example which still fails (alts! + case + recur combination) is:
(defn this-fails-to-compile [x]
(go
(loop []
On Thursday, October 29, 2015 at 5:05:04 AM UTC-5, Derek Troy-West wrote:
>
> Hi Alex, thanks for your efforts and the update.
>
> I have a few questions about promise-chan if you have a moment.
>
> Firstly, why provide promise-chan rather than requiring (chan
> (buffers/promise)). The buffer pr
Hi Alex, thanks for your efforts and the update.
I have a few questions about promise-chan if you have a moment.
Firstly, why provide promise-chan rather than requiring (chan
(buffers/promise)). The buffer provides the promise semantics and we don't
similarly have sliding-chan, dropping-chan, e
Awesome, thanks!
Le mercredi 28 octobre 2015 14:06:41 UTC-7, Alex Miller a écrit :
>
> I am happy to announce a long-overdue core.async release.
>
> Dependency info: [org.clojure/core.async "0.2.371"]
>
> There are a few new features in this release:
>
> 1) *promise-chan* is a function that retur
Excellent \o/, much appreciated!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe fro
That's great, thanks everyone involved in this release. Already made use of
offer! : ) .
On Wednesday, October 28, 2015 at 2:06:41 PM UTC-7, Alex Miller wrote:
>
> I am happy to announce a long-overdue core.async release.
>
> Dependency info: [org.clojure/core.async "0.2.371"]
>
> There are a fe
Bravo, great work Alex and team! Also appreciate the new versioning scheme.
On Wednesday, October 28, 2015 at 5:06:41 PM UTC-4, Alex Miller wrote:
>
> I am happy to announce a long-overdue core.async release.
>
> Dependency info: [org.clojure/core.async "0.2.371"]
>
> There are a few new feature
Great work Miller & Team :D
onsdag 28. oktober 2015 22.06.41 UTC+1 skrev Alex Miller følgende:
>
> I am happy to announce a long-overdue core.async release.
>
> Dependency info: [org.clojure/core.async "0.2.371"]
>
> There are a few new features in this release:
>
> 1) *promise-chan* is a functio
Thanks Alex! I appreciate the work you put in to get this out.
On Thu, Oct 29, 2015 at 10:06 AM Alex Miller wrote:
> I am happy to announce a long-overdue core.async release.
>
> Dependency info: [org.clojure/core.async "0.2.371"]
>
> There are a few new features in this release:
>
> 1) *promis
I am happy to announce a long-overdue core.async release.
Dependency info: [org.clojure/core.async "0.2.371"]
There are a few new features in this release:
1) *promise-chan* is a function that returns a new kind of channel (with a
custom buffer) with promise semantics. Specifically, channels m
20 matches
Mail list logo
