- ghc-devs - Haskell.org

9.2.6 forthcoming release
by Matthew Pickering 01 Feb '23

01 Feb '23

Hi all, We are preparing potentially the final release in the 9.2.* series. Zubin is preparing the release and we hope to deliver the release in the next 1-2 weeks. The two most critical bugs which 9.2.6 will fix is * #22425 which is a performance regression introduced in 9.2.5. * #22497 which will fix 9.2.* on recent aarch64-darwin platforms. There are a few other bugs which will be fixed in the release but we are being very conservative at this stage about introducing potential breakage. The backport set is being prepared on this branch: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9775 Cheers, Matt

1 0

Slow downloads
by Simon Peyton Jones 01 Feb '23

01 Feb '23

I'm getting very low transfer rates on Git operations. Like 16 kb/s. Things that usually take a second or two are still going 10 minutes later. See below My internet connection appears to be solid at 100Mb/s upload and download. Any ideas? Simon [image: image.png]

2 1

[ANNOUNCE] GHC 9.6.1-alpha2 is now available
by Ben Gamari 31 Jan '23

31 Jan '23

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha2. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1-alpha2/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell. - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 will include: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a [migration guide] to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older `glibc` releases (namely 2.27), respectively. Please do give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes…

1 0

Extracting comments from the source code
by Facundo Domínguez 30 Jan '23

30 Jan '23

Dear GHC devs, I'm trying to port Liquid Haskell to ghc 9.2.5. And having much difficulty using the GHC API for a specific task, so I come here to ask about it. As you may know already, Liquid Haskell needs to read special comments from Haskell source code which have the form {-@ ... @-}. For example > module Demo.Lib where > > {-@ type Pos = {v:Int | 0 < v} @-} > > {-@ incr :: Pos -> Pos @-} > incr :: Int -> Int > incr x = h x > where > {-@ h :: Pos -> Pos @-} > h x = x - 1 Since Liquid Haskell runs as a GHC plugin, it has access to the GHC API. It used to be the case that one could find all of the comments together with their source spans in a field pm_annotations :: ParsedModule -> ApiAnns -- [1] However this field has been removed in ghc-9.2, and now the comments are all spread through the AST after parsing. I managed to collect them all again with a generic traversal: > go :: forall a. Data a => a -> [LEpaComment] > go = gmapQr (++) [] go `extQ` (id @[LEpaComment]) but I'd expect this to be rather slow. So I'd like to ask here, is there a better way to collect all of the comments? The other obvious way would be to write the traversal manually, but it would be some code to write, and it would likely need attention when porting to newer GHCs onwards. Thanks! Facundo [1]: https://hackage.haskell.org/package/ghc-9.0.2/docs/GHC.html#t:ParsedModule

3 3

Searching tickets
by Simon Peyton Jones 25 Jan '23

25 Jan '23

I keep finding that 'search' in Gitlab misses things. Example https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline" (just look on that page) Yet when I go to https://gitlab.haskell.org/ghc/ghc/-/issues/ and search for "Haskeline", this ticket isn't reported. What am I doing wrong? Simon

3 4

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

24 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 17 Jan '23

17 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 14 Jan '23

14 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