- ghc-devs - Haskell.org

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 30 Jan '23

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

24 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 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 24 Dec '22

24 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