- ghc-devs - Haskell.org

GHC Weekly News - 2013/03/10
by Austin Seipp 10 Mar '15

10 Mar '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150310) Hi *, It's that time again! Today GHC HQ met on a Tuesday to avoid some scheduling conflicts, and that means it's time to send some news to people. Just a quick reminder from last week: we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. - Today, GHC HQ mostly talked about 7.10 bugs; HEAD is steaming along as usual with no impediments, but we've got several critical bugs we plan on landing fixes for this week; see milestone:7.10.1 for more. But we've also had a little more list activity this week than we did before: - Joachim Breitner asks: how do I extend the blocks in a C-- graph? Jan popped in with advice, but it looks like Joachim found a rather simple solution himself. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008467.html - Karel Gardas wrote to the list about how to better parallelize the GHC build. For background, he's using a UltraSPARC T1-CPU/T2000 server with 32 hardware threads over 8 cores, where parallelism is a bigger win than raw single-threaded performance. But despite that, the performance is of the parallel GHC build is relatively abysmal - and Karel wants help brainstorming ideas to fix it. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008474.html - Herbert Valerio Riedel noted that there are new git hooks in place for all developers on `git.haskell.org`, which will reject new kinds of pushes. In particular, Herbert took the time to implement commit message validation, and whitespace validation. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008480.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit eb3661f2b9f8472f3714774126ebe1183484dd85 - Re-export `<$>` from Prelude (#10113) - Commit 479523f3c37894d63352f1718e06696f3ed63143 - Re-export `<$` from Prelude (#10113) - Commit b359c886cd7578ed083bcedcea05d315ecaeeb54 - Custom `Typeable` solver, that keeps track of kinds (#9858) - Commit 76b1e11943d794da61d342c072a783862a9e2a1a - Improve core linter so it catches `unsafeCoerce` problems (#9122) - Commit 7a2d65a4d93273c89fbb1d19e282d5933c67c7ca - Define proper `MINIMAL` pragma for `class Ix` (#10142) Closed tickets the past week include: #7854, #10118, #10119, #3321, #10132, #9987, #10126, #9707, #10142, #10147, #10113, #9524, #10058, #10100, #2991, #10140, and #9122. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: [Haskell-cafe] ghc -O2 out of memory
by Carter Schonwald 10 Mar '15

10 Mar '15

there SHOULD be a 32bit 7.8.4 build available somewhere for windows, and if not , thats a real problem! I'm gonna shift this thread to ghc-devs, because that *should* get addressed @ghc-devs, how can we help this user get ahold of a 32bit windows 7.8.4 build? (eg, why do we not have one available yet?) -Carter On Mon, Mar 9, 2015 at 4:13 AM, Kees Bleijenberg <K.Bleijenberg(a)lijbrandt.nl > wrote: > Thanks for your answer. > > I also use ghc to create 32 bits dll’s. 7.8.4 is 64 bits GHC and can’t > create 32 bits dll’s (?). This means I have to install 7.8.3 and 7.8.4 on > the same Windows machine. Is this possible? > > > > Kees > > *Van:* Carter Schonwald [mailto:carter.schonwald@gmail.com] > *Verzonden:* zaterdag 7 maart 2015 20:02 > *Aan:* Kees Bleijenberg > *Onderwerp:* Re: [Haskell-cafe] ghc -O2 out of memory > > > > Upgrade to ghc 7.8.4, theres some known bugs in O2 optimization that > resulted in excessive memory usage that are fixed in 7.8.4 > > You'll still have painful compilation times with a 30kloc module , but > memory usage should be physically possible after the upgrade. > > On Mar 7, 2015 10:58 AM, "Kees Bleijenberg" <K.Bleijenberg(a)lijbrandt.nl> > wrote: > > I’ve written a program that reads a Excel file, parses the contents and > generates a haskell module. Every cell in the xls has it’s own function in > the module. This worked fine. > > Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines > haskell code (without comment). I created a testprogram test.hs that > calculates and prints one cell. > > I did ghc --make test.hs and everything works fine. The generated > execuatable is very slow. > > I did ghc --make –O2 test.hs. The compilations takes 15 minutes and aborts > with ‘ghc: out of memory’. I’am working on Win 7 64 bits , ghc version = > 7.8.3. > > > > What can I do to fix this? I do need –O2. I found with smaller xls’s that > optimization speeds up the executable dramatically. > > Before I start experimenting, does it help to split up the xls .hs in > seperate files? I.e. the cells that refer to other cells and cells that > don’t refer to other cells. Or will I still get ‘out of memory’ because the > optimization is global? > > > > Kees > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5751 / Virus Database: 4299/9258 - Release Date: 03/09/15 >

2 1

HEADS-UP: new Git hook linters for whitespace & commit msgs
by Herbert Valerio Riedel 09 Mar '15

09 Mar '15

Hello GHC devs, I finally got to finish reworked Git hook validations[1] which are active effective immediately for the ghc.git repo: - A new whitespace linter that enforces 3 separate in variants for files with the suffixes .hs .hsc .lhs .cabal .c .h .lhs-boot .hs-boot .x .y the 3 invariants (i.e. if the particular invariant held before the commit, it ought to hold afterwards as well): 1. no TABs 2. no trailing whitespaces (NEW) 3. no missing final EOL (NEW) - A new commit msg linter The rationale is explained in http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html TLDR: The structural conventions enforced by the new linter avoid messing up the output of Git tooling; Editors with support for commit-msg syntax-coloring like Vim or Emacs also follow these conventions. This linter has soft (-> warnings) and hard limits (-> error/rejection) The most important hard limits are: - subject line (i.e. 1st line) 80-char max length (& 8-chars min len) - 2nd line must be empty (if it exists) - body lines (i.e. 3rd+ lines) 100-char max length For more details about additional checks see actual code in [1]; the linter tries to give verbose error/warning messages and pointing exactly to the offending lines. Comments/suggestions/debate/pull-requests/etc welcome! PS: the new validators can easily be tested locally on a Git tree (although I've only tested this on Linux): usage: validate-whitespace <git-dir> [<commit-id>+] and you can pass symbolic refs such as 'HEAD' for the <commit-id>, e.g. validate-whitespace ~/Work/ghc-tree/.git HEAD Cheers, hvr [1]: https://github.com/haskell-infra/git-haskell-org-hooks/tree/master/src

3 3

Trac slow again
by Simon Peyton Jones 09 Mar '15

09 Mar '15

Is it just me, or is GHC's Trac taking multiple seconds just to serve up a web page? Simon

2 1

Pattern matching and GADTs
by Simon Peyton Jones 09 Mar '15

09 Mar '15

GHC developers You may be interested in this paper, submitted to ICFP GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness<http://research.microsoft.com/%7Esimonpj/papers/pattern-matching>, with Georgios Karachalias, Tom Schrijvers, and Dimitrios Vytiniotis. It describes a GADT-aware algorithm for detecting missing and redundant patterns. The implementation is not yet up to production quality, but it will be! If you feel able to give us any feedback about the paper itself, that would be incredibly useful. Thanks Simon

2 4

Re: How to better parallelize GHC build
by Karel Gardas 09 Mar '15

09 Mar '15

Hi Andrey, great to hear that you will find some time for Shaking ghc in the near future and even that you aim to commit first version around April. This is just in a month and half time. Great! I'll see what it will brings us, certainly will test it's paralellization capability and will report. BTW: I've already tested that, but it looks like it counts with ghc-stage1 compiler being already built so I guess this is just a first step with the idea to shake some ghc library... Thanks! Karel On 03/ 7/15 11:56 PM, Andrey Mokhov wrote: > Hi Karel, > > One of the main goals of the Shaking up GHC project is getting all the dependencies right, which should allow for more parallelism. (Another, and perhaps even more important goal is to make the build system comprehensible/easier to maintain.) > > The project is currently interrupted as I had to return to my university job for a period of time, but the aim is to push the first working version to the GHC tree around April. > > Regards, > Andrey > >>> [...] >>> >>>> Is there anything else which may be done to fix that issue? Is someone >>>> already working on some of those? (I mean those reasonable from the >>>> list)? >>> >>> are you aware of >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Building/Shake >>> >>> and >>> >>> https://github.com/snowleopard/shaking-up-ghc >>> ? >> >> I am. Is this agreed way among the GHC developers? I was not sure so I >> mentioned shake just lightly... >> >> Thanks, >> Karel >> > >

1 0

Spurious harbormaster failures
by Edward Z. Yang 07 Mar '15

07 Mar '15

Here is a recent Harbormaster build, where the validate succeeded, but after the storage failed. https://phabricator.haskell.org/harbormaster/build/3329/ Edward

2 1

Hoopl advice: How to extend the graph?
by Joachim Breitner 06 Mar '15

06 Mar '15

Dear devs, I haven’t worked with our Cmm representation before, so I have a beginner question: What function I should reach for when I want to look at each block (or each Last node) in an CmmGraph, possibly modifying it and possibly adding auxillary nodes on the way? It seems that one could use dataflowPassFwd for it, but * I could not find any use of it, and * I do not need to run an analysis along, I just want to rewrite the blocks, so I am not sure if this is the right thing. Any pointers? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 4

Re: freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556, Success
by Karel Gardas 05 Mar '15

05 Mar '15

Hi, due to recent switch to full testsuite run, our buildbots now provides a lot of output due to much more failing testcases. The case with FreeBSD buildbots even got so far, that server can't handle amount of data and leaks some binary trash to the log. I would really be curious if this is a leak of runtime memory and so it shows serious bug somewhere in GHC rts or what is it exactly... If you are curious investigate output attached to the last night freebsd buildots status emails. Thanks, Karel PS: I'm assuming the builder infrastructure as run by Gabor on his server is still written in Haskell and compiled by GHC... On 03/ 4/15 04:49 AM, Builder wrote: > freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556 > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/556.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading tarball source | Success > testing bindist | Success > testing | Success > testsuite summary | Success > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/556.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-builds

2 2

Fwd: PSA: building HEAD with Nix/NixOS
by member MP2E 05 Mar '15

05 Mar '15

Looks great, thank you! One question however, in one of the lines you have this command: 'nix-build '<nixpkgs>' -A haskell-ng.compiler.ghcHEAD --run-env -I /home/user' Is nix-build supposed to be nix-shell? Usage afterwards seems to indicate that it is, but I'm not 100% sure. On Tue, Mar 3, 2015 at 3:32 AM, Nikita Karetnikov <nikita(a)karetnikov.org> wrote: > I've just added instructions showing how easy it is to build GHC HEAD > and its dependencies with Nix/NixOS: > > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS > > I hope someone finds them useful. > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

1 0