May 2016 - ghc-devs - Haskell.org

GHC 8.0.1-rc4 source tarball availability
by Ben Gamari 14 May '17

14 May '17

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at http://downloads.haskell.org/~ghc/8.0.1-rc4/ For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

12 75

Improving trac notifications
by Matthew Pickering 12 Feb '17

12 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

timings for individual compiler passes (in rc3)
by Johannes Waldmann 07 Dec '16

07 Dec '16

Hi. There is this (closed) https://ghc.haskell.org/trac/ghc/ticket/11653 and it's landed in 8.rc3. Thats good, and I want to make an effort to use this. But how? Just "-v2"? This gives a lot of noise. And no summary? Automatic analysis (of the output text stream, by external program) could be somewhat easier if each data set (starting at "\n!!!") did occupy exactly one line (currently, line breaks do occur). Anyway, what do I look for? Any large or suspicious number - but what exactly is "suspicious"? Anything above 1 second? Are we to believe the assignment of cost to pass, or could there be mis-attribution because result of an earlier pass is only forced later? Oh, and where do you want discussion of this feature (mailing list, ticket, ...)? I do hope that it will prove useful, in the sense that it could allow non-developers like me, or even build bots, to help spot performance problems. (E.g., you could advertise to enable this on travis. Yes, their build times depend on a lot of things, but still.) - J.W.

3 6

RE: vectorisation code?
by Simon Peyton Jones 12 Sep '16

12 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

Parser changes for supporting top-level SCC annotations
by Ömer Sinan Ağacan 19 Jul '16

19 Jul '16

I'm trying to support SCCs at the top-level. The implementation should be trivial except the parsing part turned out to be tricky. Since expressions can appear at the top-level, after a {-# SCC ... #-} parser can't decide whether to reduce the token in `sigdecl` to generate a `(LHsDecl (Sig (SCCSig ...)))` or to keep shifting to parse an expression. As shifting is the default behavior when a shift/reduce conflict happens, it's always trying to parse an expression, which is always the wrong thing to do. Does anyone have any ideas on how to handle this? Motivation: Not having SCCs at the top level is becoming annoying real quick. For simplest cases, it's possible to do this transformation: f x y = ... => f = {-# SCC f #-} \x y -> ... However, it doesn't work when there's a `where` clause: f x y = <t is in scope> where t = ... => f = {-# SCC f #-} \x y -> <t is out of scope> where t = ... Or when we have a "equation style" definition: f (C1 ...) = ... f (C2 ...) = ... f (C3 ...) = ... ... (usual solution is to rename `f` to `f'` and define a new `f` with a `SCC`)

4 6

Template Haskell determinism
by Bartosz Nitka 01 Jul '16

01 Jul '16

Template Haskell with its ability to do arbitrary IO is non-deterministic by design. You could for example embed the current date in a file. There is however one kind of non-deterministic behavior that you can trigger accidentally. It has to do with how Names are reified. If you take a look at the definition of reifyName you can see that it puts the assigned Unique in a NameU: reifyName :: NamedThing n => n -> TH.Name reifyName thing | isExternalName name = mk_varg pkg_str mod_str occ_str | otherwise = TH.mkNameU occ_str (getKey (getUnique name)) ... NameFlavour which NameU is a constructor of has a default Ord instance, meaning that it ends up comparing the Uniques. The relative ordering of Uniques is not guaranteed to be stable across recompilations [1], so this can lead to ABI-incompatible binaries. This isn't an abstract problem and it actually happens in practice. The microlens package keeps Names in a Set and later turns that set into a list. The results have different orders of TyVars resulting in different ABI hashes and can potentially be optimized differently. I believe it's worth to handle this case in a deterministic way and I have a solution in mind. The idea is to extend NameU (and potentially NameL) with an ordering key. To be more concrete: - | NameU !Int + | NameU !Int !Int This way the Ord instance can use a stable key and the problem reduces to ensuring the keys are stable. To generate stable keys we can use the fact that reify traverses the expressions in the same order every time and sequentially allocate new keys based on traversal order. The way I have it implemented now is to add a new field in TcGblEnv which maps Uniques to allocated keys: + tcg_th_names :: TcRef (UniqFM Int, Int), Then the reifyName and qNewName do the necessary bookkeeping and translate the Uniques on the fly. This is a breaking change and it doesn't fix the problem that NameFlavour is not abstract and leaks the Uniques. It would break at least: - singletons - th-lift - haskell-src-meta - shakespeare - distributed-closure I'd like to get feedback if this is an acceptable solution and if the problem is worth solving. Cheers, Bartosz [1] https://ghc.haskell.org/trac/ghc/wiki/DeterministicBuilds#NondeterministicU…

5 11

Re: Optimizing "counting" GADTs
by David Feuer 19 Jun '16

19 Jun '16

Partially. Unfortunately, bidirectional pattern synonyms tie the types of the pattern synonyms to the types of the smart constructors for no good reason, making them (currently) inappropriate. But fixing that problem would offer one way to this optimization, I think. On May 25, 2016 8:37 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> wrote: could this be simulated/modeled with pattern synonyms? On Wed, May 25, 2016 at 7:51 PM, David Feuer <david.feuer(a)gmail.com> wrote: > I've started a wiki page, > https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to consider > optimizing GADTs that look like natural numbers but that possibly have > "heavy zeros". Please take a look. > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

4 7

Core of a whole package
by Alberto Sadde O. 01 Jun '16

01 Jun '16

Hi, I am trying to get the Core of a whole package. I have been using the GHC API to get the Core of each file in a package but I have a problems with non-exposed modules of the package. I might not been setting up all the flags correctly but at this point I am completely lost!! I posted a question on S.O. <http://stackoverflow.com/questions/37410615/ghc-api-compile-whole-package-t…> The code I am using is in the above link. Any help/comments/tips would be greatly appreciated! Many thanks, Alberto

2 5

Re: Strictness/laziness warnings
by David Feuer 30 May '16

30 May '16

Mostly I'm looking for a rough estimate. Some false positives and false negatives are tolerable. If I have something like f :: Int -> Maybe String -> String f _ Nothing = "Hi there!" f n (Just b) = if n > 0 then show b else "whatever" then I'd likely be interested in a warning about the fact that the first case is not strict in the Int and the second is. I'd also likely be interested in a warning about the first case because I'm taking a small primitive value (Int) and doing so lazily. On Sun, May 29, 2016 at 11:04 PM, wren romano <winterkoninkje(a)gmail.com> wrote: > On Sat, May 28, 2016 at 10:14 PM, Edward Kmett <ekmett(a)gmail.com> wrote: >> How would you detect the argument only being forced some of the time? Sounds >> like a lot of long-term cross-module book-keeping. > > Sounds to me like what the strictness analyzer is already doing, ne? I > missed the beginning of the thread, so might be off base. If it's more > about noticing when the use sites of a given function have some > pattern not captured by the strictness determined from the function's > definition, then it seems like we shouldn't need /cross/-module > bookkeeping: we should be able to just tabulate how each use site's > strictness does/doesn't match the interface's spec. > > -- > Live well, > ~wren

2 1

GHC HEAD (built with itself) blows allocation stats :-(
by Gabor Greif 30 May '16

30 May '16

Hi devs, I get some pretty bad allocation statistics when testing GHC HEAD. Not sure why, but this is with a stage-0 compiler that is also GHC HEAD. (I doubt that that is the reason, though.) I see on a linux x64 system (RHEL6) : Unexpected stat failures: /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10370 T10370 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10547 T10547 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T1969 T1969 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3064 T3064 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3294 T3294 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T4801 T4801 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5030 T5030 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FD T5321FD [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321Fun T5321Fun [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5631 T5631 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5642 T5642 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5837 T5837 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T6048 T6048 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T783 T783 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9020 T9020 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9233 T9233 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9675 T9675 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a T9872a [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872b T9872b [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872c T9872c [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872d T9872d [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9961 T9961 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/parsing001 parsing001 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/space_leaks/T4029 T4029 [stat not good enough] (ghci) Some of the tests look like this: cd /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a && "ghc-head-x86_64/inplace/test spaces/ghc-stage2" -c T9872a.hs -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history +RTS -V0 -tT9872a.comp.stats --machine-readable -RTS > T9872a.comp.stderr 2>&1 bytes allocated value is too high: Expected T9872a(normal) bytes allocated: 3352882080 +/-5% Lower bound T9872a(normal) bytes allocated: 3185237976 Upper bound T9872a(normal) bytes allocated: 3520526184 Actual T9872a(normal) bytes allocated: 13260131240 Deviation T9872a(normal) bytes allocated: 295.5 % *** unexpected stat test failure for T9872a(normal) Around 300% looks really bad. Can anybody reproduce this? For reference, this is the test command I run: $ make test TEST="T9961 T10547 T10370 T3064 T4029 T5642 parsing001 T783 T3294 T9872d T9872b T9872c T9872a T1969 T5321Fun T5837 T5631 T5321FD T5030 T4801 T6048 T9675 T9233 T9020" The testsuite works nicely otherwise. Cheers and thanks, Gabor

3 5