Gitlab upgrade tomorrow
Hi all, Gitlab will be temporarily unavailable tomorrow around 9:00 AM CEST while it's updated. This should not take long, but a short downtime is expected. Cheers, - Andreas ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: The reason for non-GHC boot dependencies
I think they could be statically linked. But those boot libraries don't change much and generally don't really cause us nor users pain so it seems like there is little reason to do so to me. > Surely the size of binaries can't be the only concern, otherwise we'd use upx¹ on them when distributing them. I believe Ben experimented with executable compression tools in the past with little success. But there were segfaults, executables being flagged by antivirus and perhaps more issues I forgot which just made using it unrealistic at the time. But perhaps the tooling has matured in the meantime. Since our distributions are already compressed purely for *distribution* purposes I would expect the gains there to be rather slim anyway. So it's not really that we don't care about size, just that these tools seemed not reliable enough for the benefits they offer in the past. Am 10/07/2024 um 11:01 schrieb Hécate via ghc-devs: Hi devs, I had a chat earlier today with someone and found myself unable to explain the reason why GHC came with boot dependencies like xhtml, that are dependencies of Haddock and HPC. Obviously, the binaries are (haskell-)dynamically linked when distributed, but what is the reason why haddock, hpc, etc can't be (haskell-)statically linked when distributed? Surely the size of binaries can't be the only concern, otherwise we'd use upx¹ on them when distributing them. Cheers, Hécate 1: https://upx.github.io ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Sunsetting CentOS support
Hello devs, with CentOS 7 reaching EOL we are demoting it to a Tier 2 platform and will eventually drop support completely. There are no immediate plans to stop supporting it, but we will not allocate any more resources towards support for it and will likely drop support completely should it break in the future. We introduced support for Rocky Linux as replacement for CentOS some time ago, so users who need a RHEL compatible GHC distribution should be able to use GHC packaged for Rocky Linux instead without issues. Best Regards Andreas Klebinger ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Build GHC in GHC2021
On a whim tried enabling it by default but it failed first because GeneralizedNewtypeDeriving is incompatible with safe haskell and once I disabled GeneralizedNewtypeDeriving it failed with some error about missmatched kinds. I would welcome a patch doing this, but it's not a priority. Especially since it doesn't seem to be as simple as changing the base language and removing some pragmas. Am 07/12/2023 um 14:29 schrieb Arnaud Spiwack: Indeed. I didn't realise the ambiguity in my wording. I'd like for GHC to be built, with Hadrian, using GHC2021 as the base language. On Thu, 7 Dec 2023 at 14:01, Tom Ellis wrote: On Thu, Dec 07, 2023 at 12:53:02PM +, Richard Eisenberg wrote: > I think this is an excellent idea! So excellent, that we've already done it. :) > > When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 is in effect. > > Is there something different you were thinking of? I think Arnaud meant that compilations of GHC's codebase itself should use the GHC2021 setting. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. ___ 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
