GitLab

Bump version to 0.8.0.0

As suggested at https://github.com/hvr/multi-ghc-travis, reduce the
effect of bug https://ghc.haskell.org/trac/ghc/ticket/9221.

This is so that we can write and read things like [Void], or (Expr Void)
- something I'm actually doing in Morte.

https://github.com/Gabriel439/Haskell-Morte-Library/pull/26

The reader always fails if you actually try to get an instance of it.
Trying to access a void value should not happen for well-formed
instances, for example:

    *Data.Binary Data.Void> decode $ encode ([] :: [Void]) :: [Void]
    []

Optimize roll by using foldl' instead of foldr

The "roll" benchmarks in the get executable show the difference:

  get roll
  benchmarking roll/foldr
  time                 547.4 ms   (537.8 ms .. 553.5 ms)
                       1.000 R²   (1.000 R² .. 1.000 R²)
  mean                 549.4 ms   (547.2 ms .. 550.4 ms)
  std dev              1.857 ms   (0.0 s .. 1.896 ms)
  variance introduced by outliers: 19% (moderately inflated)

  benchmarking roll/foldl'
  time                 434.7 ms   (426.4 ms .. 443.1 ms)
                       1.000 R²   (1.000 R² .. 1.000 R²)
  mean                 433.7 ms   (432.3 ms .. 434.7 ms)
  std dev              1.472 ms   (0.0 s .. 1.696 ms)
  variance introduced by outliers: 19% (moderately inflated)

The "Integer/decode" benchmark shows the actual decoding speed.
First the old implementation based on foldr:

  get Integer/decode
  benchmarking Integer/decode
  time                 552.9 ms   (540.2 ms .. 569.3 ms)
                       1.000 R²   (1.000 R² .. 1.000 R²)
  mean                 558.2 ms   (556.1 ms .. 559.3 ms)
  std dev              1.824 ms   (0.0 s .. 1.906 ms)
  variance introduced by outliers: 19% (moderately inflated)

The new implementation based on foldl':

  get Integer/decode
  benchmarking Integer/decode
  time                 457.5 ms   (406.2 ms .. 505.6 ms)
                       0.998 R²   (0.994 R² .. 1.000 R²)
  mean                 455.9 ms   (448.3 ms .. 462.3 ms)
  std dev              10.11 ms   (0.0 s .. 11.02 ms)
  variance introduced by outliers: 19% (moderately inflated)

The benchmark executes 25% faster, time which could not be attribute to
the speed of binary itself.

Due to the dependency cycle we need to manually preinstall all deps
before we attempt to configure/build binary.

We use Cabal's PackageDescription as the type to serialize. It is large,
has many levels of data types, and also uses enums and strings. It's a
good stress test.

GenericsBench defines criterion benchmarks for serialization and
deserialization.

In GenericsBenchTypes we derive the Binary instances. PackageDescription
already defines Binary instances for the system installed Binary, but
naturally this won't work for the benchmark - we need our own instances
that are derived from the code in this library.

The data to serialize we get from your
.cabal/package/hackage.haskell.org/ directory, it's data from hackage,
not autogenerated.
GenericsBenchCache makes sure that if we rerun the benchmark we will use
the same PackageDescriptions, even if the user has executed
'cabal update' since the last benchmark run.

Previously we had several non-allocating benchmarks.
They were not representative to the most common use case where we want
to save all the decoded input, not just a fraction.
This patch updates the benchmark to save the decoded input in lists.

The warnings are like this;
Rule "getWord16le/readN" may never fire
  because ‘getWord16le’ might inline first

The RULES do the same thing as the inlining, so either one is fine.
Specifying a phase removes the warning.

RULE:
  append flush flush = flush

Don't mark modules using bytestring as safe on GHC 7.2 to fix compilation

Should fix issue #80.

Fix AMP and Safe Haskell related warnings in GHC 7.10.

This silences a GHC 7.10 warning that indicates that these modules are
marked trustworthy when in fact they don't need to, since they are safe.

'forAll' needs Fingerprint to have a Show instance.
Starting from GHC 7.8 (base-4.7) Fingerprint has a Show instance, but
for older versions we need to provide one ourselves.

The two fields are unpacked, so this saves a couple of words per field
until the Fingerprint value gets used.