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 <qu...@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 <mich...@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.le...@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 <si...@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@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@haskell.org > http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
