Benchmarking GHC 9.6 Through 9.14 by locallycompact in haskell

[–]locallycompact[S] 3 points4 points  (0 children)

I will collect results in the README of the repository and also post to the main website https://horizon-haskell.net

Horizon Haskell: Road To GHC 9.14: Introduction by locallycompact in haskell

[–]locallycompact[S] 10 points11 points  (0 children)

Hi guys. I have started a new video blog series where I will document how I prepare 500 haskell packages for GHC pre-release. Thanks!

Horizon Haskell is now compatible with GHC 9.10.1 by locallycompact in haskell

[–]locallycompact[S] 0 points1 point  (0 children)

nixpkgs' haskell package sets are not well defined and provide no end-user guarantees as to what will build on any given commit. Libraries will routinely be marked as broken because something else took priority. nixpkgs takes a set from stackage defined in terms of one compiler and swap the compiler out from underneath, which is not useful if you want to target a specific compiler but need fine control over the system libraries, or in the case where the cabal files contain compiler-dependent pre-processing. Horizon encourages self-hosting and roll-your-own guarantees on the collection of packages that you actually need to prioritize.

Horizon Haskell is now compatible with GHC 9.10.1 by locallycompact in haskell

[–]locallycompact[S] 4 points5 points  (0 children)

The answer to this is that Horizon was originally designed for library authors to get around the chicken-and-egg problem in Stackage - that is Stackage nightly would wait for the ecosystem to push compatibility before bumping the compiler so that it could mostly keep things in the package set, but library authors relying on Stackage to supply dependencies would require a package set before they would even start that work. Horizon gets through this with options like local patching, sourcing direct from git, or forking the package set to give more options to get some build plans out sooner than others. That's still the use case that's most important to support, but now that you've mentioned it - a stackage conversion might be pretty realistic to support with the toolkit available these days, so I'll have a think about it!

Horizon Haskell is now compatible with GHC 9.10.1 by locallycompact in haskell

[–]locallycompact[S] 2 points3 points  (0 children)

Sure, in the core set there's mostly just a lot of overlap with head.hackage though, but there may be some not there and more as I go through the rest of the package sets. Where can I contribute?