August 2014 - ghc-devs

Unique as special boxing type & hidden constructors
by p.k.f.holzenspies＠utwente.nl 04 Sep '14

04 Sep '14

Dear all, I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. Right now, I'm looking at Unique and two questions come up: > data Unique = MkUnique FastInt 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): > getKeyFastInt (MkUnique x) = x > mkUniqueGrimily x = MkUnique (iUnbox x) I would propose to just make Unique a newtype for an Int and making the constructor visible. Regards, Philip

5 16

Can Phabricator be made to understand git better?
by Johan Tibell 04 Sep '14

04 Sep '14

Hi, I have to fight Phab too much because it doesn't understand git or git working conventions very well. For example, the other day I uploaded https://phabricator.haskell.org/D128, built from a single git commit on a feature branch I made on a local feature branch (based on my local master). First, doing that was in itself a bit of a pain. 'arc diff' didn't do the right thing and included some random commit(s) instead of my single commit in my feature branch. Perhaps it tried to diff against origin/master or something, which doesn't make any sense if you know how git is meant to be used (doing that would imply that you have to constantly sync with upstream to create a patch.) I eventually got it to used the right commit by doing 'arc diff <commit id>`. Second, today when I wanted to update my commit to address some review comments I 1) amended my commit in my feature branch and 2) ran 'arc diff', expecting that it would do the right thing. It didn't and now D128 contains a bunch of changes that aren't mine. I don't know where they came from. Is there a way to configure Phab so it works with git established workflows? -- Johan

3 3

wORD_SIZE vs platformWordSize of targetPlatform
by Johan Tibell 02 Sep '14

02 Sep '14

Hi, We seem to have two ways to get the same piece of information. We can get the target (?) word size as wORD_SIZE but there's also the platformWordSize field in the Platform data type, which is held as targetPlatform in DynFlags. Which one should I use? Most code uses wORD_SIZE. -- Johan

2 1

Proposal: run GHC API tests on fast
by Edward Z. Yang 02 Sep '14

02 Sep '14

Currently, most GHC API tests are not run on 'make fast', ostensibly because linking against the GHC API can take a while. I propose that change this, and run GHC API tests by default. Reasons: 1. The GHC API is closely tied a lot of internal structure of GHC, so it's very easy to make a change, track it through the rest of the compiler, but forget to update the tests/documentation. 2. We can boost this into poor man's testable documentation. The idea is to duplicate all GHC API examples in the manual in the test suite, and have a comment on all of the examples asking the developer to update the manual. (Or we could automatically extract the snippets from the manual, but that's work and this I could do in a few minutes.) 3. I don't think running these tests will add that much extra run time to the test suite; certainly interactively the time spent linking is unnoticeable. Let's set a one week discussion period for this proposal. Thanks, Edward

4 9

Re: [Haskell] ANNOUNCE: GHC version 7.8.3
by Bryan O'Sullivan 02 Sep '14

02 Sep '14

On Fri, Jul 11, 2014 at 6:40 AM, Austin Seipp <austin(a)well-typed.com> wrote: > The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3. > haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a bad interaction with cabal, it's hard to say from the outside, but here are some details. Here's the kind of error I get from haddock when I try to use cabal to install a package (primitive, in this case): module ‘primitive-0.5.3.0:Main’ is defined in multiple files: dist/build/tmp-92638/Control/Monad/Primitive.hs dist/build/tmp-92638/Data/Primitive/MachDeps.hs dist/build/tmp-92638/Data/Primitive/Types.hs dist/build/tmp-92638/Data/Primitive/Array.hs dist/build/tmp-92638/Data/Primitive/ByteArray.hs dist/build/tmp-92638/Data/Primitive/Internal/Compat.hs The result is that I have no haddock docs for any packages now :-(

9 17

cons/build and making rules look boring
by David Feuer 01 Sep '14

01 Sep '14

I think I may have figured out at least part of the reason that cons/build gives bad results. I actually ran into a clue when working on scanl. It seems at least part of the problem is that a rule like x : build g = build (\c n -> c x (g c n)) makes (:) look "interesting" to the inliner. Unfortunately, as I discovered after much extreme puzzlement about why rules relating to scanl were affecting things that had nothing to do with scanl, it turns out that making (:) look interesting is really quite bad, and something that we probably never want to happen. As a result, the only ways I see to try to make rules like that work properly are 1. If constructors are *always* best treated as boring, and the inliner knows when's a constructor, make it treat them all as boring. 2. Offer a BORINGRULE annotation to indicate that the rule should not make its LHS "interesting", or 3. (I don't like this option much) Make a special case forcing (:) in particular to be boring. David

3 3

RE: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)
by Simon Peyton Jones 01 Sep '14

01 Sep '14

Urk. It's quite surprising that this particular change would increase allocation significantly. I wonder whether it just pushed it over the threshold. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 01 August 2014 18:57 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/8df7fea7cf8a32d54ac3d6772432273 | 8595bf421/ghc | | >--------------------------------------------------------------- | | commit 8df7fea7cf8a32d54ac3d67724322738595bf421 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Fri Aug 1 19:55:52 2014 +0200 | | Bump haddock.base max_bytes_used | | It has reliably increased with commit 1ae5fa45, and has been stable | since then, so it does not seem to be a fluke. I did not investigate | why | that commit might have increased this value. | | | >--------------------------------------------------------------- | | 8df7fea7cf8a32d54ac3d67724322738595bf421 | testsuite/tests/perf/haddock/all.T | 13 +++++++------ | 1 file changed, 7 insertions(+), 6 deletions(-) | | diff --git a/testsuite/tests/perf/haddock/all.T | b/testsuite/tests/perf/haddock/all.T | index b17d472..49321b9 100644 | --- a/testsuite/tests/perf/haddock/all.T | +++ b/testsuite/tests/perf/haddock/all.T | @@ -17,13 +17,14 @@ test('haddock.base', | # 2014-01-22: 168 (x86/Linux - new haddock) | # 2014-06-29: 156 (x86/Linux) | ,stats_num_field('max_bytes_used', | - [(wordsize(64), 115113864, 10) | - # 2012-08-14: 87374568 (amd64/Linux) | - # 2012-08-21: 86428216 (amd64/Linux) | - # 2012-09-20: 84794136 (amd64/Linux) | - # 2012-11-12: 87265136 (amd64/Linux) | - # 2013-01-29: 96022312 (amd64/Linux) | + [(wordsize(64), 127954488, 10) | + # 2012-08-14: 87374568 (amd64/Linux) | + # 2012-08-21: 86428216 (amd64/Linux) | + # 2012-09-20: 84794136 (amd64/Linux) | + # 2012-11-12: 87265136 (amd64/Linux) | + # 2013-01-29: 96022312 (amd64/Linux) | # 2013-10-18: 115113864 (amd64/Linux) | + # 2014-07-31: 127954488 (amd64/Linux), correlates with | 1ae5fa45 | ,(platform('i386-unknown-mingw32'), 58557136, 10) | # 2013-02-10: 47988488 (x86/Windows) | # 2013-11-13: 58557136 (x86/Windows, | 64bit machine) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

6 11

Trouble compiling fibon
by David Feuer 31 Aug '14

31 Aug '14

I'm trying to compile the fibon benchmark suite, but I'm getting a non-specific permission error. Can anyone give me a clue? == make boot - --no-print-directory; in /home/dfeuer/src/ghc-slowmod/nofib/fibon/Hackage/Bzlib ------------------------------------------------------------------------ // Codec/Compression/BZip/Stream.hsc make[2]: execvp: //: Permission denied make[2]: *** [Codec/Compression/BZip/Stream.hs] Error 127 Failed making boot in Bzlib: 1

1 0

Raft of optimiser changes
by Simon Peyton Jones 30 Aug '14

30 Aug '14

I've just pushed a bunch of Core-to-Core optimisation changes that have been sitting in my tree for ages. The aggregate effect on nofib is very modest, but they are mostly aimed at corner cases, and consolidation. Program Size Allocs Runtime Elapsed TotalMem Min -7.2% -3.1% -7.8% -7.8% -14.8% Max +5.6% +1.3% +20.0% +19.7% +50.0% Geometric Mean -0.3% -0.1% +1.7% +1.7% +0.2% The runtime increases are spurious - I checked. A couple of perf/compiler tests (i.e. GHC's own performance) improve significantly, which is a good sign. I have a few more to come but wanted to get this lot out of my hair. Simon a1a400ed * Testsuite wibbles 39ccdf91 * White space only 6c6b001e * Remove dead lookup_dfun_id (merge-o) a0b2897e * Simple refactor of the case-of-case transform bb877266 * Performance changes 082e41b4 * Testsuite wibbles 1122857e * Run float-inwards immediately before the strictness analyser. 86a2ebf8 * Comments only 6d48ce29 * Make tidyProgram discard speculative specialisation rules fa582cc4 * Fix an egregious bug in the NonRec case of bindFreeVars b9e49d3e * Add -fspecialise-aggressively dce70957 * Compiler performance increases -- yay! a3e207f6 * More SPEC rules fire baa3c9a3 * Wibbles to "...plus N others" error message about instances in scope 99178c1f * Specialise monad functions, and make them INLINEABLE 2ef997b8 * Slightly improve fusion rules for 'take' 949ad67e * Don't float out (classop dict e1 e2) 34363330 * Move the Enum Word instance into GHC.Enum 4c03791f * Specialise Eq, Ord, Read, Show at Int, Char, String 9cf5906b * Make worker/wrapper work on INLINEABLE things 8f099374 * Make maybeUnfoldingTemplate respond to DFunUnfoldings 3af1adf9 * Kill unused setUnfoldingTemplate 6e0f6ede * Refactor unfoldings e9cd1d5e * Less voluminous output when printing continuations

2 1

Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04
by kyra 30 Aug '14

30 Aug '14

Hi, I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to ~/data/Work/ghc-7.8.1-i386. Now I have the following: awson@awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure --prefix=/home/awson/data/ghc-7.8.1-i386 checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory configure: error: cannot determine current directory ghc-pwd is definitely there but it does not start it seems. Perhaps, the system lacks some shared libs or something. There absolutely no problems with 64-bit ghc. Regards, Kyra

5 8