This project forked from meiersi/blaze-builder
Efficient serialization of Haskell values to lazy bytestrings with a large average chunk size.
Home Page: http://jaspervdj.be/blaze
License: Other
still points at meiersi
I am unable to test with newer GHC candidate releases because this package doesn't work with the Monoid/Semigroup proposal. I notice the code got merged, but there has been no subsequent release. Any chance you could fix that? Thanks!
When splitting the output of chunkedTransferEncoding into strict bytestrings, the result usually looks somewhat like this:
λ> import qualified Data.ByteString as S
λ> import qualified Data.ByteString.Lazy as L
λ> import qualified Data.ByteString.Builder as B
λ> import Blaze.ByteString.Builder.HTTP
λ> f n = L.toChunks . B.toLazyByteString . chunkedTransferEncoding . B.byteString $ S.replicate n 95
λ> f 12
["00C\r\n____________\r\n"]
Each bytestring forms a complete chunk in the sense of RFC 7230 Section 4.1. From this observation I got the assumption that the 1-to-1 correspondence between bytestrings in the output and transfer chunks should be an invariant of chunkedTransferEncoding.
As I found out during some property testing that (supposed) invariant doesn't hold for certain larger inputs – the smallest "monolithic" input breaking it being a bytestring of length 8161:
λ> f 8161
["1FE1\r\n","___<snip>___","\r\n"]
In other tests I also found chunks like this:
...___", "\r\n2276\r\n___...
So my question is: Is this supposed to be an invariant of chunkedTransferEncoding?
(Ping @meiersi, who wrote chunkedTransferEncoding)
Attempting to compile with GHC 9.2 alpha-2 (and --allow-newer) gives this error:
[ 9 of 11] Compiling Blaze.ByteString.Builder.HTTP ( Blaze/ByteString/Builder/HTTP.hs, dist/build/Blaze/ByteString/Builder/HTTP.o, dist/build/Blaze/ByteString/Builder/HTTP.dyn_o )
Blaze/ByteString/Builder/HTTP.hs:52:36: error:
• Couldn't match expected type ‘Word32#’ with actual type ‘Word#’
• In the first argument of ‘W32#’, namely
‘(w `uncheckedShiftRL#` i)’
In the expression: W32# (w `uncheckedShiftRL#` i)
In an equation for ‘shiftr_w32’:
shiftr_w32 (W32# w) (I# i) = W32# (w `uncheckedShiftRL#` i)
|
52 | shiftr_w32 (W32# w) (I# i) = W32# (w `uncheckedShiftRL#` i)
| ^^^^^^^^^^^^^^^^^^^^^^^^^
See migration guide at https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.2.
fromHtmlEscapedString in 0.4 strips out '\DEL' as well as ASCII control characters, whereas the same function from 0.3 leaves them in.
e.g. with blaze-builder-0.3.3.2
ghci> toLazyByteString (fromHtmlEscapedString "\DEL<foobar>\STX")
"\DEL<foobar>\STX"
with blaze-builder-0.4.0.0
ghci> toLazyByteString (fromHtmlEscapedString "\DEL<foobar>\STX")
"<foobar>"
Possible fixes would be to 1) release a revision of the 0.3 series that also strips out control characters, 2) adjust 0.4 so that it doesn't, or 3) leave it as-is.
It certainly is my intention that 0.4 be semantically identical to 0.3, but I am curious what the correct behavior should be here with regards to html escaping, and how much trouble this discrepancy will actually cause. Control characters aren't kosher in HTML, but I don't know if they can actually lead to security vulnerabilities. Similarly, this discrepancy does cause problems with blaze-markup's test suite, but I don't know if it'll cause any trouble in "real" applications.
http://hackage.haskell.org/package/bytestring-0.11.0.0/changelog
I suspect that bumping the bounds would be sufficient, but I haven't checked.
Maintenance moved to https://github.com/blaze-builder/blaze-builder.
Please open issues and pull requests there.
You often have ByteString data that is already properly (e.g., utf-8) encoded, that you want to include in HTML. Currently, the only way to do this properly is to decode back to Text/String, and then encode to HTML. However, it can be done directly and more efficiently by just doing HTML entity encoding on special characters and leaving the existing encoding (for 8-bit characters). For example:
https://github.com/databrary/databrary/blob/master/Blaze/ByteString/Builder/Html/Word.hs
Does this seem reasonable? I'm happy to properly comment and clean this up and and submit a PR if so.
https://github.com/lpsmith/blaze-builder/blob/5d05dc8f36a0cf903325a4f6031a475560d6a75e/CHANGES lists versions that have not been tagged, e.g. 0.4.2.0 and 0.4.1.0. These are not listed under https://github.com/lpsmith/blaze-builder/releases.
The constraints were tightened in 8509ed5, however cabal is allowed to and will in fact happily backtrack to the more permissive blaze-builder-0.4.0.0 release, unless you tighten the lower bound on
http://hackage.haskell.org/package/blaze-builder-0.4.0.0/blaze-builder.cabal/edit
accordingly to force the solver to honor the lower bounds for GHC 7.8
Here's an example of cabal selecting the undesired combination (since the meta-data allows it):
$ cabal install -v2 blaze-builder --constraint 'bytestring < 0.10.4' --dry
Using a sandbox located at /tmp/sb/.cabal-sandbox
/home/hvr/.cabal/bin/alex --version
/home/hvr/.cabal/bin/c2hs --numeric-version
/home/hvr/.cabal/bin/cpphs --version
/usr/bin/gcc -dumpversion
/opt/ghc/7.8.4/bin/haddock --version
/home/hvr/.cabal/bin/happy --version
/opt/ghc/7.8.4/bin/hpc version
looking for tool hsc2hs near compiler in /opt/ghc/7.8.4/bin
found hsc2hs in /opt/ghc/7.8.4/bin/hsc2hs
/opt/ghc/7.8.4/bin/hsc2hs --version
/home/hvr/.cabal/bin/HsColour -version
/opt/ghc/7.8.4/bin/ghc -c /tmp/16816927771714636915.c -o /tmp/1957747793424238335.o
/usr/bin/ld -x -r /tmp/1957747793424238335.o -o /tmp/7198853861649760492.o
/usr/bin/pkg-config --version
/bin/tar --help
Reading available packages...
Reading installed packages...
/opt/ghc/7.8.4/bin/ghc-pkg dump '--package-db=/tmp/sb/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d' -v0
/opt/ghc/7.8.4/bin/ghc --print-libdir
Found no modified add-source deps.
Reading available packages...
Choosing modular solver.
Resolving dependencies...
In order, the following would be installed:
bytestring-0.10.2.0 (latest: 0.10.6.0) (new version)
text-1.0.0.1 (latest: 1.2.0.4) (new package)
blaze-builder-0.4.0.0 (latest: 0.4.0.1) (new package)
If you have any questions, please ask
Is this repo the place for active development of https://hackage.haskell.org/package/blaze-builder ? (I think so, but I am not entirely sure.)
I am waiting for feedback on
If help with maintenance is needed, I am hereby volunteering, for jobs such as CI and compatibility with new GHCs.
I think a version compatible with GHC 9.2 should be released in good time, so that blaze-builder is ready when GHC 9.2 is released.
Good morning,
The description of the package on Hackage does not say what this implementation of the package does, it references the old package instead. This makes me confused. :/
I’m currently testing GHC 8.4.1, and blaze-builder-0.4.0.2 failed to compile, with the following errors:
[ 1 of 10] Compiling Blaze.ByteString.Builder.Internal.Write ( Blaze/ByteString/Builder/Internal/Write.hs, dist/build/Blaze/ByteString/Builder/Internal/Write.o )
Blaze/ByteString/Builder/Internal/Write.hs:122:10: error:
• No instance for (Semigroup Poke)
arising from the superclasses of an instance declaration
• In the instance declaration for ‘Monoid Poke’
|
122 | instance Monoid Poke where
| ^^^^^^^^^^^
Blaze/ByteString/Builder/Internal/Write.hs:132:10: error:
• No instance for (Semigroup Write)
arising from the superclasses of an instance declaration
• In the instance declaration for ‘Monoid Write’
|
132 | instance Monoid Write where
| ^^^^^^^^^^^^
Since I do not know the library or its intended functionality, I can not write a patch.
It seems clear though, that Poke and Write need to become part of Semigroup, to become part of Monoid.
I'm citing from https://hydra.nixos.org/build/77799382:
Tests:
left identity Monoid law: [OK, passed 100 tests]
right identity Monoid law: [OK, passed 100 tests]
associativity Monoid law: [OK, passed 100 tests]
mconcat Monoid law: [OK, passed 100 tests]
string → builder → string: [Failed]
*** Failed! Falsifiable (after 95 tests and 6 shrinks):
"\65534"
(used seed -6505924182177918303)
string and text: [OK, passed 100 tests]
lazy bytestring identity: [OK, passed 100 tests]
flushing identity: [OK, passed 100 tests]
writeToByteString: [OK, passed 100 tests]
escaping case 1: [OK]
escaping case 2: [OK]
escaping case 3: [OK]
Properties Test Cases Total
Passed 8 3 11
Failed 1 0 1
Total 9 3 12
Test suite test: FAIL
Test suite logged to: dist/test/blaze-builder-0.4.1.0-test.log
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.