streaming-bytestring 0.1.0.6 → 0.1.0.7
raw patch · 1 files changed
+46/−19 lines, 1 filesdep +bytestring-builderdep ~basedep ~bytestringdep ~streaming
Dependencies added: bytestring-builder
Dependency ranges changed: base, bytestring, streaming
Files
- streaming-bytestring.cabal +46/−19
streaming-bytestring.cabal view
@@ -1,6 +1,6 @@ name: streaming-bytestring-version: 0.1.0.6-synopsis: effectful byte steams, or: lazy bytestring done right+version: 0.1.0.7+synopsis: effectful byte steams, or: bytestring io done right description: This is an implementation of effectful, memory-constrained bytestrings (byte streams) and functions for streaming @@ -23,16 +23,17 @@ <https://groups.google.com/forum/#!forum/haskell-pipes pipes list>. . A tutorial module is in the works; - <https://gist.github.com/michaelt/6c6843e6dd8030e95d58 here> + <https://gist.github.com/michaelt/6c6843e6dd8030e95d58 here>,+ for the moment, is a sequence of simplified implementations of familiar shell utilities. - It closely follows those at the end of the+ The same programs are implemented at the end of the excellent <http://hackage.haskell.org/package/io-streams-1.3.2.0/docs/System-IO-Streams-Tutorial.html io-streams tutorial>. It is generally much simpler; in some case simpler than what you would write with lazy bytestrings. <https://gist.github.com/michaelt/2dcea1ba32562c091357 Here> is a simple GET request that returns a byte stream. .- The implementation follows the+ The implementation is idiot-simple; it follows the details of @Data.ByteString.Lazy@ and @Data.ByteString.Lazy.Char8@ as far as is possible, replacing the lazy bytestring type: .@@ -66,9 +67,10 @@ 'hGetContents' and the like follows @Data.ByteString.Lazy@ and operations like @lines@ and @append@ and so on are tailored not to increase chunk size. .- It is natural to think that - the direct, naive, monadic formulation of such a type - would necessarily make things much slower. This appears to be a prejudice. + The present library is thus nothing but /lazy bytestring done right/. + The authors of @Data.ByteString.Lazy@ must have supposed that + the directly monadic formulation of such their type + would necessarily make things slower. This appears to be a prejudice. For example, passing a large file of short lines through this benchmark transformation .@@ -83,12 +85,13 @@ > $ time ./benchlines streaming >> /dev/null > real 0m1.930s .- More typical, perhaps, are the results for the more - sophisticated operation + For a more sophisticated operation like . > Lazy.intercalate "!\n" . Lazy.lines > Streaming.intercalate "!\n" . Streaming.lines .+ we get results like these:+ . > time ./benchlines lazy >> /dev/null > real 0m1.250s > ...@@ -104,15 +107,28 @@ > time ./benchlines pipes >> /dev/null > real 0m6.353s .- The difference is not intrinsic to pipes, but is mostly that + The difference, however, is emphatically not intrinsic to pipes; + it is just that this library depends the @streaming@ library, which is used in place - of @free@ to express the (streaming) splitting and division of byte streams. - Those elementary concepts are catastrophically mishandled in the streaming io libraries + of @free@ to express the + <http://www.haskellforall.com/2013/09/perfect-streaming-using-pipes-bytestring.html "perfectly streaming">+ splitting and iterated division or "chunking" of byte streams. + .+ These concepts belong to the ABCs of streaming; @lines@ is just+ a textbook example, and it is of course handled correctly in + @Data.ByteString.Lazy@.+ But the concepts are catastrophically mishandled in the streaming io libraries other than pipes. Already the @enumerator@ and @iteratee@ libraries- were completely defeated by it: see e.g. the @enumerator@ implementation of + were completely defeated by @lines@: + see e.g. the @enumerator@ implementation of <http://hackage.haskell.org/package/enumerator-0.4.20/docs/Data-Enumerator-Text.html#v:splitWhen splitWhen and lines>. This will concatenate strict text forever, if that's what is coming- in. It becomes torture to express elementary distinctions. + in. The rot spreads from there. + It is just a fact that in all of the general streaming io + frameworks other than pipes, + it becomes torture to express elementary distinctions + that are transparently+ and immediately contained in any idea of streaming whatsoever. . Though we barely alter signatures in @Data.ByteString.Lazy@ more than is required by the types, @@ -152,6 +168,10 @@ extra-source-files: ChangeLog.md cabal-version: >=1.10 +flag use-bytestring-builder+ description: Use bytestring-builder package+ default: False+ library exposed-modules: Data.ByteString.Streaming , Data.ByteString.Streaming.Char8@@ -160,14 +180,21 @@ -- other-modules: other-extensions: CPP, BangPatterns, ForeignFunctionInterface, DeriveDataTypeable, Unsafe- build-depends: base >=4.7 && <4.9- , bytestring >=0.10 && <0.11+ build-depends: base <4.9+ , bytestring , deepseq , mtl >=2.1 && <2.3 , mmorph >=1.0 && <1.2 , transformers >=0.3 && <0.5- , streaming > 0.1.0.8 && < 0.1.1-+ , streaming > 0.1.0.15 && < 0.1.1+ + if flag(use-bytestring-builder)+ build-depends: bytestring < 0.10.2.0+ , bytestring-builder+ else+ build-depends: bytestring >= 0.10.2.0 -- hs-source-dirs: default-language: Haskell2010 ghc-options: -O2+ +