u/locallycompact
-
1points
-
10points
New Horizon Haskell Website updated for GHC 10.0.x-alpha1 (horizon-haskell.net)
-
17points
Haskell Vortex - Put a Haskell console in anything (vortex.openfp.net)
-
52points
Benchmarking GHC 9.6 Through 9.14 (youtu.be)
-
10points
qmk-deploy - a flake-parts module for building qmk firmware (gitlab.homotopic.tech)
-
10points
Full Time Nix | Horizon Haskell with Daniel Firth (fulltimenix.com)
-
20points
gitlab-ci - flake-parts module to use GitLab CI dynamic pipelines with nix (gitlab.horizon-haskell.net)
-
5points
gitlab-ci - flake-parts module to use GitLab CI dynamic pipelines with nix. (gitlab.horizon-haskell.net)
-
20points
Full Time Nix | Horizon Haskell with Daniel Firth (Podcast) (fulltimenix.com)
-
7points
Horizon Haskell (Road To GHC 9.14) Playlist (youtube.com)
-
10points
-
13points
-
9points
-
19points
Horizon Haskell: Road To GHC 9.14: Introduction (youtube.com)
-
16points
Horizon Haskell updates to GHC 9.12.1-alpha1 (self.haskell)
-
7points
-
15points
Horizon Haskell template available using horizon-cardano (self.cardano) [Developer]
-
30points
Horizon Haskell is now compatible with GHC 9.10.1 (self.haskell)
locallycompact
locallycompact
Yeah I would hate to have to read that.
locallycompact
I will collect results in the README of the repository and also post to the main website https://horizon-haskell.net
locallycompact
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!
locallycompact
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.
locallycompact
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!
locallycompact
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?
Hi. You can listen to the podcast here on Full Time Nix to understand what this project is about. https://fulltimenix.com/episodes/horizon-haskell-with-daniel-firth