- ghc-devs - Haskell.org

DKIM failures for gitlab mail
by Joachim Breitner 23 Jan '23

23 Jan '23

Hi Bryan (I assume), I noticed that a small number of Gitlab notification emails end up in my spamfilter. While there is not much you can do about triggering some bayesian style spam filter at my email provider (mailbox.org) I did notice this in the headers: X-Spam-Status: No, score=2.704 tagged_above=2 required=6 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: spamfilter01.heinlein-hosting.de (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=gitlab.haskell.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gitlab.haskell.org; s=mail; t=1669733134; bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id: List-Unsubscribe; b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q= It seems the DKIM configuration is broken? There is a DKIM record for the domain that’s valid acccording to https://www.dmarcanalyzer.com/de/dkim-de/dkim-record-check/?dmarcdns%5Btype… but maybe Postfix is not using the right key? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4

Marge-bot outage over the weekend
by Bryan Richter 23 Jan '23

23 Jan '23

Hi folks, Just writing to let you know that Marge experienced an error condition on Friday (unable to reach GitLab) and shut down. I noticed it this morning and restarted the service. A new batch merge https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9774 is now active. -Bryan

2 1

[ANNOUNCE] GHC 9.6.1-alpha1 is now available
by Ben Gamari 16 Jan '23

16 Jan '23

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1-alpha1/ This is the first alpha release in the 9.6 series which will bring a number of exciting features: * A new Javascript code generation backend * A new WebAssembly code generation backend, * Significant latency improvements in the non-moving garbage collector * Support for loading of multiple components in GHCi * Efficient support for delimited continuations * Improvements in error messages * Numerous improvements in compiler-residency Note that both the Javascript and WebAssembly backends are still in a state of infancy and are present in this release as a technology preview; we hope that they will mature considerably before the final 9.6.1 release. Please give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/

2 4

Deprecating Safe Haskell, or heavily investing in it?
by Hécate 13 Jan '23

13 Jan '23

Hi everyone, and happy holidays. I am looking into whether or not Safe Haskell is still worth maintaining. Currently there are two sides on which Safe Haskell hurts us: 1. GHC Development 2. Library development For point n°1: You can easily take the measure of what Safe Haskell raises in GHC as of today by visiting the bug tracker¹ and see that for example Unboxed Types cannot be used because their home modules (GHC.Prim and GHC.Types) are marked as Unsafe. Moreover, interactions between GHC2021 and Safe make the latter quite unpleasant to work with². Regarding point n°2: Safe Haskell is badly integrated within our existing frameworks for API compatibility. Neither the PVP nor the extension's documentation mention compatibility, or define what stance we should take. Thus we are bound to fight on the letter versus the spirit of the PVP (which is not an unreasonable debate since there is no formalism anywhere). This provokes debates without clear resolution beyond "Friend don't let friends use {-# Safe #-}"³ Now I am not saying that Safe Haskell does not bring any kind of good idea, far from it. However there are two things that live inside Safe Haskell that would benefit from being separated: 1. Strict type-safety 2. Restricted IO A lot of the public use-cases of Safe Haskell seem to be on the "Restricted IO", such as Lambdabot and other code evaluators out there. It's a fairly reasonable feature, I'd even say it's something that we should be publicising more when speaking about GHC's more advanced features. However, "Strict type-safety" seems to be the root of many problems that we encounter downstream. A lot of it stems from GeneralizedNewtypeDeriving being marked as unsafe (under point 1), which is fair enough, but we've had DerivingVia not marked as Safe until May 2021, which reveals a big problem: Options have to be marked as forbidden under Safe to be caught, which leaves a lot of work to the human factor of GHC development. Now, there are two options (convenient!) that are left to us: 1. Deprecate Safe Haskell: We remove the Safe mechanism as it exists today, and keep the IO restriction under another name. This will certainly cause much joy amongst maintainers and GHC developers alike. The downside is that we don't have a mechanism to enforce "Strict type-safety" anymore. 2. We heavily invest in Safe Haskell: This is the option where we amend the PVP to take changes of Safety annotations into account, invest in workforce to fix the bugs on the GHC side. Which means we also invest in the tools that check for PVP compatibility to check for Safety. This is not the matter of a GSoC, or a 2-days hackathon, and I would certainly have remorse sending students to the salt mines like that. I do not list the Status Quo as an option because it is terrible and has led us to regularly have complaints from both GHC & Ecosystem libraries maintainers. There can be no half-measures that they usually tend to make us slide back into the status quo. So, what do you think? ¹ https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=Safe%20Haskell ² https://gitlab.haskell.org/ghc/ghc/-/issues/19605 ³ https://github.com/haskell/directory/issues/147 -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

11 15

Fwd: Will there be a GHC 9.2.6?
by Clinton Mead 03 Jan '23

03 Jan '23

Hi All I just noticed Haskell Language Server (HLS) 1.9 has been released, which supports GHC 9.2.5. My organisation is currently using GHC 9.2.2 and I don't see any immediate need to jump to GHC 9.4, it would be good to settle on the latest most stable version of the GHC 9.2 series as it includes all the features we need at the moment. Also I understand that HLS tends to have long term(ish) support for the latest GHC in a release series. I'd rather not do this upgrade twice so I was just wondering whether it has been decided or not whether there will be a 9.2.6 release (if this is still unknown that's okay). I did notice this page: https://gitlab.haskell.org/ghc/ghc/-/milestones/385 but was unsure whether this page was autogenerated or a deliberate indication that there will be a GHC 9.2.6 at some point. Thanks, Clinton

2 1

[ANNOUNCE] GHC 9.4.4 is now available
by Ben Gamari 25 Dec '22

25 Dec '22

The GHC developers are happy to announce the availability of GHC 9.4.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org [1]. This release is primarily a bugfix release. Bugs fixed include: * An issue where the wrong labels were used in the eventlog for events emitted when using info table profiling which was broken in 9.4.3 (#22452) * Fix a long standing bug where invalid eventlogs would be produced with long command-lines (#20221) * Fix a regression in eta-expansion which resulted in serious performance regressions in 9.4.3 (#22424) * Fix the `-fdefer-diagnostics` flag (#22391) * Fixes to several subtle compiler panics (#22491, #22416, #22549, #22475, #22039) * Add necessary write barriers to `IORef` operations, avoiding potential soundness issues on architectures with weakly-ordered memory models (#22468) 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 [1]: https://downloads.haskell.org/ghc/9.4.4 [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

2 3

GHC and type-family rewriting?
by Benjamin Redelings 18 Dec '22

18 Dec '22

Hi, I've managed to code up implications and GADTs, and am now working on adding type families. I've been following the OutsideIn paper, but it seems that GHC is not really following the same plan for the solver. For example, instead of replacing every type family with a metavariable, it only does this for occur-check failures. It talks about "cycle breakers" instead of "flattening substitutions". It creates flatting substitutions for both givens and wanteds (I think). And I see this note: > -- | A 'Xi'-type is one that has been fully rewritten with respect > -- to the inert set; that is, it has been rewritten by the algorithm > -- in GHC.Tc.Solver.Rewrite. (Historical note: 'Xi', for years and years, > -- meant that a type was type-family-free. It does *not* mean this > -- any more.) > type Xi = TcType If I'm understanding correctly, the inert set is now thought of as a "generalized substitution" that replaces either an LHS (untouchable type variables or type family applications) with an RHS. I guess what I'm wondering is: (Q1) Did GHC evolve to this point starting from something fairly close to the OutsideIn paper? (Q2) Is the new approach (i.e. eager type family rewriting) mostly to making rewriting faster? (Q3) Does it sound reasonable to implement the approach from the OutsideIn paper, and than gradually transform it to look more like GHC? -BenRI

2 3

9.4.4 release
by Matthew Pickering 15 Dec '22

15 Dec '22

Hi all, We are going to release the latest release in the 9.4.* series before Christmas. The release fixes a number of small bugs which have surfaced to do with 9.4. For the current full list of backports see: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9523 I am preparing the release branch and then Ben will perform the final steps necessary for the release. Cheers, Matt

2 2

Re: 9.4.4 release
by Matthew Pickering 15 Dec '22

15 Dec '22

That issue has not been resolved for 9.4.4 but we will still provide CentOS7 builds (which link against the older glibc). On Thu, Dec 15, 2022 at 1:19 AM Julian Ospald <hasufell(a)posteo.de> wrote: > > Has there been any changes to the bindists? Does https://gitlab.haskell.org/ghc/ghc/-/issues/22268 still exist? > > On December 14, 2022 12:51:00 PM UTC, Matthew Pickering <matthewtpickering(a)gmail.com> wrote: >> >> Hi all, >> >> We are going to release the latest release in the 9.4.* series before Christmas. >> >> The release fixes a number of small bugs which have surfaced to do with 9.4. >> >> For the current full list of backports see: >> >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9523 >> >> I am preparing the release branch and then Ben will perform the final >> steps necessary for the release. >> >> Cheers, >> >> Matt

1 0

Merge failures due to stats increase
by Bryan Richter 30 Nov '22

30 Nov '22

Last night, Marge's merge requests failed several times because of a stats increase. compile_time/bytes allocated increased from x86_64-linux-fedora33-release baseline @ def47dd32491311289bff26230b664c895f178cc: Expected T9872a (normal) compile_time/bytes allocated: 1655471856.0 +/-1% Lower bound T9872a (normal) compile_time/bytes allocated: 1638917137 Upper bound T9872a (normal) compile_time/bytes allocated: 1672026575 Actual T9872a (normal) compile_time/bytes allocated: 1674083264 Deviation T9872a (normal) compile_time/bytes allocated: 1.1 % *** unexpected stat test failure for T9872a(normal) This happened on three separate attempts, each with a deviation of 1.1%: * https://gitlab.haskell.org/ghc/ghc/-/jobs/1247176 * https://gitlab.haskell.org/ghc/ghc/-/jobs/1247312 * https://gitlab.haskell.org/ghc/ghc/-/jobs/1247512 The reason I'm making an email out of this is that none of the individual patches that Marge is merging have this problem, but it seems to happen consistently when they are combined. You can see a list of patches by looking at the list of mentions on https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9439. There were other problems with Marge's merges last night that I DO understand and have fixed. But this one, of course, is over my head. :) Maybe somebody can look at the list of patches and deduce something useful. Otherwise, I will continue monitoring Marge's progress, and try to find a smaller set of patches that can make it through. I'll prioritize getting the Javascript backend through. -Bryan

1 0