[Haskell-cafe] Yet another Conduit question

[Michael Snoyman]

Hmm, that's an interesting trick. I can't say that I ever thought bracketP
would be used in that way. The only change I might recommend is using
addCleanup[1] instead, which doesn't introduce the MonadResource constraint.

Michael

[1]
http://haddocks.fpcomplete.com/fp/7.4.2/2012-12-11/conduit/Data-Conduit-Internal.html#v:addCleanup


On Mon, Feb 4, 2013 at 4:37 PM, Kevin Quick <quick at sparq.org> wrote:

> While on the subject of conduits and timing, I'm using the following
> conduit to add elapsed timing information:
>
> timedConduit :: MonadResource m => forall l o u . Pipe l o o u m (u,
> NominalDiffTime)
> timedConduit = bracketP getCurrentTime (\_ -> return ()) inner
>     where inner st = do r <- awaitE
>                         case r of
>                           Right x -> yield x >> inner st
>                           Left  r -> deltaTime st >>= \t -> return (r,t)
>           deltaTime st = liftIO $ flip diffUTCTime st <$> getCurrentTime
>
> I'm aware that this is primarily timing the downstream (and ultimately the
> Sink) more than the upstream, and I'm using the bracketP to attempt to
> delay the acquisition of the initial time (st) until the first downstream
> request for data.
>
> I would appreciate any other insights regarding concerns, issues, or
> oddities that I might encounter with the above.
>
> Thanks,
>   Kevin
>
>
> On Mon, 04 Feb 2013 02:25:11 -0700, Michael Snoyman <michael at snoyman.com>
> wrote:
>
>  I think this is probably the right approach. However, there's something
>> important to point out: flushing based on timing issues must be handled
>> *outside* of the conduit functionality, since by design conduit will not
>> allow you to (for example) run `await` for up to a certain amount of time.
>> You'll probably need to do this outside of your conduit chain, in the
>> initial Source. It might look something like this:
>>
>> yourSource = do
>>     mx <- timeout somePeriod myAction
>>     yield $ maybe Flush Chunk mx
>>     yourSource
>>
>>
>> On Sun, Feb 3, 2013 at 5:06 PM, Felipe Almeida Lessa <
>> felipe.lessa at gmail.com
>>
>>> wrote:
>>>
>>
>>  I guess you could use the Flush datatype [1] depending on how your
>>> data is generated.
>>>
>>> Cheers,
>>>
>>> [1]
>>> http://hackage.haskell.org/**packages/archive/conduit/0.5.**
>>> 4.1/doc/html/Data-Conduit.**html#t:Flush<http://hackage.haskell.org/packages/archive/conduit/0.5.4.1/doc/html/Data-Conduit.html#t:Flush>
>>>
>>> On Fri, Feb 1, 2013 at 6:28 AM, Simon Marechal <simon at banquise.net>
>>> wrote:
>>> > On 01/02/2013 08:21, Michael Snoyman wrote:
>>> >> So you're saying you want to keep the same grouping that you had
>>> >> originally? Or do you want to batch up a certain number of results?
>>> >> There are lots of ways of approaching this problem, and the types
>>> don't
>>> >> imply nearly enough to determine what you're hoping to achieve here.
>>> >
>>> > Sorry for not being clear. I would like to group them "as much as
>>> > possible", that is up to a certain limit, and also within a "time
>>> > threshold". I believe that the conduit code will be called only when
>>> > something happens in the conduit, so an actual timer would be useless
>>> > (unless I handle this at the source perhaps, and propagate "ticks").
>>> >
>>> > That is why in my first message I talked about stacking things into the
>>> > list until the conduit has no more input available, or a maximum size
>>> is
>>> > reached, but was not sure this even made sense.
>>> >
>>> > ______________________________**_________________
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe at haskell.org
>>> > http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>>>
>>>
>>>
>>> --
>>> Felipe.
>>>
>>>
>
> --
> -KQ
>
>
> ______________________________**_________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130204/7444f48f/attachment.htm>