Fix CI

[int-index]

also fixes #142

[int-index]

I fixed CI errors that caused master and some of the other PRs to fail sometimes. cc @kolmodin please review/merge?

[int-index]

Note that the benchmark already depended on generic-deriving transitively. That's what caused one of the problems, as both generic-deriving and GenericsBenchTypes used to define instance Generic Version.

[kolmodin]

This is good and non-obvious info, please add that as a comment in the file.
And add how exactly we already depend on generic-deriving, which package depends on it?

[int-index]

criterion depends on it via aeson.

[int-index]

ping @kolmodin

I would appreciate if you could merge this so I'd be able to adapt #148 for older compilers.

[kolmodin]

Hey! I'll take a look within a few days. Thanks a lot for fixing this!

[kolmodin]

Hmm. Maybe we should just install CABALVER=1.24 right away instead of upgrading later.
I can't remember why I made it install an older version (the one shipped with Haskell Platform, iirc) and then upgrade it.

So instead of adding CABALUPGR, does it work to just change CABALVER?

[int-index]

Alright, let me see.

[int-index]

Nope, errors out https://travis-ci.org/kolmodin/binary/builds/388723151

[int-index]

I can't remember why I made it install an older version (the one shipped with Haskell Platform, iirc) and then upgrade it.

The version of cabal-install actually doesn't matter, it's about the version of Cabal the lib that is shipped with GHC.

[int-index]

I decided to also add GHC 8.2 and 8.4 to CI — now the problem is that Cabal 1.24.* which is needed for the benchmark doesn't work on 8.4, and the benchmark doesn't work with Cabal 2.2.*

My plan is to copy-paste (or "vendor" to use the modern jargon) some bits of Cabal 1.24.* to the benchmark so it's no longer a dependency of binary. This will significantly simplify the CI script and lead to more reproducible benchmark results.

[int-index]

Turns out copying the entire Cabal parser requires more patience than I have. However, maybe instead of getting rid of a Cabal dep I can loosen it up and allow more versions than 1.24.* by copying only type definitions and writing a conversion module.

[kolmodin]

Ah, now I recall, it's part of the benchmark suite.
IIRC I adapted something that @dcoutts had done and used that as part of the benchmark suite.
However, since Cabal keeps changing this stuff keeps breaking in binary. Better would be to use code that didn't change, something we could include in the binary repository. We have no interest in the Cabal format in particular, just need something to benchmark.

What are some candidates for benchmarking binary? Cabal was good because it's real world code. Maybe good to write some custom code to try parsing trees, lists, small and large structs.

[int-index]

However, since Cabal keeps changing this stuff keeps breaking in binary. Better would be to use code that didn't change, something we could include in the binary repository. We have no interest in the Cabal format in particular, just need something to benchmark.

Cabal was good because it's real world code.

I found a way to have our cake and eat it too: instead of depending on Cabal, I copied data types from it (only 360 lines) and committed a compressed Hackage index to the repo. The benchmark reads the data from this file. This gives us a benchmark with real world code and real world data.

I also added comments explaining the difference between the current solution and the old one.

Unfortunately, I couldn't get rid of CABALUPGR — a newer Cabal lib is needed by criterion.

[kolmodin]

Ok, that looks like a good trade off.

Thanks for doing this!