- ghc-devs - Haskell.org

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

Wildcard refactor
by Simon Peyton Jones 18 Nov '15

18 Nov '15

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 1

Re: Window build broken
by Ryan Scott 18 Nov '15

18 Nov '15

Wow, I happened to try building GHC on Windows for the first time ever today, and I also experienced this error :) Interestingly, someone reported a very similar error to this on Trac, but for GHC 7.8.3 [1]. Here's where the error message comes from [2] in Linker.c: static int verifyCOFFHeader (COFF_header *hdr, pathchar *fileName) { if (hdr->Machine != 0x8664) { errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName); return 0; } ... } Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10437 [2] https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rt…

3 2

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1
by Richard Eisenberg 18 Nov '15

18 Nov '15

On Nov 4, 2015, at 11:12 AM, Peter Trommler <Peter.Trommler(a)th-nuernberg.de> wrote: > It looks like a bug to me. I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. I tend to agree -- I was surprised to see this, but I'm almost-totally clueless about these things. Thanks for the info, Richard PS: There's been much muttering about call stacks and DWARF. I haven't a clue what DWARF is, but I always assumed that this nice feature would not be available on Macs. What I realized today is that this assumption likely stems from the fact that ELF is not for Mac. ELFs and DWARFs tend to be found near one another in other settings, but perhaps this fact doesn't carry over to computer architectures. :) > > Cheers, > > Peter > >> On 04.11.2015, at 16:46, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >> >> I can't build 7.10.3 RC1 because I don't have readelf. ./configure says this: >> >>> checking for readelf... no >>> configure: error: cannot find readelf in your PATH >> >> A (very) quick search has turned up no help. I'm worried that my problem is that I'm still running Mac OS 10.8.5 (Snow Leopard? I never could keep track of all the animals... and now mountains.) I *really* don't want to upgrade, as I tried 10.9 once and it brought my system to its knees... had to reformat to downgrade back to 10.8. >> >> Help? >> >> Thanks! >> Richard >> > > > > -- > Prof. Dr. Peter Trommler email: peter.trommler(a)th-nuernberg.de > Technische Hochschule Nuernberg phone: +49-911-58 80-16 63 > Faculty of Computer Science fax: +49-911-58 80-56 66 > Postfach 31 03 20, 90121 Nuernberg office: Hohfederstrasse 40, 90489 Nuernberg > >

3 2

too many lines too long
by Richard Eisenberg 17 Nov '15

17 Nov '15

Hi devs, We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > Before your patch, 15 of the edited lines were over 80 characters. > Now, a whopping 28 of them are. Can't you do better? Please? Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) What do others think? Thanks, Richard

17 23

Further custom type error questions
by Ben Gamari 17 Nov '15

17 Nov '15

While preparing some additional documentation for Iavor's custom type errors work (which has been merged; thanks Iavor!) I noticed that Dominique Devriese has raised some additional questions on the proposal [1]. In particular, Dominique suggests that perhaps TypeError should simply be of kind `ErrorMessage -> Constraint`. My understanding of the proposal is that the intention is that `TypeError`s should be usable on the RHS of type functions, like `error` on the term level. However, is this strictly necessary? Is there any place where you couldn't just as easily express the `TypeError` as a constraint? If not, it seems like this may be substantially simpler approach and totally side-steps the detection of `TypeError` in inappropriate places on the RHS. Regardless, it seems like this (and the other questions) is worth addressing in the proposal. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#Somedesignq…:

5 4