Lazy +Data.ByteString

module Data.ByteString.Lazy
bytestring Data.ByteString.Lazy
A time and space-efficient implementation of lazy byte vectors using lists of packed Word8 arrays, suitable for high performance use, both in terms of large data quantities, or high speed requirements. Lazy ByteStrings are encoded as lazy lists of strict chunks of bytes. A key feature of lazy ByteStrings is the means to manipulate large or unbounded streams of data without requiring the entire sequence to be resident in memory. To take advantage of this you have to write your functions in a lazy streaming style, e.g. classic pipeline composition. The default I/O chunk size is 32k, which should be good in most circumstances. Some operations, such as concat, append, reverse and cons, have better complexity than their Data.ByteString equivalents, due to optimisations resulting from the list spine structure. For other operations lazy ByteStrings are usually within a few percent of strict ones. The recomended way to assemble lazy ByteStrings from smaller parts is to use the builder monoid from Data.ByteString.Lazy.Builder. This module is intended to be imported qualified, to avoid name clashes with Prelude functions. eg. > import qualified Data.ByteString.Lazy as B Original GHC implementation by Bryan O'Sullivan. Rewritten to use UArray by Simon Marlow. Rewritten to support slices and use ForeignPtr by David Roundy. Rewritten again and extended by Don Stewart and Duncan Coutts. Lazy variant by Duncan Coutts and Don Stewart.
package LazyVault
package
LazyVault is a sandboxing tool to install libraries and executables with a sandboxed environment. At the moment it's only supported under Unix or Gnu Systems. This package has only been tested under Gnu/Linux however. This program creates cabal sandboxes which you can use globally. For a detailed explaination on how this works refer to the README file found on the github page. Version 0.0.1
package lazy-csv
package
The CSV format is defined by RFC 4180. These efficient lazy parsers (String and ByteString variants) can report all CSV formatting errors, whilst also returning all the valid data, so the user can choose whether to continue, to show warnings, or to halt on error.  Valid fields retain information about their original location in the input, so a secondary parser from textual fields to typed values can give intelligent error messages. Version 0.5
package lazy-io
package
The library provides some basic but useful lazy IO functions. Keep in mind that lazy IO is generally discouraged. Perhaps a coroutine library (e.g. pipes) will better suit your needs. Version 0.1.0
package lazyarray
package
This package built on standard array package adds support for lazy monolithic arrays. Such arrays are lazy not only in their values, but in their indexes as well. Read the paper "Efficient Graph Algorithms Using Lazy Monolithic Arrays" (http://citeseer.ist.psu.edu/95126.html) for further details. Version 0.1.3
lazyByteString :: ByteString -> Builder
bytestring Data.ByteString.Builder
Create a Builder denoting the same sequence of bytes as a lazy ByteString. The Builder inserts large chunks of the lazy ByteString directly, but copies small ones to ensure that the generated chunks are large on average.
lazyByteStringCopy :: ByteString -> Builder
bytestring Data.ByteString.Builder.Extra
Construct a Builder that copies the lazy ByteString.
lazyByteStringHex :: ByteString -> Builder
bytestring Data.ByteString.Builder
Encode each byte of a lazy ByteString using its fixed-width hex encoding.
lazyByteStringInsert :: ByteString -> Builder
bytestring Data.ByteString.Builder.Extra
Construct a Builder that inserts all chunks of the lazy ByteString directly.
lazyByteStringThreshold :: Int -> ByteString -> Builder
bytestring Data.ByteString.Builder.Extra
Construct a Builder that uses the thresholding strategy of byteStringThreshold for each chunk of the lazy ByteString.
package lazyio
package
Run IO actions lazily while respecting their order. Running a value of the LazyIO monad in the IO monad is like starting a thread which is however driven by its output. That is, the LazyIO action is only executed as far as necessary in order to provide the required data. Version 0.0.3.2
package lazysmallcheck
package
Lazy SmallCheck is a library for exhaustive, demand-driven testing of Haskell programs.  It is based on the idea that if a property holds for a partially-defined input then it must also hold for all fully-defined refinements of the that input.  Compared to ``eager'' input generation as in SmallCheck, Lazy SmallCheck may require significantly fewer test-cases to verify a property for all inputs up to a given depth. Version 0.6
package lazysplines
package
See the source of Numeric.LazySplines.Examples for usage. Version 0.1
package MonadRandomLazy
package
Support for lazy computations which consume random values. Version 0.1
package NumLazyByteString
package
Num, Enum, Eq, Integral, Ord, Real, and Show instances for Lazy ByteStrings Version 0.0.0.1
primMapLazyByteStringBounded :: BoundedPrim Word8 -> ByteString -> Builder
bytestring Data.ByteString.Builder.Prim
Chunk-wise application of primMapByteStringBounded.
primMapLazyByteStringFixed :: FixedPrim Word8 -> (ByteString -> Builder)
bytestring Data.ByteString.Builder.Prim
Heavy inlining. Encode all bytes of a lazy ByteString from left-to-right with a FixedPrim.
package safe-lazy-io
package
Provides a safer API for incremental IO processing in a way very close to standard lazy IO. Version 0.1
toLazyByteString :: Builder -> ByteString
bytestring Data.ByteString.Builder
Execute a Builder and return the generated chunks as a lazy ByteString. The work is performed lazy, i.e., only when a chunk of the lazy ByteString is forced.
toLazyByteStringWith :: AllocationStrategy -> ByteString -> Builder -> ByteString
bytestring Data.ByteString.Builder.Extra
Execute a Builder with custom execution parameters. This function is forced to be inlined to allow fusing with the allocation strategy despite its rather heavy code-size. We therefore recommend that you introduce a top-level function once you have fixed your strategy. This avoids unnecessary code duplication. For example, the default Builder execution function toLazyByteString is defined as follows. > {--} > toLazyByteString = > toLazyByteStringWith (safeStrategy smallChunkSize defaultChunkSize) empty In most cases, the parameters used by toLazyByteString give good performance. A sub-performing case of toLazyByteString is executing short (<128 bytes) Builders. In this case, the allocation overhead for the first 4kb buffer and the trimming cost dominate the cost of executing the Builder. You can avoid this problem using > toLazyByteStringWith (safeStrategy 128 smallChunkSize) empty This reduces the allocation and trimming overhead, as all generated ByteStrings fit into the first buffer and there is no trimming required, if more than 64 bytes are written.

Show more results