November 2015 - ghc-devs

spj-wildcard-refactor
by Simon Peyton Jones 20 Nov '15

20 Nov '15

Status on my spj-wildcard-refactor patch · I’m down to one test failure a modest perf regression on T3064. This is really a test of type family reduction which is nothing to do with my changes, so I have no idea what’s happening there. I’m waiting till I can build a profiled compiler to test. What’s the best workflow for to take my branch with tons of wibble-ish patches, and commit to HEAD with a small number of sensible patches. I was thinking: · Git checkout wip/spj-wildcard-refactor · Git merge master · Git reset master (leaves working files alone) · Now commit patches Is that right? Simon

3 2

Profiled build
by Simon Peyton Jones 20 Nov '15

20 Nov '15

I can’t build a profiled HEAD compiler. In validate.mk I put GhcProfiled = YES GhcStage1HcOpts = -DDEBUG GhcStage2HcOpts = -fprof-auto GhcLibHcOpts += -Wwarn GhcLibWays += p But then ‘sh validate –fast’ gives rts/RtsFlags.c: In function ‘read_heap_profiling_flag’: rts/RtsFlags.c:1562:26: error: error: assignment discards ‘const’ qualifier from pointer target type [-Werror] rts/RtsFlags.c:1565:27: error: error: assignment discards ‘const’ qualifier from pointer target type [-Werror] cc1: all warnings being treated as errors `gcc' failed in phase `C Compiler'. (Exit code: 1) Does anyone have ideas for how to fix this? Simon

2 2

Feature status for GHC 8.0
by Ben Gamari 19 Nov '15

19 Nov '15

tldr. Please let us know the status of your patches for GHC 8.0. Hello everyone! You are receiving this message because you responsible for one of the in-flight items on the GHC 8.0 roadmap [1]. As you may know, the release is quickly approaching and we'd like to have final patches up for review in the next week or so. Until then we'd like to get an idea of how your various projects are progressing. Below is a list of the projects which we believe are still in progress along with my understanding of the state of your work. If you see your name in this list please let us know how things are going. * OverloadedRecordFields Adam Gundry Documentation needed Full ORF not happening? * Kind equality Richard Eisenberg Patches coming soon? * GADT pattern matching rework George Karachalias How is this coming along? * LLVM backend Austin Seipp Patches coming * Pattern synonyms Matthew Pickering Documentation needed (ongoing work in D1325) * Backpack work Edward Z. Yang How is this coming along? * Compact regions Giovanni Campagna Patches need revision Edward Z. Yang * Type signature sections Herbert Valerio Riedel Not pushing for 8.0? * DWARF-based stack traces and Ben Gamari statistical profiling Patches slowly being merged Documentation needed Thanks for all of your hard work! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

4 4

RE: About Feature status for GHC 8.0
by Simon Peyton Jones 19 Nov '15

19 Nov '15

1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. Yes: provided it all validates, just commit it. It’s already a substantial improvement over what we have right now. I’d still like to understand why putting literals in guards rather than in patterns makes performance worse. But that should not stand in the way of getting it in. Still I hope you won’t drop the investigation altogether. I suspect that making literals-in-guards work acceptably well will improve performance all round. 1. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? Yes I think so. Simon From: George Karachalias [mailto:george.karachalias@gmail.com] Sent: 18 November 2015 19:49 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Tom Schrijvers <tom.schrijvers(a)cs.kuleuven.be>; Dimitrios Vytiniotis <dimitris(a)microsoft.com> Subject: About Feature status for GHC 8.0 Hello Simon, I got the mail from Ben Gamari about the state of our patch (since GHC 8.0 release is approaching) and I would like to respond to Ben tomorrow about it. Current State As you have probably noticed, I reverted back to the last commit (just revert, I did not rewrite history) that was able to bootstrap the compiler. This means that literals are currently in the pattern syntax. I could not find why moving literals to the solver generated so many problems. The only thing that I didn't have the time to address yet is warnings for data families but the deadline is close so I will look into that. Performance of current implementation When I started the implementation, I branched on this commit (it was the HEAD at the time): https://git.haskell.org/ghc.git/commit/b14dae3cc43572a9dd5ca11241981105e428…<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.haskel…> For some time now I was under the impression that our checker consumes a lot of memory because we had many perf-failures from the test suit. Yet, I ran the test suite with the above version of GHC. The performance tests from the test suite that fail for our implementation fail for that as well. Hence, I do not think that it is our problem exactly, I expect GHC's current HEAD to perform OK, and when merging I do not expect any performance problems from our checker (the only performance test we fail is testsuite/tests/perf/compiler/T5642.hs which has pattern matching on ~100 constructors and also nested pattern matching so I think that it makes a lot of sense to consume more memory on this one). More importantly, what should my response to Ben be? Many users are expecting the new checker so I would like to merge what we have when I finish the data families handling. I would like to drop the literals from patterns but for now I think that having the improved checker in GHC 8.0 is more important. We can always make it more generic in the future. To wrap things up: 1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. 2. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? George -- things you own end up owning you

1 0

RE: Window build broken
by Tamar Christina 19 Nov '15

19 Nov '15

Hmm, Presumably Simon didn't change this. Maybe the msys2 install is broken? TamarFrom: David Macek Sent: ‎18/‎11/‎2015 09:35 To: Simon Peyton Jones; lonetiger(a)gmail.com; ghc-devs(a)haskell.org Subject: Re: Window build broken On 18. 11. 2015 9:29, Simon Peyton Jones wrote: > It’s msys2. I don’t have Cygwin on this machine. I have no idea where that prompt comes from, but I agree it’s suspicious. Looks like your /etc/fstab is wrong. There should be a line like this one, that removes the `cygdrive` prefix from Windows drive/letter mounts: none / cygdrive binary,posix=0,noacl,user 0 0 -- David Macek

3 3

Re: [ANNOUNCE] 7.10.3 release candidate 3
by Gershom B 19 Nov '15

19 Nov '15

The link provided for rc3 (https://downloads.haskell.org/~ghc/7.10.3-rc3/) appears to be empty at the moment. However I have had success with a different link: https://downloads.haskell.org/~ghc/ghc-7.10.3-rc3/ Cheers, Gershom

2 1

HEADS UP: Phabricator will be moving to a new server soon.
by Austin Seipp 18 Nov '15

18 Nov '15

Hi *, After talking with Ben today, I'll be moving the Phabricator server to a new host Real Soon. Our current load has outgrown the very basic server we've been using for the past year. It's worked fine, but occasionally it cuts into swap space, causing things like request timeouts or errors. This is particularly noticeable on things like extremely large diffs, which we tend to have a handful of. This is also the first step in a two-part upgrade to the system, which I'd like to carry out sometime within the next week. The next step will be to upgrade our Phabricator to the latest version available upstream. Why have we held off on this? The primary reason is that Harbormaster, the component that does our builds, has undergone a very large rewrite. This was expected to happen, and for the most part the new implementation is *far* better in many measurable ways. It has taken some time, but I think it's now in a usable state for replacing our current system. I didn't want to upgrade it and take away one of the more useful features in the mean time. I will reply to this email with an exact time slot on the server migration. I'll have to push over a few gigs of data and resync it after taking down the HTTP server, so I imagine the downtime window will be small (< 1hr). The upgrade to Phabricator itself will come with many benefits, including: - The patch-build process will be more robust - buildbots should no longer need 'arc patch'. Phabricator will stage diffs in a special 'staging area' repository it manages, and you will be able to 'git pull' patches people post, directly into your tree! - More scalable build machine management. We will transparently be able to add new devices into a 'pool' of machines. For example, there could be 3 ARM devices in the 'ARM pool' and 10 x86 machines in the 'x86 pool'. These pools have machines leased out appropriately to build jobs. That means if you have *any* internet-addressable machine with some spare disk space/CPU, it can be added easily at a low cost, expanding our infrastructure. - A Mac Mini is now available for us to do builds on! I'll be turning it on along with this. And if you have your *own*, internet-addressable Mac - we can use that too! - Better build security, and CI builds for 'master' will be separated (on different machines) from (possibly hostile) patch builds. - We should be able to afford a significantly better set of Linux build machines. Harbormaster can do patches and commits in about ~30 minutes. Why not go for ~10min in the common case? :) - Remarkup now supports 'figlet' and 'cowsay' syntax, allowing you to Moo to your hearts desire, or give someone advice with large, 8-bit retro-style ASCII font rendering. There will be some other fun stuff coming down the pipe soon (a 'merge this patch' button directly in Phabricator, and on-demand build machines for even better performance are two examples). That's all for now! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)
by Simon Peyton Jones 18 Nov '15

18 Nov '15

Matthew, | Remove PatSynBuilderId Thanks for doing this. But it can be simpler still! Suggestion: - remove the new 'labels' field from RecordCon; you only use it in dsExpr - In dsExpr, use the hsRecFieldSel of the first item in 'rbinds' to get a selector-Id - Inside that selector-Id you'll find RecSelId IdInfo; you can use that to get the labels. Would that work? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 07 November 2015 23:50 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab3b4%2fgh | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe4c08d2 | e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKcBoN17ALE | MES4qFLtEuWiJakOotW0IUM%3d | | >--------------------------------------------------------------- | | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | Author: Matthew Pickering <matthewtpickering(a)gmail.com> | Date: Sat Nov 7 23:46:03 2015 +0000 | | Remove PatSynBuilderId | | Summary: | It was only used to pass field labels between the typechecker and | desugarer. Instead we add an extra field the RecordCon to carry this | information. | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: thomie | | Differential Revision: https://phabricator.haskell.org/D1443 | | GHC Trac Issues: #11057 | | | >--------------------------------------------------------------- | | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | compiler/basicTypes/Id.hs | 11 +---------- | compiler/basicTypes/IdInfo.hs | 3 --- | compiler/deSugar/Coverage.hs | 5 +++-- | compiler/deSugar/DsExpr.hs | 4 +--- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 4 +++- | compiler/hsSyn/HsExpr.hs | 4 +++- | compiler/hsSyn/PlaceHolder.hs | 2 ++ | compiler/parser/RdrHsSyn.hs | 4 ++-- | compiler/rename/RnExpr.hs | 6 +++--- | compiler/typecheck/TcExpr.hs | 5 +++-- | compiler/typecheck/TcHsSyn.hs | 4 ++-- compiler/typecheck/TcPatSyn.hs | | 14 ++++++-------- | 13 files changed, 30 insertions(+), 38 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies-harder - | -ignore-space-at-eol --cc 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe | 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFFBiglS%2b | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d

3 5

Window build broken
by Simon Peyton Jones 18 Nov '15

18 Nov '15

Sigh. My Windows build is broken. See below. Any ideas? The stage2 complier in non-interactive mode works ok. It’s just ghci fails. What does “Not x86_64 PEi386” mean? What can I do to fix? I should say that my laptop broke so this is a new Windows machine, presumably with a slightly different config… Simon ./inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151117: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 7.11.20151117 for x86_64-unknown-mingw32): loadObj "C:\\code\\HEAD-1\\libraries\\ghc-prim\\dist-install\\build\\HSghc-prim-0.5.0.0.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.5.0.0.o: Not x86_64 PEi386 /cygdrive/c/code/HEAD-1$

5 8

RE: Wildcard refactor
by Simon Peyton Jones 18 Nov '15

18 Nov '15

It does, yes. It’s on 0d157fe, which is the head of wip/spj-wildcard-refactor in the haddock repo Is that what get checked out by ‘git submodule update”? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] Sent: 18 November 2015 10:57 To: Simon Peyton Jones Subject: Re: Wildcard refactor I found the haddock library did not compile, but I am skipping straight to the tests. Does it compile for you at the moment? On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Thank you! From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com<mailto:alan.zimm@gmail.com>] Sent: 18 November 2015 10:04 To: Simon Peyton Jones Cc: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Wildcard refactor ok. I have been waiting to jump in and help. Alan On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Alan I’m really close on wip/spj-wildcard-refactor, that I really want to get into HEAD asap. Could you possibly checkout wip/spj-wildcard-refactor, and validate? I get two failures I don’t understand: ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stderr] (normal) The output is not wildly different but I just don’t know how to interpret it, so I don’t even know what the problem is exactly. NB: you’’ll need to do a ‘git submodule update’ because the haddock submodule changes. Thank you! Simon

2 2