June 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

Moving ArgumentsDo forward
by Akio Takano 22 Aug '16

22 Aug '16

Hi, Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would love to see in GHC. It's a small syntactic extension that allows do, case, if and lambda blocks as function arguments, without parentheses. However, its differential revision [1] has been abandoned, citing a mixed response from the community. A message [2] on the ticket summarizes a thread in haskell-cafe on this topic. I, for one, think adding this extension is worthwhile, because a significant number of people support it. Also, given how some people seem to feel ambivalent about this change, I believe actually allowing people to try it makes it clearer whether it is a good idea. Thus I'm wondering: is there any chance that this gets merged? If so, I'm willing to work on whatever is remaining to get the change merged. Regards, Takano Akio [0]: https://ghc.haskell.org/trac/ghc/ticket/10843 [1]: https://phabricator.haskell.org/D1219 [2]: https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12

7 11

Harbourmaster is still not building diffs
by Matthew Pickering 13 Aug '16

13 Aug '16

Since a couple of months ago, harbourmaster no longer builds diffs. This is quite a large barrier to entry for new contributors as running ./validate takes a long time. It seems to be a very low priority issue to get it back working. Are there plans to get harbourmaster to build diffs again? Matt

2 2

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

Msys2 64: progress
by Simon Peyton Jones 08 Jul '16

08 Jul '16

Friends I want to thank everyone who has responded - very helpful! Thanks to your help I am making progress * I re-installed msys64 from scratch, this time following the instructions on the GHC wiki rather than the msys2 page. By doing update-core; then pacman -Su; then pacman -Su again, I got a clean install. Very good! Getting a shell between each step is tricky. o The first shell is gotten with mingw64.bat o After update-core, that file is gone; you have to use msys2_shell.cmd I think o After pacman -Su we get mingw64.exe, which we can use thereafter. * My slow-start problem appears to have gone away. I adopted the fix from you may be hitting a long standing issue some computers have in which the domain controller is being hit for every invocation of commands, causing a slowdown https://github.com/Alexpux/MSYS2-packages/issues/138 , Solution 2 from https://gist.github.com/k-takata/9b8d143f0f3fef5abdab<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.githu…> seems to fix it for most people. I am not absolutely certain that was the problem, but things seem ok now. I also excluded c:/msys64 from my antivirus check. * Emacs too is now working normally. Hurrah So that's all good. Now I'm stuck on the windows tarballs download thing. I get configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... File not found - *.tar.xz I tried both the things described on the wiki<https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows>: Pacman -R mingw-w64-x86_64-curl error: target not found: mingw-w64-x86_64-curl For the other I did the two mkdir things, and tried ./configure again, but got the same error message as above. So I'm stuck again, but further forward. Can you advise me? Thanks! Simon

4 16

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

Trac Spam
by Ben Gamari 30 Jun '16

30 Jun '16

Hello everyone, As you may have noticed we were hit with another bout of Trac spam today. I've tightened the spam filter up a bit further and things now seem to be once again under control. Of course, tightening up the spam filter may come at a cost. While I've tried my best to setup the filter such that legitimate uses are unimpeded, filtering is more of an art than a science. Please let me know if you find that you are hasseled with excessive CAPTCHAs or even outright rejection. Cheers, - Ben

1 0