- ghc-devs - Haskell.org

GHC Weekly News - 2015/01/07
by Austin Seipp 08 Jan '15

08 Jan '15

Hi *, it's time for another GHC Weekly News! This week's edition will actually be covering the last two/three weeks; your editor has missed the past few editions due to Holiday madness (and also some relaxation, which is not madness). It's also our first news posting in 2015! So let's get going without any further delay! GHC HQ met this week after the Christmas break; some of our notes include: - Austin Seipp announced the GHC 7.8.4 release on behalf of the GHC development team. https://www.haskell.org/pipermail/haskell/2014-December/024395.html - Austin Seipp ''also'' announced the GHC 7.10.1 RC on behalf of the GHC team, as well. https://www.haskell.org/pipermail/ghc-devs/2014-December/007781.html - Since Austin is back, he'll be spending some time finishing up all the remaining binary distributions for GHC 7.8.4 and GHC 7.10.1 RC1 (mostly, FreeBSD and OS X builds). - We've found that 7.10.1 RC1 is working surprisingly well for users so far; to help users accomodate the changes, Herbert has conveniently written a migration guide for users for their most common problems when upgrading to 7.10.1: https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 - We're aiming to release the 2nd Release Candidate for GHC 7.10.1 on January 19th. We're hoping this will be the last RC, with 7.10.1 final popping up in the middle of February. - GHC HQ may tentatively be working to release **another** GHC 7.8 release, but only for a specific purpose: to allow it to compile with 7.10.1. This will make it significantly easier for users to compile old GHCs (perhaps on newer platforms). However, we're not yet 100% decided on this, and we will likely only do a 'very minor release' of the source tarball, should this be the case. Thanks to Edward Yang for helping with this. - For future GHC releases on Windows, we're looking into adopting Neil Mitchell's new binary distribution of GHC, which is a nice installer that includes Cabal, MSYS and GHC. This should significantly lower the burden for Windows users to use GHC and update, ship or create packages. While we're not 100% sure we'll be able to have it ready for 7.10.1, it looks promising. Thanks Neil! (For more info, read Neil's blog post here: http://neilmitchell.blogspot.co.at/2014/12/beta-testing-windows-minimal-ghc… ) There's also been some movement and chatter on the mailing lists, as usual. - GHC 7.10 is coming close to a final release, planned in February; to help keep track of everything, users and developers are suggested to look at the GHC 7.10.1 status page as a source of truth from GHC HQ: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 - Jan Stolark is currently working on injective type families for GHC, but ran into a snag with Template Haskell while trying to understand GHC's `DsMeta` module. Richard chimed in to help: https://www.haskell.org/pipermail/ghc-devs/2014-December/007719.html - Austin Seipp opened a fun vote: what naming convention should we use for GHC buildbots? After posting the vote before the holidays, the results are in: GHC's buildbots will take their names from famous logicians and computer scientists: https://www.haskell.org/pipermail/ghc-devs/2014-December/007723.html - Carter Schonwald asked a simple question: are pattern synonyms usable in GHCi? The answer is 'no', but it seems Gergo is on the case to remedy that soon enough: https://www.haskell.org/pipermail/ghc-devs/2014-December/007724.html - Anton Dessiatov has a question about GHC's heap profiler information, but unfortunately his question has lingered. Can any GHC/Haskell hackers out there help him out? https://www.haskell.org/pipermail/ghc-devs/2014-December/007748.html - Joachim Breitner made an exciting announcement: he's working on a new performance dashboard for GHC, so we can more easily track and look at performance results over time. The current prototype looks great, and Joachim and Austin are working together to make this an official piece of GHC's infrastructure: https://www.haskell.org/pipermail/ghc-devs/2015-January/007885.html - Over the holiday, Simon went and implemented a nice new feature for GHC: detection of redundant constraints. This means if you mention `Ord` in a type signature, but actually use nothing which requires that constraint, GHC can properly warn about it. This will be going into 7.12: https://www.haskell.org/pipermail/ghc-devs/2015-January/007892.html - Now that GHC 7.10 will feature support for DWARF based debugging information, Johan Tibell opened a very obvious discussion thread: what should we do about shipping GHC and its libraries with debug support? Peter chimed in with some notes - hopefully this will all be sorted out in time for 7.10.1 proper: https://www.haskell.org/pipermail/ghc-devs/2015-January/007851.html Closed tickets the past few weeks include: #8984, #9880, #9732, #9783, #9575, #9860, #9316, #9845, #9913, #9909, #8650, #9881, #9919, #9732, #9783, #9915, #9914, #9751, #9744, #9879, #9876, #9032, #7473, #9764, #9067, #9852, #9847, #9891, #8909, #9954, #9508, #9586, and #9939. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Random holiday fun: Vote for buildbot naming conventions!
by Austin Seipp 07 Jan '15

07 Jan '15

Hi *, Everyone has been working hard getting things ready for the branch/RC later this week - and that's really appreciated! As always, GHC wouldn't be what it is without you. But it's the holidays - that's stressful for some, and real time consuming for others. So to keep things light and a little interesting, and if you have a minute as an experiment, I'd like to ask you all something: What naming conventions should we use for GHC buildbots? We've been adding more bots recently, and we've just gotten hold of some new hardware this week. Currently, GHC buildbots don't have any reserved name or identifier, or DNS entries. I'd like to change that - we mostly refer to them by IP, but this is annoying A) to remember and B) to tell other people. We'll likely begin to lease out these machines to developers so they can test and debug - meaning they'll be mentioned more. I'd like to propose a theme for naming buildbots - this theme would be used to populate DNS entries under the *.ghc.haskell.org domain. The question is: what naming convention do we use? So I created a poll for this. You can see that poll and vote for your favorite options on Phabricator: - https://phabricator.haskell.org/V3 It's an approval vote rather than a plurality; so feel free to select multiple choices. The winner with the most votes will get selected. Note: the selection of options is relatively random and pre-selected; there is an upper limit on the number of choices - 10 max - so I merely picked some categories I thought would work and be generic enough. I imagine this vote will be open for about a week or so. I'd like it if developers could vote on their favorites, or simply leave comments on the vote for further suggestion - we could institute a vote with better names. Thanks all - and be sure to have happy holidays. P.S I did not know RFC 1178 existed before today. Seems like there's one for everything... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Cabal update fails
by Simon Peyton Jones 07 Jan '15

07 Jan '15

What does this mean (on Linux)? Thanks, Simon bash$ cabal update Downloading the latest package list from hackage.haskell.org cabal: <socket: 11>: resource vanished

2 2

RE: [Diffusion] [Build Failed] rGHC471891cb774a: Mark T9938 as expect_broken again
by Simon Peyton Jones 07 Jan '15

07 Jan '15

Phab says perf/compiler T3294 [stat not good enough] (normal) but it's not failing for me. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 07 January 2015 14:50 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC471891cb774a: Mark T9938 as | expect_broken again | | Harbormaster failed to build B2865: rGHC471891cb774a: Mark T9938 as | expect_broken again! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC471891cb774a | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite

1 0

Bash completion in GHC 7.10
by Lennart Kolmodin 07 Jan '15

07 Jan '15

Hi everybody! TL;DL GHC 7.10 will have better bash completion, try it out! I'd like your help to verify the categorisation of DynFlags into ghc / ghci / shared or hidden flags. I've been working on improving the command line completion support in GHC 7.10. The main idea is that it should be more convenient to use GHC from the command line, without knowing all the flags by heart. You should be able to partly type a flag and then hit TAB twice to display the possible completions. For example; $ ghc -f<TAB><TAB> If you'd like to try it out, here's what you need to do; $ cd ghc-head $ source completion/ghc.bash Et voilà! Your bash shell will now have these super powers! There's a README <https://github.com/ghc/ghc/blob/master/completion/README> with details for a permanent setup. End users should ultimately not have to do anything to get this working. Linux distributions, and packages for other OSs are responsible for copying the required file to the right location. GHC had some basic support for command line completion even before my work, but now it also includes two significant changes compared to GHC 7.8; - "ghc" and "ghci" has different completions. - GHC 7.10 will ship and maintain the necessary bash components (and the scripts you contribute for other shells!). To support different completions for ghc and ghci, the DynFlags have been annotated with which mode the flags works. How this works has been documented under "Note [Supporting CLI completion]". Essentially all flags have been divided into four groups; - Flags only useful for ghc - Flags only useful for ghci - Flags useful from both ghc and ghci - Flags that should be invisible I've made this categorisation best I could, but it'd be nice to have another few pair of eyes glance through the flags. The separation of flags is well contained within the DynFlags module, please have a look! https://github.com/ghc/ghc/blob/master/compiler/main/DynFlags.hs The work was implemented in D337 <https://phabricator.haskell.org/D337>, D532 <https://phabricator.haskell.org/D532> and D536 <https://phabricator.haskell.org/D536> and is tracked in trac #9259 <https://ghc.haskell.org/trac/ghc/ticket/9259>. Regards, Lennart

4 4

T9938 and T9939 failing
by Edward Z. Yang 07 Jan '15

07 Jan '15

Here's what I get, on a clean validate. =====> T9939(normal) 2555 of 4389 [0, 0, 0] cd ./typecheck/should_compile && '/home/hs01/ezyang/ghc-validate/inplace/bin/ghc-stage2' -fforc e-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs - fno-ghci-history -c T9939.hs -fno-warn-incomplete-patterns >T9939.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./typecheck/should_compile/T9939.stderr 2015-01-06 13:51:47.089376284 -0800 +++ ./typecheck/should_compile/T9939.comp.stderr 2015-01-06 15:24:39.923007911 -0800 @@ -1 +1,18 @@ \ No newline at end of file +T9939.hs:5:7: + Redundant constraint: Eq a + In the type signature for: f1 :: (Eq a, Ord a) => a -> a -> Bool + +T9939.hs:9:7: + Redundant constraint: Eq a + In the type signature for: f2 :: (Eq a, Ord a) => a -> a -> Bool + +T9939.hs:13:7: + Redundant constraint: Eq b + In the type signature for: + f3 :: (Eq a, a ~ b, Eq b) => a -> b -> Bool + +T9939.hs:20:7: + Redundant constraint: Eq b + In the type signature for: + f4 :: (Eq a, Eq b) => a -> b -> Equal a b -> Bool *** unexpected failure for T9939(normal) =====> T9938(normal) 3401 of 4389 [0, 1, 0] cd ./driver && $MAKE -s --no-print-directory T9938 </dev/null >T9938.run.stdout 2>T9938.run. stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:592: recipe for target 'T9938' failed Stderr: T9938.o: In function `r3Ho_info': (.text+0x52): undefined reference to `transzuH9c1w14lEUN3zzdWCTsn8jG_ControlziMonadziTransziSta teziLazzy_zdwzdcp1Alternative_info' collect2: error: ld returned 1 exit status make[3]: *** [T9938] Error 1 *** unexpected failure for T9938(normal) Edward

2 1

Re: T9938 and T9939 failing
by Mikolaj Konarski 07 Jan '15

07 Jan '15

This looks like the result of the new cool patch by SPJ that detects redundant constraints. IIRC, it was supposed to be added to -Wall, but disabled for validate, at least for packages out of our control.

1 0

Updating submodules
by Simon Peyton Jones 06 Jan '15

06 Jan '15

Herbert, or anyone, I'm very confused about the workflow for updating submodules. I want to update several (to remove redundant constraints from contexts) which are maintained by GHC HQ. But for libraries/parallel I find: * There is no .git/config in libraries/parallel. (Whereas there is for another submodule, libraries/hoopl.) * There is, however, a .git file which points to .git/modules/libraries/parallel * In .git/modules/libraries/parallel/config, I see a url of https://git.haskell.org/packages/parallel.git. But I can't push to this URL. * That matches the url in https://ghc.haskell.org/trac/ghc/wiki/Repositories, but contradicts the url in 'packages', which says ssh://git@github.com/haskell/parallel.git * I don't understand what URL should be expected for submodules with "-" in the 'upstream url' column of the 'packages' file. It says "-" means 'this is a submodule', but parallel is certainly a submodule and doesn't have "-". But so is hoopl, which does have "-". I tried a minimal change of adding pushurl = ssh://git@git.haskell.org/packages/hoopl.git to .git/modules/libraries/parallel/config. But when I tried to push I got simonpj@cam-05-unx:~/code/HEAD-2/libraries/parallel$ git push Counting objects: 7, done. Delta compression using up to 32 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 410 bytes, done. Total 4 (delta 3), reused 0 (delta 0) remote: W refs/heads/master packages/parallel simonpj DENIED by refs/.* remote: error: hook declined to update refs/heads/master To ssh://git@git.haskell.org/packages/parallel.git ! [remote rejected] HEAD -> master (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/packages/parallel.git' So I'm thoroughly stuck. I can't push my main patch until I push the submodule patches. What do I do? And would it be possible to update the wiki pages to make this clear? Especially * https://ghc.haskell.org/trac/ghc/wiki/Repositories * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules Thanks Simon

4 6

RE: breakages due to redundant constraint removals?
by Simon Peyton Jones 06 Jan '15

06 Jan '15

| ..ah, I see, so we'll need some CPP to retain compatiblity with stable | GHCs (as parallel and deepseq have -- before your commit -- been | compatible with all stable GHC 7.x releases)... yes, I suppose so. Or, I suppose, we could revert my changes to parallel and deepseq, and add -fno-warn-redundant-constraints at the top (I suppose *that* would need cpp). And then remember in n years time to take it out. Because of the n years time issue I'm inclined to the former solution, because at least it's clear: "if compiling with GHC <= 7.10, use this signature, else that one". Simon | | | | > | > Simon | > | > | -----Original Message----- | > | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | > | Sent: 06 January 2015 22:03 | > | To: Simon Peyton Jones | > | Subject: breakages due to redundant constraint removals? | > | | > | Hello Simon, | > | | > | I just noticed that your recent commit to deepseq, had a devastating | > | effect: | > | | > | https://travis-ci.org/haskell/deepseq/builds/46063392 | > | | > | | > | similiarly for parallel: | > | | > | https://travis-ci.org/haskell/parallel/builds/46062982 | > | | > | | > | ...did you notice that as well? | > | | > | Cheers, | > | hvr | | -- | "Elegance is not optional" -- Richard O'Keefe

1 0

API Annotations status report
by Alan & Kim Zimmerman 06 Jan '15

06 Jan '15

A quick status report on API Annotations. I have managed to integrate the API Annotations into the ghc-7.10 branch of HaRe [1], with a test comand to simply roundtrip the source. So the command ghc-hare roundtrip filename.hs will produce a file 'filename.refactored.hs' which should be the same as the original, except it does not preserve trailing whitespace or tabs. This makes use of the updated ghc-mod for 7.10 [2], and ghc-exactprint [3] However this only works for the ghc-7.10 branch with D538 [4] applied. Regards Alan [1] https://github.com/alanz/HaRe/tree/ghc-7.10 [2] https://github.com/DanielG/ghc-mod [3] https://github.com/alanz/ghc-exactprint/tree/wip [4] https://phabricator.haskell.org/D538

1 0