December 2017 - ghc-devs

GHC's module hierarchy
by Simon Peyton Jones 03 Oct '19

03 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

perf.haskell.org functional again
by Joachim Breitner 30 Nov '18

30 Nov '18

Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms. I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't). Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned. Enjoy, Joachim

5 11

Re: [GHC DevOps Group] Release policies
by Boespflug, Mathieu 20 Feb '18

20 Feb '18

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Hi Mathieu, > > On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu <m(a)tweag.io> wrote: >> it's worth thinking about asking that >> the versions of all upstream packages only make it into GHC, at the >> behest of their respective maintainers, after a new release of >> upstream is made. > > Let me try to formulate the invariant such a procedure would demand: > > That would require a guarantee that the APIs provided by GHC (mostly > ghc-prim/base, but possibly more, including other boot libs; as well > as GHC's own behaviour) my package(s) rely upon are frozen to the > point that any such release of my packages advertising compatiblity > with the imminent GHC release will remain compatible with said final > GHC release. > > Is this something you're ready to guarantee? That's exactly it: a tradeoff. As you note, any package release now can't possibly anticipate all changes in future GHC. Furthermore, if a new GHC feature crucially depends on upstream but no upstream release is available yet, under this proposal merging the new GHC feature would need to be delayed. But on the other hand, if indeed GHC is to have more frequent releases, we can't have a GHC release perennially held up by upstream maintainers cutting their own releases one after the other, or worse still, releases happening *after* it already shipped in GHC as we just saw, or with breaking changes not announced to downstream tooling authors ahead of time. This is a problem that was brought up by Ben at ICFP, and again here. It's a problem relevant to the discussion at hand, which started as the result of upstream releases showing up on Hackage long after the release, and downstream tooling authors not afforded any advance notice to adapt. When this was brought up at ICFP, several GHC DevOps Group members recommended to Ben that he avoid needing *any* cooperation from upstream maintainers on the critical path towards a release. Of the packages you mention, base can't introduce breaking changes without a grace period. Are any upstream packages that closely tied to ghc-prim etc that a breaking change in the latter is likely between feature freeze and the release date? On the off-chance that a BC change does happen, package releases are cheap, so would that really be a problem? If a package is that closely tied to ghc-prim, base or any other boot lib, and conversely GHC is closely tied to it, then shouldn't that package just be part of the GHC codebase proper, rather than managed separately outside of GHC devs' control?

6 9

Nested CPR patch review
by Matthew Pickering 30 Jan '18

30 Jan '18

Hi all, I recently resurrected akio's nested cpr branch and put it on phabricator for review. https://phabricator.haskell.org/D4244 Sebastian has kindly been going over it and ironed out a few kinks in the last few days. He says now that he believes the patch is correct. Is there anything else which needs to be done before merging this patch? Simon, would you perhaps be able to give the patch a look over? Cheers, Matt

3 5

[ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 23 Jan '18

23 Jan '18

The GHC development team is pleased to announce the first alpha release of the 8.4.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha1 Note that this release drops compatibility with GCC 4.6 and earlier. While we generally try to place as few constraints on system toolchain as possible, this release depends upon the __atomic__ builtins provided by GCC 4.7 and later (see #14244). === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceeded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes in to users hands and allow better feedback on the status of the release. GHC 8.4 is slated to be released in mid-February but, due to technical constraints, we are starting the alpha-release cycle a bit later than planned under the above schedule. For this reason, it would be greatly appreciated if users could put this alpha through its paces to make up for lost time. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

4 7

Re: [ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 31 Dec '17

31 Dec '17

Emanuel Borsboom <manny(a)fpcomplete.com> writes: > Hi Ben, > > Are there any plans to start releasing Linux bindists linked with > libncurses.so.6? A number of Linux distributions have upgraded from 5, > including Fedora, Arch and Gentoo, and the currently available > official bindists don't work out of the box on those anymore. > Indeed I can add an ncurses.so.6 platform to the build matrix. I'll start with the next alpha. Thanks for mentioning this! Cheers, - Ben

1 0

Naming of HEq_sc
by Matthew Pickering 30 Dec '17

30 Dec '17

Hi all, Does anyone know why the *record selector* `HEq_sc` started with a capital letter? Would it be sensible to rename it to start with a lower case letter and perhaps mention that it is a selector in the name? git grep "HEq_sc" doesn't yield any explanation, I could only work this out from reading the source doe. I propose "heq_sel" could be more self-explanatory. Cheers, Matt

2 2

validate failure on Mac OSX for ghc head (validate fails with clang)
by Carter Schonwald 30 Dec '17

30 Dec '17

hey All, the current settings for warnings etc for ghc validate do not work on mac, this is because some gcc flag isn't in clang, or vice versa, or some version of gcc related matter the relevant error is: error: unknown warning option '-Werror=unused-but-set-variable'; did you mean '-Werror=unused-const-variable'? [-Werror,-Wunknown-warning-option] the culprit seems to be apple clang, at least if my reading of the config output by validate is correct Configure completed successfully. Building GHC version : 8.5.20171223 Git commit id : d7d0aa316f9d23d73ae617e0cc1b147907667ef4 Build platform : x86_64-apple-darwin Host platform : x86_64-apple-darwin Target platform : x86_64-apple-darwin Bootstrapping using : /Users/carter/.install-ghc/ghc-8.2.2-hq/bin/ghc which is version : 8.2.2 Using (for bootstrapping) : /usr/bin/clang Using gcc : /usr/local/bin/gcc-7 which is version : 7.2.0 Building a cross compiler : NO Unregisterised : NO hs-cpp : /usr/local/bin/gcc-7 hs-cpp-flags : -E -undef -traditional there seem to be several take aways: 1) clang doesn't support unused-but-set-variable 1.5) no one has run validate on OSX in the past few months with a vanilla checkout / env? 2) how do i change the compiler selected for boot strapping, whether via env variables or other twiddles thanks! -Carter

2 3

RE: Haskell Platform 8.2.2 - virus?
by Gershom B 29 Dec '17

29 Dec '17

Note that HitmanPro has caused plenty of problems with GHC in the past, and should be avoided by Haskell devs: https://www.reddit.com/r/haskell/comments/77from/gettting_segmentation_faul… https://github.com/commercialhaskell/intero/issues/436

3 2