April 2017 - ghc-devs

Constraint solver iterations
by amindfv＠gmail.com 27 Apr '17

27 Apr '17

To build the 'vivid' package (on Hackage) with recent versions of GHC (I believe the problem is with 8.0+, didn't see it before then), I need to compile with -fconstraint-solver-iterations=0. (0 meaning unbounded) However, I noticed today that the GHC docs say "Typically one iteration suffices; so please yell if you find you need to set it higher than the default." The code (in Vivid.SynthDef.FromUA) uses a large amount of type family recursion. Is this not a case where I should be yelling? If I should be, I can provide a smaller repro case. If this is expected, are there techniques for rewriting the code in a way that'll fit under the default number of iterations? I've tried rewriting, making the number of iterations logarithmic instead of linear (e.g. by appending lists instead of cons-ing), but still hit the problem (even with an increased but bounded number of iteration steps). Thanks! Tom

2 1

Re: Re: Re-compiling wired-in packages
by Shao Cheng 25 Apr '17

25 Apr '17

Hi, > I did just that recently, see > https://github.com/nomeata/veggies > for how I did it, in particular boot.sh. Thank you for your work! I looked at boot.sh, and tried the "ghc Setup.hs && ./Cabal" approach. It works for ghc-prim & integer-simple, but not base. Since porting gmp to my target platform is hard, I chose integer-simple, and "./Cabal build" produces the following error message for base: Preprocessing library for base-4.10.0.0.. Building library for base-4.10.0.0.. [ 1 of 238] Compiling GHC.IO[boot] ( GHC/IO.hs-boot, dist/build/GHC/IO.o-boot ) [ 2 of 238] Compiling GHC.Stack.Types ( GHC/Stack/Types.hs, dist/build/GHC/Stack/Types.o ) GHC/Stack/Types.hs:57:1: error: Bad interface file: /home/shaocheng/hana/lib/x86_64-linux-ghc-8.3.20170423/integer-simple-0.1.1.1-FieYyHVQ4yaKr3TU2vSN3a/GHC/Integer.hi Something is amiss; requested module integer-simple-0.1.1.1:GHC.Integer differs from name found in the interface file integer-simple:GHC.Integer (if these names look the same, try again with -dppr-debug) | 57 | import GHC.Integer () | ^^^^^^^^^^^^^^^^^^^^^ The compilation for integer-simple didn't produce error, and it is properly registered by ghc-pkg, so I've no idea why there's a bad interface file. Do you have any ideas on possible causes? Thanks a lot. Greetings, Shao Cheng

2 1

debug output
by Simon Peyton Jones 24 Apr '17

24 Apr '17

mk/flavours/validate.mk has GhcStage2HcOpts = -O -dcore-lint GhcLibHcOpts = -O -dcore-lint How can I override these in my validate.mk? E.g. GhcLibHcOpts += -ddebug-output does not work. Thanks. One should really be able to override anything. Simon

3 4

Re-compiling wired-in packages
by Shao Cheng 24 Apr '17

24 Apr '17

Dear friends, I'm trying to implement a new codegen for ghc, starting by using the ghc api to compile modules to STG/Cmm. In order to support importing Prelude, I also need the STG/Cmm representations of wired-in packages like base, ghc-prim, etc, and I guess that means I need to re-compile them. I can roughly think of two approaches: * Load the `ModIface` of wired-in packages, which are tidied Core modules, and convert to STG/Cmm * Get the library sources from ghc repo and launch a regular compilation. I haven't succeeded in either approach. For the first one, I haven't found a way to convert `ModIface` of external package to regular compilation targets; for the second one, regular "cabal installs" won't do the trick, seems compiling wired-in packages require quite some magic. What is the preferred way of re-compiling wired-in packages and retrieving their STG/Cmm representations? Thank a lot. Cheers, Shao Cheng

2 1

Harbormaster out to sea?
by Richard Eisenberg 23 Apr '17

23 Apr '17

I've posted a few diffs today, but Harbormaster seems stalled in checking them: - https://phabricator.haskell.org/D3424 - https://phabricator.haskell.org/D3487 - https://phabricator.haskell.org/D3490 Do you have any insight into this? Thanks! Richard

2 1

GHC Build System & Cabal
by Moritz Angermann 20 Apr '17

20 Apr '17

Dear friends, I’m currently exploring the possibility to build two versions of base similar to how we build various ways of the rts. The reasons for doing this won’t add much to the discussion. Reading https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Cabal I find the following: > For the GHC build system we need to extract that metadata and use > it to build the package. which leaves me wondering why that is? Initially I expected we’d just shell out and let cabal do the configuration and building of .cabal’ised packages. But it seems to be the case that we sidestep cabal for building ghc. Can someone shed some light on the reasoning behind this? Cheers, Moritz

2 1

Re: [Diffusion] [Raised Concern] rGHC751996e90a96: Kill off complications in CoreFVs
by Joachim Breitner 18 Apr '17

18 Apr '17

[CC’ing ghc-dev in case others are also curious about how to navigate Gipeda.] Hi, Am Donnerstag, den 13.04.2017, 08:40 +0000 schrieb Simon Peyton Jones: > Thanks for noticing this! I will investigate. > > But where do you see this? > · at perf.haskell.org I see “GHC” and “Gipeda”. It’s not > obvious which I want. You want the GHC Dashboard, as you guessed correctly. > · Clicking GHC shows me some “recent commits”. The first > three are from a few hrs ago; then the next is 8 days ago. Can’t be > right! It only shows interesting commits. Interesting ones are the most recent ones and all with significant changes. If you want to see all, press the “=” button in the top-right corner. > · There is no key to tell me what the little symbols mean – I > may have known once but I don’t know. A key would be terrific, or > even a link to a key. The symbols next to the three numbers on the right in the table? They are: * number of benchmarks * number of benchmarks improved * number of benchmarks regressed Maybe I should remove the first one, it is not very useful Hovering these icons show you which benchmarks changed, and by how much. > · Clicking on the offending patch (which does show), I see > the n-body complaint, which is good. But there is also > “testsuite/unexpected stats, which is mysterious… clicking on it > yields no more info. There is a “view buildlog” link that I use to investigate such cases. It goes to https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/751996e90a9… which shows bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T13056(optasm) bytes allocated: 440548592 +/-5% Lower bound T13056(optasm) bytes allocated: 418521162 Upper bound T13056(optasm) bytes allocated: 462576022 Actual T13056(optasm) bytes allocated: 417666128 Deviation T13056(optasm) bytes allocated: -5.2 % *** unexpected stat test failure for T13056(optasm) Probably some creep, given how close it is to cut-off percentage. According to https://perf.haskell.org/ghc/#graph/tests/alloc/T13056 this has been stable in the last 50 commits (sorry, still no way to view these graph for any other time interval). > · If compile times went up, would that show up anywhere > (except in testsuite results)? Only if it changes the total time of running make, or if it affects the allocations of a compiler perf test case. We currently have no reliable compilation time benchmarks (which would require _compiling_ stuff NofibRun times). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

Re: Where do I start if I would like help improve GHC compilation times?
by Johannes Waldmann 18 Apr '17

18 Apr '17

> it would be quite helpful if `pretty` > gained a special-case for the infinite band-width case Absolutely +1 this. Not "pretty" but similar: https://github.com/jwaldmann/wl-pprint-text/commit/7843d96db57ab01c0be336a5… - J.W.

1 0

Where do I start if I would like help improve GHC compilation times?
by Alfredo Di Napoli 18 Apr '17

18 Apr '17

Hey folks, maybe I’m setting up for something too ambitious for me, but I would like to take an active stance to the overlasting “GHC compilation times are terrible” matter, instead of simply stare at the screen with despair whenever GHC compiles a sufficiently large Haskell program ;) To make this even more interesting, I have never contributed to GHC either! The max I have pushed myself into was 2 years ago when I successfully built GHC head from source and tried to fix an Haddock “easy” ticket I don’t even recall (full disclosure, eventually I didn’t :D ). Specifically, I would love community recommendations & guidance about: 1. Is this simply too daunting for somebody like me? Maybe is better to first start contributing more regularly, take confidence with the code base AND then move forward? 2. Are compilation times largely dependant from the target platform (I’m on Darwin) or there is something which can be done “globally” so that the benefits can be experienced by everybody? 3. Is there any recommended workflow to profile GHC compilation times? Is there any build flavour one should prefer when doing so? (Maybe the full, slowest one?) Thanks in advance for taking the time reading this mail, and have a nice weekend! Alfredo

7 17

downloads.haskell.org unavailable for a bit
by Ben Gamari 14 Apr '17

14 Apr '17

Hello all, Unfortunately, due to a botched rsync, the tarballs on downloads.haskell.org will be unavailable for a few hours. I'm currently working on restoring the 8.0.2 tarballs first to ensure that they remain available to users. I will follow up with status updates as they come. Many apologies for the inconvenience. Cheers, - Ben

1 2