April 2015 - ghc-devs

Re: API Annotations and 7.10.2
by Alan & Kim Zimmerman 28 Apr '15

28 Apr '15

As you can see in the report below, there are a LOT of patches related to API Annotations. I am beginning to have difficulty keeping them up to date, as master moves ahead. I would like to request that as many of these as possible be merged into master sooner rather than later, subject to review approval. There can then be a secondary process to evaluate which of them actually belong in 7.10.2. If it would simplify things, I can collapse some of these into a mega patch. Regards Alan Report follows .... --------------------------------------------------------------- This is the current state of the patches proposed for 7.10.2 Landed in ghc-7.10 (thank you) #10207 D803 #10214 D806 Landed in master but not ghc-7.10 (also thank you) #10209 D813 #10256 D818 #10254 D822 #10255 D823 #10277 D829 Patches available #10269 D832 #10299 D840 * #10268 D825 * #10278 D833 * #10307 D842 * #10309 D848 * #10280 D834 #10287 D837 #10312 D846 #10354/#10315 D868 #10357 D869 #10358 D873 The ones marked with * form a dependent chain of merges Moved from 7.10.2 to 7.12 #10250 D815 The proposed patches all make minor changes to the Parser / RdrHsSyn, and do not affect the AST or Haddock, nor change the operation of the compiler. The one with the largest impact is D840, which corrects a conflict in the parser and now generates the correct type for '[] (`HsExplicitListTy` rather than `HsTyVar'). The merge process to produce https://github.com/alanz/ghc/tree/api-annotations is --------------------------- (2015-04-26) git checkout api-annotations git reset --hard master arc patch --nobranch D832 (cd libraries/Cabal && git checkout bda1ce6b757cdaca93f2eba4e1906a4658719537) to revert to the master libraries/Cabal submodule change) arc patch --nobranch D840 arc patch --nobranch D825 (manual fixup) arc patch --nobranch D833 (manual fixup) arc patch --nobranch D842 (manual fixup) arc patch --nobranch D848 (manual fixup) arc patch --nobranch D834 (manual fixup) arc patch --nobranch D837 (manual fixup) arc patch --nobranch D846 (manual fixup) arc patch --nobranch D868 (manual fixup) arc patch --nobranch D869 arc patch --nobranch D873 (manual fixup) On Fri, Apr 17, 2015 at 7:22 PM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > This is the current state of the patches proposed for 7.10.2 > > Landed in ghc-7.10 (thank you) > #10207 D803 > #10214 D806 > > Landed in master but not ghc-7.10 (also thank you) > #10209 D813 > #10256 D818 > #10254 D822 > #10255 D823 > #10277 D829 > > Patches available > #10269 D832 > #10299 D840 * > #10268 D825 * > #10278 D833 * > #10307 D842 * > #10309 D848 * > #10280 D834 > #10287 D837 > #10312 D846 > > The ones marked with * form a dependent chain of merges > > Patches still to be finalised/provided > #10314 > #10315 > > Moved from 7.10.2 to 7.12 > #10250 D815 > > The proposed patches all make minor changes to the Parser / RdrHsSyn, and > do not affect the AST or Haddock, nor change the operation of the compiler. > > The one with the largest impact is D840, which corrects a conflict in the > parser and now generates the correct type for '[] (`HsExplicitListTy` > rather than `HsTyVar'). > > > The merge process to produce > https://github.com/alanz/ghc/tree/api-annotations is > > --------------------------- (2015-04-17) > git checkout -b api-annotations > arc patch --nobranch D832 > arc patch --nobranch D840 > arc patch --nobranch D825 (manual fixup) > arc patch --nobranch D833 > arc patch --nobranch D842 > arc patch --nobranch D848 (manual fixup) > arc patch --nobranch D834 (manual fixup) > arc patch --nobranch D837 (manual fixup) > arc patch --nobranch D846 (manual fixup) > -------------------------------------------------- > > I am really keen to get these landed, as being able to round-trip haskell > source using the annotations is the foundation of Matt Pickerings GSOC > proposal, and it would be a pity if it could not achieve its full potential. > > Regards > Alan > > > On Mon, Apr 13, 2015 at 12:14 AM, Alan & Kim Zimmerman < > alan.zimm(a)gmail.com> wrote: > >> This is the state of the nation for API Annotations for 7.10.2 >> >> The following are ready for merging, in the order proposed. The first >> four depend on each other. >> >> #10209 D813 >> #10256 D818 (depends D813) >> #10254 D822 (depends D818) >> #10269 D832 (depends D822) >> >> #10255 D823 >> >> #10268 D825 >> #10278 D833 (depends D825) >> >> #10280 D834 >> >> #10277 D829 >> >> #10287 D837 >> >> >> These are the commands I used to apply them to a freshly checked out ghc >> tree. The manual fixup is for Makefile, .gitignore, all.T, basically keep >> both legs each time. >> >> -------------------------- >> git checkout -b api-annotations >> arc patch --nobranch D832 >> arc patch --nobranch D823 (manual fixup) >> arc patch --nobranch D825 (manual fixup) >> arc patch --nobranch D834 (manual fixup) >> arc patch --nobranch D829 >> arc patch --nobranch D837 (manual fixup) >> arc patch --nobranch D833 (manual fixup) >> -------------------------- >> >> Once these are in, I do not think there will be anything else. >> >> Regards >> Alan >> >> >> >

1 0

Can we fix our Trac that doesn't lose new ticket text
by Edward Z. Yang 24 Apr '15

24 Apr '15

Steps to reproduce: 1. Click "New Ticket" 2. Type some text into the box 3. Press "Back" in your browser 4. Press "Forward" in your browser If you try this with an official Trac this doesn't happen, so either this was fixed in a new version, or we have a plugin installed which is causing this to happen. Current version of Trac is 1.0.5, we're currently running 1.0.1 Thanks, Edward

7 9

validate failures for OSX on current head
by Carter Schonwald 23 Apr '15

23 Apr '15

hey all, on ghc head today specifically commit a55bfabbed21f17064f863450f9d94d45db9c478 i did a run of ./validate --slow here are the following unexpected failures (i know the static pointer GHCI ones are expected, but i'm not sure about the rest). Could someone care to opine on which ones are truely unexpected? i'll be doing a bit of digging on some of these as I have time over the coming week, but i thought I should share this with everyone just in case something important is amidst them cheers -Carter Unexpected results from: TEST="tc165 retc001 dsrun014 DsStaticPointers GcStaticPointers ListStaticPointers T7919 retc002 tcrun024 tcrun025 T7861 T5751 T3500a T7126 tcrun037 readRun004 rn041 TH_StaticPointers recomp001 setnumcapabilities001 allocLimit4 ghci024 termination enum01 enum03 enum02 sigcabal01 sigcabal02 CgStaticPointers recomp014 qq007 qq008 mul2 quotRem2 add2 read029" OVERALL SUMMARY for test run started at Thu Apr 23 15:02:33 2015 EDT 0:20:10 spent to go through 4483 total tests, which gave rise to 14464 test cases, of which 2785 were skipped 267 had missing libraries 11140 expected passes 170 expected failures 0 caused framework failures 0 unexpected passes 102 unexpected failures 0 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) cabal/sigcabal02 sigcabal02 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run setnumcapabilities001 [bad exit code] (threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/recomp001 recomp001 [bad stderr] (normal) driver/recomp014 recomp014 [bad stdout] (normal) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) gadt termination [exit code non-0] (optasm) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_compile read029 [exit code non-0] (optasm) parser/should_run readRun004 [bad exit code] (ghci) quasiquotation/qq007 qq007 [exit code non-0] (normal,hpc,optasm) quasiquotation/qq008 qq008 [exit code non-0] (normal,hpc,optasm) rename/should_compile rn041 [exit code non-0] (optasm) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded1,dyn) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_compile tc165 [exit code non-0] (optasm) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run T7861 [bad stderr] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7861 [bad stdout or stderr] (ghci) typecheck/should_run tcrun024 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun024 [bad stdout or stderr] (ghci) typecheck/should_run tcrun025 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun025 [bad stdout or stderr] (ghci) typecheck/should_run tcrun037 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun037 [bad stdout or stderr] (ghci)

1 0

deriving Typeable and Nat kinds
by Gabor Greif 23 Apr '15

23 Apr '15

Hi devs, between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a strange regression with deriving Typeable for data with Nat-kinded indices. Something like this used to work (I cannot post the whole thing, unfortunately) {{{ data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, Typeable) }}} With my ghc-7.11.20150407 (and later) strange obligations of the form `Typeable p` appear, rendering my code uncompilable. But there is no way I can see how I can convince the type checker that the Nat index is indeed Typeable. I *do* have a `KnownNat p` constraint around, though. The relevant changes to mainline appear to be https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 both by Iavor. So now my questions: 1) Is this a regression on mainline? (I surely hope so!) How did this work before? 2) Should `KnownNat p` imply `Typeable p` for the ability to have my `Typeable (OTU p o)` 3) if 2) is answered with "NO", how am I supposed to satisfy those constraints? Thanks and cheers, Gabor PS: Sometimes I feel like a canary doing my research-like programming with GHC-HEAD, and it is a mostly positive experience, but events like this make me shiver...

2 5

Bug: GHC creates incorrect code which throws <<loop>>
by Yongqian Li 23 Apr '15

23 Apr '15

Hi all, I wanted to bring to your attention this bug, https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about two days ago but hasn't gotten any replies to yet. In my opinion, this is a rather serious bug since GHC is producing incorrect code. While there is a workaround, it makes my program take about 2 hours to compile. Since reporting the bug, I've also seen "strange closure type" exceptions, which I believe are also caused by this bug, although I do not have a test case. Based on my limited understanding of GHC internals, I suspect the problem lies in how type class dictionaries are looked up at run time, as the problem disappears if GHC can fully resolve the types. Can others see if they can reproduce this bug? If there is any way I can help, please let me know. Sincerely, Yongqian Li

5 5

OS X bindist
by Andrew Farmer 22 Apr '15

22 Apr '15

Forgive me if this has been answered somewhere, but is there an officially sanctioned bindist of 7.10.1 for OS X yet? The page I usually visit [1] doesn't list one yet. Thanks! Andrew [1] https://www.haskell.org/ghc/download_ghc_7_10_1

5 4

Fwd: Re: Branchless implementation for literal case – is it worth it?
by Niculae Ionita 20 Apr '15

20 Apr '15

Sorry, I forgot to answer to the list. If the code is already there and some architectures can profit of it, especially in inner loops - why not just make it an optimisation flag? Nicu Am 20.04.2015 um 16:41 schrieb Joachim Breitner: > Hi, > > Am Montag, den 20.04.2015, 16:29 +0200 schrieb Sven Panne: >> 2015-04-19 9:44 GMT+02:00 Joachim Breitner<mail(a)joachim-breitner.de>: >>> [...] So my question to the general audience: Is such branchless code really >>> better than the current, branching code? Can someone provide us with an >>> example that shows that it is better? Do I need to produce different >>> branchless assembly? [...] >> Just a few war stories regarding this from the trenches (= Chrome's >> JavaScript JIT): > thanks a lot. > > The conclusion I draw from your mail, at last for our case, is: > Don’t bother (and keep the compiler code simple). Is that a correct > reading? > > Greetings, > Joachim > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 2

Branchless implementation for literal case – is it worth it?
by Joachim Breitner 20 Apr '15

20 Apr '15

Dear devs, in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that code like f :: Int -> Bool f a = case a of 1 -> True 5 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False {-# NOINLINE f #-} should not compile to a series of conditional jumps, but rather a branchless code akin to let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 `orI#` a ==# 11 `orI#` a ==# 19 case p of 1 -> do_something 0 -> do_something_else Subsequently, I refactored the way we produce Cmm code from STG, opening the possibility to implement this optimization at that stage¹. But when I then added this implementation, I could not measure any runtime improvement, see https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 So my question to the general audience: Is such branchless code really better than the current, branching code? Can someone provide us with an example that shows that it is better? Do I need to produce different branchless assembly? If it is not better, I can again refactor the switch generation and simplify it a bit again. Hmm, only now I see that rwbarton has replied there. Not sure why I missed that. Anyways, more voices are welcome :-) Greetings, Joachim ¹ This should not preclude an implementation on the Core level, which SPJ preferred. But I improved other aspects of the code generation as well, so this is worthwhile on its own. -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

8 9

Trac is soul-extinguishingly slow
by Richard Eisenberg 18 Apr '15

18 Apr '15

Hi devs, Trac isn't working again. In an entirely unscientific study, 4 out of the last 5 sessions where I tried to access Trac, I was unable to. If ghc.haskell.org is getting slammed, is it possible to disconnect Trac from that name and instead just publish some IP address until we have things working better? (Apologies if that sentence doesn't make any sense at all. I've dealt very little with these sorts of issues.) Thanks, Richard

4 5

RE: [Haskell] Haskell on Windows instructions - is MinGHC version update needed?
by Simon Peyton Jones 16 Apr '15

16 Apr '15

Fwding to the GHC Windows Task force, who will doubtless know what to do. Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces@haskell.org] On Behalf Of Howard B. | Golden | Sent: 15 April 2015 17:51 | To: haskell(a)haskell.org | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version | update needed? | | Hi, | | Currently, the Haskell website's Windows download page | (https://www.haskell.org/downloads/windows) offers two alternatives, | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. | | Howard | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

4 4