December 2019 - ghc-devs

Perf metrics
by Simon Peyton Jones 20 Dec '19

20 Dec '19

When I run `sh validate -legacy`, towards the end I see stuff like this Performance Metrics (test environment: local): Conversions(normal) runtime/bytes allocated 107696.000 DeriveNull(normal) runtime/bytes allocated 112050960.000 InlineArrayAlloc(normal) runtime/bytes allocated 1600041088.000 InlineByteArrayAlloc(normal) runtime/bytes allocated 1440041088.000 InlineCloneArrayAlloc(normal) runtime/bytes allocated 1600041248.000 ManyAlternatives(normal) compile_time/bytes allocated 840985728.000 ManyConstructors(normal) compile_time/bytes allocated 4540766560.000 MethSharing(normal) runtime/peak_megabytes_allocated 2.000 MethSharing(normal) runtime/bytes allocated 480098136.000 MultiLayerModules(normal) compile_time/bytes allocated 5856970504.000 ... It is intermingled with other apparently unrelated output. What should I conclude form this? Is it good or bad? By what amount have these figures changed, and relative to what? How can I run a single perf test? Thanks Simon

2 3

Re: haskell/bytestring stalled?
by Simon Jakobi 19 Dec '19

19 Dec '19

Hi Herbert, I apologize for the overly harsh and accusatory tone in my last email. After looking through the existing PRs and issues, I was admittedly somewhat disappointed over the current situation with bytestring issues and PRs, but I shouldn't have expressed my feelings in this way. Also, thanks a lot for responding so quickly today to my many comments on issues and PRs. To be clear, I'm not interested in putting blame on you or Duncan or anyone else. I do however strongly believe that bytestring needs a more responsive maintainer: 1. Contributors IMO deserve to get a response within weeks or ideally days. 2. bytestring users (and that transitively includes all GHC users) could benefit massively if some of the current PRs were finally merged. For example in [#175], Sylvain Henry reports improvements of **11%** for some compilation tasks when he used the PR to build GHC. And I admittedly don't want to ask you, Herbert, to lead the effort of clearing up the maintenance backlog in bytestring. Of course, _any_ Haskell project you're involved in benefits from your massive experience! However, I feel that since your involvement is so crucial in so many other essential projects in the Haskell ecosystem, if you would shift your focus towards bytestring, these other projects would suffer! I also believe that projects like cabal or Hackage need your domain knowledge more dearly than bytestring does. So to ask you to allocate more time to bytestring, would feel a bit like a zero-sum game, or possibly a negative-sum game. A second, more personal reason, why I would prefer to see a different maintainer for bytestring, is your preference for coordinating things in private communication. The many PRs and issues in the bytestring project, and this email thread demonstrate that there are a lot of people who would like to be involved in improving bytestring. Private coordination would exclude most of them, and make it more difficult to make use of all the help that this project currently needs. I understand that your preference for private communication is related to your experiences with previous discussions over Haskell projects, and I am sorry that it has come so far, but I believe that a more open and transparent style of communication is more healthy. So, while I'm very grateful for your work on bytestring, and while I hope that you stay involved in the project, I hope that that someone else can take over official maintainer duties. Now I am not sure who could take on that job. Clearly we need someone whom Duncan trusts. That's why I wonder whether someone involved in the performance work on GHC could help. Ultimately I don't think that their time involvement would need to be very high – good judgment and responsiveness seem more important to me. I'm CC'ing the ghc-devs list, hoping that someone with the right experience and availability would come forward. Thanks, Simon [#175] https://github.com/haskell/bytestring/pull/175#issuecomment-567233984

2 2

Invitation to GHC Week
by Matthew Pickering 19 Dec '19

19 Dec '19

Dear all, I am happy to announce GHC Week, a developers meeting focusing on GHC, organized by myself and AndreasK. We are renting a big holiday cottage in rural Belgium during March so that participants can hack on GHC uninterrupted for a whole week. The place has a large number of beds and a nice open living area for collaboration and relaxation. Dates: 13th - 20th March 2020 Location: Annevoie, Belgium If you are interested in attending GHC Week then please consult the linked webpage which contains information about how to attend. There are only a limited number of spaces and we already have a number of confirmed attendees. Hopefully no one will be disappointed but if all 700 subscribers to ghc-devs want to attend there will not be enough space! We would particularly like to encourage undergraduate students who are interested in working on GHC to attend GHC Week. Thanks to our sponsors, Haskell.org and Well-Typed we are in a position to not only make the event itself very affordable, but also to cover travel and accommodation costs for those in need. This is an exceptional opportunity to learn about GHC from experienced developers. So if you can, make sure you don’t miss it! For more details please consult the following page: https://andreaspk.github.io/ghc-week Cheers, Matt & Andreas

1 1

Typo in closure name in rts/Prelude.h
by Csaba Hruska 15 Dec '19

15 Dec '19

Hello, Could you confirm if *base_GHCziWeak_rrts/win32/libHSbase.def_closure* <https://gitlab.haskell.org/ghc/ghc/blob/master/rts/Prelude.h#L30> is a typo in rts/Prelude.h? I guess it is a typo because *base_GHCziWeak_runFinalizerBatch_closure* does exists in base/GHC/Weak.hs. <https://gitlab.haskell.org/ghc/ghc/blob/master/libraries/base/GHC/Weak.hs#L…> The following files have the wrong name: - rts/package.conf.in - rts/rts.cabal.in - rts/Prelude.h - rts/win32/libHSbase.def Regards, Csaba

2 3

[ANNOUNCE] GHC 8.8.1-alpha2 is now available
by Ben Gamari 12 Dec '19

12 Dec '19

Hello everyone, The GHC team is pleased to announce the second and likely last alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha2 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release brings a number of fixes since alpha 1: * A number of linker fixes (#16779, #16784) * The process, binary, Cabal, time, terminfo libraries have all been bumped to their final release versions * A regression rendering TemplateHaskell unusable in cross-compiled configurations has been fixed (#16331) * A regression causing compiler panics on compilation of some programs has been fixed (#16449) * -Wmissing-home-modules now handles hs-boot files correctly (#16551) * A regression causing some programs to fail at runtime has been fixed (#16066) Due to on-going work on our release and testing infrastructure this cycle is proceeding at a pace significantly slower than expected. However, we anticipate that this investment will allow us to release a more reliable, easier-to-install compiler on the planned six-month release cadence in the future. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-…

8 18

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 11 Dec '19

11 Dec '19

Dear Haskell community, the GHC Steering committee is seeking nominations for one new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until January 2nd. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

GitLab # trick
by Richard Eisenberg 10 Dec '19

10 Dec '19

Today I learned that if you type # in an input field on GitLab, you can start typing the description of a ticket, and GitLab will find the number of the (open) ticket for you. For example, I typed #zap and got #16775, just what I was looking for. (That I would get this was very clear in the UI -- no surprises here.) Maybe others already knew this, but this was just so snazzy and ergonomic, I had to write. Richard

1 0

Total failure
by Simon Peyton Jones 10 Dec '19

10 Dec '19

Bad things are happening. I can't build GHC at all! I'm trying 'sh validate -fast' on a clean build of a master checkout HEAD detached at 3a96a0b6db (this is the master checkout from which !2276 branches off) But alas I get this Exit code: 1 Stderr: compiler/main/DynFlags.hs:323:0: error: error: "GHC_STAGE" is not defined, evaluates to 0 [-Werror=undef] #if GHC_STAGE >= 2 | 323 | #if GHC_STAGE >= 2 | ^ compiler/main/DynFlags.hs:5750:0: error: error: "GHC_STAGE" is not defined, evaluates to 0 [-Werror=undef] #if GHC_STAGE < 2 | 5750 | #if GHC_STAGE < 2 | ^ cc1: all warnings being treated as errors What should I do? Simon

2 2

Re: More failure
by Andrey Mokhov 10 Dec '19

10 Dec '19

Hi Simon, (Re-sending from the email address that's allowed on the mailing list.) > Ugh. That's not a very happy state of affairs, is it? It didn't happen with 'make'. > Is it a fundamental problem, or just not yet fixed? I think this is not a fundamental problem, but the problem of getting dependencies right. In this case, the complexity comes from the fact that a single invocation of GHC produces a set of files, and which set depends on the command line flags, which are in turn determined dynamically by reading environment settings (specifically, `platformSupportsSharedLibs`). Such rules are hard to describe precisely, because build systems are tuned to the typical case where we statically know, for every output file, which rule produces it -- recall the Tasks = k -> Maybe Task function from our paper. In this case, we deal with something like k -> f (Maybe Task) instead, i.e. with `f` around the Maybe. The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy. (I never really had a chance to look at dynamic builds, since they are not supported on Windows. I guess I should finally find a Linux box for Hadrian.) Cheers, Andrey

2 2

Running test with the stage-1 compiler
by Simon Peyton Jones 10 Dec '19

10 Dec '19

Apparently 'sh validate' now uses Hadrian. This has broken one of my workflows: * build the stage1 compiler * cd testsuite/tests * make stage=1 That is, run the testsuite with the stage-1 compile. (This often produces a small test case for a compiler crash, much easier than debugging GHC compiling itself.) How do I do this? Thanks Simon

4 4