April 2015 - ghc-devs

DocBook to AsciiDoc
by Daniel Bergey 16 Apr '15

16 Apr '15

I just read that GHC wants to convert the manual to asciidoc. If no one else has yet volunteered to do this, I hearby volunteer myself. I haven't contributed to the GHC manual before, nor to GHC. I guess that I will need to learn my way around Phabricator? I expect to be proof-reading sections that I haven't read before, about GHC features I don't use. I don't expect this to be a problem, since the goal is just to match the current HTML output. I do have some experience with DocBook, Asciidoc, and Pandoc, which should be helpful. Is there anything I should convert that isn't in under the users_guide folder?[1] It looks as though the users guide gets frequent commits.[2] Does one `arc diff` per file, approximately, sound reasonable, to keep merge conflicts manageable? Anything else I should know before I begin? Who to list as reviewers? A Trac ticket to link all the asciidoc commits together? Thanks, Daniel Footnotes: [1] http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide [2] http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide

2 1

ghc-7.10 branch regression
by Erik de Castro Lopo 16 Apr '15

16 Apr '15

Hi all, It seems that commit 42448e3757 from git HEAD has been pulled into the ghc-7.10 branch as commit 07da52ce2d. This is problematic because that patch puts in a *requirement* for llvm-3.6 (which is good for git HEAD) but the llvm backend code in the ghc-7.10 branch does not compiler with llvm-3.6. Specifically, on armhf I get: /usr/bin/opt-3.6: /tmp/ghc16494_0/ghc16494_2.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} Furthermore, validating the ghc-7.10 branch on amd64-linis results in 16 unexpected failures (i'm currenty in the process of validating this branch with the problematic commit reverted). At this point we need to decide whether: a) Require llvm-3.6 for 7.10.2 and later. or b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use llvm-3.5 for the 7.10 series. For option a) we would need to do the following: * Pull in 5d5abdca31 from git HEAD that upgrades the LLVM backend to support llvm-3.6 only. * Pull in 485dba86 from git HEAD that updates the configure stuff and is really the second part of 42448e3757. For option b) we would need to do the following: * Revert 07da52ce2d from ghc-7.10 * Apply the patch mentioned here: https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11 At this point, my personal preference would be a). For me, git HEAD using llvm-3.6 has been working a lot better on armhf and arm64 than the ghc-7.10 branch. Ticket #10234 has been set to 'merge' status to refect this. Cheers, Erik PS : I would have raised another ticket about this, but I think the problem here was actually caused by too many tickets and too many commits being involved. Interesting tidbits in case anyone is interested: * On armhf, building the ghc-7.10 branch fails because we a generating LLVM IR code targeted for llvm-3.5 and trying to compile it with llcm-3.6. * The ghc-7.10 validates (with 16 unexpected failures) in x86 variants because validation uses the NCG to build the compiler and ignores the requirement for llvm-3.6, and then bindisttest compiler just uses "llc" and "opt" (in git HEAD this difference between the compiler configure script and the binary-dist configure script is fixed in 485dba86 and it is fixed in ghc-7.10 by the patch in https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11) -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 6

Building patches that change format of interface files
by Jan Stolarek 15 Apr '15

15 Apr '15

GHC Devs, Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does not work if my code changes modify the format of interface files - the resulting compiler is unusable. In fact the only way to get a working compiler after interface format change that I am aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is there a better way? I'd like to test D841 but if this means rebuilding everything then I'll have to pass. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 3

Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
by Ozgun Ataman 15 Apr '15

15 Apr '15

Hello, Apologies upfront for the long post below, but I thought our experience on this particular point might be worth sharing. I present some observations first and then mention the particular problem around "cabal repl" facilitated development workflow. Any ideas/feedback on the latter point would be much appreciated and please let me know if there are other metrics, info or output I can produce here for further investigation/clarification. Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC 7.8.4 and as a result observed a very significant slowdown in compile times. Code changes were very minimal and should not be a factor. Any mistakes below are mine, but I can fairly confidently say that there is a visible-to-the-eye slowdown in compile times. We made a few measurements to quantify the issue and here is the data: - This project has 220 direct modules (non-dependency) that are compiled with each "cabal build" and we always use sandboxes - Tests were performed on OS X, though we saw similar results on Linux - Single threaded (-j=1) wall-clock compile time has gone up by around 30% for the overall project - With O1 and -j=N, the overall wall-clock time is approximately the same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!) - With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!) - With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!) - 7.8.4: 3 min. 35 seconds - 7.6.3: 1 min. 2 seconds - Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile: - We have 10 modules that each take over 10 seconds - We have 3 modules that each take over 35 seconds - Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing: - Example with 7.6.3, O0: cabal build 140.57s user 13.25s system 100% cpu 2:33.70 total - Example with 7.8.4, O0: cabal build 507.83s user 655.43s system 549% cpu 3:31.59 total The main hurt here has been the infeasibility of using "cabal repl / ghci" fast-feedback style development (via emacs, vim, command-line, etc.), since: - Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation) - The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes. - cabal repl does not seem to benefit from -j at all - cabal repl 7.8.4 appears to be hurt particularly by the heavier modules - The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time Let me know if I'm missing anything here and any/all feedback is much appreciated! Cheers, Oz

5 6

stack traces when debugging GHC
by Richard Eisenberg 15 Apr '15

15 Apr '15

Hi devs, I've just made a miraculous discovery and I want to share! It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk). And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! I'd love to put this on the wiki. Any clue where this might be found? Richard

5 5

GHC Weekly News - 2015/04/14
by Austin Seipp 14 Apr '15

14 Apr '15

(You can find a copy of this post online at https://ghc.haskell.org/trac/ghc/blog/weekly20150414) Hi *, It's been a few weeks since the last news bulletin - your editor apologizes about that. It's actually been a relatively slow few weeks here too, and busy-ness outside of GHC has attracted some of my attention. Despite that, GHC 7.10.1 was released, a new HP alpha is out, and things are moving along smoothly. Now that the release is done, things are quitely moving along in `HEAD` - with people committing code with reckless abandon, of course. This week, GHC HQ met up, but it's been very light since the 7.10.1 release. Currently there isn't anything pushing us to do a 7.10.2 release at least for a few more weeks it looks like - but see below. - We puzzled a bit about the release status of 7.10.2, and thought: it's only holding up people who are depending on it. So, who's depending on it, and what do they need fixed? See below for more. - We also talked a bit about performance - it seems the compiler has been getting much slower over time since the 7.8.x release series, and it's time to reign it in. Austin will be spending his week investigating a bit of this, and the causes. == 7.10.2 Status == So, you may be wondering when the 7.10.2 release is. The trick is it happens when you tell us it should happen! So far, taking a look at milestone:7.10.2, we've fixed about half the bugs we currently have marked down to fix. But we're probably going to punt some of those - and we're not sure all the ones that are there should be. So this is a call: **If you need something to be fixed during 7.10.2, please file a ticket, set the milestone, and alert us**. The sooner the better, because it'll inform us as to when we should release. Emailing `ghc-devs(a)haskell.org` is also a sure-fire way to get our attention. And remember: you can always find out the latest about the next release at the Status page (in this case, for 7.10.2) - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 == Call for help: DocBook to AsciiDoc == The GHC team needs some help. A few months ago, we put out a poll to convert our DocBook-based manual to AsciiDoc. The poll had a mostly lukewarm reception, with the idea that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. It looks like we still **want** to do this - but alas, many of us don't have time! So, we're asking the public: Is anyone willing to step up and help here? For example, it may be possible to get a long ways with just `pandoc`, but we need someone to finish it - and in return, we'll help along the way! == List chatter == - Austin Seipp announced GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html - Mark Lentczner announced an alpha Haskell Platform release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html - David Macek announced MSYS2 packages for GHC on Windows, and also asked for some help with continuous windows building - Windows hackers should help out! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html - Jan Stolarek reports about increased memory usage with GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html - Thomas Miedema chimed into a thread started by Karel Gardas about better parallelizing the GHC build - and hopefully we can get something good out of it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html - Austin Seipp made a call for help on working on and improving the GHC homepage, and luckily Sergey Bushnyak answered the call and has helped out! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html - Ozgun Ataman kicked off a thread about slower compilation times, with some nasty numbers. It's becoming more clear compiler performance should be a priority for 7.12, and we've let some things slip away from us: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html - A GHC user, Dave, asked the list about some questions with Cross Compilation, as he's attempting to get GHC to work natively inside the Open Embedded build environment. Unfortunately, things haven't been going well so far, and any input from enterprising hackers is appreciated: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html - Dan Aloni has started a discussion about improving GHC's error messages, spurred by a popular blog post he wrote and posted on Reddit about some Happy/GHC improvements he's made. This is a difficult area (error messages in general are hard) to work on, so thanks to Dan for helping! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html - Simon Peyton Jones started a discussion about `GeneralizedNewtypeDeriving` and Safe Haskell, in particular, whatever the current status, our documentation doesn't accurately reflect it! Perhaps someone could help out writing the documentation based on the current status quo? https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html - Tamar Christina started a thread about replacing `ghc-split`, an old Perl script inside GHC, but he wanted to know: what do we do about a regex replacement? Mikhail Glushenkov spoke up about a similar decision the LLVM developers used: to use the OpenBSD regex implementation. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html - Alan Zimmerman has posted several questions and threads about the parser and the status of API annotations, which he's been furiously working on now that GHC 7.10 is being used on Hackage. Interested onlookers could learn a thing or two! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html - Gabor Greif has a question about some seemingly strange behavior regarding the interaction between poly-kinded `data` types and overlapping instances. Richard sez: this behavior is expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html == Noteworthy commits == - Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the story around switch cases (with a code-size improvement) - Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old `integer-gmp-0.5` source code. - Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind information generation (fixes DWARF generation) - Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug in the demand analyzer (with some nice compiler performance boosts). - Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for multiple signature files in scope (Backpack). == Closed tickets == #10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236, #10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252, #9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188, #10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286, #10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232, #10274, #10275, #10195, and #10233. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Help wanted: working on the GHC webpage
by Austin Seipp 14 Apr '15

14 Apr '15

Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of "server side include" files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4

Phabricator as bug tracker system (off topic)
by Andrés Sicard-Ramírez 14 Apr '15

14 Apr '15

Hi, (I apologise for this off topic message) >From the discussion started in https://mail.haskell.org/pipermail/ghc-devs/2014-June/005117.html, it seems GHC HQ didn't choose Phabricator as bug tracker system because migrating from Trac "...There's no real pressure to do so and it would be tons of work". Since Google is shutting down Google Code, we need to move Agda's bug tracker system from Google Code to something else. >From some preliminary investigation, it seems Phabricator bug tracker system (Maniphest) is more robust than GitHub one. I would appreciate some feedback related to Maniphest or other bug tracker system. Thanks, -- Andrés

3 3

GHC Trac down
by Simon Peyton Jones 14 Apr '15

14 Apr '15

Is GHC's Trac down again? It's not working for me. Simon

3 3

Overlapping instances for poly-kinded data
by Gabor Greif 13 Apr '15

13 Apr '15

Hi all, I observe a strange "deriving Show" behaviour for my data type Foo that has proxies: data Foo :: k -> * where Foo :: Proxy t -> Foo t deriving instance Show (Foo t) This works as expected. But now I add instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where show = ('#' :) . symbolVal instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where show = ('#' :) . show . natVal these orphan instances, and "deriving Show" won't pick them up. When I go and specialise deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat)) deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol)) then it seems to work allright. Is polykinded derivation so different from the monokinded one? Or is this simply a bug? (a more elaborate WIP example can be found here: https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn…) Cheers, Gabor

3 2