April 2016 - ghc-devs

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

[Action Needed] Document your work for the Haskell Communities and Activities Report
by Ben Gamari 05 May '16

05 May '16

TL;DR. If you see your name in one of the two lists below, please edit the entries for your contributions to 8.0 and plans for 8.2 in the 2016 GHC HCAR report [1]. The deadline is in a few short weeks so act soon! Hello GHC people, As you might know, it's that time of the year where we have an opportunity to reflect on the past and future strides taken by our glorious compiler in GHC's Haskell Communities and Activities Report submission [1]. We have had lots of great work go in to the imminent 8.0.1 release; let's make sure the community knows about it. Currently listed is, Adam Gundry Record system improvements Adam Sandberg Eriksson Strict pragma Duncan Coutts Environment files? Edward Z. Yang Backpack improvements Eric Seidel Implicit callstacks Eric de Casto Lopo ARM support George Karachalias Pattern match checker rewrite Herbert V. Riedel AIX support Jan Stolarek Injective type families Richard Eisenberg Visible type application, kind equalities Ryan Scott Improved Generics, DerivingLift Sergei Trofimovich Portability Simon Marlow Applicative do syntax, external GHCi Tamar Christina Windows improvements While Austin and I have done our best to stub out these entries, we need your help to fill in the details. If you see your name in this list please look at the current draft [1] and add what you can. Also, if you see anything missing from this list please let us know or, better yet, add an entry to the submission yourself. Also, if you are planning on including any major changes in the 8.2 release, please add an entry to the "upcoming plans" section. As far as I know at very least the following people should have interesting things to share, Andrew Farmer Profiler improvements Andrey Mokhov Shake build system Austin Seipp LLVM backend Bartosz Nikita Deterministic compilation Core Libs Committee Core libraries changes Edward Yang Backpack, Compact regions Giovanni Campagna Compact regions Simon Marlow Various things I'm sure Ömer Sinan Ağacan Unboxed sums, unpacking sum types Again, if you know of someone not on this list who is considering contributing to 8.2 please have them add their item to the report. If there is any way that Austin or I can help don't hesitate to reach out. Thanks for your contributions over the last year! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/May16

1 1

Draft 8.0 Mac build directions
by Carter Schonwald 04 May '16

04 May '16

Hey all: I've drafted some hopefully cleaner Mac build directions and I'd love some feedback on them Nb: I think I forgot to mention the cabal install hscolour step, I'll add that -Carter

5 9

Bikeshedding request for GHCi's :type
by Richard Eisenberg 03 May '16

03 May '16

Hi devs, Over the weekend, I was pondering the Haskell course I will be teaching next year and shuddered at having to teach Foldable at the same time as `length`. So I implemented feature request #10963 (https://ghc.haskell.org/trac/ghc/ticket/10963) which allows for a way for a user to request a specialization of a type. It all works wonderfully, but there is a real user-facing design issue here around the default behavior of :type and whether or not to add new :type-y like commands. I have outlined the situation here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type I'd love some broad input on this issue. If you've got a stake in how this all works, please skim that wiki page and comment on #10963. Thanks! Richard

7 7

Reverted your commit
by Simon Peyton Jones 01 May '16

01 May '16

Simon I reverted your commit https://phabricator.haskell.org/rGHC546f24e4f8a7c086b1e5afcdda624176610cbcf8 because it made every single binary that GHC builds seg-fault on windows. Even main = return () seg-faults. You may want to review and re-commit it. Simon commit 24864ba5587c1a0447beabae90529e8bb4fa117a Author: Simon Marlow <marlowsd(a)gmail.com> Date: Sat Apr 23 22:14:43 2016 +0100 Use __builtin_clz() to implement log_2() A microoptimisation in the block allocator.

3 2

Testsuite change: CLEANUP=1 is now the default
by Thomas Miedema 30 Apr '16

30 Apr '16

Hello devs, by popular request (#9758), the testsuite will now clean up after itself after running the tests, removing generated files, saving you some 10G of diskspace in the worst case. If you want the old behavior back, you can do: ``` $ make test CLEANUP=0 ``` I updated https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running. The cleaning itself is not perfect at the moment; some temporary files are not deleted. I have a solution for this in https://ghc.haskell.org/trac/ghc/ticket/11980 and https://phabricator.haskell.org/D1187. More about that later. Cheers, Thomas

1 0

Re: Bikeshedding request for GHCi's :type
by Johannes Waldmann 29 Apr '16

29 Apr '16

> .. :type should report the real type What about defaulting? Is it real? https://ghc.haskell.org/trac/ghc/ticket/11994 - J.W.

3 3