Glasgow-haskell-users

Download

glasgow-haskell-users@haskell.org

March 2020

2 participants
2 discussions

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released
by Ben Gamari 18 May '20

18 May '20

Hello all, The GHC team is happy to announce the availability of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1/ GHC 8.10.1 brings a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. This situation will hopefully be improved for GHC 8.10.2 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

2 4

is cabal-install buildable?
by Evan Laforge 29 Mar '20

29 Mar '20

I recently upgraded to ghc 8.8.3, thinking that since it's been around 8 months and 8.10 is already out, maybe things have stabilized enough. But I immediately ran into confusing trouble with cabal-install. It seems like it's just not buildable since 8.8 came out. Can this really be true? The reason is that from 2.4.0.0 onwards, it requires base <=4.13, and 8.8 uses base-4.13. Oddly, 2.2.0.0 claims support up to base 5, but actually not, because it also requires stm <2.5, and 8.8 uses stm 2.5, and it's a bootlib. I thought maybe the new nix-style build was supposed to no longer require version matches for bootlibs, but since `cabal v2-configure` fails I guess it must still have that requirement. In any case, my understanding is that linking to different versions of bootlibs isn't a good idea anyway, because once you have a dependency on the ghci api you're stuck. I looked into how nixpkgs builds cabal-install, and it looks like it disables version constraints, pulls a patch for hackage-security from hvr's personal github. So it is buildable, if you apply custom patches. Of course in the limit that's true of everything! I guess we don't need source builds to work as long as someone somewhere can figure out how to do the build and upload a binary, so I downloaded the pre-built binary of 3.0.0.0 from https://www.haskell.org/cabal/download.html, and it seemed to work at first. However, it couldn't build a particular package, and when I tried to download and `cabal configure` it, I got a version conflict which was not very clear, but the important line seems to be this: [__1] rejecting: hlibgit2:setup.Cabal-3.0.1.0/installed-3.0..., hlibgit2:setup.Cabal-3.0.0.0, hlibgit2:setup.Cabal-2.4.1.0, hlibgit2:setup.Cabal-2.4.0.1, hlibgit2:setup.Cabal-2.4.0.0 (conflict: hlibgit2 => hlibgit2:setup.Cabal>=1.10 && <1.25) My best guess about what this means is that, while hlibgit2 has no explicit dependency on Cabal (the library), it does have a Setup.hs, which imports Distribution.Simple, and perhaps this creates a dependency, and the ghc 8.8.3 has `Cabal-3.0.1.0` while cabal-install was compiled against `Cabal-3.0.0.0`, and I vaguely remember if you use a cabal-install whose Cabal version doesn't match the Cabal version of the ghc you are using, it will appear to work, until it doesn't, and then things will crash with confusing errors, or rebuild constantly, or do something bad. But of course I can't compile cabal-install against Cabal-3.0.1.0 because I can't build it at all. Maybe it actually is important for source builds to work! It looks like I could downgrade to 8.8.1 and maybe things would work. Is this really the situation? If it's not, where did I go wrong? If it is, how can we fix it? Provided people agree it's a problem, but if not, why not? I seem to recall that just about every ghc release has had this kind ghc-Cabal-cabal-install synchronization problem, and it's one of the reasons I wait 6 months or so before upgrading. But of course that's not good for me or for ghc, because then I'm reporting the bugs rather late.

1 0