Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
Hi all, I will shortly prepare a blog post which describes the situation in more detail for a general audience but for the subscribers here is a summary of the release status. 9.4.1-alpha2: The release is imminent, and fixes a number of packaging issues identified with alpha1. Slightly delayed due to regression involving deb9 toolchains. (Ben) 9.2.3: The release will follow shortly (within 1 week) after the 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin) 9.4.1: The target for the final release is end of July. 9.0.* series: We do not intend to do any more releases in the 9.0.* series. - The 9.2 series is more stable - The 9.2 series does not contain significant breakage (when upgrading from 9.0) - Anecdotal evidence suggests users are upgrading straight from 8.10.7 to 9.2.2 - We do not have capacity to manage 4 active branches. Any thoughts, please reply promptly before I communicate these facts with the community. Best Wishes, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: What to do with gmp wasm fixes
Hi Cheng, Couldn't the changes be upstreamed into libgmp directly? Other projects may benefit from being able to compile libgmp into wasm. Or are the changes specific to GHC? > - Send a PR to gmp-tarballs, including our patch (doesn't alter behavior on native archs) and the updated tarball build script I'm not sure if it's still the case, but in the past we applied some patches to gmp before building it (to use fPIC and to remove the docs). So it should be possible to do it for wasm. > - Give up gmp completely, only support native bignum for wasm32. That's the solution we will use for the JS backend. For wasm, it would be great to compare performance between both native and gmp ghc-bignum backends. libgmp uses some asm code when it is directly compiled to x86-64 asm for example and afaict passing through wasm will make it use less optimized codes. It may make the gmp backend less relevant: only benchmarks will tell. I would ensure that everything works with ghc-bignum's native backend before worrying about using gmp. Cheers, Sylvain On 20/05/2022 13:43, Cheng Shao wrote: Hi all, The ghc wasm32-wasi build needs to patch gmp. Currently, our working branch uses a fork of gmp-tarballs that includes the patch into the tarball, but at some point we need to upstream it. What's the best way to add these fixes? - Send a PR to gmp-tarballs, including our patch (doesn't alter behavior on native archs) and the updated tarball build script - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp build process is decoupled from ghc build - Give up gmp completely, only support native bignum for wasm32. Cheers. Cheng ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: What to do with gmp wasm fixes
Hi Sylvain, > Couldn't the changes be upstreamed into libgmp directly? GMP is a very old project with long release cycles, last release dates back to 2020. So there's no guarantee a GMP release will be ready by the time 9.6 branch is cut. Even if the patch is upstreamed, there's no proper CI to avoid wasm breakage. > Or are the changes specific to GHC? Not really. It's due to the timing & future-proof issue above, so even if we do send patch to gmp, we need to prepare for situation as if we still need to do patching in our build. > I'm not sure if it's still the case, but in the past we applied some > patches to gmp before building it (to use fPIC and to remove the docs). > So it should be possible to do it for wasm. We still patch gmp tarball to remove the docs. Yes, as long as GHC HQ doesn't push back the idea of including a patch for wasm, I'll send a PR to gmp-tarballs. > I would ensure that everything works with > ghc-bignum's native backend before worrying about using gmp. Both gmp/native already works for wasm32. As long as we figure out the plan to include gmp patches, we intend to provide both gmp/native bindists. As for benchmarking, may be worthwhile at some point, but we got tons of other stuff on our plate right now. On Mon, May 23, 2022 at 11:36 AM Sylvain Henry wrote: > > Hi Cheng, > > Couldn't the changes be upstreamed into libgmp directly? Other projects > may benefit from being able to compile libgmp into wasm. Or are the > changes specific to GHC? > > > - Send a PR to gmp-tarballs, including our patch (doesn't alter > behavior on native archs) and the updated tarball build script > > I'm not sure if it's still the case, but in the past we applied some > patches to gmp before building it (to use fPIC and to remove the docs). > So it should be possible to do it for wasm. > > > - Give up gmp completely, only support native bignum for wasm32. > > That's the solution we will use for the JS backend. For wasm, it would > be great to compare performance between both native and gmp ghc-bignum > backends. libgmp uses some asm code when it is directly compiled to > x86-64 asm for example and afaict passing through wasm will make it use > less optimized codes. It may make the gmp backend less relevant: only > benchmarks will tell. I would ensure that everything works with > ghc-bignum's native backend before worrying about using gmp. > > Cheers, > Sylvain > > > On 20/05/2022 13:43, Cheng Shao wrote: > > Hi all, > > > > The ghc wasm32-wasi build needs to patch gmp. Currently, our working > > branch uses a fork of gmp-tarballs that includes the patch into the > > tarball, but at some point we need to upstream it. What's the best way > > to add these fixes? > > > > - Send a PR to gmp-tarballs, including our patch (doesn't alter > > behavior on native archs) and the updated tarball build script > > - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp > > build process is decoupled from ghc build > > - Give up gmp completely, only support native bignum for wasm32. > > > > Cheers. > > Cheng > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
best way to detect invalid Haddock early?
I've had some CI failures because of invalid Haddock comments. What is the best way to detect such issues locally, early? I tried setting environment variable GHC_FLAGS to "-Winvalid-haddock", which should have told `./hadrian/ghci` to issue a warning. But for some reason, no warning was issued. What's a good way to detect invalid Haddock before it hits CI? Norman ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
Blog post: https://www.haskell.org/ghc/blog/20220523-release-status.html On Mon, May 23, 2022 at 10:33 AM Matthew Pickering wrote: > > Hi all, > > I will shortly prepare a blog post which describes the situation in > more detail for a general audience but for the subscribers here is a > summary of the release status. > > 9.4.1-alpha2: The release is imminent, and fixes a number of packaging > issues identified with alpha1. Slightly delayed due to regression > involving deb9 toolchains. (Ben) > > 9.2.3: The release will follow shortly (within 1 week) after the > 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin) > > 9.4.1: The target for the final release is end of July. > > 9.0.* series: We do not intend to do any more releases in the 9.0.* series. > - The 9.2 series is more stable > - The 9.2 series does not contain significant breakage (when > upgrading from 9.0) > - Anecdotal evidence suggests users are upgrading straight from 8.10.7 to > 9.2.2 > - We do not have capacity to manage 4 active branches. > > Any thoughts, please reply promptly before I communicate these facts > with the community. > > Best Wishes, > > Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
For the record, I have three exact print annotations commits that I would like to backport to 9.4. I am doing my final checks at the moment, will make an official request for them soon. On Mon, 23 May 2022 at 19:13, Matthew Pickering wrote: > Blog post: https://www.haskell.org/ghc/blog/20220523-release-status.html > > On Mon, May 23, 2022 at 10:33 AM Matthew Pickering > wrote: > > > > Hi all, > > > > I will shortly prepare a blog post which describes the situation in > > more detail for a general audience but for the subscribers here is a > > summary of the release status. > > > > 9.4.1-alpha2: The release is imminent, and fixes a number of packaging > > issues identified with alpha1. Slightly delayed due to regression > > involving deb9 toolchains. (Ben) > > > > 9.2.3: The release will follow shortly (within 1 week) after the > > 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin) > > > > 9.4.1: The target for the final release is end of July. > > > > 9.0.* series: We do not intend to do any more releases in the 9.0.* > series. > > - The 9.2 series is more stable > > - The 9.2 series does not contain significant breakage (when > > upgrading from 9.0) > > - Anecdotal evidence suggests users are upgrading straight from 8.10.7 > to 9.2.2 > > - We do not have capacity to manage 4 active branches. > > > > Any thoughts, please reply promptly before I communicate these facts > > with the community. > > > > Best Wishes, > > > > Matt > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
