[Haskell-cafe] Yet another Conduit question

[Kevin Quick]

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
>>
>> 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
>>
>>
>>
>> --
>> Felipe.
>>


-- 
-KQ