- ghc-devs - Haskell.org

Upcoming maintenance on Haskell services
by Bryan Richter 22 Nov '22

22 Nov '22

Hello folks, On Thursday 24 November at 6 AM UTC, I will start a 4-hour maintenance window for the following Haskell services: 1. downloads.haskell.org 2. gitlab.haskell.org In particular, I expect the following outages: 1. downloads.haskell.org will be read-only for the duration of the window. * No uploads 2. gitlab.haskell.org will be read-only for the duration of the window. * No CI pipelines(!) * No git pushes * No commenting on issues or merge requests 3. gitlab.haskell.org will furthermore be entirely inaccessible very briefly. * There will be 1-2 outages. * Each outage will last a few seconds. The reason for the maintenance is that our hosting sponsor, Equinix Metal, is performing a facilities migration. One of our servers, gitlab-storage, is slated for retirement. All data and services that run on that server must be moved to a new server. I'm sending this first notification to a wide audience as an extra precaution in case something goes wrong. :) In reality, I expect this maintenance to only affect GHC developers and a small group of ecosystem maintainers. In particular, web access of https://downloads.haskell.org should *not* be affected by this maintenance. I will send further updates to a smaller audience. Note: The actual migration will be quick. Most of the maintenance window will be spent waiting for DNS propagation. -Bryan Haskell Foundation DevOps

1 0

How do you build GHC 9.2.4 cross compilers for windows?
by Moritz Angermann 16 Nov '22

16 Nov '22

Hi, Does anyone know how to build a 9.2.4 windows cross compiler? Hadrian seems to get in the way a lot? This is the essence of what we tried to get working: ./configure --enable-bootstrap-with-devel-snapshot --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-w64-mingw32 hadrian --flavour=default+no_dynamic_ghc --docs=no-sphinx -j Can someone please advise how this is supposed to be built now? Cheers, Moritz

2 1

GitLab runners having issues
by Bryan Richter 16 Nov '22

16 Nov '22

Hi everyone, Unfortunately, many CI jobs are failing for similar reasons on a number of runners. Examples: 1. Running /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z... Downloading the latest package list from hackage.haskell.org Version of <repo>/root.json is less than the previous version /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z failed error: cabal update failed -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224391 2. ERROR: Job failed: failed to pull image "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v1…" -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224641 Moritz, can you look into these? Could it have something to do with the GitLab emergency upgrade that happened yesterday? Or were the runners reconfigured in some way? I don't have administrative access to these runners. I have created an issue: https://gitlab.haskell.org/ghc/ghc/-/issues/22422 -Bryan

2 3

Gitlab slow?
by Simon Peyton Jones 15 Nov '22

15 Nov '22

Is it just me, or is GitLab taking an unusually long time to serve up pages when looking at GHC tickets? Simon

4 4

Status of Stream Fusion?
by J. Reinders 14 Nov '22

14 Nov '22

Dear GHC devs, I’m interested in stream fusion and would like to see what it takes to fix the remaining issues, so that it can replace foldr/build fusion in base. First of all I would like to know what exactly the challenges are that are left. I believe one of the main remaining problems is the fusion of ‘concatMap’. Is that really the only thing? Secondly, I would like to know what has already been tried. I know Sebastian Graf has spent a lot of effort trying to get SpecConstr to work on lambda arguments without success. I’ve read that Sebastian now considers the static argument transformation more promising. However, Duncan Coutts proposed in his thesis to make rewrite rules slightly more powerful and use the rewrite rule: concatMap (λx → Stream next (f x)) = concatMap' next f Has that ever been tried? If so, what is the problem with this rewrite rule approach? I can understand that the `f x` function application is usually in a more reduced form, but it seems relatively easy to make the rewrite rule matcher smart enough to see through beta-reductions like that. So my main questions are: 1. Is the ‘concatMap’ problem really the only problem left on the way to using stream fusion instead of foldr/build fusion in base? 2. Has the rewrite rule approach to solving the ‘concatMap’ problem ever been tried? Any other information about the current status of stream fusion is also much appreciated. Cheers, Jaro Reinders

3 6

GitLab maintenance today
by Ben Gamari 07 Nov '22

07 Nov '22

Hi all, Today we will be doing some maintenance on gitlab.haskell.org to address #22418. I can't yet say precisely when the outage will begin but I do expect there to be one. I will try to provide at least 30 minutes notice. Cheers, - Ben

1 0

[Haskell] [ANNOUNCE] GHC 9.2.5 released
by Zubin Duggal 07 Nov '22

07 Nov '22

The GHC developers are very happy to at announce the availability of GHC 9.2.5. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.5). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_5.html Blog Post: https://www.haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.4. These include: * Code generation issues in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282, #21964) * Fixes for a number of issues with the simplifier leading to core lint errors and suboptimal performance (#21694, #21755, #22114) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A runtime system bug where creating empty mutable arrays resulted in a crash (#21962) - ... and a few more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.5/docs/html/users_guide/9.2.5-notes.…

1 0

Is Prep supposed to keep thing in (reverse) dependency order?
by ÉRDI Gergő 03 Nov '22

03 Nov '22

Hi, I was under the impression that the Prep'd Core is still in reverse dependency order, i.e. if definition A refers to intra-module definition B, then A's binding will always be preceding B's binding. I've been exploiting this (hopefully not made-up and accidental!) property in my work so far. However, for the following input: ``` $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` <Co:32>) x1 } in (\ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` <Co:55>) x2) `cast` <Co:22>) `cast` <Co:148>) `cast` <Co:125>) ``` I am getting the following output from Prep: ``` sat_s2iCp :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b sat_s2iCp = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` <Co:32>) x1 } in let { sat_s2iCo :: CSASource -> Currency -> Fun '[String] b sat_s2iCo = \ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` <Co:55>) x2) `cast` <Co:22>) } in sat_s2iCo `cast` <Co:148>) `cast` <Co:125> $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = \ (@a) (@b) (eta_B0 :: a -> b) (eta_B1 :: Fun '[AnnexType, CSASource, Currency, String] a) -> sat_s2iCp @a @b eta_B0 eta_B1 ``` Note that the body of `$s$fFunctorFun_$sfmap` has been lifted out to `sat_s2iCp`, but the binding of `sat_s2iCp` precedes the binding of `$s$fFunctorFun_$sfmap`. Is this expected, for some reason, or is this a GHC bug? If the latter, I'm happy to file a ticket but I can't promise an actual end-to-end compilable reproducer...

2 1

[ANNOUNCE] GHC 9.4.3 is now available
by Ben Gamari 03 Nov '22

03 Nov '22

The GHC developers are happy to announce the availability of GHC 9.4.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.3 This release is primarily a bugfix release addressing a few issues found in 9.4.2. These include: * An issue where recursively calls could be speculatively evaluated, resulting in non-termination (#20836) * A code generation issue in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282) * A crash on Darwin when running executables compiled with IPE support (#22080) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A bug in the `process` library where file handles specified as `NoStream` would still be usable in the child (process#251) Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a ticket if you see anything amiss. Happy Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 0

Reducing all type family applications as far as possible
by ÉRDI Gergő 28 Oct '22

28 Oct '22

Hi, Is there a way to have GHC reduce all (reducable) type familiy applications? For example, if I have ``` type family Id x where Id x = x foo :: Bool -> Id Bool foo x = x ``` then I would like the `Id` of `foo` to have type `Bool -> Bool`, and the generated Core should be either `foo = \x -> x` or, if that's asking for too much, at least something like `foo = \x -> x |> (somePossiblyOvercomplicatedCoercion :: Bool ~ Bool)`. Is there already some functionality for this in GHC? If not, how messy would it be to implement it as a separate `CoreProgram` transformation just after desugaring? It'd need to be immediately after desugaring because I would like e.g. the specialiser to already specialise in terms of these reduced types. Thanks, Gergo

1 0