-- Hoogle documentation, generated by Haddock
-- See Hoogle, http://www.haskell.org/hoogle/


-- | Conduit-based algorithms
--   
--   Algorithms on Conduits, including higher level asynchronous processing
--   and some other utilities.
@package conduit-algorithms
@version 0.0.8.0


-- | Higher level async processing interfaces.
module Data.Conduit.Algorithms.Storable

-- | write a Storable vector
--   
--   This uses the same format as in-memory
--   
--   See <a>readStorableV</a>
writeStorableV :: forall m a. (MonadIO m, Monad m, Storable a) => Conduit (Vector a) m ByteString

-- | read a Storable vector
--   
--   This expects the same format as the in-memory vector
--   
--   See <a>writeStorableV</a>
readStorableV :: forall m a. (MonadIO m, Storable a) => Int -> ConduitM ByteString (Vector a) m ()


-- | A few miscellaneous conduit utils
module Data.Conduit.Algorithms.Utils

-- | Act on the next input (do nothing if no input). <tt>awaitJust f</tt>
--   is equivalent to
--   
--   <pre>
--   do
--        next &lt;- C.await
--        case next of
--            Just val -&gt; f val
--            Nothing -&gt; return ()
--   </pre>
--   
--   This is a simple utility adapted from
--   <a>http://neilmitchell.blogspot.de/2015/07/thoughts-on-conduits.html</a>
awaitJust :: Monad m => (a -> Conduit a m b) -> Conduit a m b

-- | Conduit analogue to Python's enumerate function
enumerateC :: Monad m => Conduit a m (Int, a)

-- | groupC yields the input as groups of <tt>n</tt> elements. If the input
--   is not a multiple of <tt>n</tt>, the last element will be incomplete
--   
--   Example:
--   
--   <pre>
--   CC.yieldMany [0..10] .| groupC 3 .| CC.consumeList
--   </pre>
--   
--   results in <tt>[ [0,1,2], [3,4,5], [6,7,8], [9, 10] ]</tt>
--   
--   This function is deprecated; use <a>chunksOf</a>
groupC :: (Monad m) => Int -> Conduit a m [a]


-- | Higher level async processing interfaces.
module Data.Conduit.Algorithms.Async

-- | If the filename indicates a gzipped file (or, on Unix, also a bz2
--   file), then it reads it and uncompresses it.
--   
--   On Windows, attempting to read from a bzip2 file, results in
--   <a>error</a>.
--   
--   For the case of gzip, <a>asyncGzipFromFile</a> is used.
conduitPossiblyCompressedFile :: (MonadUnliftIO m, MonadResource m, MonadThrow m) => FilePath -> Source m ByteString
conduitPossiblyCompressedToFile :: (MonadUnliftIO m, MonadResource m) => FilePath -> Sink ByteString m ()

-- | This is like <a>map</a>, except that each element is processed in a
--   separate thread (up to <tt>maxThreads</tt> can be queued up at any one
--   time). Results are evaluated to normal form (not weak-head normal
--   form!, i.e., the structure is deeply evaluated) to ensure that the
--   computation is fully evaluated in the worker thread.
--   
--   Note that there is some overhead in threading. It is often a good idea
--   to build larger chunks of input before passing it to <a>asyncMapC</a>
--   to amortize the costs. That is, when <tt>f</tt> is not a lot of work,
--   instead of <tt>asyncMapC f</tt>, it is sometimes better to do
--   
--   <pre>
--   CC.conduitVector 4096 .| asyncMapC (V.map f) .| CC.concat
--   </pre>
--   
--   where <tt>CC</tt> refers to <a>Combinators</a>
--   
--   See <a>unorderedAsyncMapC</a>
asyncMapC :: forall a m b. (MonadIO m, NFData b) => Int -> (a -> b) -> Conduit a m b

-- | <a>asyncMapC</a> with error handling. The inner function can now
--   return an error (as a <a>Left</a>). When the first error is seen, it
--   <a>throwError</a>s in the main monad. Note that <tt>f</tt> may be
--   evaluated for arguments beyond the first error (as some threads may be
--   running in the background and already processing elements after the
--   first error).
--   
--   See <a>asyncMapC</a>
asyncMapEitherC :: forall a m b e. (MonadIO m, NFData b, NFData e, MonadError e m) => Int -> (a -> Either e b) -> Conduit a m b

-- | A simple sink which performs gzip compression in a separate thread and
--   writes the results to <tt>h</tt>.
--   
--   See also <a>asyncGzipToFile</a>
asyncGzipTo :: forall m. (MonadIO m, MonadUnliftIO m) => Handle -> Sink ByteString m ()

-- | Compresses the output and writes to the given file with compression
--   being performed in a separate thread.
--   
--   See also <a>asyncGzipTo</a>
asyncGzipToFile :: forall m. (MonadResource m, MonadUnliftIO m) => FilePath -> Sink ByteString m ()

-- | A source which produces the ungzipped content from the the given
--   handle. Note that this "reads ahead" so if you do not use all the
--   input, the Handle will probably be left at an undefined position in
--   the file.
--   
--   See also <a>asyncGzipFromFile</a>
asyncGzipFrom :: forall m. (MonadIO m, MonadResource m, MonadUnliftIO m) => Handle -> Source m ByteString

-- | Open and read a gzip file with the uncompression being performed in a
--   separate thread.
--   
--   See also <a>asyncGzipFrom</a>
asyncGzipFromFile :: forall m. (MonadResource m, MonadUnliftIO m) => FilePath -> Source m ByteString

-- | A simple sink which performs bzip2 compression in a separate thread
--   and writes the results to <tt>h</tt>.
--   
--   See also <a>asyncGzipToFile</a>
asyncBzip2To :: forall m. (MonadIO m, MonadResource m, MonadUnliftIO m) => Handle -> Sink ByteString m ()

-- | Compresses the output and writes to the given file with compression
--   being performed in a separate thread.
--   
--   See also <a>asyncGzipTo</a>
asyncBzip2ToFile :: forall m. (MonadResource m, MonadUnliftIO m) => FilePath -> Sink ByteString m ()

-- | A source which produces the bzipped2 content from the the given
--   handle. Note that this "reads ahead" so if you do not use all the
--   input, the Handle will probably be left at an undefined position in
--   the file.
--   
--   See also <a>asyncGzipFromFile</a>
asyncBzip2From :: forall m. (MonadIO m, MonadResource m, MonadUnliftIO m) => Handle -> Source m ByteString

-- | Open and read a bzip2 file with the uncompression being performed in a
--   separate thread.
--   
--   See also <a>asyncGzipFrom</a>
asyncBzip2FromFile :: forall m. (MonadResource m, MonadUnliftIO m) => FilePath -> Source m ByteString

-- | A simple sink which performs lzma/xz compression in a separate thread
--   and writes the results to <tt>h</tt>.
--   
--   See also <a>asyncGzipToFile</a>
asyncXzTo :: forall m. (MonadIO m, MonadResource m, MonadUnliftIO m) => Handle -> Sink ByteString m ()

-- | Compresses the output and writes to the given file with compression
--   being performed in a separate thread.
--   
--   See also <a>asyncGzipTo</a>
asyncXzToFile :: forall m. (MonadResource m, MonadUnliftIO m) => FilePath -> Sink ByteString m ()

-- | A source which produces the unxzipped content from the the given
--   handle. Note that this "reads ahead" so if you do not use all the
--   input, the Handle will probably be left at an undefined position in
--   the file.
--   
--   See also <a>asyncGzipFromFile</a>
asyncXzFrom :: forall m. (MonadIO m, MonadResource m, MonadUnliftIO m, MonadThrow m) => Handle -> Source m ByteString

-- | Open and read a lzma/xz file with the uncompression being performed in
--   a separate thread.
--   
--   See also <a>asyncXzFrom</a>
asyncXzFromFile :: forall m. (MonadResource m, MonadUnliftIO m, MonadThrow m) => FilePath -> Source m ByteString

-- | A version of <a>asyncMapC</a> which can reorder results in the stream
--   
--   If the order of the results is not important, this function can lead
--   to a better use of resources if some of the chunks take longer to
--   complete.
--   
--   See <a>asyncMapC</a>
unorderedAsyncMapC :: forall a m b. (MonadIO m, NFData b) => Int -> (a -> b) -> Conduit a m b


-- | Higher level async processing interfaces for handling
--   <tt>ByteString</tt> objects.
module Data.Conduit.Algorithms.Async.ByteString

-- | Apply a function to groups of lines
--   
--   Note that this is much more efficient than the (more or less
--   equivalent, except that the intermediate lists can be of varying
--   sizes):
--   
--   <pre>
--   CB.lines .| CC.conduitVector N .| CAlg.asyncMapC nthreads (f . V.toList)
--   </pre>
--   
--   The reason being that splitting into lines then becomes the bottleneck
--   and processing a single line is typically a tiny chunk of work so that
--   the threading overhead overwhelms the advantage of using multiple
--   cores. Instead, <a>asyncMapLineGroupsC</a> will pass big chunks to the
--   worker thread and perform most of the line splitting _in the worker
--   thread_.
--   
--   Only Unix-style ASCII lines are supported (splitting at Bytes with
--   value 10, i.e., \n). When Windows lines (\r\n) are passed to this
--   function, this results in each element having an extra \r at the end.
asyncMapLineGroupsC :: (MonadIO m, NFData a) => Int -> ([ByteString] -> a) -> Conduit ByteString m a

-- | Filter lines using multiple threads
--   
--   It is not clear from the types but the input is taken to unbroken
--   lines, while the output will be yielded line by line. This conduit is
--   equivalent to
--   
--   <pre>
--   CB.lines .| CL.filer f
--   </pre>
asyncFilterLinesC :: MonadIO m => Int -> (ByteString -> Bool) -> Conduit ByteString m ByteString


-- | Simple algorithms packaged as Conduits
module Data.Conduit.Algorithms

-- | Unique conduit.
--   
--   For each element, it checks its key (using the <tt>a -&gt; b</tt> key
--   function) and yields it if it has not seen it before.
--   
--   Note that this conduit <i>does not</i> assume that the input is
--   sorted. Instead it uses a <a>Set</a> to store previously seen
--   elements. Thus, memory usage is O(N) and time is O(N log N). If the
--   input is sorted, you can use <a>removeRepeatsC</a>
uniqueOnC :: (Ord b, Monad m) => (a -> b) -> Conduit a m a

-- | Unique conduit
--   
--   See <a>uniqueOnC</a> and <a>removeRepeatsC</a>
uniqueC :: (Ord a, Monad m) => Conduit a m a

-- | Removes repeated elements
--   
--   <pre>
--   yieldMany [0, 0, 1, 1, 1, 2, 2, 0] .| removeRepeatsC .| consume
--   </pre>
--   
--   is equivalent to <tt>[0, 1, 2, 0]</tt>
--   
--   See <a>uniqueC</a> and <a>uniqueOnC</a>
removeRepeatsC :: (Eq a, Monad m) => Conduit a m a

-- | Merge a list of sorted sources to produce a single (sorted) source
--   
--   This takes a list of sorted sources and produces a <a>Source</a> which
--   outputs all elements in sorted order.
--   
--   See <a>mergeC2</a>
mergeC :: (Ord a, Monad m) => [Source m a] -> Source m a

-- | Take two sorted sources and merge them.
--   
--   See <a>mergeC</a>
mergeC2 :: (Ord a, Monad m) => Source m a -> Source m a -> Source m a
