- ghc-devs - Haskell.org

linker_unload
by Simon Peyton Jones 08 Jan '15

08 Jan '15

I'm getting this for test linker_unload on Linux. I'm sure it's not my fault! But it makes validate fail Simon Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 *** unexpected failure for linker_unload(normal)

6 18

Windows build gotchas
by Martin Foster 08 Jan '15

08 Jan '15

Hello all, I've been spending some of my winter break trying my hand at compiling GHC, with a mind to hopefully contributing down the line. I've got it working, but I ran into a few things along the way that I figure might be worth fixing and/or documenting. In the approximate order I encountered them: - The first pacman mirror on the list bundled with MSYS2 is down, with the result that every download pacman makes takes ~10sec longer than it should. It downloads a lot, so that really adds up - but it's easy to fix, just "pacman -Sy pacman-mirrors" before doing anything else with it. Is that worth mentioning on the wiki? I was thinking a line on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows could be helpful. - That page mentions "If you see errors related to fork(), try closing and reopening the shell" - I've determined that you can reliably avoid that problem by following the instructions at http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/#iii-updating-pack…, ie by running "pacman --needed -S bash pacman msys2-runtime", then closing & re-opening the MSYS shell, before you tell pacman to install the GHC prerequisite packages. - A minor point: I found it helpful to include "man-db" in the list of packages to install - without it, "git help" breaks down with " failed to exec 'man'". - I note "./sync-all --help" says, under "Flags", that "--windows also clones the ghc-tarballs repository (enabled by default on Windows)", and I've confirmed that default behaviour experimentally - but https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources tells you to manually clone ghc-tarballs when on Windows. Is that line on the wiki obsolete, or am I overlooking something? - And finally, the big one: cabal and/or ghc-pkg put some files outside the MSYS root directory, and caused me no end of trouble in doing so... I made a bit of a mess at one point, and tried to fix it by starting over completely from scratch. I expected uninstalling & reinstalling MSYS to achieve this (it deletes its root directory when you uninstall it), but that left me with a huge pile of errors when I tried to run "cabal install -j --prefix=/usr/local alex happy", of the form "Could not find module `...': There are files missing in the `...' package". I noticed that the cabal output made reference to "C:\Users\Martin\AppData\Roaming\cabal\", so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, "%APPDATA%\cabal", there were also files left over in "%APPDATA%\ghc". Once I removed that directory as well, things started working again - but it took me a lot of time & frustration to get there. I'm not entirely sure, but I think the copy of Cabal I already had from installing the Platform may also have been storing files in those directories, in which case this process completely mangled them - which isn't great. It seems to me that, ideally, the "build GHC inside MSYS" procedure would keep itself entirely inside the MSYS directory structure: if it were wholly self-contained, you'd know where everything is, and it couldn't break anything outside. As far as I can tell, the only breach is those two directories courtesy of Cabal, so I didn't think it would be too difficult - but none of the things I've tried (the --package-db cabal flag, a custom cabal --config-file, setting the GHC_PACKAGE_PATH environment variable, maybe some others I've forgotten) had the desired effect. Is it possible? Is it even a good idea? If that's just how it has to be, I feel like there should be an obvious note somewhere for the sake of the next person to trip over it. I'd be happy to amend the wiki for any/all of the first four points, if people think it'd be appropriate; I'm not sure at all what to do about the last one. Any thoughts? - Martin

3 3

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