August 2021 - ghc-devs

[Haskell] [ANNOUNCE] GHC 8.10.6 released
by Zubin Duggal 14 Aug '21

14 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.…. As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

Fwd: GHC Module change database
by Ari Fordsham 09 Aug '21

09 Aug '21

AF ---------- Forwarded message --------- From: Ari Fordsham <arifordsham(a)gmail.com> Date: Sun, 8 Aug 2021 at 16:43 Subject: Re: GHC Module change database To: Vaibhav Sagar <vaibhavsagar(a)gmail.com> That's where I generated it from :-) It would be nice to generate that from the new database. My main motivation was as follows: There are two possible paradigms for GHC API compatibility: - Export old names for new modules - as in ghc-api-compat <https://gitlab.haskell.org/haskell/ghc-api-compat> This allows existing code to (kind of) 'just work' - but it doesn't help in managing that code as it gets extended to use new features - Export new names to old modules I am thinking of working on a tool that does this. You need to rewrite code to use current modules (maybe https://github.com/facebookincubator/retrie/issues/33 will help), but then you can just target the latest API, and have compatibility built in. This seems to me better for active codebases. Having a 'single source of truth' database will help with this. AF On Sun, 8 Aug 2021 at 16:36, Vaibhav Sagar <vaibhavsagar(a)gmail.com> wrote: > Hi Ari, > > Have you seen https://gitlab.haskell.org/haskell/ghc-api-compat? > > Thanks, > Vaibhav > > On Mon, Aug 9, 2021 at 1:34 AM Ari Fordsham <arifordsham(a)gmail.com> wrote: > >> I've made a database of GHC API module changes. >> >> https://github.com/AriFordsham/ghc-module-renames >> >> This might be useful for automatic tooling. >> >> It would be nice if this would be moved into the GHC Gitlab, and kept >> up-to-date. >> >> Ari Fordsham >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >

2 1

Fwd: GHC Module change database
by Ari Fordsham 08 Aug '21

08 Aug '21

I've made a database of GHC API module changes. https://github.com/AriFordsham/ghc-module-renames This might be useful for automatic tooling. It would be nice if this would be moved into the GHC Gitlab, and kept up-to-date. Ari Fordsham

2 1

How to Collect Type Errors?
by Guanda Yuan 07 Aug '21

07 Aug '21

Hello all, I want to write a plugin for Haskell Language Server, to collect type errors in the code. I'm new to GHC API, so I need some help. My current thought is, I can collect diagnostics or the error messages and extract the type error infos. I have tried to referred to the Haddock documentation for GHC API, but I'm still not sure which function should I use. Thanks, Guanda

2 2

Call for Lightning Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 06 Aug '21

06 Aug '21

Call for Lightning Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Thursday, 19 Aug, 2021 (or when slots are full, whichever is sooner) Workshop: Sunday, 22 Aug, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. We will have a number of slots for lightning talks. Lightning talks will be ~7 minutes and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Submissions should be made via Google form: https://forms.gle/BmUSyWWTXt1AMTec8 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Contact ------- * Ningning Xie <xnningxie(a)gmail.com>

1 0

Email Threading (finally fixed)
by Matthew Pickering 02 Aug '21

02 Aug '21

Hi all, If anyone received emails from gitlab you may have noticed that the comments to issues ended up in different threads to the original issue description. This was because of a custom patch on our gitlab instance which I think I have now fixed. For example issue #20192 now has the correct threading, the original issue and comment now appear in the same email thread (at least in my client). Cheers, Matt

2 1