February 2021 - ghc-devs

Has ghc-9.0 for windows changed to require installation?
by Takenobu Tani 09 Feb '21

09 Feb '21

Hi devs, The ghc-binary for windows needs to `make install` since ghc-9.0 [1]. Is this an intended change? Previously, ghc-8.10.4 binary for windows [2] doesn't need to `make install`. We only expand the tar-file and then we can execute `bin/ghcii.sh`. [1]: https://downloads.haskell.org/ghc/9.0.1/ghc-9.0.1-x86_64-unknown-mingw32.ta… [2]: https://downloads.haskell.org/ghc/8.10.4/ghc-8.10.4-x86_64-unknown-mingw32.… Regards, Takenobu

3 3

[ANNOUNCE] GHC 9.0.1 released
by Ben Gamari 09 Feb '21

09 Feb '21

The GHC team is very pleased to announce the availability of GHC 9.0.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/9.0.1/ In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new features: * A first cut of the new LinearTypes language extension [2], allowing use of linear function syntax and linear record fields. * A new bignum library, ghc-bignum, improving portability and allowing GHC to be more easily used with integer libraries other than GMP. * Improvements in code generation, resulting in considerable runtime performance improvements in some programs. * Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time. * Implementation of the "simplified subsumption" proposal [3] simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2. * Implementation of the QualifiedDo extension [4], allowing more convenient overloading of `do` syntax. * An experimental new IO manager implementation for Windows platforms, both improving performance and fixing many of the quirks with the old manager built on POSIX-emulation. * Improvements in compilation time. And many more. See the release notes [5] for a full accounting of the changes in this release. As always, feel free to report any issues you encounter via gitlab.haskell.org. Cheers, - Ben [1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.0#ghc-prim-07 [2]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-l… [3]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s… [4]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-q… [5]: https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/9.0.1-notes.h…

3 4

Reduction in Windows CI capacity
by Ben Gamari 09 Feb '21

09 Feb '21

tl;dr. GHC's CI capacity will be a reduced due to a loss of sponsorship, particularly in Windows runner capacity. Help wanted in finding additional capacity. Hi all, For many years Google X has generously donated Google Compute Engine resources to GHC's CI infrastructure. We all owe a debt of gratitude to Google X for providing us with what has undoubtedly amounted to tens of thousands of dollars of computational capacity over the years. I would especially like to thank Greg Steuck, whose advocacy made this donation possible. Of course, organizational priorities understandably change and Google X will be unable to continue their sponsorship in the future. This puts us in a bit of a tricky situation; Google Compute Engine is currently the home of nearly 100 cores worth of CI capacity, including: * roughly 20% of our x86-64/Linux capacity * our only x86-64/FreeBSD runner * all five of our x86-64 Windows runners While the Linux runners are fairly easy to replace, the Windows capacity is a bit harder since Windows cloud capacity is quite expensive (IIRC nearly half of the cost of our Windows GCE instances is put towards the license). In the short term I can cover for some of this lost capacity by bringing up a Windows runner using our generous donation from Packet [1]. However, I am extrmely wary of outspending our welcome on Packet's infrastructure and therefore we will need to accept a small reduction in capacity for a bit while we work out a more sustainable path forward. We will have to see how things go but it may be necessary to disable the Windows jobs on (non-Marge) merge request validation pipelines. I am looking into various options for again reaching our previous capacity, but this is an area where you might be able to help: * Familiarity with Windows licensing. Unfortunately the details of Windows licensing for virtualization purposes are a bit tricky. I suspect that the cheapest way forward is a single Windows Server license on a large machine but if you are familiar with Windows licensing in this setting, please do be in touch. * Providing Windows licenses. If you know of an organization that may be able to donate Windows licenses either in-kind or via financial support, please do be in touch. * Providing Windows cloud instances. If you know of an organization that may be able to donate Windows cloud instances, do holler. As always, we welcome any hardware or cloud instance contributions. Do be in touch if you may be in an position to help out. Cheers, - Ben [1] https://www.packet.com/

1 0

remAddr# primop inconsistency
by Csaba Hruska 06 Feb '21

06 Feb '21

Hello, I've discovered that the remAddr# primop documentation is inconsistent with the implementation. According to the docs (primops.txt.pp) the remAddr# should be the same as remInt#. > primop AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int# {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt Int\#}, is divided by the {\tt Int\#} arg.} > > But it is implemented with the mo_wordURem instruction, just like the WordRemOp primop. > GHC/StgToCmm/Prim.hs: > AddrRemOp -> \args -> opTranslate args (mo_wordURem platform) > WordRemOp -> \args -> opTranslate args (mo_wordURem platform) > IntRemOp -> \args -> opTranslate args (mo_wordSRem platform) > Which one is correct, the docs or the implementation? Regards, Csaba Hruska

2 2

GHC Reading Guide
by Takenobu Tani 06 Feb '21

06 Feb '21

Dear devs, I've written a simple document about "GHC source reading" for myself and potential newcomers: * https://takenobu-hs.github.io/downloads/haskell_ghc_reading_guide.pdf (https://github.com/takenobu-hs/haskell-ghc-reading-guide) Please teach me if something's wrong. I'll learn and correct them. Happy Haskelling :) Regards, Takenobu

3 3

Happy version downgrade
by Simon Peyton Jones 04 Feb '21

04 Feb '21

Friends I can't build ghc-9.0 because of this: checking for ghc-pkg matching /opt/ghc/bin/ghc... /opt/ghc/bin/ghc-pkg checking for happy... /home/simonpj/.cabal/bin/happy checking for version of happy... 1.20.0 configure: error: Happy version 1.19 is required to compile GHC. What is the easiest way to fix? I have happy 1.19.8, but it's not called plain "happy" bash$ happy-1.19.8 --version Happy Version 1.19.8 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. This program is free software; you can redistribute it and/or modify it under the terms given in the file 'LICENSE' distributed with the Happy sources. Thanks Simon

2 1

Inspecting function arguments in GHCi
by Andrew Kvapil 02 Feb '21

02 Feb '21

Hello, I'm interested in inspecting the strictness of functions at runtime and the depth of thunks "in the wild." For this reason I'm modifying GHC 8.10.2, essentially to add additional information to breakpoints. I'd like to reuse the logic behind GHCi's :print command (pprintClosureCommand, obtainTermFromId, ...) for which I suppose I need Id's. Those however don't exist for destructuring patterns, such as those in the following equations: last [x] = x last (_:xs) = last xs So I'm wondering where would be a good place in the pipeline to transform patterns like these into at-patterns, to give them Id's. However, the breakpoint logic only looks at the free variables of the right-hand sides and not transitively, which means that e.g. in the following example neither ':print arg1' nor ':print as' works when the interpreter hits a breakpoint in the top level expression on the RHS: qsort arg1@(a:as) = qsort left ++ [a] ++ qsort right where (left, right) = (filter (<=a) as, filter (>a) as) Thus I'd also like to know how to extend the free var logic for Tickish that eventually leads to CgBreakInfo and :print's ability to inspect these bindings at runtime. My goal would be to determine to what extent was a thunk evaluated during function application. Any advice would be greatly appreciated! Regards, Andrew Kvapil

4 5

Storage layout of integral types
by Stefan Schulze Frielinghaus 01 Feb '21

01 Feb '21

Hi all, I'm wondering what the supposed storage layout of integral types is. In particular for integral types with size less than the size of a word. For example, on a 64bit machine is a 32bit integer supposed to be written as a whole word and therefore as 64 bits or just as 32bits in the payload of a closure? I'm asking because since commit be5d74ca I see differently aligned integers in the payload of a closure on a 64bit big-endian machine. For example, in the following code an Int32 object is created which contains the actual integer in the high part of the payload (the snippet comes from the add operator GHC.Int.$fNumInt32_$c+_entry): Hp = Hp + 16; ... I64[Hp - 8] = GHC.Int.I32#_con_info; I32[Hp] = _scz7::I32; whereas e.g. in function rts_getInt32 the opposite is assumed and the actual integer is expected in the low part of the payload: HsInt32 rts_getInt32 (HaskellObj p) { // See comment above: // ASSERT(p->header.info == I32zh_con_info || // p->header.info == I32zh_static_info); return (HsInt32)(HsInt)(UNTAG_CLOSURE(p)->payload[0]); } The same seems to be the case for the interpreter and foreign calls (case bci_CCALL) where integral arguments are passed in the low part of a whole word. Currently, my intuition is that the payload of a closure for an integral type with size smaller than WordSize is written as a whole word where the subword is aligned according to the machines endianness. Can someone confirm this? If that is indeed true, then rts_getInt32 seems to be correct but not the former. Otherwise the converse seems to be the case. Cheers, Stefan

1 1