On 5 September 2014 at 06:08:17, Colin Fleming (colin.mailingl...@gmail.com)
wrote:
> Given that there's a long time between major releases and 1.6
> just came out, are they likely to be backported to a 1.6 point release
> when they're done or will we have to wait for 1.7?
FWIW, Clojure doesn
Define "stable". We've had Clojure 1.7.0 Alpha 1 in production since August
12th with no problems.
On Sep 4, 2014, at 7:07 PM, Colin Fleming wrote:
> Is there any indication of when transducers are likely to make it to a stable
> version of Clojure? Given that there's a long time between major
Is there any indication of when transducers are likely to make it to a
stable version of Clojure? Given that there's a long time between major
releases and 1.6 just came out, are they likely to be backported to a 1.6
point release when they're done or will we have to wait for 1.7?
On 5 September
Transducers are available now in Clojure 1.7.0-alpha1. Alpha2 coming real soon
now.
--
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
IIRC they are coming out in clojure 1.7. I don't see any indication of when it
will be declared as stable, but there are alpha builds available if you need
them.
--
Ashton
On Thu, Sep 4, 2014 at 1:29 AM, cig wrote:
> Thanks Alex. Feel silly not to have noticed the partition function. When
Thanks Alex. Feel silly not to have noticed the partition function. When
will transduces be available to use?
On Wednesday, 3 September 2014 22:48:20 UTC+2, Alex Miller wrote:
>
> I think that's just a partition transducer on the channel?
>
>
> On Wednesday, September 3, 2014 2:24:28 AM UTC-5, Ga
I think that's just a partition transducer on the channel?
On Wednesday, September 3, 2014 2:24:28 AM UTC-5, Gary Verhaegen wrote:
>
> I'd use another channel on which I put vectors of the correct length, with
> an intermediate loop that takes from the first channel, accumulates until
> the vec
On Wed, Sep 3, 2014 at 11:31 AM, cig wrote:
> Thanks Timothy, that makes sense.
>
> A follow on question if you don't mind.
>
> I would like to 'take' n items off of a channel, but wait until n items are
> available rather than eagerly returning the way take does. Do you have any
> ideas on how
>
I'd use another channel on which I put vectors of the correct length, with
an intermediate loop that takes from the first channel, accumulates until
the vector has the right size, and then put the vector on the second
channel.
There might be a better solution with transducers, though. (Or without.
Thanks Timothy, that makes sense.
A follow on question if you don't mind.
I would like to 'take' n items off of a channel, but wait until n items are
available rather than eagerly returning the way take does. Do you have any
ideas on how
I could achieve this?
On Tuesday, 2 September 2014 22:23
It's because into is pulling items as fast as it can from take. Sure the
buffer might get full but then into takes another value allowing take to
continue.
Timothy
On Tue, Sep 2, 2014 at 1:48 PM, cig wrote:
> Hi
>
> I was expecting the following example to park, waiting for the 'out'
> channel
Hi
I was expecting the following example to park, waiting for the 'out'
channel to be cleared. Could anybody explain why 'take' does not
park when the output buffer size is smaller than the number of entries
being taken from the input channel?
(def from (to-chan [1 2 3 4 5 6 7]))
( [1 2 3 4]
12 matches
Mail list logo
