Daniel,
Thank you very much, I will definitely give it a try!
Cheers,
Alexey.
On Tuesday, August 25, 2015 at 4:29:41 PM UTC+10, Daniel Díaz wrote:
>
> Hi Alexey,
>
> > I need to group elements differently in each branch. I wouldn't be able
> to use pipes-groups here because it gives me function
Hi Alexey,
> I need to group elements differently in each branch. I wouldn't be able
to use pipes-groups here because it gives me functions of Producers, not
Pipes.
> - due to grouping my branches would emit at different rates and not for
every input element.
I have uploaded foldl-transduce
I think you might end up having to do the two `Fold`s which each return
a `Maybe`. I don't know a more elegant way of decomposing the problem.
On 8/23/2015 3:51 PM, Alexey Raga wrote:
Thanks, Gabriel!
You are right, I don't need any concurrency, I just wanted to use it
for the ability to br
Thanks, Gabriel!
You are right, I don't need any concurrency, I just wanted to use it for
the ability to broadcast producers.
I actually was looking at Fold, but I couldn't figure out how it could work
for the following requirements :
- I need to group elements differently in each branch. I woul
The general rule of thumb is that you should only use concurrency for
two reasons:
* Increased performance (and only if the increase offsets the context
switching)
* Waiting on multiple concurrent input streams
Generally you should try to avoid using concurrency just as a control
flow mechan
Hi,
I am using "pipes-concurrency" trying to model the following scenario: my
"source" pipe has type of
stream :: Producer InputData (StateT References IO) ()
where "References" is just a map that I accumulate while streaming the
source. Then I am following the "broadcast" example from t
