- ghc-devs - Haskell.org

Proposal process status
by Ben Gamari 22 Jul '16

22 Jul '16

Hello everyone, As you hopefully know, a few weeks ago we proposed a new process [1] for collecting, discussing, and deciding upon changes to GHC and its Haskell superset. While we have been happy to see a small contingent of contributors join the discussion, the number is significantly smaller than the set who took part in the earlier Reddit discussions. In light of this, we are left a bit uncertain of how to proceed. So, we would like to ask you to let us know your feelings regarding the proposed process: * Do you feel the proposed process is an improvement over the status quo? * Why? (this needn't be long, just a sentence hitting the major points) * What would you like to see changed in the proposed process, if anything? That's all. Again, feel free to reply either on the GitHub pull request [1] or this thread if you would prefer. Your response needn't be long; we just want to get a sense of how much of the community feels that 1) this effort is worth undertaking, and 2) that the proposal before us is in fact an improvement over the current state of affairs. Thanks for your help! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/1

11 18

GHC build currently broken on OS X and Windows
by Erik de Castro Lopo 22 Jul '16

22 Jul '16

Hi all. The recent Compact Regions commit (cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453) builds fine on Linux but doesn't build on OS X and is at least 99% certain not to build on Windows. I'm in the process of fixing it, but it will be 24-36 hours before I have a patch ready. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

5 4

Should we send Travis messages to ghc-builds?
by Ben Gamari 21 Jul '16

21 Jul '16

Hello everyone, While picking up the pieces from a failed merge today I realized that we currently spend a fair bit of carbon footprint and CPU cycles making Travis test GHC yet the results of these tests aren't pushed anywhere. Would anyone object to having Travis push notifications of changes in red/green state to ghc-builds@haskell.org? Perhaps this will allow some of us to react more quickly to regressions. Cheers, - Ben

3 3

Re: Proposal process status
by Niklas Larsson 20 Jul '16

20 Jul '16

> 20 juli 2016 kl. 19:38 skrev amindfv(a)gmail.com: > > > >> El 20 jul 2016, a las 12:45, Ben Gamari <ben(a)well-typed.com> escribió: >> >> Iavor Diatchki <iavor.diatchki(a)gmail.com> writes: >> >>> Hello Ben, >>> >>> I posted this when you originally asked for feed-back, but perhaps it >>> got buried among the rest of the e-mails. >> Indeed it seems that way. Sorry about that! >> >>> I think the proposal sounds fairly reasonable, but it is hard to say how >>> well it will work in practice until we try it, and we should be ready to >>> change it if needs be. >> Right. I fully expect that we will have to iterate on it. >> >>> Some clarifying questions on the intended process: >>> 1. After submitting the initial merge request, is the person making the >>> proposal to wait for any kind of acknowledgment, or just move on to step 2? >> The discussion phase can happen asynchronously from any action by the >> Committee. Of course, the Committee should engauge in discussion early, >> but I don't think any sort of acknowledgement is needed. An open pull >> request should be taken to mean "let's discuss this idea." >> >>> 2. Is the discussion going to happen on one of the mailing lists, if so >>> which? Is it the job of the proposing person to involve/notify the >>> committee about the discussion? If so, how are they to find out who is on >>> the committee? >> >> The proposed process places the discussion in a pull request. The idea >> here is to use well-understood and widely-used code review tools to >> faciliate the conversation. > > This part runs strongly against the grain of what I'd prefer: email is lightweight, decentralized, standard, and has many clients. We can read discussion of Haskell proposals any way we like. Github on the other hand only allows us to read issues by going to Github, and using whatever interface Github has given us (which personally I find very annoying, esp. on mobile). In addition, reading proposals offline becomes very difficult. Many of us read discussion when commuting, where, e.g. in NYC, there isn't cell service. > > For reviewing code that implements a proposal, I'm a lot more flexible (although again I'm not a fan of Github) > > For the people who like having history tracked with git: gitit is a possibility, and is written in Haskell. > > Tom > It's possible both follow and contribute to issues in a github repo via email. I do it all the time for Idris. // Niklas > > >> The Committee members will be notified of the open pull request by the >> usual event notification mechanism (e.g. in GitHub one can subscribe to >> a repository). >> >>> 3. How does one actually perform step 3, another pull request or simply >>> an e-mail to someone? >> The opening of the pull request would mark the beginning of the >> discussion period. When the author feels that the discussion has come to >> something of a conclusion, they will request that the GHC Committee >> consider the proposal for acceptable by leaving a comment on the pull >> request. >> >>> Typo: two separate bullets in the proposal are labelled as 4. >> I believe this should be fixed now. Thanks! >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

1 0

git.haskell.org slow
by Simon Peyton Jones 20 Jul '16

20 Jul '16

Is it my imagination or is git.haskell.org really slow at the moment? SImion

1 0

Note [Api annotations]
by Ömer Sinan Ağacan 20 Jul '16

20 Jul '16

I see some weird comments like -- - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnVbar','ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnClose' -- For details on above see note [Api annotations] in ApiAnnotation in some files, but Note [Api annotations] in compiler/parser/ApiAnnotation.hs doesn't say anything about those comments. Can someone update the note to explain what are those comments for?

4 4

first unboxed sums patch is ready for reviews
by Ömer Sinan Ağacan 19 Jul '16

19 Jul '16

Hi all, I'm almost done with the unboxed sums patch and I'd like to get some reviews at this point. https://phabricator.haskell.org/D2259 Two key files in the patch are UnariseStg.hs and RepType.hs. For the example programs see files in testsuite/tests/unboxedsums/ In addition to any comments about the code and documentation, it'd be appreciated if you tell me about some potential uses of unboxed sums, example programs, edge cases etc. so that I can test it a bit more and make sure the generated code is good. Thanks, Omer

1 1

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

RE: [commit: ghc] wip/generics-flip: Flip around imports of GHC.Generics (cb12bdf)
by Simon Peyton Jones 18 Jul '16

18 Jul '16

I don’t object to this, but I suspect that it's just covering up some other bug. Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 18 July 2016 14:57 To: ghc-commits(a)haskell.org Subject: [commit: ghc] wip/generics-flip: Flip around imports of GHC.Generics (cb12bdf) Repository : ssh://git@git.haskell.org/ghc On branch : wip/generics-flip Link : https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell… >--------------------------------------------------------------- commit cb12bdf942df5e61771d69bbb6049f3b23ed580c Author: Ben Gamari <ben(a)smart-cactus.org> Date: Mon Jul 18 15:54:16 2016 +0200 Flip around imports of GHC.Generics Previously we had, GHC.Generics imports GHC.Ptr Data.Monoid imports GHC.Generics Data.Foldable imports GHC.Generics Data.Foldable imports Data.Monoid Prelude imports Data.Foldable Unfortunately this meant that any program importing Prelude (essentially all programs) would end up pulling in GHC.Generics and GHC.Ptr unnecessarily. Hopefully helps #12367. >--------------------------------------------------------------- cb12bdf942df5e61771d69bbb6049f3b23ed580c libraries/base/Data/Foldable.hs | 36 ---------------------- libraries/base/Data/Monoid.hs | 19 +++++------- libraries/base/GHC/Generics.hs | 67 +++++++++++++++++++++++++++++++++++++++-- 3 files changed, 72 insertions(+), 50 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc cb12bdf942df5e61771d69bbb6049f3b23ed580c _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…

2 1

Slow validate currently fails
by Ömer Sinan Ağacan 15 Jul '16

15 Jul '16

Hi all, Just wanted to say that HEAD (37aeff6) doesn't currently pass validate (in slow mode). See details below. ==== STAGE 2 TESTS ==== Unexpected results from: TEST="haddock.Cabal hpc_fork T4114c T4114d dynamic-paper" SUMMARY for test run started at Fri Jul 15 11:19:15 2016 UTC 0:43:36 spent to go through 5264 total tests, which gave rise to 21166 test cases, of which 3817 were skipped 197 had missing libraries 16928 expected passes 219 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures 1 unexpected stat failures Unexpected failures: /tmp/ghctest-7VEJbb/test spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) /tmp/ghctest-7VEJbb/test spaces/./driver/T4114c.run T4114c [bad exit code] (ghci) /tmp/ghctest-7VEJbb/test spaces/./driver/T4114d.run T4114d [bad exit code] (ghci) /tmp/ghctest-7VEJbb/test spaces/../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) Unexpected stat failures: /tmp/ghctest-7VEJbb/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) It validates in fast mode though (haven't tried the default mode).

1 0