From simonpj at microsoft.com Mon Dec 1 08:31:51 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 08:31:51 +0000 Subject: Windows build broken again: urgent Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EECE8@DB3PRD3001MB020.064d.mgd.msft.net> Alas. Alack. The Windows build is broken again. This time it's pretty fundamental: the stage2 compiler seg-faults every time it invokes the linker: * On GHCi startup * On every Template Haskell splice I don't know when this started, but I did a successful build at 23.10 on 24 November, so it's during the last week. I would gladly do any experiments if someone tells me what to do. It would be really good to fix this. At the moment I'm pretty much stalled on laptop work. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 1 08:38:37 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 08:38:37 +0000 Subject: Windows build broken again: urgent In-Reply-To: <87fvczhil8.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3EECE8@DB3PRD3001MB020.064d.mgd.msft.net> <87fvczhil8.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EED4E@DB3PRD3001MB020.064d.mgd.msft.net> | Just a hunch... could it have been broken by one of the recent linker- | related patches since Nov 24th? That seems very plausible, yes. But still there's the question of what to do about it. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 01 December 2014 08:37 | To: Simon Peyton Jones | Subject: Re: Windows build broken again: urgent | | On 2014-12-01 at 09:31:51 +0100, Simon Peyton Jones wrote: | > Alas. Alack. The Windows build is broken again. | > This time it's pretty fundamental: the stage2 compiler seg-faults | every time it invokes the linker: | > | > * On GHCi startup | > | > * On every Template Haskell splice | > | > I don't know when this started, but I did a successful build at | 23.10 on 24 November, so it's during the last week. | > I would gladly do any experiments if someone tells me what to do. | > It would be really good to fix this. At the moment I'm pretty much | stalled on laptop work. | | Just a hunch... could it have been broken by one of the recent linker- | related patches since Nov 24th? From mail at joachim-breitner.de Mon Dec 1 08:42:48 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 01 Dec 2014 09:42:48 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <87y4qsfdw1.fsf@gmail.com> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> Message-ID: <1417423368.1448.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari: > > Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari: > >> > What would be a reliable way to make the build system pass > >> > -B/usr/bin/ld.gold to gcc? Is > >> > SRC_HC_OPTS += -optc-B/usr/bin/ld.gold > >> > in mk/build.mk a good idea? > >> > > >> Indeed this is much cleaner. I just wanted a way to accomplish this > >> without editing build.mk. > > > > Cleaner maybe, but it was not picked up either. Or maybe we are looking > > at a different issue, not solved by using ld.gold? > > > I suspect that it this is the gold issue. I should have looked at your > command line a bit more carefully; I suspect you want > > SRC_HC_OPTS += -optl-B/usr/bin/ld.gold > > Hopefully this will do it; at least the option appears to make it to the > right phase now. Trying it right now... > Is the Debian packaging tracked in version control somewhere? All I can > find is the packaging tarball [1]. It?s at http://darcs.debian.org/pkg-haskell/experimental/ghc (but due to a index.html in that directory, you cannot browse it, so you have to "darcs get" it) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvriedel at gmail.com Mon Dec 1 08:43:39 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 01 Dec 2014 09:43:39 +0100 Subject: Windows build broken again: urgent In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3EED4E@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Mon, 1 Dec 2014 08:38:37 +0000") References: <618BE556AADD624C9C918AA5D5911BEF3F3EECE8@DB3PRD3001MB020.064d.mgd.msft.net> <87fvczhil8.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF3F3EED4E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87bnnnhi9w.fsf@gmail.com> Hello Simon, On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote: > | Just a hunch... could it have been broken by one of the recent linker- > | related patches since Nov 24th? > > That seems very plausible, yes. But still there's the question of > what to do about it. a) Empirically: Try locally 'git revert'ing 383733b9191a36e2d3f757700842dbc3855911d9 and/or b5e8b3b162b3ff15ae6caf1afc659565365f54a8 and see if your problem goes away, or b) Ask Simon Marlow (he either wrote or reviewed those two patches) if he sees something odd in those patches that could have broken Windows' GHCi... Cheers, hvr From johan.tibell at gmail.com Mon Dec 1 09:45:07 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 1 Dec 2014 10:45:07 +0100 Subject: Windows build broken again: urgent In-Reply-To: <87bnnnhi9w.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3EECE8@DB3PRD3001MB020.064d.mgd.msft.net> <87fvczhil8.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF3F3EED4E@DB3PRD3001MB020.064d.mgd.msft.net> <87bnnnhi9w.fsf@gmail.com> Message-ID: In general I think a good course of action when this happens is: * Use git bisect to find the offending commit. This works now because we moved to submodules. * Revert the commit. * Push the patch to master and notify the author. This style of early rollback will become more important as we grow as it puts the onus on fixing on the right person and minimizes negative impact on other developers. On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel" wrote: > Hello Simon, > > On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote: > > | Just a hunch... could it have been broken by one of the recent linker- > > | related patches since Nov 24th? > > > > That seems very plausible, yes. But still there's the question of > > what to do about it. > > a) Empirically: Try locally 'git revert'ing > > 383733b9191a36e2d3f757700842dbc3855911d9 > > and/or > > b5e8b3b162b3ff15ae6caf1afc659565365f54a8 > > and see if your problem goes away, or > > b) Ask Simon Marlow (he either wrote or reviewed those two patches) if > he sees something odd in those patches that could have broken > Windows' GHCi... > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Dec 1 09:45:11 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 1 Dec 2014 10:45:11 +0100 Subject: Possible error with strict_mark in Parser.y In-Reply-To: References: Message-ID: <201412011045.11927.jan.stolarek@p.lodz.pl> Looking at the source code comments it seems that you're right: data HsBang = HsUserBang -- The user's source-code request (Maybe Bool) -- Just True {-# UNPACK #-} -- Just False {-# NOUNPACK #-} -- Nothing no pragma Bool -- True <=> '!' specified Can anyone confirm? Janek Dnia niedziela, 30 listopada 2014, Alan & Kim Zimmerman napisa?: > If I look at the production for strict_mark in the parser > > https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355 > > strict_mark :: { Located ([AddAnn],HsBang) } > > : '!' { sL1 $1 ([],HsUserBang Nothing > > True) } > > | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang > > (Just True) False) } > > | '{-# NOUNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang > > (Just False) True) } -- ***Correct? > > | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang > > (Just True) True) } > > | '{-# NOUNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang > > (Just False) True) } > > I would expect the final True or False value to reflect the presence of the > '!' mark. > > But the second line has no '!' but returns True. > > I suspect this is an error. > > Alan From karel.gardas at centrum.cz Mon Dec 1 09:53:45 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 01 Dec 2014 10:53:45 +0100 Subject: Cross-compiling GHC for ARM (RPi) In-Reply-To: <547BABA1.4080907@gmail.com> References: <547BABA1.4080907@gmail.com> Message-ID: <547C3AA9.7030900@centrum.cz> Two obvious questions: 1) have you installed your ncurses into your sysroot? 2) have you passed your sysroot to really all gcc invocations? Your description looks like at least one answer to above question should be "no". For example I used custom bash script to solve (2), see [1]. Cheers, Karel [1]: https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/ On 12/ 1/14 12:43 AM, Xandaros wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm having some trouble cross-compiling GHC (or just making a > cross-compiler, which is what I am trying to do for now). > > I got my toolchain through crosstool-ng. I just took the > arm-unknown-linux-gnueabi sample and disabled the "render the toolchain > read-only" option. > > Unfortunately nt-ng does not come with ncurses, so I also compiled and > installed that. I set the prefix to > ~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot, > where ~/x-tools/arm-unknown-linux-gnueabi is where my toolchain is located. > > I copied the mk/build.mk.sample file to mk/build.mk and uncommented the > quick-cross option. I left everything else as-is. > > After configuring I executed make, which runs for quite a while but > eventually it complains about not being able to find the curses headers. > > What do I do to fix this? I wouldn't mind using a different toolchain if > I can get it to work, so I am open for anything. > > Configure summary of ncurses and last lines of output of make: > http://hastebin.com/uwuwenucux.txt > > I hope you can help me resolve this, I've been trying to do this for a > long time now :/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUe6uhAAoJEGBf7SEXmH6sIMkH/3eK500hnjjN3+hv/7P0YmY2 > QVcDWJxRMgnFCyFA9oxAeJYqKeIps2H3555NSLdB19DK7QCG1x4TJpUBGCz09PfX > mH8ZN2qIirHIYUHOZa5JdE8cqvWd3hI1syr22PsxqyI4tkDuIfKsAp8IbJOd/vSX > 9oqKjHe0OYHKIoUUlHST1AI2lElMby69nxBMprhU8yugIyEFSmQg+nuxG2Hq5GA4 > SgOExWeuJHrxIAW0WZ8vipw7PG3IfJTzDSCMzIAPfri8TVhy2UNNVpjg4aaq//X0 > TXXweFS1O/EpDSuRkU/2b5nGlxbaNObLI5eAJ0Lot7Pl5Oa1afK5l5ZWYipx+Fk= > =ol51 > -----END PGP SIGNATURE----- > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Dec 1 12:02:48 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 12:02:48 +0000 Subject: Performance regression on typechecking type families? In-Reply-To: <201411301114.34585.jan.stolarek@p.lodz.pl> References: <201411301114.34585.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EF26B@DB3PRD3001MB020.064d.mgd.msft.net> | I personally have run into exponential compile times with type families. | Unfortunately I have not | had the time yet to reduce my test case to something tractable. Ha! If you do find the time, I'm sure everyone would be grateful. Just use the time while waiting for the type checker. If it is truly exponential, you will easily have enough waiting time :-) Simon From mail at joachim-breitner.de Mon Dec 1 13:28:03 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 01 Dec 2014 14:28:03 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1417423368.1448.3.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> Message-ID: <1417440483.2364.0.camel@joachim-breitner.de> Hi, Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner: > Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari: > > > Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari: > > >> > What would be a reliable way to make the build system pass > > >> > -B/usr/bin/ld.gold to gcc? Is > > >> > SRC_HC_OPTS += -optc-B/usr/bin/ld.gold > > >> > in mk/build.mk a good idea? > > >> > > > >> Indeed this is much cleaner. I just wanted a way to accomplish this > > >> without editing build.mk. > > > > > > Cleaner maybe, but it was not picked up either. Or maybe we are looking > > > at a different issue, not solved by using ld.gold? > > > > > I suspect that it this is the gold issue. I should have looked at your > > command line a bit more carefully; I suspect you want > > > > SRC_HC_OPTS += -optl-B/usr/bin/ld.gold > > > > Hopefully this will do it; at least the option appears to make it to the > > right phase now. > > Trying it right now... no success, same error: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20141119-6&stamp=1417438953&file=log Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Dec 1 15:34:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 15:34:18 +0000 Subject: Windows build broken again: urgent In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3EECE8@DB3PRD3001MB020.064d.mgd.msft.net> <87fvczhil8.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF3F3EED4E@DB3PRD3001MB020.064d.mgd.msft.net> <87bnnnhi9w.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EF8BE@DB3PRD3001MB020.064d.mgd.msft.net> Indeed. But each bisect takes quite a while. So my attention switches and it takes a while to get back. I was hoping some machine might do it for me. Herbert suggested some commits to revert. I?ll try that first From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 01 December 2014 09:45 To: Herbert Valerio Riedel Cc: ghc-devs at haskell.org; Simon Marlow; Simon Peyton Jones Subject: Re: Windows build broken again: urgent In general I think a good course of action when this happens is: * Use git bisect to find the offending commit. This works now because we moved to submodules. * Revert the commit. * Push the patch to master and notify the author. This style of early rollback will become more important as we grow as it puts the onus on fixing on the right person and minimizes negative impact on other developers. On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel" > wrote: Hello Simon, On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote: > | Just a hunch... could it have been broken by one of the recent linker- > | related patches since Nov 24th? > > That seems very plausible, yes. But still there's the question of > what to do about it. a) Empirically: Try locally 'git revert'ing 383733b9191a36e2d3f757700842dbc3855911d9 and/or b5e8b3b162b3ff15ae6caf1afc659565365f54a8 and see if your problem goes away, or b) Ask Simon Marlow (he either wrote or reviewed those two patches) if he sees something odd in those patches that could have broken Windows' GHCi... Cheers, hvr _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Mon Dec 1 15:38:03 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 1 Dec 2014 09:38:03 -0600 Subject: GHC Weekly News - 2014/12/01 Message-ID: Hi *, It's that time again for some good ol' fashion GHC news, this time just after the holidays. Some of the things happening in the past week include: - Partial Type Signatures has been merged into HEAD. Many thanks to Thomas Winant, who worked on this feature for several months! - As mentioned last week, GHC 7.10 will no longer ship `haskell98` and `haskell2010`, nor `old-time` or `old-locale`. - Neil Mitchell asked a very good question on `ghc-devs`: what's the process for getting your library synced for the GHC 7.10 release? As the maintainer of `filepath` he'd like to know, and Herbert responded quickly: https://www.haskell.org/pipermail/ghc-devs/2014-November/007394.html - Yuras Shumovich has more questions about exception handling, primarily: why is `mask` used in `waitQSem`? Simon Marlow responds: https://www.haskell.org/pipermail/ghc-devs/2014-November/007394.html - Carter Schonwald reports that GHC is having problems building on OS X with XCode 6, but Kazu Yamamoto replied he had no problem - perhaps some OS X wizards can help figure out the discrepancy: https://www.haskell.org/pipermail/ghc-devs/2014-November/007394.html - Austin Seipp announced GHC 7.8.4 Release Candidate 1, with about a dozen bugfixes for major features: https://www.haskell.org/pipermail/ghc-devs/2014-November/007438.html - Gergo Erdi asked about backporting pattern synonym type signatures to 7.8.4. The conclusion? Probably won't happen - it's a bit too late! https://www.haskell.org/pipermail/ghc-devs/2014-November/007440.html - Carter Schonwald had some questions about the let-app invariant and primop code, which he was puzzling about to help with some code generation work. There are also some nice discussions of caches and prefetching in pure programs later on, too: https://www.haskell.org/pipermail/ghc-devs/2014-November/007440.html & https://www.haskell.org/pipermail/ghc-devs/2014-November/007410.html - Ben Gamari talked about the current status of GHC and LLVM, GHC on ARM, and the future of our LLVM support on both the mailing lists, and his blog. A good read overall for those interested in the war-stories of GHC-on-ARM: https://www.haskell.org/pipermail/ghc-devs/2014-November/007469.html Closed tickets this week include: #9827, #7475, #9826, #7460, #7643, #8044, #8031, #7072, #3654, #7033, #9834, #6098, #6022, #5859, #5763, #9838, #9830, #7243, #9736, #9574, #5158, #9844, #9281, #9818, #4429, #8815, #2182, #4290, #9005, #9828, #9833, #9582, and #9850. Another huge thanks to **Thomas Miedema** who closed an extraordinary amount of tickets for us - the above list is still not even complete, and he's made a huge impact on the amount of open tickets in the past month or so. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ggreif at gmail.com Mon Dec 1 15:52:32 2014 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 1 Dec 2014 16:52:32 +0100 Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Gerg?, even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) Gabor On 11/29/14, Dr. ERDI Gergo wrote: > On Wed, 26 Nov 2014, Simon Peyton Jones wrote: > >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. >> But what do others think? > > Just to give an idea of how limited the scope of this change would be, > I've went and implemented it, on the 'wip/pattern-synonym-sig-backport' > branch (of both GHC and Haddock). > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From ggreif at gmail.com Mon Dec 1 16:01:11 2014 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 1 Dec 2014 17:01:11 +0100 Subject: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050) In-Reply-To: <20141201141923.58FC03A300@ghc.haskell.org> References: <20141201141923.58FC03A300@ghc.haskell.org> Message-ID: Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too? Cheers, Gabor On 12/1/14, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715fbab355ca/ghc > >>--------------------------------------------------------------- > > commit e6a2050ebb6da316aecec66a6795715fbab355ca > Author: Simon Peyton Jones > Date: Mon Dec 1 11:43:20 2014 +0000 > > Fix the handling of instance signatures (Trac #9582, #9833) > > This finally solves the issue of instance-method signatures that are > more polymorphic than the instanted class method. > > See Note [Instance method signatures] in TcInstDcls. > > A very nice fix for the two Trac tickets above. > > >>--------------------------------------------------------------- > > e6a2050ebb6da316aecec66a6795715fbab355ca > compiler/typecheck/TcBinds.lhs | 18 ++- > compiler/typecheck/TcClassDcl.lhs | 16 +-- > compiler/typecheck/TcInstDcls.lhs | 121 > ++++++++++++--------- > docs/users_guide/glasgow_exts.xml | 29 ++++- > .../tests/indexed-types/should_compile/T9582.hs | 14 +++ > testsuite/tests/indexed-types/should_compile/all.T | 1 + > testsuite/tests/polykinds/T9833.hs | 18 +++ > testsuite/tests/polykinds/all.T | 2 + > testsuite/tests/typecheck/should_fail/T6001.stderr | 9 +- > testsuite/tests/typecheck/should_fail/T7545.hs | 1 + > testsuite/tests/typecheck/should_fail/T7545.stderr | 5 - > testsuite/tests/typecheck/should_fail/all.T | 2 +- > 12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > From johan.tibell at gmail.com Mon Dec 1 18:01:17 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 1 Dec 2014 19:01:17 +0100 Subject: Windows build broken again: urgent In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3EF8BE@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3EECE8@DB3PRD3001MB020.064d.mgd.msft.net> <87fvczhil8.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF3F3EED4E@DB3PRD3001MB020.064d.mgd.msft.net> <87bnnnhi9w.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF3F3EF8BE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yes, ideally this would have been caught by a Windows build bot. On Mon, Dec 1, 2014 at 4:34 PM, Simon Peyton Jones wrote: > Indeed. But each bisect takes quite a while. So my attention switches > and it takes a while to get back. I was hoping some machine might do it > for me. > > > > Herbert suggested some commits to revert. I?ll try that first > > > > *From:* Johan Tibell [mailto:johan.tibell at gmail.com] > *Sent:* 01 December 2014 09:45 > *To:* Herbert Valerio Riedel > *Cc:* ghc-devs at haskell.org; Simon Marlow; Simon Peyton Jones > *Subject:* Re: Windows build broken again: urgent > > > > In general I think a good course of action when this happens is: > > * Use git bisect to find the offending commit. This works now because we > moved to submodules. > * Revert the commit. > * Push the patch to master and notify the author. > > This style of early rollback will become more important as we grow as it > puts the onus on fixing on the right person and minimizes negative impact > on other developers. > > On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel" > wrote: > > Hello Simon, > > On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote: > > | Just a hunch... could it have been broken by one of the recent linker- > > | related patches since Nov 24th? > > > > That seems very plausible, yes. But still there's the question of > > what to do about it. > > a) Empirically: Try locally 'git revert'ing > > 383733b9191a36e2d3f757700842dbc3855911d9 > > and/or > > b5e8b3b162b3ff15ae6caf1afc659565365f54a8 > > and see if your problem goes away, or > > b) Ask Simon Marlow (he either wrote or reviewed those two patches) if > he sees something odd in those patches that could have broken > Windows' GHCi... > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Mon Dec 1 18:17:00 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 01 Dec 2014 13:17:00 -0500 Subject: Status and future of the LLVM backend In-Reply-To: <1417440483.2364.0.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> Message-ID: <87h9xffd5v.fsf@gmail.com> Joachim Breitner writes: > Hi, > > > Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner: >> Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari: >> > I suspect that it this is the gold issue. I should have looked at your >> > command line a bit more carefully; I suspect you want >> > >> > SRC_HC_OPTS += -optl-B/usr/bin/ld.gold >> > >> > Hopefully this will do it; at least the option appears to make it to the >> > right phase now. >> >> Trying it right now... > > no success, same error: > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20141119-6&stamp=1417438953&file=log > Is there any way you could poke around at the state of the tree after the failure? It would be nice to confirm that this is in fact that bfd/gold issue and perhaps figure out why ld.gold isn't being used. Otherwise I can try to reproduce this on my ARM box. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Mon Dec 1 20:12:29 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 1 Dec 2014 15:12:29 -0500 Subject: more parser conflicts? Message-ID: Hi devs, In unrelated work, I saw this scroll across when happy'ing the parser: > shift/reduce conflicts: 60 > reduce/reduce conflicts: 16 These numbers seem quite a bit higher than what I last remember (which is something like 48 and 1, not 60 and 16). Does anyone know why? Thanks, Richard From greg at gregorycollins.net Mon Dec 1 21:21:08 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 1 Dec 2014 13:21:08 -0800 Subject: help wrt semantics / primops for pure prefetches In-Reply-To: References: <5476F0A9.7080208@gmail.com> Message-ID: On Sat, Nov 29, 2014 at 6:33 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > @greg, i'd love more code review if you dont mind :) I'm not familiar enough with the relevant code to have anything to say about your patch one way or the other, I'm afraid :(. LGTM, in principle. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 1 21:33:46 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 21:33:46 +0000 Subject: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050) In-Reply-To: References: <20141201141923.58FC03A300@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EFC3A@DB3PRD3001MB020.064d.mgd.msft.net> Good point, thank you! | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 01 December 2014 16:01 | To: ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Fix the handling of instance | signatures (Trac #9582, #9833) (e6a2050) | | Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too? | | Cheers, | | Gabor | | On 12/1/14, git at git.haskell.org wrote: | > Repository : ssh://git at git.haskell.org/ghc | > | > On branch : master | > Link : | > | http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715 | fbab355ca/ghc | > | >>--------------------------------------------------------------- | > | > commit e6a2050ebb6da316aecec66a6795715fbab355ca | > Author: Simon Peyton Jones | > Date: Mon Dec 1 11:43:20 2014 +0000 | > | > Fix the handling of instance signatures (Trac #9582, #9833) | > | > This finally solves the issue of instance-method signatures that | are | > more polymorphic than the instanted class method. | > | > See Note [Instance method signatures] in TcInstDcls. | > | > A very nice fix for the two Trac tickets above. | > | > | >>--------------------------------------------------------------- | > | > e6a2050ebb6da316aecec66a6795715fbab355ca | > compiler/typecheck/TcBinds.lhs | 18 ++- | > compiler/typecheck/TcClassDcl.lhs | 16 +-- | > compiler/typecheck/TcInstDcls.lhs | 121 | > ++++++++++++--------- | > docs/users_guide/glasgow_exts.xml | 29 ++++- | > .../tests/indexed-types/should_compile/T9582.hs | 14 +++ | > testsuite/tests/indexed-types/should_compile/all.T | 1 + | > testsuite/tests/polykinds/T9833.hs | 18 +++ | > testsuite/tests/polykinds/all.T | 2 + | > testsuite/tests/typecheck/should_fail/T6001.stderr | 9 +- | > testsuite/tests/typecheck/should_fail/T7545.hs | 1 + | > testsuite/tests/typecheck/should_fail/T7545.stderr | 5 - | > testsuite/tests/typecheck/should_fail/all.T | 2 +- | > 12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca | > _______________________________________________ | > ghc-commits mailing list | > ghc-commits at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-commits | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Dec 1 21:43:41 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 21:43:41 +0000 Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EFCA8@DB3PRD3001MB020.064d.mgd.msft.net> The issue is not so much timing for 7.8.4 (it's a modes change to pretty-printing only) but rather that it would make 7.8.4 behave differently to 7.8.3 (although similarly to 7.10). We typically do not do that. And the same would be true of 7.8.5. Simon | -----Original Message----- | From: Gabor Greif [mailto:ggreif at gmail.com] | Sent: 01 December 2014 15:53 | To: Dr. ERDI Gergo | Cc: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: Back-porting pattern synonym type signature syntax for GHC | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] | | Gerg?, | | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) | | Gabor | | | On 11/29/14, Dr. ERDI Gergo wrote: | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote: | > | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. | >> But what do others think? | > | > Just to give an idea of how limited the scope of this change would be, | > I've went and implemented it, on the 'wip/pattern-synonym-sig-backport' | > branch (of both GHC and Haddock). | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > From simonpj at microsoft.com Mon Dec 1 22:13:01 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Dec 2014 22:13:01 +0000 Subject: Possible error with strict_mark in Parser.y In-Reply-To: <201412011045.11927.jan.stolarek@p.lodz.pl> References: <201412011045.11927.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3EFD6F@DB3PRD3001MB020.064d.mgd.msft.net> Thanks. It was totally wrong. I have fixed it. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan | Stolarek | Sent: 01 December 2014 09:45 | To: ghc-devs at haskell.org | Subject: Re: Possible error with strict_mark in Parser.y | | Looking at the source code comments it seems that you're right: | | data HsBang | = HsUserBang -- The user's source-code request | (Maybe Bool) -- Just True {-# UNPACK #-} | -- Just False {-# NOUNPACK #-} | -- Nothing no pragma | Bool -- True <=> '!' specified | | | Can anyone confirm? | | Janek | | Dnia niedziela, 30 listopada 2014, Alan & Kim Zimmerman napisa?: | > If I look at the production for strict_mark in the parser | > | > https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355 | > | > strict_mark :: { Located ([AddAnn],HsBang) } | > | > : '!' { sL1 $1 ([],HsUserBang Nothing | > | > True) } | > | > | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc | $2],HsUserBang | > | > (Just True) False) } | > | > | '{-# NOUNPACK' '#-}' { sLL $1 $> ([mo $1,mc | $2],HsUserBang | > | > (Just False) True) } -- ***Correct? | > | > | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc | $2],HsUserBang | > | > (Just True) True) } | > | > | '{-# NOUNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc | $2],HsUserBang | > | > (Just False) True) } | > | > I would expect the final True or False value to reflect the presence of | the | > '!' mark. | > | > But the second line has no '!' but returns True. | > | > I suspect this is an error. | > | > Alan | | | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From ggreif at gmail.com Mon Dec 1 22:19:57 2014 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 1 Dec 2014 23:19:57 +0100 Subject: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050) In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3EFC3A@DB3PRD3001MB020.064d.mgd.msft.net> References: <20141201141923.58FC03A300@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF3F3EFC3A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I tried to build HEAD to verify this, but got a linker error. IIRC when I filed this bug I provided a test case which did compile, but you had to uncomment signatures to see an error. I did not see those sigs uncommented in your repro checkin. So it might be too early for a party... Gabor Em segunda-feira, 1 de dezembro de 2014, Simon Peyton Jones < simonpj at microsoft.com> escreveu: > Good point, thank you! > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org ] On > Behalf Of Gabor > | Greif > | Sent: 01 December 2014 16:01 > | To: ghc-devs at haskell.org > | Subject: Re: [commit: ghc] master: Fix the handling of instance > | signatures (Trac #9582, #9833) (e6a2050) > | > | Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too? > | > | Cheers, > | > | Gabor > | > | On 12/1/14, git at git.haskell.org > wrote: > | > Repository : ssh://git at git.haskell.org/ghc > | > > | > On branch : master > | > Link : > | > > | > http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715 > | fbab355ca/ghc > | > > | >>--------------------------------------------------------------- > | > > | > commit e6a2050ebb6da316aecec66a6795715fbab355ca > | > Author: Simon Peyton Jones > > | > Date: Mon Dec 1 11:43:20 2014 +0000 > | > > | > Fix the handling of instance signatures (Trac #9582, #9833) > | > > | > This finally solves the issue of instance-method signatures that > | are > | > more polymorphic than the instanted class method. > | > > | > See Note [Instance method signatures] in TcInstDcls. > | > > | > A very nice fix for the two Trac tickets above. > | > > | > > | >>--------------------------------------------------------------- > | > > | > e6a2050ebb6da316aecec66a6795715fbab355ca > | > compiler/typecheck/TcBinds.lhs | 18 ++- > | > compiler/typecheck/TcClassDcl.lhs | 16 +-- > | > compiler/typecheck/TcInstDcls.lhs | 121 > | > ++++++++++++--------- > | > docs/users_guide/glasgow_exts.xml | 29 ++++- > | > .../tests/indexed-types/should_compile/T9582.hs | 14 +++ > | > testsuite/tests/indexed-types/should_compile/all.T | 1 + > | > testsuite/tests/polykinds/T9833.hs | 18 +++ > | > testsuite/tests/polykinds/all.T | 2 + > | > testsuite/tests/typecheck/should_fail/T6001.stderr | 9 +- > | > testsuite/tests/typecheck/should_fail/T7545.hs | 1 + > | > testsuite/tests/typecheck/should_fail/T7545.stderr | 5 - > | > testsuite/tests/typecheck/should_fail/all.T | 2 +- > | > 12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca > | > _______________________________________________ > | > ghc-commits mailing list > | > ghc-commits at haskell.org > | > http://www.haskell.org/mailman/listinfo/ghc-commits > | > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergo at erdi.hu Mon Dec 1 23:09:02 2014 From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=) Date: Tue, 2 Dec 2014 07:09:02 +0800 Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3EFCA8@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F3EFCA8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: It is clear to everyone that all it would change is the *output* of GHCi's :info and Haddock-generated docs, right? There's no change whatsoever to what programs are accepted by GHC, or what they mean. On Dec 2, 2014 5:44 AM, "Simon Peyton Jones" wrote: > The issue is not so much timing for 7.8.4 (it's a modes change to > pretty-printing only) but rather that it would make 7.8.4 behave > differently to 7.8.3 (although similarly to 7.10). We typically do not do > that. And the same would be true of 7.8.5. > > Simon > > | -----Original Message----- > | From: Gabor Greif [mailto:ggreif at gmail.com] > | Sent: 01 December 2014 15:53 > | To: Dr. ERDI Gergo > | Cc: Simon Peyton Jones; ghc-devs at haskell.org > | Subject: Re: Back-porting pattern synonym type signature syntax for GHC > | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] > | > | Gerg?, > | > | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) > | > | Gabor > | > | > | On 11/29/14, Dr. ERDI Gergo wrote: > | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote: > | > > | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. > | >> But what do others think? > | > > | > Just to give an idea of how limited the scope of this change would be, > | > I've went and implemented it, on the 'wip/pattern-synonym-sig-backport' > | > branch (of both GHC and Haddock). > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Mon Dec 1 23:27:57 2014 From: ggreif at gmail.com (Gabor Greif) Date: Tue, 2 Dec 2014 00:27:57 +0100 Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F3EFCA8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: So it could be regarded as a bugfix? Em ter?a-feira, 2 de dezembro de 2014, Dr. ?RDI Gerg? escreveu: > It is clear to everyone that all it would change is the *output* of GHCi's > :info and Haddock-generated docs, right? There's no change whatsoever to > what programs are accepted by GHC, or what they mean. > On Dec 2, 2014 5:44 AM, "Simon Peyton Jones" > wrote: > >> The issue is not so much timing for 7.8.4 (it's a modes change to >> pretty-printing only) but rather that it would make 7.8.4 behave >> differently to 7.8.3 (although similarly to 7.10). We typically do not do >> that. And the same would be true of 7.8.5. >> >> Simon >> >> | -----Original Message----- >> | From: Gabor Greif [mailto:ggreif at gmail.com >> ] >> | Sent: 01 December 2014 15:53 >> | To: Dr. ERDI Gergo >> | Cc: Simon Peyton Jones; ghc-devs at haskell.org >> >> | Subject: Re: Back-porting pattern synonym type signature syntax for GHC >> | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] >> | >> | Gerg?, >> | >> | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) >> | >> | Gabor >> | >> | >> | On 11/29/14, Dr. ERDI Gergo > > wrote: >> | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote: >> | > >> | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs >> lie. >> | >> But what do others think? >> | > >> | > Just to give an idea of how limited the scope of this change would be, >> | > I've went and implemented it, on the >> 'wip/pattern-synonym-sig-backport' >> | > branch (of both GHC and Haddock). >> | > _______________________________________________ >> | > ghc-devs mailing list >> | > ghc-devs at haskell.org >> >> | > http://www.haskell.org/mailman/listinfo/ghc-devs >> | > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergo at erdi.hu Tue Dec 2 00:12:12 2014 From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=) Date: Tue, 2 Dec 2014 08:12:12 +0800 Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F3EFCA8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: With enough intellectual dishonesty, sure... On Dec 2, 2014 7:29 AM, "Gabor Greif" wrote: > So it could be regarded as a bugfix? > > Em ter?a-feira, 2 de dezembro de 2014, Dr. ?RDI Gerg? > escreveu: > >> It is clear to everyone that all it would change is the *output* of >> GHCi's :info and Haddock-generated docs, right? There's no change >> whatsoever to what programs are accepted by GHC, or what they mean. >> On Dec 2, 2014 5:44 AM, "Simon Peyton Jones" >> wrote: >> >>> The issue is not so much timing for 7.8.4 (it's a modes change to >>> pretty-printing only) but rather that it would make 7.8.4 behave >>> differently to 7.8.3 (although similarly to 7.10). We typically do not do >>> that. And the same would be true of 7.8.5. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: Gabor Greif [mailto:ggreif at gmail.com] >>> | Sent: 01 December 2014 15:53 >>> | To: Dr. ERDI Gergo >>> | Cc: Simon Peyton Jones; ghc-devs at haskell.org >>> | Subject: Re: Back-porting pattern synonym type signature syntax for GHC >>> | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] >>> | >>> | Gerg?, >>> | >>> | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 >>> :-) >>> | >>> | Gabor >>> | >>> | >>> | On 11/29/14, Dr. ERDI Gergo wrote: >>> | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote: >>> | > >>> | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs >>> lie. >>> | >> But what do others think? >>> | > >>> | > Just to give an idea of how limited the scope of this change would >>> be, >>> | > I've went and implemented it, on the >>> 'wip/pattern-synonym-sig-backport' >>> | > branch (of both GHC and Haddock). >>> | > _______________________________________________ >>> | > ghc-devs mailing list >>> | > ghc-devs at haskell.org >>> | > http://www.haskell.org/mailman/listinfo/ghc-devs >>> | > >>> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.crayne at gmail.com Tue Dec 2 01:50:47 2014 From: jim.crayne at gmail.com (James Crayne) Date: Mon, 1 Dec 2014 20:50:47 -0500 Subject: Keeping the "Newcomers" wiki page alive In-Reply-To: <5476E6C1.1020702@gmail.com> References: <201411121358.48239.jan.stolarek@p.lodz.pl> <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu> <201411130844.00005.jan.stolarek@p.lodz.pl> <5476E6C1.1020702@gmail.com> Message-ID: I am entirely new, in fact, this is my first post on this list, and I am not entirely sure I have picked the right spot to jump in tbh. I tried to think of a word for this category that fits better than difficulty, and it seems to me that the word that best captures what I understand to be the intention is something like "Barrier" as in barrier to entry. Perhaps the barrier to entry might best be read component-wise, as in Compiler-{virgin,newbie,veteren} etc? And so that could be combined into the component tag? On Thu, Nov 27, 2014 at 3:54 AM, Simon Marlow wrote: > On 13/11/2014 07:43, Jan Stolarek wrote: > >> I believe that current difficulty field is intended to mean "the amount >> of time required by >> someone who already knows what to do". Obviously, that's not the metric >> that we want to use for >> labelling newcomer-friendly tasks. (I wonder if the difficulty field in >> its current form is even >> useful to us?) >> >> Obviously, the metric that we want is "the amount of code familiarity >> required to fix a bug". For >> newcommers we probably want tickets that require knowledge of <1000 lines >> of code. >> >> I think the important questions are: >> >> 1. Do we find the current "difficulty" field useful? >> 2. Should we have a Trac field to label accessibility for newcomers? >> >> My answers are: >> 1. No. >> > > We could remove the Difficulty field, given that it hasn't really been > useful and it can be subsumed by the keywords field for the things we want > it for. It was originally intended to help (a) new developers find tickets > to work on, and (b) help us find good projects for the GSoc. Both of which > can be keywords, so I'd be happy to get rid of Difficulty. > > Cheers, > Simon > > > > > 2. Yes, we should have a filed with accessibility levels like: >> newcomer/intermediate/advanced/rocket science. >> >> If we have 2) then we can have a list of tickets in the Newcomers page >> generated dynamically. >> >> Janek >> >> Dnia czwartek, 13 listopada 2014, Richard Eisenberg napisa?: >> >>> Forgive me if I'm repeating others' comments, but the newcomer label, to >>> me, is independent of level of difficulty -- it has much more to do with >>> how "messy" the work is, I think. >>> >>> I'll make a concrete proposal: Tag appropriate bugs/feature requests with >>> "newcomer" and, if you want, mention that you'll mentor in a comment. I >>> don't think there's a glaring need to be able to search by mentor, so I'm >>> not proposing a Trac field for that. >>> >>> If I see here that a few others will adopt this proposal, I'll start >>> doing >>> it -- I already have several tickets in mind. >>> >>> Richard >>> >>> On Nov 12, 2014, at 6:27 PM, Isaac Hollander McCreery < >>> ihmccreery at gmail.com> wrote: >>> >>>> Glad people are excited about this, >>>> >>>> I like "beginner/intermediate/advanced". I think it's more accurate >>>> than >>>> "easy/hard" and clearer than "accessible", "welcoming", etc. >>>> >>>> I also want to call out the "mentor" label that the Rust team is using: >>>> experienced devs nominate themselves as mentors on projects, then >>>> newcomers can tackle them with some support. As a newcomer, that's >>>> *extremely* appealing to me. >>>> >>>> Cheers, >>>> Ike >>>> >>>> On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery >>>> wrote: On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner >>>> wrote: The quality that we are looking for >>>> is >>>> ?tacklabe by a newcomer?, i.e. not requiring too deep knowledge of GHC. >>>> Is there a nice word for that? I found ?accessible?, ?welcoming?, >>>> ?appealing? ? anything that sounds good in native English speaker?s >>>> ears? >>>> :-) >>>> >>>> Various projects I'm involved with use >>>> >>>> difficulty: beginner (or just "beginner") >>>> babydev-bait (!) >>>> newcomer (several use "newbie" but I do not recommend that label) >>>> >>>> -- >>>> brandon s allbery kf8nh sine nomine >>>> associates allbery.b at gmail.com >>>> ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad >>>> http://sinenomine.net >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Dec 2 08:05:01 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Dec 2014 08:05:01 +0000 Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F3EFCA8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F0210@DB3PRD3001MB020.064d.mgd.msft.net> It is clear to everyone that all it would change is the *output* of GHCi's :info and Haddock-generated docs, right? There's no change whatsoever to what programs are accepted by GHC, or what they mean. Yes that?s right. (Your patch was helpful in clarifying that.) To me it doesn?t seem a big deal either way. Personally I?m on the fence on this one, but it?s true that we never do anything in a patch release except fix bugs, and Simon M was reluctant to break that policy without pretty strong reason. If there was an uprising of user sentiment that we ought to break that policy on this occasion, it?d be easily to do. Simon From: Dr. ?RDI Gerg? [mailto:gergo at erdi.hu] Sent: 01 December 2014 23:09 To: Simon Peyton Jones Cc: GHC Devs; Gabor Greif Subject: RE: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] It is clear to everyone that all it would change is the *output* of GHCi's :info and Haddock-generated docs, right? There's no change whatsoever to what programs are accepted by GHC, or what they mean. On Dec 2, 2014 5:44 AM, "Simon Peyton Jones" > wrote: The issue is not so much timing for 7.8.4 (it's a modes change to pretty-printing only) but rather that it would make 7.8.4 behave differently to 7.8.3 (although similarly to 7.10). We typically do not do that. And the same would be true of 7.8.5. Simon | -----Original Message----- | From: Gabor Greif [mailto:ggreif at gmail.com] | Sent: 01 December 2014 15:53 | To: Dr. ERDI Gergo | Cc: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: Back-porting pattern synonym type signature syntax for GHC | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] | | Gerg?, | | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) | | Gabor | | | On 11/29/14, Dr. ERDI Gergo > wrote: | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote: | > | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. | >> But what do others think? | > | > Just to give an idea of how limited the scope of this change would be, | > I've went and implemented it, on the 'wip/pattern-synonym-sig-backport' | > branch (of both GHC and Haddock). | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 2 09:14:00 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 02 Dec 2014 10:14:00 +0100 Subject: Keeping the "Newcomers" wiki page alive In-Reply-To: References: <201411121358.48239.jan.stolarek@p.lodz.pl> <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu> <201411130844.00005.jan.stolarek@p.lodz.pl> <5476E6C1.1020702@gmail.com> Message-ID: <1417511640.1490.1.camel@joachim-breitner.de> Dear James, Am Montag, den 01.12.2014, 20:50 -0500 schrieb James Crayne: > I am entirely new, in fact, this is my first post on this list, and I > am not entirely sure I have picked the right spot to jump in tbh. > welcome! > > I tried to think of a word for this category that fits better than > difficulty, and it seems to me that the word that best captures what I > understand to be the intention is something like "Barrier" as in > barrier to entry. > > Perhaps the barrier to entry might best be read component-wise, as in > Compiler-{virgin,newbie,veteren} etc? And so that could be combined > into the component tag? The concept of the ?barrier? is a good one. But we already started using the "newcomer" tag, and after all its just a name, so I do not think it matters much... I say we stick what we have right now. You are free to jump right in, of course: https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gergo at erdi.hu Tue Dec 2 10:19:32 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Tue, 2 Dec 2014 18:19:32 +0800 (SGT) Subject: more parser conflicts? In-Reply-To: References: Message-ID: On Mon, 1 Dec 2014, Richard Eisenberg wrote: > In unrelated work, I saw this scroll across when happy'ing the parser: > >> shift/reduce conflicts: 60 >> reduce/reduce conflicts: 16 > > These numbers seem quite a bit higher than what I last remember (which is something like 48 and 1, not 60 and 16). Does anyone know why? The offending commit is bc2289e13d9586be087bd8136943dc35a0130c88. I know this because I was changing the parser for patsyn signatures, and so I updated the numbers in Parser.y to make sure I'm not adding any new conflicts: 25 June 2014 Conflicts: 47 shift/reduce 1 reduce/reduce but then when time came to rebase my changes before pushing, I noticed that it has gone up, and I had to update it yet again in Parser.y: 20 Nov 2014 Conflicts: 60 shift/reduce 12 reduce/reduce So anyway, the point is, if you try bc2289e and bc2289e^ you can see that that is the commit that introduced these new conflicts. From simonpj at microsoft.com Tue Dec 2 10:23:34 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Dec 2014 10:23:34 +0000 Subject: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050) In-Reply-To: References: <20141201141923.58FC03A300@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF3F3EFC3A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F0571@DB3PRD3001MB020.064d.mgd.msft.net> Good point! I un-commented the offending signatures and it?s still all fine. So party on! Simon From: Gabor Greif [mailto:ggreif at gmail.com] Sent: 01 December 2014 22:20 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050) I tried to build HEAD to verify this, but got a linker error. IIRC when I filed this bug I provided a test case which did compile, but you had to uncomment signatures to see an error. I did not see those sigs uncommented in your repro checkin. So it might be too early for a party... Gabor Em segunda-feira, 1 de dezembro de 2014, Simon Peyton Jones > escreveu: Good point, thank you! | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 01 December 2014 16:01 | To: ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Fix the handling of instance | signatures (Trac #9582, #9833) (e6a2050) | | Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too? | | Cheers, | | Gabor | | On 12/1/14, git at git.haskell.org > wrote: | > Repository : ssh://git at git.haskell.org/ghc | > | > On branch : master | > Link : | > | http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715 | fbab355ca/ghc | > | >>--------------------------------------------------------------- | > | > commit e6a2050ebb6da316aecec66a6795715fbab355ca | > Author: Simon Peyton Jones > | > Date: Mon Dec 1 11:43:20 2014 +0000 | > | > Fix the handling of instance signatures (Trac #9582, #9833) | > | > This finally solves the issue of instance-method signatures that | are | > more polymorphic than the instanted class method. | > | > See Note [Instance method signatures] in TcInstDcls. | > | > A very nice fix for the two Trac tickets above. | > | > | >>--------------------------------------------------------------- | > | > e6a2050ebb6da316aecec66a6795715fbab355ca | > compiler/typecheck/TcBinds.lhs | 18 ++- | > compiler/typecheck/TcClassDcl.lhs | 16 +-- | > compiler/typecheck/TcInstDcls.lhs | 121 | > ++++++++++++--------- | > docs/users_guide/glasgow_exts.xml | 29 ++++- | > .../tests/indexed-types/should_compile/T9582.hs | 14 +++ | > testsuite/tests/indexed-types/should_compile/all.T | 1 + | > testsuite/tests/polykinds/T9833.hs | 18 +++ | > testsuite/tests/polykinds/all.T | 2 + | > testsuite/tests/typecheck/should_fail/T6001.stderr | 9 +- | > testsuite/tests/typecheck/should_fail/T7545.hs | 1 + | > testsuite/tests/typecheck/should_fail/T7545.stderr | 5 - | > testsuite/tests/typecheck/should_fail/all.T | 2 +- | > 12 files changed, 157 insertions(+), 79 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 e6a2050ebb6da316aecec66a6795715fbab355ca | > _______________________________________________ | > ghc-commits mailing list | > ghc-commits at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-commits | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From g9ks157k at acme.softbase.org Tue Dec 2 12:48:56 2014 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue, 02 Dec 2014 14:48:56 +0200 Subject: Arrow notation and GHC 7.10 freeze Message-ID: <1417524536.29262.1.camel@idefix> Hi, I would like to work on . It would be great if the results of this work could go into GHC 7.10. Is this still possible? When will GHC 7.10 be frozen? All the best, Wolfgang From simonpj at microsoft.com Tue Dec 2 13:27:47 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Dec 2014 13:27:47 +0000 Subject: Arrow notation and GHC 7.10 freeze In-Reply-To: <1417524536.29262.1.camel@idefix> References: <1417524536.29262.1.camel@idefix> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F081B@DB3PRD3001MB020.064d.mgd.msft.net> It's frozen now. But do work on it for 7.12! It'll come round sooner than you think. There are many arrow-related tickets longing for love. e.g. #7828, #5267, #5777, #5333, #344 Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Wolfgang Jeltsch | Sent: 02 December 2014 12:49 | To: ghc-devs at haskell.org | Subject: Arrow notation and GHC 7.10 freeze | | Hi, | | I would like to work on | . | It would be great if the results of this work could go into GHC 7.10. | Is this still possible? When will GHC 7.10 be frozen? | | All the best, | Wolfgang | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Tue Dec 2 20:19:17 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 2 Dec 2014 22:19:17 +0200 Subject: API Annotations and HsSCC / HsTickPragma Message-ID: I am in the process of working the shiny new API annotations through into a practical example in ghc-exactprint [1], but I have hit a snag. A SCC annotation appears in the source as {-# SCC "name" #-} and if enabled via -prof results in the expression being wrapped in HsSCC FastString (LHsExpr id) BUT, if not enabled, it appears as HsPar (LHsExpr id) >From the parser/annotation point of view, the appropriate annotations are generated, and can be used to distinguish the two cases. The problem is that the annotations only capture the SrcSpan of the thing being annotated, so in the HsPar case the contents of the FastString is lost. A similar situation exists for HsTickPragma, HsTickPragma -- A pragma introduced tick (FastString,(Int,Int),(Int,Int)) -- external span for this tick (LHsExpr id) which also degrades to HsPar I see a number of possible solutions 1. Add the missing information to HsPar in a Maybe HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they are active or not. 3. Introduce an additional annotation type to carry the missing information. I welcome advice on the best way forward. Alan [1] https://github.com/alanz/ghc-exactprint/tree/wip -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.dominguez at tweag.io Tue Dec 2 21:06:12 2014 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Tue, 2 Dec 2014 19:06:12 -0200 Subject: New implementation draft for -XStaticPointers Message-ID: Hello, We are pleased to announce a new implementation draft of the StaticPointers extension [1]. We plan to improve the code still, and probably the interface of GHC.StaticPtr will undergo some changes, but the draft already covers the features that would make us happy to have in ghc 7.10. Looking forward to your comments. Best, Tweag I/O Team [1] https://phabricator.haskell.org/D550 From bos at serpentine.com Tue Dec 2 21:06:50 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 2 Dec 2014 13:06:50 -0800 Subject: Linker change in GHC 7.8 leads to widespread issues Message-ID: Hi folks, It seems that something somewhere in linker-land changed in GHC 7.8 such that packages that include C components now need to be built with position-independent code on some platforms. This affects a number of my packages. I am not sure whether the correct fix is to pepper all of these packages (and presumably dozens to hundreds of other packages on Hackage) with "-fPIC" and issue new releases, or to instead teach Cabal to do this. It would certainly be vastly less disruptive to all of the affected package authors to have Cabal automatically do the right thing here. Could someone who's closer to both piles of code please suggest which approach they believe is more appropriate? -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Dec 2 21:31:15 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 2 Dec 2014 16:31:15 -0500 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: whats an example of such a package? On Tue, Dec 2, 2014 at 4:06 PM, Bryan O'Sullivan wrote: > Hi folks, > > It seems that something somewhere in linker-land changed in GHC 7.8 such > that packages that include C components now need to be built with > position-independent code on some platforms. > > This affects a number of my packages. I am not sure whether the correct > fix is to pepper all of these packages (and presumably dozens to hundreds > of other packages on Hackage) with "-fPIC" and issue new releases, or to > instead teach Cabal to do this. It would certainly be vastly less > disruptive to all of the affected package authors to have Cabal > automatically do the right thing here. > > Could someone who's closer to both piles of code please suggest which > approach they believe is more appropriate? > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mietek at bak.io Tue Dec 2 21:43:47 2014 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Tue, 2 Dec 2014 21:43:47 +0000 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: On 2014-12-02, at 21:31, Carter Schonwald wrote: > whats an example of such a package? text-icu. https://github.com/bos/text-icu/pull/9 FWIW, I?m in favour of fixing this at the Cabal level. https://github.com/haskell/cabal/issues/2207 -- Mi?tek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From g9ks157k at acme.softbase.org Tue Dec 2 22:17:20 2014 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed, 03 Dec 2014 00:17:20 +0200 Subject: Arrow notation and GHC 7.10 freeze In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F081B@DB3PRD3001MB020.064d.mgd.msft.net> References: <1417524536.29262.1.camel@idefix> <618BE556AADD624C9C918AA5D5911BEF3F3F081B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1417558640.29262.20.camel@idefix> Am Dienstag, den 02.12.2014, 13:27 +0000 schrieb Simon Peyton Jones: > It's frozen now. Hmm, given the current weather, this is actually not surprising. ;-) > But do work on it for 7.12! It'll come round sooner than you think. When is 7.12 expected to be frozen, and when to be released? All the best, Wolfgang > There are many arrow-related tickets longing for love. > e.g. #7828, #5267, #5777, #5333, #344 > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Wolfgang Jeltsch > | Sent: 02 December 2014 12:49 > | To: ghc-devs at haskell.org > | Subject: Arrow notation and GHC 7.10 freeze > | > | Hi, > | > | I would like to work on > | . > | It would be great if the results of this work could go into GHC 7.10. > | Is this still possible? When will GHC 7.10 be frozen? > | > | All the best, > | Wolfgang > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs From johan.tibell at gmail.com Tue Dec 2 22:50:39 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 2 Dec 2014 23:50:39 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: If someone can figure out what the right fix is and if it happens to be in Cabal I'd be happy to merge any changes. On Tue, Dec 2, 2014 at 10:43 PM, Mi?tek Bak wrote: > On 2014-12-02, at 21:31, Carter Schonwald > wrote: > > > whats an example of such a package? > > > text-icu. > https://github.com/bos/text-icu/pull/9 > > FWIW, I?m in favour of fixing this at the Cabal level. > https://github.com/haskell/cabal/issues/2207 > > -- > Mi?tek > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 2 22:58:09 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 02 Dec 2014 23:58:09 +0100 Subject: Failing tests: literals T5681 annotations In-Reply-To: <1417374073.3101.10.camel@joachim-breitner.de> References: <1416652515.1406.1.camel@joachim-breitner.de> <1416930493.21627.3.camel@joachim-breitner.de> <1417374073.3101.10.camel@joachim-breitner.de> Message-ID: <1417561089.344.1.camel@joachim-breitner.de> Hi, Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner: > I?m still seeing this failure: > > Compile failed (status 256) errors were: > /tmp/ghc16123_0/ghc16123_5.s: Assembler messages: > > /tmp/ghc16123_0/ghc16123_5.s:26:0: > Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section} > > /tmp/ghc16123_0/ghc16123_5.s:46:0: > Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section} > > /tmp/ghc16123_0/ghc16123_5.s:66:0: > Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section} > > /tmp/ghc16123_0/ghc16123_5.s:86:0: > Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section} > > /tmp/ghc16123_0/ghc16123_5.s:106:0: > Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section} > > /tmp/ghc16123_0/ghc16123_5.s:126:0: > Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section} > > *** unexpected failure for T5681(optllvm) > > > https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt > > Any ideas? is it possible that this is due the llvm version used? Do we support 3.4 in GHC HEAD? Using LLVM tools llc : /usr/local/clang-3.4/bin/llc opt : /usr/local/clang-3.4/bin/opt Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ekmett at gmail.com Wed Dec 3 04:31:21 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 3 Dec 2014 15:31:21 +1100 Subject: Arrow notation and GHC 7.10 freeze In-Reply-To: <1417558640.29262.20.camel@idefix> References: <1417524536.29262.1.camel@idefix> <618BE556AADD624C9C918AA5D5911BEF3F3F081B@DB3PRD3001MB020.064d.mgd.msft.net> <1417558640.29262.20.camel@idefix> Message-ID: We typically have a year between releases, so in the absence of anything contradictory I'd expect the freeze for that to be about this time next year. -Edward On Wed, Dec 3, 2014 at 9:17 AM, Wolfgang Jeltsch wrote: > Am Dienstag, den 02.12.2014, 13:27 +0000 schrieb Simon Peyton Jones: > > It's frozen now. > > Hmm, given the current weather, this is actually not surprising. ;-) > > > But do work on it for 7.12! It'll come round sooner than you think. > > When is 7.12 expected to be frozen, and when to be released? > > All the best, > Wolfgang > > > There are many arrow-related tickets longing for love. > > e.g. #7828, #5267, #5777, #5333, #344 > > > > Simon > > > > | -----Original Message----- > > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > > | Wolfgang Jeltsch > > | Sent: 02 December 2014 12:49 > > | To: ghc-devs at haskell.org > > | Subject: Arrow notation and GHC 7.10 freeze > > | > > | Hi, > > | > > | I would like to work on > > | . > > | It would be great if the results of this work could go into GHC 7.10. > > | Is this still possible? When will GHC 7.10 be frozen? > > | > > | All the best, > > | Wolfgang > > | > > | _______________________________________________ > > | ghc-devs mailing list > > | ghc-devs at haskell.org > > | http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Dec 3 08:02:41 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Dec 2014 08:02:41 +0000 Subject: Arrow notation and GHC 7.10 freeze In-Reply-To: <1417558640.29262.20.camel@idefix> References: <1417524536.29262.1.camel@idefix> <618BE556AADD624C9C918AA5D5911BEF3F3F081B@DB3PRD3001MB020.064d.mgd.msft.net> <1417558640.29262.20.camel@idefix> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F11EE@DB3PRD3001MB020.064d.mgd.msft.net> | > But do work on it for 7.12! It'll come round sooner than you think. | | When is 7.12 expected to be frozen, and when to be released? Maximum a year. Minimum depends on user demand Simon From mail at joachim-breitner.de Wed Dec 3 08:25:55 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Dec 2014 09:25:55 +0100 Subject: linker_unload In-Reply-To: <87d28cpxsj.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> Message-ID: <1417595155.2162.2.camel@joachim-breitner.de> Hi, Am Montag, den 24.11.2014, 13:50 +0100 schrieb Herbert Valerio Riedel: > On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote: > >> linker_unload: > >> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: > >> unknown symbol `__gmpn_rshift' > > > Herbert, perhaps this is integer-gmp2 breakage? > > ...can't rule it out, but I haven't seen that failure anywhere else so > far (including http://haskell.inf.elte.hu/builders/) and can't reproduce > it myself either :-/ I can confirm this on my performance builder machine (Ubuntu 13.10): Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /data1/ghc-builder/logs/ghc-tmp-REV/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Fehler 1 *** unexpected failure for linker_unload(normal) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed Dec 3 08:38:09 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Dec 2014 09:38:09 +0100 Subject: linker_unload In-Reply-To: <1417595155.2162.2.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> Message-ID: <1417595889.2162.3.camel@joachim-breitner.de> Hi, Am Mittwoch, den 03.12.2014, 09:25 +0100 schrieb Joachim Breitner: > I can confirm this on my performance builder machine (Ubuntu 13.10): and on Ubuntu 14.04. Reported as http://ghc.haskell.org/trac/ghc/ticket/9856 This was clearly triggered by the integer-gmp2 commit. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvriedel at gmail.com Wed Dec 3 08:44:48 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 03 Dec 2014 09:44:48 +0100 Subject: linker_unload In-Reply-To: <1417595889.2162.3.camel@joachim-breitner.de> (Joachim Breitner's message of "Wed, 03 Dec 2014 09:38:09 +0100") References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <1417595889.2162.3.camel@joachim-breitner.de> Message-ID: <87iohtktq7.fsf@gmail.com> On 2014-12-03 at 09:38:09 +0100, Joachim Breitner wrote: > Am Mittwoch, den 03.12.2014, 09:25 +0100 schrieb Joachim Breitner: >> I can confirm this on my performance builder machine (Ubuntu 13.10): > > and on Ubuntu 14.04. Reported as > http://ghc.haskell.org/trac/ghc/ticket/9856 > > This was clearly triggered by the integer-gmp2 commit. ...but why don't we see it everywhere (I for one have never experienced the linker_unload failure myself (which makes it difficult to debug...), and neither did Phab)? What's triggering it only on some configurations? Cheers, hvr From simonpj at microsoft.com Wed Dec 3 08:48:58 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Dec 2014 08:48:58 +0000 Subject: linker_unload In-Reply-To: <1417595155.2162.2.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> I did the Ubuntu upgrade thing, and it's still happening for me too. I have no idea how to narrow it down some more. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 03 December 2014 08:26 | To: ghc-devs at haskell.org | Subject: Re: linker_unload | | Hi, | | | Am Montag, den 24.11.2014, 13:50 +0100 schrieb Herbert Valerio Riedel: | > On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote: | > >> linker_unload: | > >> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist- | install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: | > >> unknown symbol `__gmpn_rshift' | > | > > Herbert, perhaps this is integer-gmp2 breakage? | > | > ...can't rule it out, but I haven't seen that failure anywhere else | so | > far (including http://haskell.inf.elte.hu/builders/) and can't | > reproduce it myself either :-/ | | I can confirm this on my performance builder machine (Ubuntu 13.10): | | Wrong exit code (expected 0 , actual 2 ) | Stdout: | | Stderr: | linker_unload: /data1/ghc-builder/logs/ghc-tmp-REV/libraries/integer- | gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown | symbol `__gmpn_rshift' | linker_unload: resolveObjs failed | make[3]: *** [linker_unload] Fehler 1 | | *** unexpected failure for linker_unload(normal) | | | Greetings, | Joachim | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? http://www.joachim-breitner.de/ | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F | Debian Developer: nomeata at debian.org From hvriedel at gmail.com Wed Dec 3 10:18:34 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 03 Dec 2014 11:18:34 +0100 Subject: linker_unload In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Wed, 3 Dec 2014 08:48:58 +0000") References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <877fy9kpdx.fsf@gmail.com> On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: > I did the Ubuntu upgrade thing, and it's still happening for me too. > > I have no idea how to narrow it down some more. I had a short conversation w/ Joachim on #ghc, and what we know so far: For a non-failing linker_unload environment, the testprogram is linked against libgmp.so: $ ldd tests/rts/linker_unload linux-vdso.so.1 => (0x00007fff20f6c000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f83c5bbb000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f83c58b5000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f83c56ac000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83c54a8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83c50e3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f83c4ec4000) /lib64/ld-linux-x86-64.so.2 (0x00007f83c5e76000) Also, in the reported test failure, the failure occurs when calling resolveObjs() on the Test.o file (after the libHS-libs were already succesfully loadPkg()ed) r = loadObj(OBJPATH); if (!r) { errorBelch("loadObj(%s) failed", OBJPATH); exit(1); } r = resolveObjs(); if (!r) { errorBelch("resolveObjs failed"); exit(1); } Alas we still don't know what property of the build-environment determines whether this test fails or succeeds... :-/ From simonpj at microsoft.com Wed Dec 3 11:30:26 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Dec 2014 11:30:26 +0000 Subject: API Annotations and HsSCC / HsTickPragma In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F1595@DB3PRD3001MB020.064d.mgd.msft.net> Please don?t do (1). That would horribly clutter HsPar. I suggest (2). Actually I suggest you don?t have the Bool at all. Instead, in the desugarer, if you come across a HsScc, discard it unless it is active. We only need the Bool to cache the ?am I active? question if there are zillions of places where we need to know. But I bet there is only one, namely the desugarer. The spirit of the front end is: leave the source code entirely undisturbed until desugaring. Throwing away HsScc and turning them in HsPar is against this spirit SImon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 02 December 2014 20:19 To: ghc-devs at haskell.org Subject: API Annotations and HsSCC / HsTickPragma I am in the process of working the shiny new API annotations through into a practical example in ghc-exactprint [1], but I have hit a snag. A SCC annotation appears in the source as {-# SCC "name" #-} and if enabled via -prof results in the expression being wrapped in HsSCC FastString (LHsExpr id) BUT, if not enabled, it appears as HsPar (LHsExpr id) From the parser/annotation point of view, the appropriate annotations are generated, and can be used to distinguish the two cases. The problem is that the annotations only capture the SrcSpan of the thing being annotated, so in the HsPar case the contents of the FastString is lost. A similar situation exists for HsTickPragma, HsTickPragma -- A pragma introduced tick (FastString,(Int,Int),(Int,Int)) -- external span for this tick (LHsExpr id) which also degrades to HsPar I see a number of possible solutions 1. Add the missing information to HsPar in a Maybe HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they are active or not. 3. Introduce an additional annotation type to carry the missing information. I welcome advice on the best way forward. Alan [1] https://github.com/alanz/ghc-exactprint/tree/wip -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Dec 3 11:52:07 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 3 Dec 2014 13:52:07 +0200 Subject: API Annotations and HsSCC / HsTickPragma In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F1595@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3F1595@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Ok, that makes sense. Thanks Alan On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones wrote: > Please don?t do (1). That would horribly clutter HsPar. > > > > I suggest (2). Actually I suggest you don?t have the Bool at all. > Instead, in the desugarer, if you come across a HsScc, discard it unless it > is active. We only need the Bool to cache the ?am I active? question if > there are zillions of places where we need to know. But I bet there is > only one, namely the desugarer. > > > > The spirit of the front end is: leave the source code entirely undisturbed > until desugaring. Throwing away HsScc and turning them in HsPar is against > this spirit > > > > SImon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 02 December 2014 20:19 > *To:* ghc-devs at haskell.org > *Subject:* API Annotations and HsSCC / HsTickPragma > > > > I am in the process of working the shiny new API annotations through into > a practical example in ghc-exactprint [1], but I have hit a snag. > > A SCC annotation appears in the source as > > {-# SCC "name" #-} > > > > and if enabled via -prof results in the expression being wrapped in > > HsSCC FastString (LHsExpr id) > > > BUT, if not enabled, it appears as > > HsPar (LHsExpr id) > > From the parser/annotation point of view, the appropriate annotations are > generated, and can be used to distinguish the two cases. The problem is > that the annotations only capture the SrcSpan of the thing being annotated, > so in the HsPar case the contents of the FastString is lost. > > > > A similar situation exists for HsTickPragma, > > HsTickPragma -- A pragma introduced tick > (FastString,(Int,Int),(Int,Int)) -- external span for this tick > (LHsExpr id) > > which also degrades to HsPar > > > > I see a number of possible solutions > > 1. Add the missing information to HsPar in a Maybe > > > HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) > > > > 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they > are active or not. > > > > 3. Introduce an additional annotation type to carry the missing > information. > > I welcome advice on the best way forward. > > > > Alan > > > > [1] https://github.com/alanz/ghc-exactprint/tree/wip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Dec 3 11:59:42 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 03 Dec 2014 11:59:42 +0000 Subject: more parser conflicts? In-Reply-To: References: Message-ID: <547EFB2E.7080306@gmail.com> reduce/reduce conflicts are bad, especially so since they're undocumented. We don't know whether this introduced parser bugs or not. Mike - could you look at this please? It was your commit that introduced the new conflicts. Cheers, Simon On 02/12/2014 10:19, Dr. ERDI Gergo wrote: > On Mon, 1 Dec 2014, Richard Eisenberg wrote: > >> In unrelated work, I saw this scroll across when happy'ing the parser: >> >>> shift/reduce conflicts: 60 >>> reduce/reduce conflicts: 16 >> >> These numbers seem quite a bit higher than what I last remember (which >> is something like 48 and 1, not 60 and 16). Does anyone know why? > > The offending commit is bc2289e13d9586be087bd8136943dc35a0130c88. I know > this because I was changing the parser for patsyn signatures, and so I > updated the numbers in Parser.y to make sure I'm not adding any new > conflicts: > > 25 June 2014 > > Conflicts: 47 shift/reduce > 1 reduce/reduce > > > but then when time came to rebase my changes before pushing, I noticed > that it has gone up, and I had to update it yet again in Parser.y: > > 20 Nov 2014 > > Conflicts: 60 shift/reduce > 12 reduce/reduce > > So anyway, the point is, if you try bc2289e and bc2289e^ you can see > that that is the commit that introduced these new conflicts. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From marlowsd at gmail.com Wed Dec 3 12:03:42 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 03 Dec 2014 12:03:42 +0000 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: <547EFC1E.1030201@gmail.com> On 02/12/2014 21:43, Mi?tek Bak wrote: > On 2014-12-02, at 21:31, Carter Schonwald wrote: > >> whats an example of such a package? > > > text-icu. > https://github.com/bos/text-icu/pull/9 > > FWIW, I?m in favour of fixing this at the Cabal level. > https://github.com/haskell/cabal/issues/2207 I'm actually rather surprised we got away without doing this up to now. Why haven't there been more complaints? Cheers, Simon From alan.zimm at gmail.com Wed Dec 3 13:03:21 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 3 Dec 2014 15:03:21 +0200 Subject: API Annotations and HsSCC / HsTickPragma In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3F1595@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: If I look in DeSugar.lhs I see -- Desugar the program ; let export_set = availsToNameSet exports target = hscTarget dflags hpcInfo = emptyHpcInfo other_hpc_info want_ticks = gopt Opt_Hpc dflags || target == HscInterpreted || (gopt Opt_SccProfilingOn dflags && case profAuto dflags of NoProfAuto -> False _ -> True) ; (binds_cvr, ds_hpc_info, modBreaks) <- if want_ticks && not (isHsBootOrSig hsc_src) then addTicksToBinds dflags mod mod_loc export_set (typeEnvTyCons type_env) binds else return (binds, hpcInfo, emptyModBreaks) So it looks like `addTicksToBinds` is only called when profiling is on. But there is also DsExpr.lhs which does dsExpr (HsSCC cc expr@(L loc _)) = do mod_name <- getModule count <- goptM Opt_ProfCountEntries uniq <- newUnique Tick (ProfNote (mkUserCC cc mod_name loc uniq) count True) <$> dsLExpr expr I *think* that the dsExpr value is ignored if profiling is inactive, and I am hoping that all that needs changing is the parser to always emit HsSCC, instead of HsPar if Opt_SccProfilingOn is not set. Is this correct? Alan On Wed, Dec 3, 2014 at 1:52 PM, Alan & Kim Zimmerman wrote: > Ok, that makes sense. > > Thanks > Alan > > On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones > wrote: > >> Please don?t do (1). That would horribly clutter HsPar. >> >> >> >> I suggest (2). Actually I suggest you don?t have the Bool at all. >> Instead, in the desugarer, if you come across a HsScc, discard it unless it >> is active. We only need the Bool to cache the ?am I active? question if >> there are zillions of places where we need to know. But I bet there is >> only one, namely the desugarer. >> >> >> >> The spirit of the front end is: leave the source code entirely >> undisturbed until desugaring. Throwing away HsScc and turning them in HsPar >> is against this spirit >> >> >> >> SImon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan >> & Kim Zimmerman >> *Sent:* 02 December 2014 20:19 >> *To:* ghc-devs at haskell.org >> *Subject:* API Annotations and HsSCC / HsTickPragma >> >> >> >> I am in the process of working the shiny new API annotations through into >> a practical example in ghc-exactprint [1], but I have hit a snag. >> >> A SCC annotation appears in the source as >> >> {-# SCC "name" #-} >> >> >> >> and if enabled via -prof results in the expression being wrapped in >> >> HsSCC FastString (LHsExpr id) >> >> >> BUT, if not enabled, it appears as >> >> HsPar (LHsExpr id) >> >> From the parser/annotation point of view, the appropriate annotations are >> generated, and can be used to distinguish the two cases. The problem is >> that the annotations only capture the SrcSpan of the thing being annotated, >> so in the HsPar case the contents of the FastString is lost. >> >> >> >> A similar situation exists for HsTickPragma, >> >> HsTickPragma -- A pragma introduced tick >> (FastString,(Int,Int),(Int,Int)) -- external span for this tick >> (LHsExpr id) >> >> which also degrades to HsPar >> >> >> >> I see a number of possible solutions >> >> 1. Add the missing information to HsPar in a Maybe >> >> >> HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) >> >> >> >> 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they >> are active or not. >> >> >> >> 3. Introduce an additional annotation type to carry the missing >> information. >> >> I welcome advice on the best way forward. >> >> >> >> Alan >> >> >> >> [1] https://github.com/alanz/ghc-exactprint/tree/wip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 3 13:13:24 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Dec 2014 14:13:24 +0100 Subject: linker_unload In-Reply-To: <877fy9kpdx.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> <877fy9kpdx.fsf@gmail.com> Message-ID: <1417612404.2162.6.camel@joachim-breitner.de> Hi, Am Mittwoch, den 03.12.2014, 11:18 +0100 schrieb Herbert Valerio Riedel: > On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: > For a non-failing linker_unload environment, the testprogram is linked > against libgmp.so: > > $ ldd tests/rts/linker_unload > linux-vdso.so.1 => (0x00007fff20f6c000) > libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f83c5bbb000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f83c58b5000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f83c56ac000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83c54a8000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83c50e3000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f83c4ec4000) > /lib64/ld-linux-x86-64.so.2 (0x00007f83c5e76000) and for a failing, it is not. I further narrowed it down to the question of whether gcc passes "--as-needed" to ld by default: If I pass "-optl-Wl,--no-as-needed" to ghc when compiling linker_unload.c, it works there as well. In some releases of Ubuntu, --as-needed is the default?. Not sure why Herbert does not see this behavior in a recent release (14.04). I?m also not sure about the right fix: Should we just pass -Wl,--no-as-needed to gcc always? But clearly there is a reason for this flag becoming default. Can we set up things so that they work with --as-needed? Greetings, Joachim ? https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783.html -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Dec 3 13:20:29 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Dec 2014 13:20:29 +0000 Subject: new Coercible solver In-Reply-To: <5C385B1A-3702-427D-86EF-B4B211F5C3B2@cis.upenn.edu> References: <5C385B1A-3702-427D-86EF-B4B211F5C3B2@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F16D3@DB3PRD3001MB020.064d.mgd.msft.net> | If you have a few minutes, I would love a review of my new Coercible | solver (D546). It seems to be humming along, and it tackles #9117 | nicely. Even better, for me, it will work much more smoothly with my | dependent types branch. I'm eager to get back to that branch, which is | why I'd like to merge this into master soon. A few minutes??!! Hardly. Two hours later... Anyway I've made a start. I assume this is going to land immediately after the 7.10 fork? But it's not entirely obvious: - it is not essential functionality for 7.10 - but it shouldn't mess anything up (or if it does we want to fix it anyway) - and it's a big diff, so *not* putting it in 7.10 will make merging patches to the 7.10 branch harder My instinct is to merge soon (assuming it validates), and let Austin decide whether it makes his life easier to have it or not to have it. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] | Sent: 02 December 2014 03:15 | To: Simon Peyton Jones | Subject: new Coercible solver | | Hi Simon, | | If you have a few minutes, I would love a review of my new Coercible | solver (D546). It seems to be humming along, and it tackles #9117 | nicely. Even better, for me, it will work much more smoothly with my | dependent types branch. I'm eager to get back to that branch, which is | why I'd like to merge this into master soon. | | Thanks! | Richard | | PS: If you want to Skype, I should be available from about 10am my | time on Tuesday. (Also, possibly available somewhere in the 7am-7:45am | stretch, depending on when Emma wakes up.) From m at tweag.io Wed Dec 3 13:22:51 2014 From: m at tweag.io (Boespflug, Mathieu) Date: Wed, 3 Dec 2014 14:22:51 +0100 Subject: linker_unload In-Reply-To: <1417612404.2162.6.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> <877fy9kpdx.fsf@gmail.com> <1417612404.2162.6.camel@joachim-breitner.de> Message-ID: Have you tried using ld.gold instead? I've run into many issues with the default ld.bfd recently (none of which seems related to this issue, but it tells me that weird linker bugs do happen and testing with another linker may help isolate the root cause). -- Mathieu Boespflug Founder at http://tweag.io. On 3 December 2014 at 14:13, Joachim Breitner wrote: > Hi, > > > Am Mittwoch, den 03.12.2014, 11:18 +0100 schrieb Herbert Valerio Riedel: >> On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: >> For a non-failing linker_unload environment, the testprogram is linked >> against libgmp.so: >> >> $ ldd tests/rts/linker_unload >> linux-vdso.so.1 => (0x00007fff20f6c000) >> libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f83c5bbb000) >> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f83c58b5000) >> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f83c56ac000) >> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83c54a8000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83c50e3000) >> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f83c4ec4000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f83c5e76000) > > and for a failing, it is not. > > > I further narrowed it down to the question of whether gcc passes > "--as-needed" to ld by default: If I pass "-optl-Wl,--no-as-needed" to > ghc when compiling linker_unload.c, it works there as well. > > > In some releases of Ubuntu, --as-needed is the default?. Not sure why > Herbert does not see this behavior in a recent release (14.04). > > I?m also not sure about the right fix: Should we just pass > -Wl,--no-as-needed to gcc always? But clearly there is a reason for this > flag becoming default. Can we set up things so that they work with > --as-needed? > > Greetings, > Joachim > > > > > ? https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783.html > > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Wed Dec 3 13:22:53 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 03 Dec 2014 13:22:53 +0000 Subject: linker_unload In-Reply-To: <877fy9kpdx.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> <877fy9kpdx.fsf@gmail.com> Message-ID: <547F0EAD.1070100@gmail.com> At a guess, you could try this: --- a/testsuite/tests/rts/Makefile +++ b/testsuite/tests/rts/Makefile @@ -124,7 +124,7 @@ linker_unload: $(RM) Test.o Test.hi "$(TEST_HC)" $(TEST_HC_OPTS) -c Test.hs -v0 # -rtsopts causes a warning - "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g + "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g -lgmp ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP) On 03/12/2014 10:18, Herbert Valerio Riedel wrote: > On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: >> I did the Ubuntu upgrade thing, and it's still happening for me too. >> >> I have no idea how to narrow it down some more. > > I had a short conversation w/ Joachim on #ghc, and what we know so far: > > For a non-failing linker_unload environment, the testprogram is linked > against libgmp.so: > > $ ldd tests/rts/linker_unload > linux-vdso.so.1 => (0x00007fff20f6c000) > libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f83c5bbb000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f83c58b5000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f83c56ac000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83c54a8000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83c50e3000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f83c4ec4000) > /lib64/ld-linux-x86-64.so.2 (0x00007f83c5e76000) > > Also, in the reported test failure, the failure occurs when calling > resolveObjs() on the Test.o file (after the libHS-libs were already > succesfully loadPkg()ed) > > > r = loadObj(OBJPATH); > if (!r) { > errorBelch("loadObj(%s) failed", OBJPATH); > exit(1); > } > r = resolveObjs(); > if (!r) { > errorBelch("resolveObjs failed"); > exit(1); > } > > > Alas we still don't know what property of the build-environment > determines whether this test fails or succeeds... :-/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From mail at joachim-breitner.de Wed Dec 3 13:25:21 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Dec 2014 14:25:21 +0100 Subject: linker_unload In-Reply-To: <547F0EAD.1070100@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> <877fy9kpdx.fsf@gmail.com> <547F0EAD.1070100@gmail.com> Message-ID: <1417613121.2162.8.camel@joachim-breitner.de> Hi, Am Mittwoch, den 03.12.2014, 13:22 +0000 schrieb Simon Marlow: > At a guess, you could try this: > > --- a/testsuite/tests/rts/Makefile > +++ b/testsuite/tests/rts/Makefile > @@ -124,7 +124,7 @@ linker_unload: > $(RM) Test.o Test.hi > "$(TEST_HC)" $(TEST_HC_OPTS) -c Test.hs -v0 > # -rtsopts causes a warning > - "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) > linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g > + "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) > linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g > -lgmp > ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP) no, does not help, as -lgmp is already passed to gcc by ghc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o linker_unload linker_unload.o -L/data1/ghc-builder/ghc-master/libraries/base/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/integer-gmp2/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/ghc-prim/dist-install/build -L/data1/ghc-builder/ghc-master/rts/dist/build /tmp/ghc26637_1/ghc26637_4.o /tmp/ghc26637_1/ghc26637_6.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase_469rOtLAqwTGFEOGWxSUiQ -lHSinteg_21cuTlnn00eFNd4GMrxOMi -lHSghcpr_FgrV6cgh2JHBlbcx1OSlwt -lHSrts_debug -lCffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads but due to --no-needed, and linker_unload indeed not requiring any symbols from gmp, the linker does not link it. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Dec 3 13:24:43 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Dec 2014 13:24:43 +0000 Subject: API Annotations and HsSCC / HsTickPragma In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3F1595@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F1737@DB3PRD3001MB020.064d.mgd.msft.net> I assume that if cost-centre-profiling is off then dsExpr (HsScc _ e) = dsExpr e Looks like the dsExpr case for HsScc would need that test. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 03 December 2014 13:03 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: API Annotations and HsSCC / HsTickPragma If I look in DeSugar.lhs I see -- Desugar the program ; let export_set = availsToNameSet exports target = hscTarget dflags hpcInfo = emptyHpcInfo other_hpc_info want_ticks = gopt Opt_Hpc dflags || target == HscInterpreted || (gopt Opt_SccProfilingOn dflags && case profAuto dflags of NoProfAuto -> False _ -> True) ; (binds_cvr, ds_hpc_info, modBreaks) <- if want_ticks && not (isHsBootOrSig hsc_src) then addTicksToBinds dflags mod mod_loc export_set (typeEnvTyCons type_env) binds else return (binds, hpcInfo, emptyModBreaks) So it looks like `addTicksToBinds` is only called when profiling is on. But there is also DsExpr.lhs which does dsExpr (HsSCC cc expr@(L loc _)) = do mod_name <- getModule count <- goptM Opt_ProfCountEntries uniq <- newUnique Tick (ProfNote (mkUserCC cc mod_name loc uniq) count True) <$> dsLExpr expr I *think* that the dsExpr value is ignored if profiling is inactive, and I am hoping that all that needs changing is the parser to always emit HsSCC, instead of HsPar if Opt_SccProfilingOn is not set. Is this correct? Alan On Wed, Dec 3, 2014 at 1:52 PM, Alan & Kim Zimmerman > wrote: Ok, that makes sense. Thanks Alan On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones > wrote: Please don?t do (1). That would horribly clutter HsPar. I suggest (2). Actually I suggest you don?t have the Bool at all. Instead, in the desugarer, if you come across a HsScc, discard it unless it is active. We only need the Bool to cache the ?am I active? question if there are zillions of places where we need to know. But I bet there is only one, namely the desugarer. The spirit of the front end is: leave the source code entirely undisturbed until desugaring. Throwing away HsScc and turning them in HsPar is against this spirit SImon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 02 December 2014 20:19 To: ghc-devs at haskell.org Subject: API Annotations and HsSCC / HsTickPragma I am in the process of working the shiny new API annotations through into a practical example in ghc-exactprint [1], but I have hit a snag. A SCC annotation appears in the source as {-# SCC "name" #-} and if enabled via -prof results in the expression being wrapped in HsSCC FastString (LHsExpr id) BUT, if not enabled, it appears as HsPar (LHsExpr id) From the parser/annotation point of view, the appropriate annotations are generated, and can be used to distinguish the two cases. The problem is that the annotations only capture the SrcSpan of the thing being annotated, so in the HsPar case the contents of the FastString is lost. A similar situation exists for HsTickPragma, HsTickPragma -- A pragma introduced tick (FastString,(Int,Int),(Int,Int)) -- external span for this tick (LHsExpr id) which also degrades to HsPar I see a number of possible solutions 1. Add the missing information to HsPar in a Maybe HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they are active or not. 3. Introduce an additional annotation type to carry the missing information. I welcome advice on the best way forward. Alan [1] https://github.com/alanz/ghc-exactprint/tree/wip -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Dec 3 13:34:05 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 3 Dec 2014 08:34:05 -0500 Subject: new Coercible solver In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F16D3@DB3PRD3001MB020.064d.mgd.msft.net> References: <5C385B1A-3702-427D-86EF-B4B211F5C3B2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF3F3F16D3@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Dec 3, 2014, at 8:20 AM, Simon Peyton Jones wrote: > | If you have a few minutes, I would love a review of my new Coercible > | solver (D546). It seems to be humming along, and it tackles #9117 > | nicely. Even better, for me, it will work much more smoothly with my > | dependent types branch. I'm eager to get back to that branch, which is > | why I'd like to merge this into master soon. > > A few minutes??!! Hardly. Two hours later... Anyway I've made a start. Take it as a compliment -- my impression of your infinite efficiency. :) > > I assume this is going to land immediately after the 7.10 fork? But it's not entirely obvious: > > - it is not essential functionality for 7.10 > - but it shouldn't mess anything up (or if it does we want to fix it anyway) > - and it's a big diff, so *not* putting it in 7.10 will make merging > patches to the 7.10 branch harder > > My instinct is to merge soon (assuming it validates), and let Austin decide whether it makes his life easier to have it or not to have it. Agreed with all your points. At its core, this is just a bugfix for #9117. It's just a rather invasive one. And it's certainly not essential for 7.10. I'm agnostic on whether it gets into 7.10, but my tendency is to believe it will make life easier to merge into 7.10 than not. Richard > > Simon > > | -----Original Message----- > | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] > | Sent: 02 December 2014 03:15 > | To: Simon Peyton Jones > | Subject: new Coercible solver > | > | Hi Simon, > | > | If you have a few minutes, I would love a review of my new Coercible > | solver (D546). It seems to be humming along, and it tackles #9117 > | nicely. Even better, for me, it will work much more smoothly with my > | dependent types branch. I'm eager to get back to that branch, which is > | why I'd like to merge this into master soon. > | > | Thanks! > | Richard > | > | PS: If you want to Skype, I should be available from about 10am my > | time on Tuesday. (Also, possibly available somewhere in the 7am-7:45am > | stretch, depending on when Emma wakes up.) > From austin at well-typed.com Wed Dec 3 17:51:44 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 3 Dec 2014 11:51:44 -0600 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: <547EFC1E.1030201@gmail.com> References: <547EFC1E.1030201@gmail.com> Message-ID: I'm also quite surprised about this; Cabal was supposed to handle -fPIC based on whether GHC was dynamically linked a long time ago, I figured. The fact it's broken this long is really unfortunate. I'll attempt to take a look at this when I have time; we should very much fix this for 7.10 (and perhaps backport the fix to older Cabal versions too, maybe). On Wed, Dec 3, 2014 at 6:03 AM, Simon Marlow wrote: > On 02/12/2014 21:43, Mi?tek Bak wrote: >> >> On 2014-12-02, at 21:31, Carter Schonwald >> wrote: >> >>> whats an example of such a package? >> >> >> >> text-icu. >> https://github.com/bos/text-icu/pull/9 >> >> FWIW, I?m in favour of fixing this at the Cabal level. >> https://github.com/haskell/cabal/issues/2207 > > > I'm actually rather surprised we got away without doing this up to now. Why > haven't there been more complaints? > > Cheers, > Simon > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From iavor.diatchki at gmail.com Wed Dec 3 18:03:09 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 03 Dec 2014 18:03:09 +0000 Subject: more parser conflicts? References: <547EFB2E.7080306@gmail.com> Message-ID: Indeed! Even documented, this seems like way too many reduce/reduce conflicts---we should be able to refactor the grammar to avoid them. On Wed Dec 03 2014 at 3:59:48 AM Simon Marlow wrote: > reduce/reduce conflicts are bad, especially so since they're > undocumented. We don't know whether this introduced parser bugs or not. > Mike - could you look at this please? It was your commit that > introduced the new conflicts. > > Cheers, > Simon > > On 02/12/2014 10:19, Dr. ERDI Gergo wrote: > > On Mon, 1 Dec 2014, Richard Eisenberg wrote: > > > >> In unrelated work, I saw this scroll across when happy'ing the parser: > >> > >>> shift/reduce conflicts: 60 > >>> reduce/reduce conflicts: 16 > >> > >> These numbers seem quite a bit higher than what I last remember (which > >> is something like 48 and 1, not 60 and 16). Does anyone know why? > > > > The offending commit is bc2289e13d9586be087bd8136943dc35a0130c88. I know > > this because I was changing the parser for patsyn signatures, and so I > > updated the numbers in Parser.y to make sure I'm not adding any new > > conflicts: > > > > 25 June 2014 > > > > Conflicts: 47 shift/reduce > > 1 reduce/reduce > > > > > > but then when time came to rebase my changes before pushing, I noticed > > that it has gone up, and I had to update it yet again in Parser.y: > > > > 20 Nov 2014 > > > > Conflicts: 60 shift/reduce > > 12 reduce/reduce > > > > So anyway, the point is, if you try bc2289e and bc2289e^ you can see > > that that is the commit that introduced these new conflicts. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Wed Dec 3 18:25:13 2014 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 3 Dec 2014 18:25:13 +0000 (UTC) Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: <547EFC1E.1030201@gmail.com> References: <547EFC1E.1030201@gmail.com> Message-ID: <1092323127.2788068.1417631113995.JavaMail.yahoo@jws100141.mail.ne1.yahoo.com> Hi, There aren't more complaints because most people haven't tried 7.8 seriously yet. (I didn't notice the problem since I've only been using GHC 7.8 under Windows.) This points out the need for some sort of regular testing of canaries (full systems producing known results) to test the entire toolchain including common libraries (HP, perhaps) and Cabal. At the risk of antagonizing the developers again, I will point out that there is a bit of disconnect between GHC developers, Cabal developers, library developers and users (application developers). Without slowing the GHC developers' creativity, there is a need to look at the experience of the application developers. FWIW, my sense is that there is too much turbulence for many potential application developers to adopt Haskell as their production platform unless they have significant in-house resources to deal with the rapid changes. (As as thought experiment, how many changes have to be made to Real World Haskell's programs to get them to run?) Howard ----- Original Message ----- From: Simon Marlow To: Mi?tek Bak ; Carter Schonwald Cc: "cabal-devel at haskell.org" ; "ghc-devs at haskell.org" Sent: Wednesday, December 3, 2014 4:03 AM Subject: Re: Linker change in GHC 7.8 leads to widespread issues I'm actually rather surprised we got away without doing this up to now. Why haven't there been more complaints? Cheers, Simon From ganesh at earth.li Wed Dec 3 18:34:32 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed, 03 Dec 2014 18:34:32 +0000 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: <547F57B8.2050701@earth.li> On 02/12/2014 21:43, Mi?tek Bak wrote: > On 2014-12-02, at 21:31, Carter Schonwald wrote: > >> whats an example of such a package? > > > text-icu. > https://github.com/bos/text-icu/pull/9 > > FWIW, I?m in favour of fixing this at the Cabal level. > https://github.com/haskell/cabal/issues/2207 I've actually seen this same problem when building GHC 7.8.4rc1 from source, but I assumed it was some problem with my development environment given that this presumably works for others. Ganesh From mail at joachim-breitner.de Wed Dec 3 18:47:39 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Dec 2014 19:47:39 +0100 Subject: more parser conflicts? In-Reply-To: References: Message-ID: <1417632459.20619.2.camel@joachim-breitner.de> Hi, Am Montag, den 01.12.2014, 15:12 -0500 schrieb Richard Eisenberg: > In unrelated work, I saw this scroll across when happy'ing the parser: > > > shift/reduce conflicts: 60 > > reduce/reduce conflicts: 16 > > These numbers seem quite a bit higher than what I last remember (which is something like 48 and 1, not 60 and 16). Does anyone know why? a side node: You can use the collected build logs at https://github.com/nomeata/ghc-speed-logs if you need to find out when something first changed. In this case, the increase from 47 to 60 was http://git.haskell.org/ghc.git/commit/bc2289e, as Gergo figured out already. I?ve now started tracking these two numbers on ghcspeed as well (but I did not import the old numbers retroactively): http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=reduce%2Freduce&env=1&revs=50&equid=off http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=shift%2Freduce&env=1&revs=50&equid=off Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed Dec 3 18:50:38 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Dec 2014 19:50:38 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: <547EFC1E.1030201@gmail.com> References: <547EFC1E.1030201@gmail.com> Message-ID: <1417632638.20619.4.camel@joachim-breitner.de> Hi, Am Mittwoch, den 03.12.2014, 12:03 +0000 schrieb Simon Marlow: > > text-icu. > > https://github.com/bos/text-icu/pull/9 > > > > FWIW, I?m in favour of fixing this at the Cabal level. > > https://github.com/haskell/cabal/issues/2207 > > I'm actually rather surprised we got away without doing this up to now. > Why haven't there been more complaints? Debian, for example, hasn?t started using GHC-7.8 properly yet, due to a combination of (at first) ?let it settle a bit due to the new dynamic linking scheme? and (later) ?we cannot tackle this this close to the Debian freeze? and a bit of ?these unresolved build problems on arm look scary, let?s wait and see if the are resolved automatically?. (Not sure if there is a conclusion to be drawn here.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mietek at bak.io Wed Dec 3 18:53:22 2014 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Wed, 3 Dec 2014 18:53:22 +0000 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: <1092323127.2788068.1417631113995.JavaMail.yahoo@jws100141.mail.ne1.yahoo.com> References: <547EFC1E.1030201@gmail.com> <1092323127.2788068.1417631113995.JavaMail.yahoo@jws100141.mail.ne1.yahoo.com> Message-ID: I agree, and I?m hoping to help improve these matters with my project, Halcyon (https://halcyon.sh/). Halcyon allows all build-time and run-time dependencies of an application to be explicitly declared and installed with a single invocation. This builds on the great work done recently in Cabal to get us `cabal freeze`, and works around many long-standing Cabal issues, such as the inability to automatically install missing build-tools. Halcyon can also be used to restore entire Haskell installations in seconds, and supports GHC versions including 7.8.3, 7.8.2, 7.6.3, 7.6.1, 7.4.2, 7.2.2, and 7.0.4. Hopefully, being able to swap GHC versions in and out, without needing to have them on disk, should help lessen the amount of work needed for comprehensive testing. I am currently putting the final touches on my project before announcement. Please let me know what you think. -- Mi?tek On 2014-12-03, at 18:25, Howard B. Golden wrote: > Hi, > > There aren't more complaints because most people haven't tried 7.8 seriously yet. (I didn't notice the problem since I've only been using GHC 7.8 under Windows.) This points out the need for some sort of regular testing of canaries (full systems producing known results) to test the entire toolchain including common libraries (HP, perhaps) and Cabal. > > At the risk of antagonizing the developers again, I will point out that there is a bit of disconnect between GHC developers, Cabal developers, library developers and users (application developers). Without slowing the GHC developers' creativity, there is a need to look at the experience of the application developers. FWIW, my sense is that there is too much turbulence for many potential application developers to adopt Haskell as their production platform unless they have significant in-house resources to deal with the rapid changes. (As as thought experiment, how many changes have to be made to Real World Haskell's programs to get them to run?) > > > Howard > > > > ----- Original Message ----- > From: Simon Marlow > To: Mi?tek Bak ; Carter Schonwald > Cc: "cabal-devel at haskell.org" ; "ghc-devs at haskell.org" > Sent: Wednesday, December 3, 2014 4:03 AM > Subject: Re: Linker change in GHC 7.8 leads to widespread issues > > I'm actually rather surprised we got away without doing this up to now. > Why haven't there been more complaints? > > Cheers, > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From austin at well-typed.com Wed Dec 3 20:05:35 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 3 Dec 2014 14:05:35 -0600 Subject: HEADS UP: I'm removing the remaining .lhs files in compiler/ soon Message-ID: Hi *, Quick note: before the branch occurs, me and Herbert really really wanted to remove all the .lhs files in the compiler. We tried to do this as close as possible to the branch to minimize merge headaches, and I've got my tree doing so. This set of patches removes about 100 lhs files in the compiler, across several subsystems. Undoubtly, this will affect some of your work that you're all doing to get into HEAD soon. If you have a currently outstanding branch, a rebase should set you straight; just do: $ git rebase master Git tracks renames for rebases, so it should correctly do most of the work. Nonetheless, you may have some out of date code that has been touched in the mean time (a lot of things have gone through in the past few days), so be sure to be diligent when you rebase it all and whatnot. Thanks -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From jan.stolarek at p.lodz.pl Wed Dec 3 20:25:04 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 3 Dec 2014 21:25:04 +0100 Subject: HEADS UP: I'm removing the remaining .lhs files in compiler/ soon In-Reply-To: References: Message-ID: <201412032125.04380.jan.stolarek@p.lodz.pl> > me and Herbert really really wanted to remove all the .lhs files in the compiler. I'll only say one thing: FINALLY ! Janek From the.dead.shall.rise at gmail.com Wed Dec 3 20:49:20 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 3 Dec 2014 21:49:20 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: Hi, On 2 December 2014 at 22:06, Bryan O'Sullivan wrote: > Hi folks, > > It seems that something somewhere in linker-land changed in GHC 7.8 such > that packages that include C components now need to be built with > position-independent code on some platforms. I've now fixed this issue in Cabal HEAD and also pushed the fix to 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out soon. From moritz at lichtzwerge.de Wed Dec 3 21:24:02 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Wed, 3 Dec 2014 22:24:02 +0100 Subject: Out Of Process Template Haskell Message-ID: <25E2F948-7444-40B6-A585-86DAC883ECEB@lichtzwerge.de> Hi, as you may or may not know, template haskell is not available to cross compilers. And therefore cross compiler are devoid of an important feature of haskell. We are currently building ghc cross compiler as stage1 compiler with a foreign target. This means that we use a stage0 compiler (the one that is used to build ghc), to build the ghc that will run on the host and produce binaries for the target (e.g. running on x86_64, building for arm). Template Haskell and GHCi are enabled only in stage2. To build a stage2 compiler we use the stage1 compiler. Hence the stage2 compiler runs on the target of the stage1 compiler. A motivating example could be ghc running on an Intel based Mac OS X targeting iOS (ARM). A *theoretical* stage2 compiler could have GHCi and Template Haskell, but would run on the iOS Device, which is neat but probably not a practical solution. Hence a compiler running on a more powerful host, producing executables for a foreign target can be a very good solution when the host is much more powerful. (Ref. [1]). In [2] we can read the following: > Stage 1 does not support interactive execution (GHCi) and Template Haskell. The reason > being that when running byte code we must dynamically link the packages, and only in > stage 2 and later can we guarantee that the packages we dynamically link are compatible > with those that GHC was built against (because they are the very same packages). One of the prominent cross compilers is ghcjs, which admittedly is build a little different than the above cross compiler would be. ghcjs shares the same template haskell issue though. ghcjs--to my knowledge--followed a few different routes to solve this. And finally came up with the *out-of-process-template-haskell* solution. The Out Of Process Template Haskell approach works by having a *runner* on the target that waits for the compiler to send the template haskell splices, and compiles those splices on the target, whilte querying the *master* ghc for potential lookups during the splice compilation. The result is then shipped back to the host to integrate into the produced binary for the target. Hence allowing the more powerful host to do the bulk of the compilation and using the *runner* as a *slave compiler* on the target. .-- host -. .- target -. | | -- ( encounters splice and sends it to runner ) ---> | | | | | | | ghc | .<---- ( compiles and queries ghc for lookups ) ----. | runner | | master | '----------- ( responds to to queries ) ----------->' | slave | | | | | | | <- ( receives the compiled splice from the runner ) - | | '---------' '----------' Fig. 1: ghc - th runner communication. I have implemented the *out-of-process-template-haskell* approach with the help from luite for ghc as a plugin for stage2 *non*-cross compiler[3] using dynamic libraries and a tcp transport by adapting the code from ghcjs to run on the host. Obviously for a regular stage2 ghc, which has GHCi and Template Haskell, this doesn't really buy anyone anything yet. Also a plugin is impossible to load into a stage1 compiler yet, as the plugin code is wrapped in #ifdef GHCI sections. SIDENOTE: To allow the out-of-process-template-haskell, the plugin api had to be adapted minimally to allow plugins to install hooks. Patches for 7.8[4] and 7.10[5] are readily available. Clearly the *out-of-process-template-haskell* could be integrated into the ghc tree by hard wiring it in, where the plugin did the wiring ad-hoc previous. This would imply that ghc would have to integrate all dependencies which *out-of-process-template-haskell* would bring with it. There are now three options discussed on #ghc so far: a) Full integration in ghc, as described above. b) Enabling the plugin interface in stage1 compiler [See Note 1 for details]. This is probably only interesting for cross-compiler, where stage1 is the final stage on the host. [See Note 2 for an example] c) As proposed by luite: integrate a thin layer in ghc, that uses pipes to communicate with an external program on the same host that ghc is running on. That external program will then communicate with the *runner* on the target. The ultimate goal would be a multi-target compiler, that could produce a stage2 compiler that runs on the host but can produce binaries for multiple targets of which the host it's running on is one. I am in favor of extending the plugin api and making it available to stage1 compiler, because I see much potential in the plugin api. Which--with the noted patches [4][5]-- allows you to install hooks, and hence allow you to hook into the complete compiler pipeline and potential other parts as well. It also makes developing plugins easier, because they can be developed outside of the ghc source tree. And only be used with cross compilers if we can load plugins in stage1 compilers. Cheers, Moritz [1]: https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Stages [3]: https://github.com/angerman/oopth [4]: https://gist.github.com/angerman/7db11c24f8935c73fcf5 [5]: https://phabricator.haskell.org/D535 Note 1: where the plugin will have to be compiled with a stage0 compiler, and may even require a stage0 compiler that is as new as the stage1 compiler one wants to build, because the compiler being built has to be binary compatible with the plugin. Note 2: An example would be building 7.10 on the host for the host with stage0=ghc7.8, stage1=ghc7.10(built with ghc7.8), stage2=ghc7.10(built with stage1), *and then* building a ghc cross compiler for arm with stage0'=stage2 and stage1'(ghc7.10 targeting ARM built with ghc7.10 on the host). And allowing this newly built cross compiler (stage1') to accept -fplugin for plugins built with stage2 (the same that built stage1') From george.colpitts at gmail.com Wed Dec 3 22:53:40 2014 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 3 Dec 2014 18:53:40 -0400 Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1 In-Reply-To: <87bnnu3ufg.fsf@gnu.org> References: <87bnnu3ufg.fsf@gnu.org> Message-ID: Would it be possible to get a RC for the Mac up at https://downloads.haskell.org/~ghc/7.8.4-rc1/ ? Thanks George On Wed, Nov 26, 2014 at 10:31 AM, Herbert Valerio Riedel wrote: > On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote: > > 2014-11-25 20:46 GMT+01:00 Austin Seipp : > >> We are pleased to announce the first release candidate for GHC 7.8.4: > >> > >> https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...] > > > > Would it be possible to get the RC on > > https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could > > easily test things on Travis CI. > > I'll put a 7.8.4rc .deb up soon (probably right after the GHC 7.10 > branch has been created) > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Wed Dec 3 23:44:09 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 3 Dec 2014 15:44:09 -0800 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: On Wed, Dec 3, 2014 at 12:49 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > I've now fixed this issue in Cabal HEAD and also pushed the fix to > 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out > soon. > Thanks, Mikhail! Does this imply that package authors can simply advise bug reporters to upgrade cabal-install? -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu Dec 4 00:08:07 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 4 Dec 2014 01:08:07 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: Hi, On 4 December 2014 at 00:44, Bryan O'Sullivan wrote: > Thanks, Mikhail! Does this imply that package authors can simply advise bug > reporters to upgrade cabal-install? Yes, once the new point releases of Cabal/cabal-install are out (in a week or two, according to Johan). From mail at joachim-breitner.de Thu Dec 4 08:45:07 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 04 Dec 2014 09:45:07 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: <1417682707.1485.1.camel@joachim-breitner.de> Hi, Am Donnerstag, den 04.12.2014, 01:08 +0100 schrieb Mikhail Glushenkov: > On 4 December 2014 at 00:44, Bryan O'Sullivan wrote: > > Thanks, Mikhail! Does this imply that package authors can simply advise bug > > reporters to upgrade cabal-install? > > Yes, once the new point releases of Cabal/cabal-install are out (in a > week or two, according to Johan). is the bug in Cabal or cabal-install? If the former, are we going to include a fixed version of Cabal in GHC-7.8.4? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Thu Dec 4 08:54:04 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 04 Dec 2014 08:54:04 +0000 Subject: linker_unload In-Reply-To: <1417612404.2162.6.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> <877fy9kpdx.fsf@gmail.com> <1417612404.2162.6.camel@joachim-breitner.de> Message-ID: <5480212C.3010703@gmail.com> On 03/12/2014 13:13, Joachim Breitner wrote: > Hi, > > > Am Mittwoch, den 03.12.2014, 11:18 +0100 schrieb Herbert Valerio Riedel: >> On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: >> For a non-failing linker_unload environment, the testprogram is linked >> against libgmp.so: >> >> $ ldd tests/rts/linker_unload >> linux-vdso.so.1 => (0x00007fff20f6c000) >> libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f83c5bbb000) >> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f83c58b5000) >> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f83c56ac000) >> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83c54a8000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83c50e3000) >> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f83c4ec4000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f83c5e76000) > > and for a failing, it is not. > > > I further narrowed it down to the question of whether gcc passes > "--as-needed" to ld by default: If I pass "-optl-Wl,--no-as-needed" to > ghc when compiling linker_unload.c, it works there as well. > > > In some releases of Ubuntu, --as-needed is the default?. Not sure why > Herbert does not see this behavior in a recent release (14.04). > > I?m also not sure about the right fix: Should we just pass > -Wl,--no-as-needed to gcc always? But clearly there is a reason for this > flag becoming default. Can we set up things so that they work with > --as-needed? No, I don't think we should do that. We should play nicely with however the platform decides it wants to do linking. Cheers, Simon From marlowsd at gmail.com Thu Dec 4 08:56:02 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 04 Dec 2014 08:56:02 +0000 Subject: linker_unload In-Reply-To: <1417613121.2162.8.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net> <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com> <1417595155.2162.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F3F1301@DB3PRD3001MB020.064d.mgd.msft.net> <877fy9kpdx.fsf@gmail.com> <547F0EAD.1070100@gmail.com> <1417613121.2162.8.camel@joachim-breitner.de> Message-ID: <548021A2.4050707@gmail.com> On 03/12/2014 13:25, Joachim Breitner wrote: > Hi, > > > Am Mittwoch, den 03.12.2014, 13:22 +0000 schrieb Simon Marlow: >> At a guess, you could try this: >> >> --- a/testsuite/tests/rts/Makefile >> +++ b/testsuite/tests/rts/Makefile >> @@ -124,7 +124,7 @@ linker_unload: >> $(RM) Test.o Test.hi >> "$(TEST_HC)" $(TEST_HC_OPTS) -c Test.hs -v0 >> # -rtsopts causes a warning >> - "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) >> linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g >> + "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) >> linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g >> -lgmp >> ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP) > > no, does not help, as -lgmp is already passed to gcc by ghc: > > > /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o > linker_unload linker_unload.o > -L/data1/ghc-builder/ghc-master/libraries/base/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/integer-gmp2/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/ghc-prim/dist-install/build -L/data1/ghc-builder/ghc-master/rts/dist/build /tmp/ghc26637_1/ghc26637_4.o /tmp/ghc26637_1/ghc26637_6.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmp rim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_run NonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase_469rOtLAqwTGFEOGWxSUiQ -lHSinteg_21cuTlnn00eFNd4GMrxOMi -lHSghcpr_FgrV6cgh2JHBlbcx1OSlwt -lHSrts_debug -lCffi > -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' > -Wl,--reduce-memory-overheads > > but due to --no-needed, and linker_unload indeed not requiring any > symbols from gmp, the linker does not link it. Ok, I was afraid of that. The test needs to be fixed to explicitly dlopen("libgmp"). I'll take a look at it today. Cheers, Simon From alan.zimm at gmail.com Thu Dec 4 09:52:09 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 4 Dec 2014 11:52:09 +0200 Subject: API Annotations for pragmas Message-ID: It seems that pragma definitions in source are not only case insensitive, but can accept UK or US spelling variants. I am going to need to capture SourceText values in the tokens, and bring them through into the AST. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 4 11:07:48 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Dec 2014 11:07:48 +0000 Subject: Out Of Process Template Haskell In-Reply-To: <25E2F948-7444-40B6-A585-86DAC883ECEB@lichtzwerge.de> References: <25E2F948-7444-40B6-A585-86DAC883ECEB@lichtzwerge.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F31EA@DB3PRD3001MB020.064d.mgd.msft.net> Luite's "out of process TH" work is amazing. If someone had suggested it to me I'd have said "it sounds entirely impractical", but he showed that I would have been quite wrong. I'm open to fixing up GHC, preferably via some plugin variations, to support this. (I would prefer not to add a whole batch of new dependencies.) If a little sub-group would like to: * Articulate their preferred design (from a user point of view) on a wiki page * Sketch the implementation plan * Build a patch and get consensus on all of that, let's go for it. I guess that means at least Luite and Moritz; I'm not sure who else is keen here. The ball is in your court. Thank you! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Moritz Angermann | Sent: 03 December 2014 21:24 | To: ghc-devs | Subject: Out Of Process Template Haskell | | Hi, | | as you may or may not know, template haskell is not available to cross | compilers. And therefore cross compiler are devoid of an important | feature of haskell. | | We are currently building ghc cross compiler as stage1 compiler with | a foreign target. | This means that we use a stage0 compiler (the one that is used to | build ghc), to build the ghc that will run on the host and produce | binaries for the target (e.g. running on x86_64, building for arm). | Template Haskell and GHCi are enabled only in stage2. To build a | stage2 compiler we use the stage1 compiler. Hence the stage2 compiler | runs on the target of the stage1 compiler. A motivating example could | be ghc running on an Intel based Mac OS X targeting iOS (ARM). A | *theoretical* stage2 compiler could have GHCi and Template Haskell, | but would run on the iOS Device, which is neat but probably not a | practical solution. Hence a compiler running on a more powerful host, | producing executables for a foreign target can be a very good solution | when the host is much more powerful. (Ref. [1]). In [2] we can read | the following: | | > Stage 1 does not support interactive execution (GHCi) and Template | > Haskell. The reason being that when running byte code we must | > dynamically link the packages, and only in stage 2 and later can we | > guarantee that the packages we dynamically link are compatible with | those that GHC was built against (because they are the very same | packages). | | One of the prominent cross compilers is ghcjs, which admittedly is | build a little different than the above cross compiler would be. | ghcjs shares the same template haskell issue though. ghcjs--to my | knowledge--followed a few different routes to solve this. And finally | came up with the *out-of-process-template-haskell* solution. | | The Out Of Process Template Haskell approach works by having a | *runner* on the target that waits for the compiler to send the | template haskell splices, and compiles those splices on the target, | whilte querying the *master* ghc for potential lookups during the | splice compilation. The result is then shipped back to the host to | integrate into the produced binary for the target. Hence allowing the | more powerful host to do the bulk of the compilation and using the | *runner* as a *slave compiler* on the target. | | | .-- host -. | .- target -. | | | -- ( encounters splice and sends it to runner ) ---> | | | | | | | | | | | ghc | .<---- ( compiles and queries ghc for lookups ) ----. | | runner | | | master | '----------- ( responds to to queries ) ----------->' | | slave | | | | | | | | | | <- ( receives the compiled splice from the runner ) - | | | | '---------' | '----------' | | Fig. 1: ghc - th runner communication. | | | I have implemented the *out-of-process-template-haskell* approach | with the help from luite for ghc as a plugin for stage2 *non*-cross | compiler[3] using dynamic libraries and a tcp transport by adapting | the code from ghcjs to run on the host. | Obviously for a regular stage2 ghc, which has GHCi and Template | Haskell, this doesn't really buy anyone anything yet. Also a plugin | is impossible to load into a stage1 compiler yet, as the plugin code | is wrapped in #ifdef GHCI sections. | | SIDENOTE: To allow the out-of-process-template-haskell, the plugin | api had to be | adapted minimally to allow plugins to install hooks. | Patches for 7.8[4] | and 7.10[5] are readily available. | | | Clearly the *out-of-process-template-haskell* could be integrated | into the ghc tree by hard wiring it in, where the plugin did the | wiring ad-hoc previous. This would imply that ghc would have to | integrate all dependencies which *out-of-process-template-haskell* | would bring with it. | | There are now three options discussed on #ghc so far: | a) Full integration in ghc, as described above. | b) Enabling the plugin interface in stage1 compiler [See Note 1 for | details]. | This is probably only interesting for cross-compiler, where stage1 | is the final | stage on the host. [See Note 2 for an example] | c) As proposed by luite: integrate a thin layer in ghc, that uses | pipes to communicate | with an external program on the same host that ghc is running on. | That external | program will then communicate with the *runner* on the target. | | The ultimate goal would be a multi-target compiler, that could | produce a stage2 compiler that runs on the host but can produce | binaries for multiple targets of which the host it's running on is | one. | | I am in favor of extending the plugin api and making it available to | stage1 compiler, because I see much potential in the plugin api. | Which--with the noted patches [4][5]-- allows you to install hooks, | and hence allow you to hook into the complete compiler pipeline and | potential other parts as well. It also makes developing plugins | easier, because they can be developed outside of the ghc source tree. | And only be used with cross compilers if we can load plugins in stage1 | compilers. | | Cheers, | Moritz | | | [1]: https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation | [2]: | https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Stag | es | [3]: https://github.com/angerman/oopth | [4]: https://gist.github.com/angerman/7db11c24f8935c73fcf5 | [5]: https://phabricator.haskell.org/D535 | Note 1: where the plugin will have to be compiled with a stage0 | compiler, and may even | require a stage0 compiler that is as new as the stage1 | compiler one wants to build, | because the compiler being built has to be binary compatible | with the plugin. | Note 2: An example would be building 7.10 on the host for the host | with stage0=ghc7.8, | stage1=ghc7.10(built with ghc7.8), stage2=ghc7.10(built with | stage1), *and then* | building a ghc cross compiler for arm with stage0'=stage2 and | stage1'(ghc7.10 targeting | ARM built with ghc7.10 on the host). And allowing this newly | built cross compiler | (stage1') to accept -fplugin for plugins built with stage2 | (the same that built stage1') | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From gale at sefer.org Thu Dec 4 12:43:48 2014 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 4 Dec 2014 14:43:48 +0200 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: Bryan O'Sullivan wrote: >> It seems that something somewhere in linker-land >> changed in GHC 7.8 such that packages that include >> C components now need to be built with >> position-independent code on some platforms... >> I am not sure whether the correct fix is to pepper? >> packages... with "-fPIC"... or to instead teach Cabal >> to do this. Aha! Thanks for this explanation of what I have been suffering from. Mikhail Glushenkov wrote: > I've now fixed this issue in Cabal HEAD and also pushed the fix to > 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out > soon. Thanks a million for the speedy response to this serious issue! I can't wait for the point releases. I'll go with HEAD on one of the branches for now. -Yitz From johan.tibell at gmail.com Thu Dec 4 12:52:40 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 4 Dec 2014 13:52:40 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: I've merged the patches into the 1.20 branch. Look forward to a patch release this weekend. On Thu, Dec 4, 2014 at 1:43 PM, Yitzchak Gale wrote: > Bryan O'Sullivan wrote: > >> It seems that something somewhere in linker-land > >> changed in GHC 7.8 such that packages that include > >> C components now need to be built with > >> position-independent code on some platforms... > >> I am not sure whether the correct fix is to pepper? > >> packages... with "-fPIC"... or to instead teach Cabal > >> to do this. > > Aha! Thanks for this explanation of what I have been > suffering from. > > Mikhail Glushenkov wrote: > > I've now fixed this issue in Cabal HEAD and also pushed the fix to > > 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out > > soon. > > Thanks a million for the speedy response to this > serious issue! > > I can't wait for the point releases. I'll go with HEAD on one > of the branches for now. > > -Yitz > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stegeman at gmail.com Thu Dec 4 14:21:10 2014 From: stegeman at gmail.com (Luite Stegeman) Date: Thu, 4 Dec 2014 15:21:10 +0100 Subject: Out Of Process Template Haskell In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F31EA@DB3PRD3001MB020.064d.mgd.msft.net> References: <25E2F948-7444-40B6-A585-86DAC883ECEB@lichtzwerge.de> <618BE556AADD624C9C918AA5D5911BEF3F3F31EA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Thu, Dec 4, 2014 at 12:07 PM, Simon Peyton Jones wrote: > Luite's "out of process TH" work is amazing. If someone had suggested it > to me I'd have said "it sounds entirely impractical", but he showed that I > would have been quite wrong. > > I haven't had much time to actually help Moritz lately, due to other GHC 7.10 patches, the new GHCJS codegen and work to get Cabal support for GHCJS merged. Building/linking the code for the splices can be done in GHC without additional dependencies, and with the recent changes in the template-haskell package (if I haven't missed anything), serialization for communication can also be implemented in a ligthtweight way based on Generic or Data without additional dependencies. I'd like to start simple and treat the Template Haskell runner as an external build tool, possibly installable as a cabal package. GHC would just start a runner process and communicate with it over the standard pipes whenever it needs to run TH. The runner is then responsible for loading and executing the code (in most cases a dynamic library for each splice) on the target. I intend to start by making a patch that adds the runner to the 'settings' file, such that users can enable TH in a stage1 (cross) compiler by pointing GHC to the correct runner program. Other than the minor changes in SysTools (for 'settings'), the code for this would be common to all implementation alternatives. We can then figure out whether this approach is flexible enough and further work out configuration options and serialization protocol, or whether Moritz' idea of loading a plugin to have more control over TH code generation is worth the additional complexity (a different loading mechanism would be required for plugins in cross compilers). luite -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu Dec 4 16:44:45 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 4 Dec 2014 17:44:45 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: <1417682707.1485.1.camel@joachim-breitner.de> References: <1417682707.1485.1.camel@joachim-breitner.de> Message-ID: Hi, On 4 December 2014 at 09:45, Joachim Breitner wrote: > is the bug in Cabal or cabal-install? It's in Cabal. So once the new point releases are out, the users will need to run `cabal install cabal-install --constraint="Cabal > 1.20.0.2"`. From mail at joachim-breitner.de Thu Dec 4 16:50:00 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 04 Dec 2014 17:50:00 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: <1417682707.1485.1.camel@joachim-breitner.de> Message-ID: <1417711800.11267.0.camel@joachim-breitner.de> Hi, Am Donnerstag, den 04.12.2014, 17:44 +0100 schrieb Mikhail Glushenkov: > On 4 December 2014 at 09:45, Joachim Breitner wrote: > > is the bug in Cabal or cabal-install? > > It's in Cabal. So once the new point releases are out, the users will > need to run `cabal install cabal-install --constraint="Cabal > > 1.20.0.2"`. in this case, can we get a fixed Cabal in 7.8.4? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Thu Dec 4 22:37:02 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 04 Dec 2014 23:37:02 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <87h9xffd5v.fsf@gmail.com> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> Message-ID: <1417732622.11267.9.camel@joachim-breitner.de> Hi, Am Montag, den 01.12.2014, 13:17 -0500 schrieb Ben Gamari: > Is there any way you could poke around at the state of the tree after > the failure? It would be nice to confirm that this is in fact that > bfd/gold issue and perhaps figure out why ld.gold isn't being used. > > Otherwise I can try to reproduce this on my ARM box. ok, I finally reproduced this on a porter box, and (using strace...) I found out that -B/usr/bin/ld.gold was ignored. What did work was passing -optl-fuse-ld=gold to ghc. But that, in turn, causes /usr/bin/ld.gold: --hash-size=31: unknown option There seems to be some special handling for Gold in SysTools.lhs, via getLinkerInfo'. But passing -pgml=/usr/bin/ld.gold to ghc causes /usr/bin/ld.gold: -pthread: unknown option /usr/bin/ld.gold: use the --help option for usage information so this is not the right thing to do. The problem is that in order to find out which linker is used, ghc calls /usr/bin/gcc -Wl,-version without passing the options from -optl, so the -fuse-ld=gold is not used in this step. I?m a bit confused, because the code in getLinkerInfo' looks like it should be passing them... ah, but only on HEAD, not in 7.8... and git blame tells me that I probably want to apply this patch: commit e7b414a3cc0e27049f2608f5e0a00c47146cc46d Author: Sebastian Dr?ge Date: Tue Nov 18 12:40:20 2014 -0600 Fix detection of GNU gold linker if invoked via gcc with parameters Previously the linker was called without any commandline parameters to detect whether bfd or gold is used. However the -fuse-ld parameter can be used to switch between gold and bfd and should be taken into account here. Trac #9336 Signed-off-by: Austin Seipp (which would have saved me some work had I known about it). I?ll try it and report back. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sean.seefried at gmail.com Thu Dec 4 23:42:14 2014 From: sean.seefried at gmail.com (Sean Seefried) Date: Fri, 5 Dec 2014 10:42:14 +1100 Subject: Out Of Process Template Haskell In-Reply-To: References: <25E2F948-7444-40B6-A585-86DAC883ECEB@lichtzwerge.de> <618BE556AADD624C9C918AA5D5911BEF3F3F31EA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm not a GHC dev, but I have been following the list. I recently managed to build and run a small game written in Haskell on Android. I am also interested in iOS development. Being able to use Template Haskell inside a cross-compiler would allow me to use Manuel Chakravarty's 'language-c-inline' package which makes heavy use of it. I'm very excited by your work and would be interested in testing any solutions you came up with. Sean On 5 December 2014 at 01:21, Luite Stegeman wrote: > > > On Thu, Dec 4, 2014 at 12:07 PM, Simon Peyton Jones > wrote: > >> Luite's "out of process TH" work is amazing. If someone had suggested it >> to me I'd have said "it sounds entirely impractical", but he showed that I >> would have been quite wrong. >> >> > I haven't had much time to actually help Moritz lately, due to other GHC > 7.10 patches, the new GHCJS codegen and work to get Cabal support for GHCJS > merged. > > Building/linking the code for the splices can be done in GHC without > additional dependencies, and with the recent changes in the > template-haskell package (if I haven't missed anything), serialization for > communication can also be implemented in a ligthtweight way based on > Generic or Data without additional dependencies. > > I'd like to start simple and treat the Template Haskell runner as an > external build tool, possibly installable as a cabal package. GHC would > just start a runner process and communicate with it over the standard pipes > whenever it needs to run TH. The runner is then responsible for loading and > executing the code (in most cases a dynamic library for each splice) on the > target. > > I intend to start by making a patch that adds the runner to the 'settings' > file, such that users can enable TH in a stage1 (cross) compiler by > pointing GHC to the correct runner program. Other than the minor changes in > SysTools (for 'settings'), the code for this would be common to all > implementation alternatives. > > We can then figure out whether this approach is flexible enough and > further work out configuration options and serialization protocol, or > whether Moritz' idea of loading a plugin to have more control over TH code > generation is worth the additional complexity (a different loading > mechanism would be required for plugins in cross compilers). > > luite > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Dec 5 08:54:41 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 5 Dec 2014 10:54:41 +0200 Subject: API Annotations for pragmas In-Reply-To: References: Message-ID: I already have an open diff in D538, covering haddock doc changes for the API annotations, and bringing in a `SourceText` field for HsTyLit. Should I include the changes for SourceText in pragmas in D538, or create a new one? Alan On Thu, Dec 4, 2014 at 11:52 AM, Alan & Kim Zimmerman wrote: > It seems that pragma definitions in source are not only case insensitive, > but can accept UK or US spelling variants. > > I am going to need to capture SourceText values in the tokens, and bring > them through into the AST. > > Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Dec 5 09:01:54 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 05 Dec 2014 01:01:54 -0800 Subject: Can we rename completion to autocomplete Message-ID: <1417770099-sup-4642@sabre> I keep typing 'comp' and expecting it to autocomplete to compiler, and this is stopped working. Can we rename the 'completion' directory to something? How about 'autocomplete'? Thanks, Edward From simonpj at microsoft.com Fri Dec 5 09:48:24 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 5 Dec 2014 09:48:24 +0000 Subject: API Annotations for pragmas In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F41C1@DB3PRD3001MB020.064d.mgd.msft.net> I?d combine them; but make sure you add a Note explaining the purpose of the extra fields is. Maybe you can use the same Note S From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 05 December 2014 08:55 To: ghc-devs at haskell.org Subject: Re: API Annotations for pragmas I already have an open diff in D538, covering haddock doc changes for the API annotations, and bringing in a `SourceText` field for HsTyLit. Should I include the changes for SourceText in pragmas in D538, or create a new one? Alan On Thu, Dec 4, 2014 at 11:52 AM, Alan & Kim Zimmerman > wrote: It seems that pragma definitions in source are not only case insensitive, but can accept UK or US spelling variants. I am going to need to capture SourceText values in the tokens, and bring them through into the AST. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Dec 5 09:54:57 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 5 Dec 2014 09:54:57 +0000 Subject: ghc.haskell.org Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F429B@DB3PRD3001MB020.064d.mgd.msft.net> Is it just me, or is ghc.haskell.org very slow at serving up Trac pages today? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri Dec 5 11:49:21 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 05 Dec 2014 12:49:21 +0100 Subject: Can we rename completion to autocomplete In-Reply-To: <1417770099-sup-4642@sabre> (Edward Z. Yang's message of "Fri, 05 Dec 2014 01:01:54 -0800") References: <1417770099-sup-4642@sabre> Message-ID: <87ppbyl3jy.fsf@gmail.com> On 2014-12-05 at 10:01:54 +0100, Edward Z. Yang wrote: > I keep typing 'comp' and expecting it to autocomplete to compiler, > and this is stopped working. Can we rename the 'completion' directory > to something? How about 'autocomplete'? I'm not sure about the folder-name/location either. I'm used to see completion-scripts and similiar in sub-folders of 'contrib/', e.g. https://github.com/git/git/tree/master/contrib/completion otoh, we do already have a 'utils/' folder, we could simply move it there, as ghc's top-folder is already quite crowded... From mail at joachim-breitner.de Fri Dec 5 19:25:03 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Dec 2014 20:25:03 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1417732622.11267.9.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> Message-ID: <1417807503.3959.14.camel@joachim-breitner.de> Hi, Am Donnerstag, den 04.12.2014, 23:37 +0100 schrieb Joachim Breitner: > The problem is that in order to find out which linker is used, ghc calls > > /usr/bin/gcc -Wl,-version > > without passing the options from -optl, so the -fuse-ld=gold is not used > in this step. I?m a bit confused, because the code in getLinkerInfo' > looks like it should be passing them... ah, but only on HEAD, not in > 7.8... and git blame tells me that I probably want to apply this patch: > > commit e7b414a3cc0e27049f2608f5e0a00c47146cc46d > Author: Sebastian Dr?ge > Date: Tue Nov 18 12:40:20 2014 -0600 now gold is used, but if I set this in SRC_HC_OPTS, it is also passed to the bootstrapping compiler, which does not work with gold. So it seems I want to modify the "C compiler link flags" settings. I tried to achieve this using Index: ghc-7.8.20141119/aclocal.m4 =================================================================== --- ghc-7.8.20141119.orig/aclocal.m4 +++ ghc-7.8.20141119/aclocal.m4 @@ -553,6 +553,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], $3="$$3 -D_HPUX_SOURCE" $5="$$5 -D_HPUX_SOURCE" ;; + arm*) + # On arm, link using gold + $3="$$3 -fuse-ld=gold" + ;; esac # If gcc knows about the stack protector, turn it off. but this made the settings reach parts of the build system where I did not want them, and for example tips over configuring terminfo-0.4.0.0...: checking for setupterm in -ltinfo... yes configure: creating ./config.status config.status: creating terminfo.buildinfo configure: WARNING: unrecognized options: --with-compiler, --with-gcc ghc-cabal: Missing dependency on a foreign library: * Missing C library: tinfo This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. because --gcc-options=-fuse-ld=gold is being passed to ./configure. Now idea why that confuses ghc-cabal. Unfortunately, cabal is not very verbose and does not tell me why and how the test C program failed to compile.... but strace helps. And we are back at /usr/bin/ld.gold: --hash-size=31: unknown option But I?m not sure where this comes from. So, less elegantly, I?m now trying @@ -487,7 +487,7 @@ AC_DEFUN([FP_SETTINGS], fi fi SettingsCCompilerFlags="$CONF_CC_OPTS_STAGE2" - SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2" + SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2 -fuse-ld=gold" SettingsLdFlags="$CONF_LD_LINKER_OPTS_STAGE2" AC_SUBST(SettingsCCompilerCommand) AC_SUBST(SettingsHaskellCPPCommand) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From the.dead.shall.rise at gmail.com Fri Dec 5 20:10:49 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Fri, 5 Dec 2014 21:10:49 +0100 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: <1417711800.11267.0.camel@joachim-breitner.de> References: <1417682707.1485.1.camel@joachim-breitner.de> <1417711800.11267.0.camel@joachim-breitner.de> Message-ID: Hi, On 4 December 2014 at 17:50, Joachim Breitner wrote: > > in this case, can we get a fixed Cabal in 7.8.4? This is up to whoever manages the release at GHC HQ, which I guess means Austin. From mail at joachim-breitner.de Sat Dec 6 14:59:00 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 06 Dec 2014 15:59:00 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1417807503.3959.14.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> Message-ID: <1417877940.1501.17.camel@joachim-breitner.de> Hi, Am Freitag, den 05.12.2014, 20:25 +0100 schrieb Joachim Breitner: > So, less elegantly, I?m now trying > > @@ -487,7 +487,7 @@ AC_DEFUN([FP_SETTINGS], > fi > fi > SettingsCCompilerFlags="$CONF_CC_OPTS_STAGE2" > - SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2" > + SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2 -fuse-ld=gold" > SettingsLdFlags="$CONF_LD_LINKER_OPTS_STAGE2" > AC_SUBST(SettingsCCompilerCommand) > AC_SUBST(SettingsHaskellCPPCommand) great, this works, and the build proceeds up to calling dll-split, and that does not crash as it did before. But it gives this error message: inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed make[2]: *** [compiler/stage2/dll-split.stamp] Error 1 any idea what might be causing this? I started the build from a fresh checkout. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Dec 6 15:19:02 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 06 Dec 2014 16:19:02 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1417877940.1501.17.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> Message-ID: <1417879142.1501.18.camel@joachim-breitner.de> Hi, Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner: > any idea what might be causing this? I started the build from a fresh > checkout. nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 and will try with these. Once I get it to compile I?ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From shumovichy at gmail.com Sat Dec 6 16:04:03 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 06 Dec 2014 19:04:03 +0300 Subject: Typechecker tests failures Message-ID: <1417881843.2684.1.camel@gmail.com> Hello, I was working on #9605, and found a number of failed tests: Unexpected failures: should_compile T7891 [exit code non-0] (hpc,optasm,optllvm) should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) They seem to be unrelated to my work, and they are skipped when "fast" is enabled. T7891 and tc124 fail with Core Lint errors. Looks like Phabricator uses "fast" way to validate revisions, so the failures were not noticed. Thanks, Yuras From bgamari.foss at gmail.com Sat Dec 6 16:06:38 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sat, 06 Dec 2014 11:06:38 -0500 Subject: Status and future of the LLVM backend In-Reply-To: <1417879142.1501.18.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> Message-ID: <87sigsdapd.fsf@gmail.com> Joachim Breitner writes: > Hi, > > > Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner: >> any idea what might be causing this? I started the build from a fresh >> checkout. > > nevermind, I found > https://ghc.haskell.org/trac/ghc/ticket/9552 and > https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 > and will try with these. > > Once I get it to compile I?ll give a complete list of patches that I had > to backport, with the recommendation to include them in GHC 7.8.4. > Excellent! Thanks for doing this. I wish I had been able to provide more guidance but the end of the semester has been a bit crazy. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From lennart at augustsson.net Sat Dec 6 23:58:56 2014 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun, 7 Dec 2014 00:58:56 +0100 Subject: Out of memory mystery Message-ID: I'm running the 32-bit Windows version of ghc-7.8.3. Here are two runs: $ RunMu +RTS -A64M -h -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main Compiling afresh Strat.App.Abacus.Main Compiled afresh Strat.App.Abacus.Main, 1302.84s $ RunMu +RTS -A64M -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main Compiling afresh Strat.App.Abacus.Main RunMu.exe: out of memory The binary is compiled without profiling, but in the first run I'm using the -h flag to get the rudimentary heap profile. And with -h it works, but without the flag it runs out of memory. Any bright ideas from the RTS experts on why this could happen? -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Dec 7 10:07:10 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 07 Dec 2014 11:07:10 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1417879142.1501.18.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> Message-ID: <1417946830.13556.2.camel@joachim-breitner.de> Hi, Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner: > nevermind, I found > https://ghc.haskell.org/trac/ghc/ticket/9552 and > https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 > and will try with these. > > Once I get it to compile I?ll give a complete list of patches that I had > to backport, with the recommendation to include them in GHC 7.8.4. and the build went further, I now have "inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -lffi -optl-pthread -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.2 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.3.20141119 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/xhtml/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/compiler/stage2/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/transformers/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/hpc/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/hoopl/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/bin-package-db/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/binary/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/Cabal/Cabal/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/process/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/pretty/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/directory/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/unix/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/time/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/old-locale/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/filepath/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/containers/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/bytestring/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/deepseq/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/array/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/base/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/integer-gmp/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/ghc-prim/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/rts/dist/build' -optl-lrt -optl-lutil -optl-ldl -optl-lpthread -optl-lgmp -optl-lm -optl-lrt -optl-ldl -optl-lffi -fPIC -dynamic -H32m -O -lffi -optl-pthread -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.2 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.3.20141119 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../xhtml-3000.2.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-7.8.3.20141119' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../transformers-0.3.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../hpc-0.6.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../hoopl-3.10.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../bin-package-db-0.0.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../binary-0.7.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../Cabal-1.18.1.3' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../process-1.2.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../pretty-1.1.1.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../directory-1.2.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../unix-2.7.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../time-1.4.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../old-locale-1.0.0.6' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../bytestring-0.10.4.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/haddock/dist/build/Main.dyn_o utils/haddock/dist/build/Documentation/Haddock.dyn_o utils/haddock/dist/build/Data/Attoparsec.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.dyn_o utils/haddock/dist/build/Data/Attoparsec/Combinator.dyn_o utils/haddock/dist/build/Data/Attoparsec/Number.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.dyn_o utils/haddock/dist/build/Data/Attoparsec/Internal.dyn_o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.dyn_o utils/haddock/dist/build/Haddock.dyn_o utils/haddock/dist/build/Haddock/Interface.dyn_o utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/dist/build/Haddock/Interface/AttachInstances.dyn_o utils/haddock/dist/build/Haddock/Interface/LexParseRn.dyn_o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.dyn_o utils/haddock/dist/build/Haddock/Parser.dyn_o utils/haddock/dist/build/Haddock/Parser/Util.dyn_o utils/haddock/dist/build/Haddock/Utf8.dyn_o utils/haddock/dist/build/Haddock/Utils.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.dyn_o utils/haddock/dist/build/Haddock/Backends/LaTeX.dyn_o utils/haddock/dist/build/Haddock/Backends/HaddockDB.dyn_o utils/haddock/dist/build/Haddock/Backends/Hoogle.dyn_o utils/haddock/dist/build/Haddock/ModuleTree.dyn_o utils/haddock/dist/build/Haddock/Types.dyn_o utils/haddock/dist/build/Haddock/Doc.dyn_o utils/haddock/dist/build/Haddock/Version.dyn_o utils/haddock/dist/build/Haddock/InterfaceFile.dyn_o utils/haddock/dist/build/Haddock/Options.dyn_o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o utils/haddock/dist/build/Haddock/Convert.dyn_o utils/haddock/dist/build/Paths_haddock.dyn_o /home/nomeata/ghc-7.8.20141119/compiler/stage2/build/libHSghc-7.8.3.20141119-ghc7.8.3.20141119.so: error: undefined reference to 'arm_atomic_spin_lock' /home/nomeata/ghc-7.8.20141119/compiler/stage2/build/libHSghc-7.8.3.20141119-ghc7.8.3.20141119.so: error: undefined reference to 'arm_atomic_spin_unlock' collect2: error: ld returned 1 exit status utils/haddock/ghc.mk:15: recipe for target 'utils/haddock/dist/build/tmp/haddock' failed make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951 Ben, can you help me out here? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From eir at cis.upenn.edu Sun Dec 7 16:19:24 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 7 Dec 2014 11:19:24 -0500 Subject: testsuite no longer parellel? Message-ID: Hi devs, Previously, I've had much success with the THREADS environment variable for getting the testsuite to run multiple tests in parallel. This no longer seems to be working on my Macs. Is this an expected change? Is there something I can do to fix this locally? It takes a long time to run tests one at a time! Thanks! Richard From dnspies at gmail.com Sun Dec 7 17:52:07 2014 From: dnspies at gmail.com (David Spies) Date: Sun, 7 Dec 2014 10:52:07 -0700 Subject: -O/-O2 causes program to run too slow Message-ID: I have a program I wrote to submit for the Car Game problem on Kattis: https://open.kattis.com/problems/cargame but it runs over the 5-second time-limit I downloaded the test data and found that on GHC 7.8.3, if I switch from -O2 to -O0, it runs three times faster (almost certainly fast enough for Kattis to accept). Can someone tell me what's going on? Is this a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.hs Type: text/x-haskell Size: 1980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cargame-03.in Type: application/octet-stream Size: 535014 bytes Desc: not available URL: From eir at cis.upenn.edu Sun Dec 7 18:59:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 7 Dec 2014 13:59:36 -0500 Subject: painful merges Message-ID: Hi devs, There are various times when we want to make some change to a large number of lines/files, but the change is very very boring. Two somewhat recent cases that come to mind are de-tabbing and the .lhs -> .hs conversion. These sorts of changes cause painful merges for anyone who is working on a branch. However, this pain is mitigated substantially if two properties hold: 1) The commit does *nothing* interesting. 2) The branch-writer knows about the commit in question. If these two properties hold, then the branch-writer can merge with the commit previous to the painful one, resolve all conflicts, and then merge the painful commit. During the painful merge, the branch-writer can be blissfully carefree about understanding the code -- after all, the painful merge is uninteresting and mechanical. Then, the branch-writer can continuing merging more commits, paying closer attention. In most cases, it should be easy for us to maintain property (1) going forward. Property (2) is harder, so I propose the following: ** All commits expected to be painful to merge, but are otherwise uninteresting, include "[painful merge]" in the commit message. ** This seems to be a really easy workflow to implement, and it would make, for example, the long, drawn-out debate over detabbing perhaps easier to resolve. Bikeshedding over the keyword [painful merge] welcome, along with more constructive comments. Is anyone aware of this convention implemented in other projects? Thanks, Richard From gale at sefer.org Sun Dec 7 19:03:01 2014 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 7 Dec 2014 21:03:01 +0200 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: I wrote: > Aha! Thanks [to Bryan] for this explanation of what I have been > suffering from... > I can't wait for the point releases. I'll go with HEAD on one > of the branches for now. Unfortunately, this patch did *not* fix what I have been suffering from. I'm still getting segfaults. I'll describe what I'm doing. Please let me know if either of the two problems below are actual problems, or if I'm just missing something. I'll submit them as issues if they are problems. Sample code: http://github.com/ygale/test-text-icu The following procedure worked fine for 32 bit Windows versions of GHC previous to 7.8.* and with all recent versions of cabal-install. Using Haskell Platform 2014.2.0.0 (GHC 7.8.3) 64 bit on Windows 7. Using rev. caf257cd96e766b293943bbac07d766ec2f552dd of cabal, the latest rev. at the moment, on the 1.20 branch. I locally changed the version numbers in the cabal files of both Cabal and cabal-install so I could verify that I really am using cabal.exe from that revision. I verified in the source code that the -fPIC fix is included. Clone the above sample code, and unzip ICU4C 54.1 (currently the latest) for 64 bit Windows in a nearby folder. ***Problem #1 (minor): Relative linker paths don't work anymore cabal sandbox init cabal install --extra-lib-dirs=..\relative\path\to\icu\lib64 --extra-include-dirs=..\relative\path\to\icu\include text-icu This fails with: Warning: 'extra-lib-dirs: ../relative/path/to/icu/lib64' directory does not exist. Warning: 'include-dirs: ../relative/path/to/icu/include' directory does not exist. cabal: Missing dependencies on foreign libraries: * Missing C libraries: icuuc, icuin, icudt Note: The same problem occurs if you copy the ICU folders into the source tree. That just gets rid of the warnings that sdist won't work. ***Problem #2 (major): segfault! cabal install --extra-lib-dirs=C:\absolute\path\to\icu\lib64 --extra-include-dirs=C:\absolute\path\to\icu\include text-icu cabal install Now, place .cabal-sandbox\bin\test-text-icu.exe together with the 3 DLLs icudt54.dll, icuin54.dll, and icuuc54.dll from icu\bin64 all together in the same folder. Run test-text-icu. Kaboom! Note: The same problem occurs if you place *all* of the DLLs from icu\bin64 in the folder together with the exe. So it's not a missing DLL. Thanks, Yitz From dnspies at gmail.com Sun Dec 7 19:43:43 2014 From: dnspies at gmail.com (David Spies) Date: Sun, 7 Dec 2014 12:43:43 -0700 Subject: -O/-O2 causes program to run too slow In-Reply-To: References: Message-ID: Ok, so I found that it was an instance of this: https://ghc.haskell.org/trac/ghc/ticket/1168 and I read through this whole thread: https://www.haskell.org/pipermail/glasgow-haskell-users/2008-February/014259.html I don't understand the state-hack optimization. It's clearly not safe and I'm not convinced that it actually is an optimization. In what circumstances does the state-hack identify a single-entry function that can't be identified as single-entry by some other (safe) method? On Sun, Dec 7, 2014 at 10:52 AM, David Spies wrote: > I have a program I wrote to submit for the Car Game problem on Kattis: > https://open.kattis.com/problems/cargame > but it runs over the 5-second time-limit > > I downloaded the test data and found that on GHC 7.8.3, if I switch from > -O2 to -O0, it runs three times faster (almost certainly fast enough for > Kattis to accept). Can someone tell me what's going on? Is this a bug? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Dec 8 03:41:47 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 7 Dec 2014 22:41:47 -0500 Subject: inferred contexts from `deriving` Message-ID: <85CDA193-B477-418F-9B92-52A13E937F81@cis.upenn.edu> Hi devs, I've just hit on (what I view to be) a design wart in what is allowed in an instance context inferred through the use of non-standalone `deriving`. I've posed a problem and potential solution in #8984 (https://ghc.haskell.org/trac/ghc/ticket/8984#comment:6). See Note [Exotic derived instance contexts] (https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcDeriv.hs#L1915) for some background info. I would love input on this issue, as it all boils down to a simple design choice. The implementation is dead easy no matter what. Please post any further comments to the ticket, but I wanted to bleat here because it seems easy to ignore emails from #8984, whose title is about tweaking an error message. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Mon Dec 8 05:48:12 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Mon, 08 Dec 2014 08:48:12 +0300 Subject: Typechecker tests failures In-Reply-To: <1417881843.2684.1.camel@gmail.com> References: <1417881843.2684.1.camel@gmail.com> Message-ID: <1418017692.2602.2.camel@gmail.com> Simon, I tracked T7891 and tc124 failure down to simplifier, namely `simplExprF1` for `Case`. Core lint catches the bug (requires -O1 at least), but without -dcore-lint compiler hangs in busy loop. I made it work with simple patch: > diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs > index 7611f56..d396b60 100644 > --- a/compiler/simplCore/Simplify.hs > +++ b/compiler/simplCore/Simplify.hs > @@ -950,8 +950,10 @@ simplExprF1 env expr@(Lam {}) cont > zap b | isTyVar b = b > | otherwise = zapLamIdInfo b > > -simplExprF1 env (Case scrut bndr _ alts) cont > - = simplExprF env scrut (Select NoDup bndr alts env cont) > +simplExprF1 env (Case scrut bndr alts_ty alts) cont > + = do { expr <- simplExprC env scrut (Select NoDup bndr alts env > + (mkBoringStop alts_ty)) > + ; rebuild env expr cont } > > simplExprF1 env (Let (Rec pairs) body) cont > = do { env' <- simplRecBndrs env (map fst pairs) (I have no idea what most of this code does, but I learned a lot while investigating this issue :) ) The relevant commit is: > commit a0b2897ee406e24a05c41768a0fc2395442dfa06 > Author: Simon Peyton Jones > Date: Tue May 27 09:09:28 2014 +0100 > > Simple refactor of the case-of-case transform > > More modular, less code. No change in behaviour. The T7861 failed because additional lambda abstraction in Core. Not sure whether it is important. Thanks, Yuras On Sat, 2014-12-06 at 19:04 +0300, Yuras Shumovich wrote: > Hello, > > I was working on #9605, and found a number of failed tests: > > Unexpected failures: > should_compile T7891 [exit code non-0] (hpc,optasm,optllvm) > should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) > should_run T7861 [bad exit code] > (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) > > They seem to be unrelated to my work, and they are skipped when "fast" > is enabled. > > T7891 and tc124 fail with Core Lint errors. > > Looks like Phabricator uses "fast" way to validate revisions, so the > failures were not noticed. > > Thanks, > Yuras > > From jan.stolarek at p.lodz.pl Mon Dec 8 09:18:12 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 8 Dec 2014 10:18:12 +0100 Subject: -O/-O2 causes program to run too slow In-Reply-To: References: Message-ID: <201412081018.12835.jan.stolarek@p.lodz.pl> While I don't know how to help with your problem I encourage you to attach your code example to #1168. This will certainly be helpful in working on that bug. Janek Dnia niedziela, 7 grudnia 2014, David Spies napisa?: > Ok, so I found that it was an instance of this: > https://ghc.haskell.org/trac/ghc/ticket/1168 > and I read through this whole thread: > https://www.haskell.org/pipermail/glasgow-haskell-users/2008-February/01425 >9.html > > I don't understand the state-hack optimization. It's clearly not safe and > I'm not convinced that it actually is an optimization. In what > circumstances does the state-hack identify a single-entry function that > can't be identified as single-entry by some other (safe) method? > > On Sun, Dec 7, 2014 at 10:52 AM, David Spies wrote: > > I have a program I wrote to submit for the Car Game problem on Kattis: > > https://open.kattis.com/problems/cargame > > but it runs over the 5-second time-limit > > > > I downloaded the test data and found that on GHC 7.8.3, if I switch from > > -O2 to -O0, it runs three times faster (almost certainly fast enough for > > Kattis to accept). Can someone tell me what's going on? Is this a bug? From bgamari.foss at gmail.com Mon Dec 8 13:20:06 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 08 Dec 2014 08:20:06 -0500 Subject: Status and future of the LLVM backend In-Reply-To: <1417946830.13556.2.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> Message-ID: <8761dmcm7t.fsf@gmail.com> Joachim Breitner writes: > Hi, > > > Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner: >> nevermind, I found >> https://ghc.haskell.org/trac/ghc/ticket/9552 and >> https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 >> and will try with these. >> >> Once I get it to compile I?ll give a complete list of patches that I had >> to backport, with the recommendation to include them in GHC 7.8.4. > > and the build went further, I now have snip > Again Google finds me a bug, but this time one that has no fix > associated with it: > https://ghc.haskell.org/trac/ghc/ticket/8951 > > Ben, can you help me out here? > I've been unable to reproduce this issue in my environment. The build succeeded using your packaging on my Odroid XU running Debian Jessie. Unfortunately every subsequent build seems to fail with this build system issue, ... "inplace/bin/ghc-cabal" configure libraries/integer-gmp dist-install "" --with-ghc="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/ghc-stage1" --with-ghc-pkg="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/gh c-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=L DFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" -- with-ranlib="/usr/bin/ranlib" --with-alex="/home/ben/.cabal/bin/alex" --with-happy="/home/ben/.cabal/bin/happy" Configuring integer-gmp-0.5.1.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: error: cannot run /bin/bash ./config.sub libraries/integer-gmp/ghc.mk:4: recipe for target 'libraries/integer-gmp/dist-install/package-data.mk' failed It seems that this is likely due to dh_autoreconf which overwrites all config.subs with /usr/share/misc/config.sub. It's totally unclear to me how the first build succeeded, however. Have you seen this in the past? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at joachim-breitner.de Mon Dec 8 14:49:07 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 08 Dec 2014 15:49:07 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <8761dmcm7t.fsf@gmail.com> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> Message-ID: <1418050147.1441.47.camel@joachim-breitner.de> Hi, Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari: > > Again Google finds me a bug, but this time one that has no fix > > associated with it: > > https://ghc.haskell.org/trac/ghc/ticket/8951 > > > > Ben, can you help me out here? > > > I've been unable to reproduce this issue in my environment. The build > succeeded using your packaging on my Odroid XU running Debian Jessie. Weird. Can you try creating a sid chroot and building it in there? I managed to finish the build with this patch attached: Index: ghc-7.8.20141119/includes/stg/SMP.h =================================================================== --- ghc-7.8.20141119.orig/includes/stg/SMP.h +++ ghc-7.8.20141119/includes/stg/SMP.h @@ -14,13 +14,13 @@ #ifndef SMP_H #define SMP_H -#if defined(THREADED_RTS) - #if arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6) void arm_atomic_spin_lock(void); void arm_atomic_spin_unlock(void); #endif +#if defined(THREADED_RTS) + /* ---------------------------------------------------------------------------- Atomic operations ------------------------------------------------------------------------- */ Index: ghc-7.8.20141119/rts/OldARMAtomic.c =================================================================== --- ghc-7.8.20141119.orig/rts/OldARMAtomic.c +++ ghc-7.8.20141119/rts/OldARMAtomic.c @@ -14,8 +14,6 @@ #include #endif -#if defined(THREADED_RTS) - #if arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6) static volatile int atomic_spin = 0; @@ -51,6 +49,3 @@ void arm_atomic_spin_unlock() } #endif /* arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6) */ - -#endif /* defined(THREADED_RTS) */ - So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? > Unfortunately every subsequent build seems to fail with this > build system issue, > > ... > "inplace/bin/ghc-cabal" configure libraries/integer-gmp dist-install "" --with-ghc="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/ghc-stage1" --with-ghc-pkg="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/gh > c-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=L > DFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" -- > with-ranlib="/usr/bin/ranlib" --with-alex="/home/ben/.cabal/bin/alex" --with-happy="/home/ben/.cabal/bin/happy" > Configuring integer-gmp-0.5.1.0... > configure: WARNING: unrecognized options: --with-compiler, --with-gcc > configure: error: cannot run /bin/bash ./config.sub > libraries/integer-gmp/ghc.mk:4: recipe for target 'libraries/integer-gmp/dist-install/package-data.mk' failed > > It seems that this is likely due to dh_autoreconf which overwrites all > config.subs with /usr/share/misc/config.sub. It's totally unclear to me > how the first build succeeded, however. > > Have you seen this in the past? Yes, likely a bug in dh_autoreconf that does not handle rebuilds well (or a bug in how we use it). Until that is fixed I use rm -rf ghc-7.8.20141119 && dpkg-source -x ghc_7.8.20141119-6.dsc && cd ghc-7.8.20141119/ && schroot -r -c ghc -- debuild -uc -us to get a clean state again. I?ll have to look into that eventually. Autoconf is a mess. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Dec 8 15:23:46 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 8 Dec 2014 15:23:46 +0000 Subject: ghc.haskell.org slow? Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3F8159@DB3PRD3001MB020.064d.mgd.msft.net> Is it just me, or is access to ghc.haskell.org and git.haskell.org very slow? I guess it could be at my end; I don't know how to tell. But git pull and Trac access takes tens of seconds, even minutes Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Mon Dec 8 15:34:53 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 08 Dec 2014 16:34:53 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1418050147.1441.47.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> Message-ID: <5485C51D.3000200@centrum.cz> On 12/ 8/14 03:49 PM, Joachim Breitner wrote: > So what does that tell us? Maybe Peter can help us: Is it normal for a > Debian system to pretend that its a pre-v6 ARM, even if the actual > hardware is not? Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1]. I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware... Hope that helps, Karel [1]: https://wiki.debian.org/ArmEabiPort [2]: https://wiki.debian.org/ArmHardFloatPort From austin at well-typed.com Mon Dec 8 15:35:26 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 8 Dec 2014 09:35:26 -0600 Subject: GHC Weekly News - 2014/12/08 Message-ID: Hi *, Once more, it's time for some news about GHC! This week's regularly scheduled programming (get it?) has brought you... - As of last week, GHC officially has no more `.lhs` files in its source repository; instead, they've all been converted to `.hs` and are now much more consistent with each other: https://www.haskell.org/pipermail/ghc-devs/2014-December/007552.html - Joachim Breitner has reported that the `linker_unload` test in GHC has been failing, but it's been surprisingly hard to reproduce reliably on our build machines! https://www.haskell.org/pipermail/ghc-devs/2014-December/007528.html - Moritz Angermann posted a proposal about the "Out of Process Template Haskell" project, started by the GHCJS developers. In short, they want to work out how to get Template Haskell working in a stage2 GHC for things like iOS or Browser devices: https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html - Lennart Augustsson has an inquiry about his program: why is it running out of memory? But the stranger thing: why does it only run out if heap profiling ''is not enabled''? Nobody has quite figured out, but if you're a guru, it may be a good chance to help out: https://www.haskell.org/pipermail/ghc-devs/2014-December/007582.html - Yuras Shumovich tracked down some nasty bugs in the typechecker's linter, causing several programs to fail to work when compiled by GHC. A quick diagnosis, but no fix has been merged quite yet: https://www.haskell.org/pipermail/ghc-devs/2014-December/007580.html - Richard Eisenberg wants feedback on a what he thinks is a design wart in the use of `-XStandaloneDeriving`, and he's not only proposed a solution, but wants to know what people think; typechecking fans are surely puzzling away already: https://www.haskell.org/pipermail/ghc-devs/2014-December/007589.html - David Spies has run into an interesting situation: why does -O make his program **slower** instead of faster? Well, nobody has quite figured out why yet, but it's an interesting question - maybe on a lazy monday developer can help figure out: https://www.haskell.org/pipermail/ghc-devs/2014-December/thread.html - Richard E. has another thread on the list, this time about development work flows: what do we do about painful merges? https://www.haskell.org/pipermail/ghc-devs/2014-December/007586.html Closed tickets this week include: #9850, #9005, #9828, #9833, #9582, #8935, #9186, #9480, #9497, #7908, #4347, #3977, #3859, #3844, #3814, #3771, #3739, #2182, #9812, #4921, #7947, #9240, #5401, #3625, #3517, #9444, #9142, #3447, #8894, #3065, #3191, #2697, #2836, #5443, #7736, #2489, #2456, #2204, #9777, #9859, #9869, #9808 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Mon Dec 8 15:41:19 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 8 Dec 2014 10:41:19 -0500 Subject: ghc.haskell.org slow? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F8159@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3F8159@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: They seem fine to me, right now.... On Dec 8, 2014, at 10:23 AM, Simon Peyton Jones wrote: > Is it just me, or is access to ghc.haskell.org and git.haskell.org very slow? > > I guess it could be at my end; I don?t know how to tell. But git pull and Trac access takes tens of seconds, even minutes > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 8 15:44:41 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 08 Dec 2014 16:44:41 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <5485C51D.3000200@centrum.cz> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> <5485C51D.3000200@centrum.cz> Message-ID: <1418053481.1441.51.camel@joachim-breitner.de> Hi, Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: > On 12/ 8/14 03:49 PM, Joachim Breitner wrote: > > So what does that tell us? Maybe Peter can help us: Is it normal for a > > Debian system to pretend that its a pre-v6 ARM, even if the actual > > hardware is not? > > Sorry to get into this, but are you using EABI[1] port of HardFloat[2] > port? Wheezy claims to support[2], the release before this was[1]. I?m currently working on what Debian calls armel, so [1]. We?ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there > I'm not sure what you use so I'm asking, anyway, if you use[1], then > it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 > debian port in the past which was running happily on i686 but pretend to > be i386 to be compatible with all the supported hardware... Yes, that makes sense. In that case, the use of the slow spinlock implementation is correct, and GHC?s build system needs to be fixed to work in that situation, right? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From karel.gardas at centrum.cz Mon Dec 8 16:06:01 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 08 Dec 2014 17:06:01 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <1418053481.1441.51.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> <5485C51D.3000200@centrum.cz> <1418053481.1441.51.camel@joachim-breitner.de> Message-ID: <5485CC69.4080000@centrum.cz> On 12/ 8/14 04:44 PM, Joachim Breitner wrote: > Hi, > > > Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: >> On 12/ 8/14 03:49 PM, Joachim Breitner wrote: >>> So what does that tell us? Maybe Peter can help us: Is it normal for a >>> Debian system to pretend that its a pre-v6 ARM, even if the actual >>> hardware is not? >> >> Sorry to get into this, but are you using EABI[1] port of HardFloat[2] >> port? Wheezy claims to support[2], the release before this was[1]. > > > I?m currently working on what Debian calls armel, so [1]. We?ll also > have to get it working on armhf (which seems to be [2]). Maybe things > are different there Yes, but [2] is what Ubuntu is using and it was all right in the past at least modulo ghci/linker support which Ben was fixing. >> I'm not sure what you use so I'm asking, anyway, if you use[1], then >> it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 >> debian port in the past which was running happily on i686 but pretend to >> be i386 to be compatible with all the supported hardware... > > Yes, that makes sense. > > In that case, the use of the slow spinlock implementation is correct, > and GHC?s build system needs to be fixed to work in that situation, > right? Yes, probably, I've not followed whole thread of discussion unfortunately. BTW, IIRC this is configure/aclocal.m4 check what's the target ARM platrform capability, I'm a little bit surprised this is not working for you now. Also please make sure generated platform details are correct in settings file... Karel From bgamari.foss at gmail.com Mon Dec 8 16:07:29 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 08 Dec 2014 11:07:29 -0500 Subject: Status and future of the LLVM backend In-Reply-To: <1418046221.1441.31.camel@debian.org> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418046221.1441.31.camel@debian.org> Message-ID: <87y4qiazwe.fsf@gmail.com> Joachim Breitner writes: > Hi, > > > Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari: >> > Again Google finds me a bug, but this time one that has no fix >> > associated with it: >> > https://ghc.haskell.org/trac/ghc/ticket/8951 >> > >> > Ben, can you help me out here? >> > >> I've been unable to reproduce this issue in my environment. The build >> succeeded using your packaging on my Odroid XU running Debian Jessie. > > Weird. Can you try creating a sid chroot and building it in there? > > I managed to finish the build with this patch attached: > Great! > So what does that tell us? Maybe Peter can help us: Is it normal for a > Debian system to pretend that its a pre-v6 ARM, even if the actual > hardware is not? > Could you confirm that arm_HOST_ARCH_PRE_ARMv6 is actually defined in mk/config.h? If so we should try to figure out why. The architecture is determined by autoconf. Perhaps you could attach config.log? >> >> It seems that this is likely due to dh_autoreconf which overwrites all >> config.subs with /usr/share/misc/config.sub. It's totally unclear to me >> how the first build succeeded, however. >> >> Have you seen this in the past? > > Yes, likely a bug in dh_autoreconf that does not handle rebuilds well > (or a bug in how we use it). > Hmm, alright. Why exactly do we overwrite config.sub and config.guess? I guess we are trying to ensure that the build systems in libraries/* are generated by the system's autoconf (taking the place of `boot`)? Is there a reason we can't just use autoreconf as `boot` does? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at joachim-breitner.de Mon Dec 8 16:30:09 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 08 Dec 2014 17:30:09 +0100 Subject: Status and future of the LLVM backend In-Reply-To: <87y4qiazwe.fsf@gmail.com> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418046221.1441.31.camel@debian.org> <87y4qiazwe.fsf@gmail.com> Message-ID: <1418056209.1441.55.camel@joachim-breitner.de> Hi, Am Montag, den 08.12.2014, 11:07 -0500 schrieb Ben Gamari: > > So what does that tell us? Maybe Peter can help us: Is it normal for a > > Debian system to pretend that its a pre-v6 ARM, even if the actual > > hardware is not? > > > Could you confirm that arm_HOST_ARCH_PRE_ARMv6 is actually defined in > mk/config.h? If so we should try to figure out why. The architecture is > determined by autoconf. Perhaps you could attach config.log? Yes: /* ARM pre v6 */ #define arm_HOST_ARCH_PRE_ARMv6 1 /* ARM pre v7 */ #define arm_HOST_ARCH_PRE_ARMv7 1 I think we should continue under the hypothesis that this is correct, i.e. that packages built for Debian?s armel are expected to run on ARMv5 machines. config.log attached. > > Yes, likely a bug in dh_autoreconf that does not handle rebuilds well > > (or a bug in how we use it). > > > Hmm, alright. Why exactly do we overwrite config.sub and config.guess? > I guess we are trying to ensure that the build systems in libraries/* > are generated by the system's autoconf (taking the place of `boot`)? > Is there a reason we can't just use autoreconf as `boot` does? It?s recommended to take the system?s autoconf files, as sometimes the Debian porters adjust these files. The handling of that in debian/rules is currently a mess, and is clearly broken. But that?s Debian?s very own problem, don?t worry about that :-) Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: text/x-log Size: 198671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From bgamari.foss at gmail.com Mon Dec 8 16:43:33 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 08 Dec 2014 11:43:33 -0500 Subject: Status and future of the LLVM backend In-Reply-To: <1418053481.1441.51.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> <5485C51D.3000200@centrum.cz> <1418053481.1441.51.camel@joachim-breitner.de> Message-ID: <87vblmay8a.fsf@gmail.com> Joachim Breitner writes: > Hi, > > > Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: >> On 12/ 8/14 03:49 PM, Joachim Breitner wrote: >> > So what does that tell us? Maybe Peter can help us: Is it normal for a >> > Debian system to pretend that its a pre-v6 ARM, even if the actual >> > hardware is not? >> >> Sorry to get into this, but are you using EABI[1] port of HardFloat[2] >> port? Wheezy claims to support[2], the release before this was[1]. > > > I?m currently working on what Debian calls armel, so [1]. We?ll also > have to get it working on armhf (which seems to be [2]). Maybe things > are different there > Indeed I think Karel has identified the difference in that case. I'm on armhf. Thanks Karel! I didn't realize that armel supported such old hardware. >> I'm not sure what you use so I'm asking, anyway, if you use[1], then >> it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 >> debian port in the past which was running happily on i686 but pretend to >> be i386 to be compatible with all the supported hardware... > > Yes, that makes sense. > > In that case, the use of the slow spinlock implementation is correct, > and GHC?s build system needs to be fixed to work in that situation, > right? > Indeed. It seems that armel is indeed supposed to support down to ARMv5 for which we'll need the spinlock fallback. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Mon Dec 8 17:54:15 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 8 Dec 2014 18:54:15 +0100 Subject: ghc.haskell.org slow? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3F8159@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3F8159@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <201412081854.15710.jan.stolarek@p.lodz.pl> Works fine for me. Janek Dnia poniedzia?ek, 8 grudnia 2014, Simon Peyton Jones napisa?: > Is it just me, or is access to ghc.haskell.org and git.haskell.org very > slow? > > I guess it could be at my end; I don't know how to tell. But git pull and > Trac access takes tens of seconds, even minutes > > Simon From austin at well-typed.com Mon Dec 8 18:17:10 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 8 Dec 2014 12:17:10 -0600 Subject: ghc.haskell.org slow? In-Reply-To: <201412081854.15710.jan.stolarek@p.lodz.pl> References: <618BE556AADD624C9C918AA5D5911BEF3F3F8159@DB3PRD3001MB020.064d.mgd.msft.net> <201412081854.15710.jan.stolarek@p.lodz.pl> Message-ID: FWIW, Herbert and I managed to pin down part of this to Simon's machine; for some reason he's unable to contact the machine via IPv6 which his machine defaults to (neither I nor Herbert could reproduce this); in the mean time, IPv4 appears fine. On Mon, Dec 8, 2014 at 11:54 AM, Jan Stolarek wrote: > Works fine for me. > > Janek > > Dnia poniedzia?ek, 8 grudnia 2014, Simon Peyton Jones napisa?: >> Is it just me, or is access to ghc.haskell.org and git.haskell.org very >> slow? >> >> I guess it could be at my end; I don't know how to tell. But git pull and >> Trac access takes tens of seconds, even minutes >> >> Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From bgamari.foss at gmail.com Mon Dec 8 20:59:39 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 08 Dec 2014 15:59:39 -0500 Subject: Out of memory mystery In-Reply-To: References: Message-ID: <87h9x5c0xw.fsf@gmail.com> Lennart Augustsson writes: > I'm running the 32-bit Windows version of ghc-7.8.3. > > Here are two runs: > > $ RunMu +RTS -A64M -h -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main > Compiling afresh Strat.App.Abacus.Main > Compiled afresh Strat.App.Abacus.Main, 1302.84s > > $ RunMu +RTS -A64M -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main > Compiling afresh Strat.App.Abacus.Main > RunMu.exe: out of memory > > The binary is compiled without profiling, but in the first run I'm using > the -h flag to get the rudimentary heap profile. And with -h it works, but > without the flag it runs out of memory. > How does the produced profile look? How much memory do you expect this process to require? Can you get a backtrace of the crash? If you're lucky it will crash in RTS code, in which case the backtrace may be informative. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From greg at gregweber.info Tue Dec 9 00:35:36 2014 From: greg at gregweber.info (Greg Weber) Date: Mon, 8 Dec 2014 16:35:36 -0800 Subject: docker GHC image for hacking Message-ID: Friends, As someone who started hacking on GHC last month I wanted to tell you that there is to high an overhead to getting started and overall to contributing to GHC. One thing that can help is to make getting to the point of compiling GHC a much faster experience rather than starting off by dreading the process of installing dependencies. I created a docker image that has everything needed pre-installed. I do know that there are existing docker images for running the GHC compiler, but I am not aware of any designed for hacking on it. Please give it a try and let me know if it works for you. The beauty is that once you have GHC checked out, if you have docker installed you are a single command away from having a working GHC environment: docker run --rm -i -t -v `pwd`:/home/ghc gregweber/ghc-haskell-dev /bin/bash Once getting some feedback, I would like to document this on the wiki and recommend it for Linux users (definitely for anyone that is familiar with docker). Thank you, Greg Weber -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.seefried at gmail.com Tue Dec 9 00:45:00 2014 From: sean.seefried at gmail.com (Sean Seefried) Date: Tue, 9 Dec 2014 11:45:00 +1100 Subject: docker GHC image for hacking In-Reply-To: References: Message-ID: I came to a similar conclusion. I recently put together a Dockerfile that builds GHC 7.8.3 as an ARM cross compiler https://github.com/sseefried/docker-build-ghc-android I've also written a draft blog post about it. It might contain some inaccuracies but any feedback is welcome. (Please send to my email address.) http://lambdalog.seanseefried.com/drafts/docker-build-scripts.html Sean On 9 December 2014 at 11:35, Greg Weber wrote: > Friends, > > As someone who started hacking on GHC last month I wanted to tell you that > there is to high an overhead to getting started and overall to contributing > to GHC. > > One thing that can help is to make getting to the point of compiling GHC a > much faster experience rather than starting off by dreading the process of > installing dependencies. I created a docker image that has everything > needed pre-installed. I do know that there are existing docker images for > running the GHC compiler, but I am not aware of any designed for hacking on > it. > > Please give it a try and let me know if it works for you. The beauty is > that once you have GHC checked out, if you have docker installed you are a > single command away from having a working GHC environment: > > docker run --rm -i -t -v `pwd`:/home/ghc gregweber/ghc-haskell-dev > /bin/bash > > Once getting some feedback, I would like to document this on the wiki and > recommend it for Linux users (definitely for anyone that is familiar with > docker). > > > Thank you, > Greg Weber > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 9 10:06:00 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 09 Dec 2014 11:06:00 +0100 Subject: The GHC 7.8.4 debian package now builds on arm In-Reply-To: <87vblmay8a.fsf@gmail.com> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> <5485C51D.3000200@centrum.cz> <1418053481.1441.51.camel@joachim-breitner.de> <87vblmay8a.fsf@gmail.com> Message-ID: <1418119560.3339.29.camel@joachim-breitner.de> [Fixing the subject, it hasn?t been about LLVM for a while] Hi, with the help of Ben I managed to create a GHC 7.8.4-rc1 Debian package that builds on arm and armhf. I had to apply a few patches from GHC HEAD, which I hope can enter 7.8.4. (I?ve marked their tickets as "merge" in trac.) Additionally, I had to fix something related to the pre-ARMv6 spinlock implementation: https://phabricator.haskell.org/D564 Finally, I had to find a reliable way to make ghc (and only ghc!) pass the flags to gcc to make it use the gold linker, but I don?t know if my approach is sensible. See http://ghc.haskell.org/trac/ghc/ticket/9873 I have a patch that seems to work here: https://ghc.haskell.org/trac/ghc/attachment/ticket/9873/saner-linker-opt-handling.patch but I?d rather avoid using non-blessed patches in the Debian package. If using the gold linker is a requirement on armel, maybe that should also be handled in upstream? The patch is rather simple: Index: ghc-7.8.3.20141119/aclocal.m4 =================================================================== --- ghc-7.8.3.20141119.orig/aclocal.m4 2014-12-08 18:49:28.207171714 +0100 +++ ghc-7.8.3.20141119/aclocal.m4 2014-12-08 19:03:06.815522917 +0100 @@ -553,6 +553,10 @@ $3="$$3 -D_HPUX_SOURCE" $5="$$5 -D_HPUX_SOURCE" ;; + arm*) + # On arm, link using gold + $3="$$3 -fuse-ld=gold" + ;; esac # If gcc knows about the stack protector, turn it off. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Dec 9 13:27:40 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 9 Dec 2014 13:27:40 +0000 Subject: docker GHC image for hacking In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> Once getting some feedback, I would like to document this on the wiki and recommend it for Linux users (definitely for anyone that is familiar with docker). Sounds really helpful thanks Greg. Do make a GHC wiki page about it, with links Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Greg Weber Sent: 09 December 2014 00:36 To: ghc-devs at haskell.org Subject: docker GHC image for hacking Friends, As someone who started hacking on GHC last month I wanted to tell you that there is to high an overhead to getting started and overall to contributing to GHC. One thing that can help is to make getting to the point of compiling GHC a much faster experience rather than starting off by dreading the process of installing dependencies. I created a docker image that has everything needed pre-installed. I do know that there are existing docker images for running the GHC compiler, but I am not aware of any designed for hacking on it. Please give it a try and let me know if it works for you. The beauty is that once you have GHC checked out, if you have docker installed you are a single command away from having a working GHC environment: docker run --rm -i -t -v `pwd`:/home/ghc gregweber/ghc-haskell-dev /bin/bash Once getting some feedback, I would like to document this on the wiki and recommend it for Linux users (definitely for anyone that is familiar with docker). Thank you, Greg Weber -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Tue Dec 9 22:10:48 2014 From: greg at gregweber.info (Greg Weber) Date: Tue, 9 Dec 2014 14:10:48 -0800 Subject: help writing a test case Message-ID: https://phabricator.haskell.org/D518 Can someone give me guidance on how to write a test case? I am trying to write a test case for a new flag that generates a file (much like -ddump-to-file). I started by trying to cat the generated file to get it into the stdout/stderr +test('T8624', normal, run_command,+ ['echo $MAKE && $MAKE T8624 && cat T8624.th.hs']) But I get this error: cd . && echo $MAKE && $MAKE T8624 && cat T8624.th.hs T8624.run.stdout 2>T8624.run.stderrmakemake[1]: Entering directory '/home/ghc/testsuite/tests/th'cc T8624.o -o T8624/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start':(.text+0x20): undefined reference to `main'collect2: error: ld returned 1 exit status: recipe for target 'T8624' failedmake[1]: *** [T8624] Error 1make[1]: Leaving directory '/home/ghc/testsuite/tests/th'Wrong exit code (expected 0 , actual 2 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Tue Dec 9 22:47:01 2014 From: greg at gregweber.info (Greg Weber) Date: Tue, 9 Dec 2014 14:47:01 -0800 Subject: docker GHC image for hacking In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I added documentation to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and linked from https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX On Tue, Dec 9, 2014 at 5:27 AM, Simon Peyton Jones wrote: > Once getting some feedback, I would like to document this on the wiki > and recommend it for Linux users (definitely for anyone that is familiar > with docker). > > > > Sounds really helpful thanks Greg. Do make a GHC wiki page about it, with > links > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Greg > Weber > *Sent:* 09 December 2014 00:36 > *To:* ghc-devs at haskell.org > *Subject:* docker GHC image for hacking > > > > Friends, > > > > As someone who started hacking on GHC last month I wanted to tell you that > there is to high an overhead to getting started and overall to contributing > to GHC. > > > > One thing that can help is to make getting to the point of compiling GHC a > much faster experience rather than starting off by dreading the process of > installing dependencies. I created a docker image that has everything > needed pre-installed. I do know that there are existing docker images for > running the GHC compiler, but I am not aware of any designed for hacking on > it. > > > > Please give it a try and let me know if it works for you. The beauty is > that once you have GHC checked out, if you have docker installed you are a > single command away from having a working GHC environment: > > > > docker run --rm -i -t -v `pwd`:/home/ghc gregweber/ghc-haskell-dev > /bin/bash > > > > Once getting some feedback, I would like to document this on the wiki and > recommend it for Linux users (definitely for anyone that is familiar with > docker). > > > > > > Thank you, > > Greg Weber > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at cse.unsw.edu.au Wed Dec 10 00:07:27 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 10 Dec 2014 11:07:27 +1100 Subject: docker GHC image for hacking In-Reply-To: References: Message-ID: Sean, That?s an interesting approach. Now, if I could only convince Xcode to use Docker in that way? Manuel > Sean Seefried : > > I came to a similar conclusion. I recently put together a Dockerfile that builds GHC 7.8.3 as an ARM cross compiler > > https://github.com/sseefried/docker-build-ghc-android > > I've also written a draft blog post about it. It might contain some inaccuracies but any feedback is welcome. (Please send to my email address.) > > http://lambdalog.seanseefried.com/drafts/docker-build-scripts.html > > Sean > > On 9 December 2014 at 11:35, Greg Weber > wrote: > Friends, > > As someone who started hacking on GHC last month I wanted to tell you that there is to high an overhead to getting started and overall to contributing to GHC. > > One thing that can help is to make getting to the point of compiling GHC a much faster experience rather than starting off by dreading the process of installing dependencies. I created a docker image that has everything needed pre-installed. I do know that there are existing docker images for running the GHC compiler, but I am not aware of any designed for hacking on it. > > Please give it a try and let me know if it works for you. The beauty is that once you have GHC checked out, if you have docker installed you are a single command away from having a working GHC environment: > > docker run --rm -i -t -v `pwd`:/home/ghc gregweber/ghc-haskell-dev /bin/bash > > Once getting some feedback, I would like to document this on the wiki and recommend it for Linux users (definitely for anyone that is familiar with docker). > > > Thank you, > Greg Weber > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Dec 10 11:06:03 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 10 Dec 2014 12:06:03 +0100 Subject: docker GHC image for hacking In-Reply-To: (Greg Weber's message of "Tue, 9 Dec 2014 14:47:01 -0800") References: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87388n4vdw.fsf@gmail.com> On 2014-12-09 at 23:47:01 +0100, Greg Weber wrote: > I added documentation to > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and linked > from https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX Btw, you write > This way you can still hack on GHC with Emacs, etc, but you are just > building from the docker container. ...does that mean you can't invoke `make` directly from within Emacs via `M-x haskell-compile`? I'm still trying to understand what you meant exactly by "too high an overhead to getting started" with GHC development (as I don't consider having to basically `apt-get install ...` (and possibly `cabal install ...` if your distribution doesn't have a recent alex/happy package) such a high overhead to get your system able to compile a cloned GHC source tree) So I'd like to identify what you consider an overhead to improve the underlying issues to make it easier for interested parties to get up and running with GHC development. Cheers, hvr From kolmodin at gmail.com Wed Dec 10 12:43:57 2014 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Wed, 10 Dec 2014 16:43:57 +0400 Subject: Bash completion in GHC 7.10 Message-ID: Hi everybody! TL;DL GHC 7.10 will have better bash completion, try it out! I'd like your help to verify the categorisation of DynFlags into ghc / ghci / shared or hidden flags. I've been working on improving the command line completion support in GHC 7.10. The main idea is that it should be more convenient to use GHC from the command line, without knowing all the flags by heart. You should be able to partly type a flag and then hit TAB twice to display the possible completions. For example; $ ghc -f If you'd like to try it out, here's what you need to do; $ cd ghc-head $ source completion/ghc.bash Et voil?! Your bash shell will now have these super powers! There's a README with details for a permanent setup. End users should ultimately not have to do anything to get this working. Linux distributions, and packages for other OSs are responsible for copying the required file to the right location. GHC had some basic support for command line completion even before my work, but now it also includes two significant changes compared to GHC 7.8; - "ghc" and "ghci" has different completions. - GHC 7.10 will ship and maintain the necessary bash components (and the scripts you contribute for other shells!). To support different completions for ghc and ghci, the DynFlags have been annotated with which mode the flags works. How this works has been documented under "Note [Supporting CLI completion]". Essentially all flags have been divided into four groups; - Flags only useful for ghc - Flags only useful for ghci - Flags useful from both ghc and ghci - Flags that should be invisible I've made this categorisation best I could, but it'd be nice to have another few pair of eyes glance through the flags. The separation of flags is well contained within the DynFlags module, please have a look! https://github.com/ghc/ghc/blob/master/compiler/main/DynFlags.hs The work was implemented in D337 , D532 and D536 and is tracked in trac #9259 . Regards, Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 10 13:16:01 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 10 Dec 2014 14:16:01 +0100 Subject: Bash completion in GHC 7.10 In-Reply-To: References: Message-ID: <1418217361.1440.22.camel@joachim-breitner.de> Hi, I guess you CCed me because of: Am Mittwoch, den 10.12.2014, 16:43 +0400 schrieb Lennart Kolmodin: > Linux distributions, and packages for other OSs are responsible for > copying the required file to the right location. I?ll include that file once we get around to packaging 7.10 (which isn?t too soon :-)) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gale at sefer.org Wed Dec 10 14:17:02 2014 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 10 Dec 2014 16:17:02 +0200 Subject: Linker change in GHC 7.8 leads to widespread issues In-Reply-To: References: Message-ID: Here's an update to our efforts to get a working build of text-icu on Windows 64 bits: I am working together with Kyra on this on the caf? list. It is becoming clear that GHC is unable to use standard DLLs on Windows 64 bits. That means FFI is really broken on that platform at the moment. By "unable to use standard DLLs" I mean specifically this: When GHC creates an executable with FFI by linking against object files, the GHC runtime is unable to use the DLLs corresponding to the object files if those DLLs were created by standard Microsoft build tools and not MingW. It's not clear yet whether this incompatibility is due to a change in GHC, or a new incompatibility between MingW's binutils and Microsoft's native DLL tools. Currently I am trying create new ICU DLLs from the object files using binutils so that we can use text-icu. If successful, that will solve our particular problem in the short term. But it won't solve the problem of FFI on Windows 64 bits in general. Here is the bug report I submitted for text-icu, with a simple way to reproduce the problem: https://github.com/bos/text-icu/issues/12 Shall I report that as a GHC bug as well? Thanks, Yitz From greg at gregweber.info Wed Dec 10 14:31:37 2014 From: greg at gregweber.info (Greg Weber) Date: Wed, 10 Dec 2014 06:31:37 -0800 Subject: docker GHC image for hacking In-Reply-To: <87388n4vdw.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> <87388n4vdw.fsf@gmail.com> Message-ID: On Wed, Dec 10, 2014 at 3:06 AM, Herbert Valerio Riedel wrote: > On 2014-12-09 at 23:47:01 +0100, Greg Weber wrote: > > I added documentation to > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and > linked > > from https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX > > Btw, you write > > > This way you can still hack on GHC with Emacs, etc, but you are just > > building from the docker container. > > ...does that mean you can't invoke `make` directly from within Emacs via > `M-x haskell-compile`? > The build needs to happen from the docker container. So you would need to modify your make command to run the container. docker run `pwd`:/home/ghc gregweber/ghc-haskell-dev make > > I'm still trying to understand what you meant exactly by "too high an > overhead to getting started" with GHC development (as I don't consider > having to basically `apt-get install ...` (and possibly `cabal install > ...` if your distribution doesn't have a recent alex/happy package) such > a high overhead to get your system able to compile a cloned GHC source > tree) > Hacking on GHC for the first time is death by a thousand cuts. Any one part of the process is not that bad, but as a whole the process is very cumbersome for someone new. Running an apt-get line is not too bad if it actually works. The apt-get instructions on the wiki did not list all of the development dependencies (it may now since I updated the documentation). It also doesn't mention arc (that is on a different page and a more manual installation). As a casual contributor though, my first thought is to question whether I want to install more dependencies. They will clutter my system since I won't remember to remove them later and they could end up conflicting with another project. Using a sandbox removes this hesitation. Again, this is just the first step to using GHC, by itself it is not that bad, but there is much more to the process for a newcomer. > So I'd like to identify what you consider an overhead to improve the > underlying issues to make it easier for interested parties to get up and > running with GHC development. > > Cheers, > hvr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Wed Dec 10 15:25:37 2014 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Wed, 10 Dec 2014 16:25:37 +0100 Subject: docker GHC image for hacking In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> <87388n4vdw.fsf@gmail.com> Message-ID: Hello, > Hacking on GHC for the first time is death by a thousand cuts. > Any one part of the process is not that bad, but as a whole the process is > very cumbersome for someone new. > With the docker image, would it be possible to distribute pre-built versions of the GHC source tarball? Maybe phabricator could do this? The biggest overhead for me always is that compiling the source the first time takes something like 2 hours (even without optimizations) on my machine. If there was a pre-built version, I could just change one file and only recompile what I changed. -- Benno -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Wed Dec 10 15:47:31 2014 From: greg at gregweber.info (Greg Weber) Date: Wed, 10 Dec 2014 07:47:31 -0800 Subject: docker GHC image for hacking In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> <87388n4vdw.fsf@gmail.com> Message-ID: The image I created is designed to mount your source code into the image. You could certainly stick the source code in the image. do a make, and then distribute that docker image. The problem is now: how do you modify files with Emacs? Before it was easy: the source code is mounted from your file system, so you just edit it like you normally would. There may be solutions here, particularly if everyone is comfortable with using the same few editors. I did put vim into this docker image to have something to edit commit messages with when using arc (although it is probably a better workflow to use arc from the host). Another problem with this approach of course is that you have to download all the binaries that were built (you don't have to re-download anything else), which will be slow for some. On Wed, Dec 10, 2014 at 7:25 AM, Benno F?nfst?ck < benno.fuenfstueck at gmail.com> wrote: > Hello, > > >> Hacking on GHC for the first time is death by a thousand cuts. > > >> Any one part of the process is not that bad, but as a whole the process >> is very cumbersome for someone new. >> > > With the docker image, would it be possible to distribute pre-built > versions of the GHC source tarball? Maybe phabricator could do this? The > biggest overhead for me always is that compiling the source the first time > takes something like 2 hours (even without optimizations) on my machine. If > there was a pre-built version, I could just change one file and only > recompile what I changed. > > -- > Benno > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From creichert07 at gmail.com Wed Dec 10 16:07:30 2014 From: creichert07 at gmail.com (Christopher Reichert) Date: Wed, 10 Dec 2014 10:07:30 -0600 Subject: docker GHC image for hacking In-Reply-To: <87388n4vdw.fsf@gmail.com> (Herbert Valerio Riedel's message of "Wed, 10 Dec 2014 12:06:03 +0100") References: <618BE556AADD624C9C918AA5D5911BEF3F3FB411@DB3PRD3001MB020.064d.mgd.msft.net> <87388n4vdw.fsf@gmail.com> Message-ID: <54886fc0.214cb60a.71b9.ffffa1ee@mx.google.com> On Wed, Dec 10 2014, Herbert Valerio Riedel wrote: > On 2014-12-09 at 23:47:01 +0100, Greg Weber wrote: >> I added documentation to >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and linked >> from https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX > > Btw, you write > >> This way you can still hack on GHC with Emacs, etc, but you are just >> building from the docker container. > > ...does that mean you can't invoke `make` directly from within Emacs via > `M-x haskell-compile`? > I'm confused by this. Is it possible to compile ghc with haskell-compile (e.g. cabal build)? Or did you simply mean 'compile (e.g. `make` as you said). When I use haskell-compile I get errors[0] whereas make builds cleanly. For what it's worth, I usually have a very easy time setting up and building ghc. Navigating and testing the code is a bit more difficult for me. The tricky part was remembering to update my build.mk to compile stage 2 only after the initial make. Regards, [0] - Module `Packages` does not export `pprPackages`... -- Christopher Reichert irc: creichert gpg: C81D 18C8 862A 3618 1376 FFA5 6BFC A992 9955 929B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From simonpj at microsoft.com Wed Dec 10 17:49:09 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 10 Dec 2014 17:49:09 +0000 Subject: -O/-O2 causes program to run too slow In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3FCC7F@DB3PRD3001MB020.064d.mgd.msft.net> Just to check, when you say that ?I found it was an instance of?? do you mean ?I compiled with ?fno-state-hack as the only change, and it got faster again?? Otherwise how would you know this was the cause? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Spies Sent: 07 December 2014 19:44 To: ghc-devs at haskell.org Subject: Re: -O/-O2 causes program to run too slow Ok, so I found that it was an instance of this: https://ghc.haskell.org/trac/ghc/ticket/1168 and I read through this whole thread: https://www.haskell.org/pipermail/glasgow-haskell-users/2008-February/014259.html I don't understand the state-hack optimization. It's clearly not safe and I'm not convinced that it actually is an optimization. In what circumstances does the state-hack identify a single-entry function that can't be identified as single-entry by some other (safe) method? On Sun, Dec 7, 2014 at 10:52 AM, David Spies > wrote: I have a program I wrote to submit for the Car Game problem on Kattis: https://open.kattis.com/problems/cargame but it runs over the 5-second time-limit I downloaded the test data and found that on GHC 7.8.3, if I switch from -O2 to -O0, it runs three times faster (almost certainly fast enough for Kattis to accept). Can someone tell me what's going on? Is this a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnspies at gmail.com Wed Dec 10 18:04:18 2014 From: dnspies at gmail.com (David Spies) Date: Wed, 10 Dec 2014 11:04:18 -0700 Subject: -O/-O2 causes program to run too slow In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3FCC7F@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3FCC7F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yes, it got faster when compiled with -fno-state-hack. It also got faster when I added a second (useless) reference to cf (changing the definition of doProbs to cf `seq` replicateM_ m doProb) Also, when profiling, the number of entries into findChain decreased significantly after adding -fno-state-hack On Wed, Dec 10, 2014 at 10:49 AM, Simon Peyton Jones wrote: > Just to check, when you say that ?I found it was an instance of?? do you > mean ?I compiled with ?fno-state-hack as the only change, and it got faster > again?? Otherwise how would you know this was the cause? > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *David > Spies > *Sent:* 07 December 2014 19:44 > *To:* ghc-devs at haskell.org > *Subject:* Re: -O/-O2 causes program to run too slow > > > > Ok, so I found that it was an instance of this: > https://ghc.haskell.org/trac/ghc/ticket/1168 > > and I read through this whole thread: > https://www.haskell.org/pipermail/glasgow-haskell-users/2008-February/014259.html > > I don't understand the state-hack optimization. It's clearly not safe and > I'm not convinced that it actually is an optimization. In what > circumstances does the state-hack identify a single-entry function that > can't be identified as single-entry by some other (safe) method? > > > > > > On Sun, Dec 7, 2014 at 10:52 AM, David Spies wrote: > > I have a program I wrote to submit for the Car Game problem on Kattis: > https://open.kattis.com/problems/cargame > > but it runs over the 5-second time-limit > > > > I downloaded the test data and found that on GHC 7.8.3, if I switch from > -O2 to -O0, it runs three times faster (almost certainly fast enough for > Kattis to accept). Can someone tell me what's going on? Is this a bug? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Dec 10 22:13:14 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 10 Dec 2014 22:13:14 +0000 Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles from constraint-solver improvements In-Reply-To: <20141210184740.98248.46507@phabricator.haskell.org> References: <20141210184740.98248.46507@phabricator.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3FCF76@DB3PRD3001MB020.064d.mgd.msft.net> This is a single stat failure in haddock.base; doesn't happen for me. Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 10 December 2014 18:48 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements | | Harbormaster failed to build B2572: rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC37b3646c9da4 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite From kolmodin at gmail.com Wed Dec 10 22:56:13 2014 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Thu, 11 Dec 2014 02:56:13 +0400 Subject: Bash completion in GHC 7.10 In-Reply-To: <1418217361.1440.22.camel@joachim-breitner.de> References: <1418217361.1440.22.camel@joachim-breitner.de> Message-ID: 2014-12-10 16:16 GMT+03:00 Joachim Breitner : > Hi, > > I guess you CCed me because of: > > Am Mittwoch, den 10.12.2014, 16:43 +0400 schrieb Lennart Kolmodin: > > Linux distributions, and packages for other OSs are responsible for > > copying the required file to the right location. > Yes, and also Sergei and Jens :) I?ll include that file once we get around to packaging 7.10 (which isn?t > too soon :-)) > That's great, thanks! Regards, Lennart > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Thu Dec 11 03:08:54 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 11 Dec 2014 03:08:54 +0000 Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles from constraint-solver improvements In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3FCF76@DB3PRD3001MB020.064d.mgd.msft.net> References: <20141210184740.98248.46507@phabricator.haskell.org> <618BE556AADD624C9C918AA5D5911BEF3F3FCF76@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54890AC6.2080905@fuuzetsu.co.uk> On 12/10/2014 10:13 PM, Simon Peyton Jones wrote: > This is a single stat failure in haddock.base; doesn't happen for me. > > Simon > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 10 December 2014 18:48 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles > | from constraint-solver improvements > | > | Harbormaster failed to build B2572: rGHC37b3646c9da4: Testsuite wibbles > | from constraint-solver improvements! > | > | USERS > | simonpj (Author) > | GHC - Testsuite (Auditor) > | > | COMMIT > | https://phabricator.haskell.org/rGHC37b3646c9da4 > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Testsuite > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > As I suggested yesterday on IRC, it may be worthwhile to make the check on Haddock numbers quite a bit looser considering it's not developed in-tree anymore and fails quite frequently due to other things. -- Mateusz K. From adam at well-typed.com Thu Dec 11 12:22:37 2014 From: adam at well-typed.com (Adam Gundry) Date: Thu, 11 Dec 2014 12:22:37 +0000 Subject: Serialising evidence generated by typechecker plugins Message-ID: <54898C8D.9010801@well-typed.com> Hi folks, I've just discovered tcIfaceCoAxiomRule, which is used when typechecking a coercion from an interface file. It turns out that CoAxiomRules are represented in interface files by their names, so tcIfaceCoAxiomRule looks up this name in a map containing all the built-in typeNatCoAxiomRules. Unfortunately, this lookup fails when a plugin has defined its own CoAxiomRule (as both uom-plugin and type-nat-solver do)! This means that if a module uses a plugin and exports some of the evidence generated via an unfolding, importing the module may result in a tcIfaceCoAxiomRule panic. At the moment, both plugins generate fake CoAxiomRules that can prove the equality of any types, so one workaround would be to expose this ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In the future, however, it would be nice if plugins could actually generate bona fide evidence based on their own axioms (e.g. the abelian group laws, for uom-plugin). We can't currently serialise CoAxiomRule directly, because it contains a function in the coaxrProves field. Could we support an alternative first-order representation that could be serialised? This probably wouldn't be as expressive, in particular it might not cover the built-in axioms that define type-level comparison functions and arithmetic operators, but it would allow plugins to axiomatize algebraic theories. Any thoughts? Adam P.S. I've updated https://phabricator.haskell.org/D553 with the TcPluginM changes we discussed. -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Thu Dec 11 14:34:52 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 11 Dec 2014 09:34:52 -0500 Subject: Serialising evidence generated by typechecker plugins In-Reply-To: <54898C8D.9010801@well-typed.com> References: <54898C8D.9010801@well-typed.com> Message-ID: <2DF27322-69D0-47A4-8F57-262014A64999@cis.upenn.edu> I've been following the plugins stuff at a small distance. I'vm very interested as a user, but don't have the bandwidth to think deeply as an implementor. With that caveat, I have a proposal: Suppose plugin P is responsible for producing CoAxiomRule R while compiling module M. I think it's reasonable to require any module N that imports M to have access to plugin P. (And, perhaps, to specify the use of P in GHC options while compiling N.) With this requirement, rule R could be serialized with its name, as is done now, but with an enhanced name that includes all the info about P, including versioning/checksum. Then, we can keep a nice higher-order representation of CoAxiomRules, and still get serialization. Or is there a basic assumption about plugins that I'm missing here? Richard On Dec 11, 2014, at 7:22 AM, Adam Gundry wrote: > Hi folks, > > I've just discovered tcIfaceCoAxiomRule, which is used when typechecking > a coercion from an interface file. It turns out that CoAxiomRules are > represented in interface files by their names, so tcIfaceCoAxiomRule > looks up this name in a map containing all the built-in typeNatCoAxiomRules. > > Unfortunately, this lookup fails when a plugin has defined its own > CoAxiomRule (as both uom-plugin and type-nat-solver do)! This means that > if a module uses a plugin and exports some of the evidence generated via > an unfolding, importing the module may result in a tcIfaceCoAxiomRule panic. > > At the moment, both plugins generate fake CoAxiomRules that can prove > the equality of any types, so one workaround would be to expose this > ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In > the future, however, it would be nice if plugins could actually generate > bona fide evidence based on their own axioms (e.g. the abelian group > laws, for uom-plugin). > > We can't currently serialise CoAxiomRule directly, because it contains a > function in the coaxrProves field. Could we support an alternative > first-order representation that could be serialised? This probably > wouldn't be as expressive, in particular it might not cover the built-in > axioms that define type-level comparison functions and arithmetic > operators, but it would allow plugins to axiomatize algebraic theories. > > Any thoughts? > > Adam > > P.S. I've updated https://phabricator.haskell.org/D553 with the > TcPluginM changes we discussed. > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Thu Dec 11 20:46:50 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 11 Dec 2014 20:46:50 +0000 Subject: Serialising evidence generated by typechecker plugins In-Reply-To: <54898C8D.9010801@well-typed.com> References: <54898C8D.9010801@well-typed.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3FE09C@DB3PRD3001MB020.064d.mgd.msft.net> Go ahead and make suggestions here. Since a CoAxiomRule embodies essentially arbitrary computation, it's hardly surprising that there's a fixed range of possibilities. I suppose that for extensibilty, any particular plugin could say "TypeNats:Rule1", "TypeNats:Rule" etc, and recognise that at the other end. We'd just need generic way to identify a plugin, plus an Int to say which axiom from that plugin. Anyway, it's all to play for. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Adam | Gundry | Sent: 11 December 2014 12:23 | To: Iavor Diatchki; Eric Seidel | Cc: ghc-devs at haskell.org | Subject: Serialising evidence generated by typechecker plugins | | Hi folks, | | I've just discovered tcIfaceCoAxiomRule, which is used when typechecking | a coercion from an interface file. It turns out that CoAxiomRules are | represented in interface files by their names, so tcIfaceCoAxiomRule | looks up this name in a map containing all the built-in | typeNatCoAxiomRules. | | Unfortunately, this lookup fails when a plugin has defined its own | CoAxiomRule (as both uom-plugin and type-nat-solver do)! This means that | if a module uses a plugin and exports some of the evidence generated via | an unfolding, importing the module may result in a tcIfaceCoAxiomRule | panic. | | At the moment, both plugins generate fake CoAxiomRules that can prove | the equality of any types, so one workaround would be to expose this | ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In | the future, however, it would be nice if plugins could actually generate | bona fide evidence based on their own axioms (e.g. the abelian group | laws, for uom-plugin). | | We can't currently serialise CoAxiomRule directly, because it contains a | function in the coaxrProves field. Could we support an alternative | first-order representation that could be serialised? This probably | wouldn't be as expressive, in particular it might not cover the built-in | axioms that define type-level comparison functions and arithmetic | operators, but it would allow plugins to axiomatize algebraic theories. | | Any thoughts? | | Adam | | P.S. I've updated https://phabricator.haskell.org/D553 with the | TcPluginM changes we discussed. | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From iavor.diatchki at gmail.com Thu Dec 11 22:44:38 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 11 Dec 2014 14:44:38 -0800 Subject: Serialising evidence generated by typechecker plugins In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3FE09C@DB3PRD3001MB020.064d.mgd.msft.net> References: <54898C8D.9010801@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF3F3FE09C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hello, the reason there's a function there is that the type-nats are using an infinite family of axioms (e..g, the axiom `AddDef` which can be applied to any two concrete number, so `AddDef 1 2 : (1 + 2) ~ 3`). Do you think it'd be possible to allow plugins to "register" a list of axioms, so that when we load interfaces, we lookup axioms not only in the built-in type-nats list, but also in the axioms provided by various plugins? -Iavor On Thu, Dec 11, 2014 at 12:46 PM, Simon Peyton Jones wrote: > > Go ahead and make suggestions here. Since a CoAxiomRule embodies > essentially arbitrary computation, it's hardly surprising that there's a > fixed range of possibilities. > > I suppose that for extensibilty, any particular plugin could say > "TypeNats:Rule1", "TypeNats:Rule" etc, and recognise that at the other > end. We'd just need generic way to identify a plugin, plus an Int to say > which axiom from that plugin. > > Anyway, it's all to play for. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Adam > | Gundry > | Sent: 11 December 2014 12:23 > | To: Iavor Diatchki; Eric Seidel > | Cc: ghc-devs at haskell.org > | Subject: Serialising evidence generated by typechecker plugins > | > | Hi folks, > | > | I've just discovered tcIfaceCoAxiomRule, which is used when typechecking > | a coercion from an interface file. It turns out that CoAxiomRules are > | represented in interface files by their names, so tcIfaceCoAxiomRule > | looks up this name in a map containing all the built-in > | typeNatCoAxiomRules. > | > | Unfortunately, this lookup fails when a plugin has defined its own > | CoAxiomRule (as both uom-plugin and type-nat-solver do)! This means that > | if a module uses a plugin and exports some of the evidence generated via > | an unfolding, importing the module may result in a tcIfaceCoAxiomRule > | panic. > | > | At the moment, both plugins generate fake CoAxiomRules that can prove > | the equality of any types, so one workaround would be to expose this > | ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In > | the future, however, it would be nice if plugins could actually generate > | bona fide evidence based on their own axioms (e.g. the abelian group > | laws, for uom-plugin). > | > | We can't currently serialise CoAxiomRule directly, because it contains a > | function in the coaxrProves field. Could we support an alternative > | first-order representation that could be serialised? This probably > | wouldn't be as expressive, in particular it might not cover the built-in > | axioms that define type-level comparison functions and arithmetic > | operators, but it would allow plugins to axiomatize algebraic theories. > | > | Any thoughts? > | > | Adam > | > | P.S. I've updated https://phabricator.haskell.org/D553 with the > | TcPluginM changes we discussed. > | > | > | -- > | Adam Gundry, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Dec 12 01:22:55 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 12 Dec 2014 02:22:55 +0100 Subject: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches Message-ID: I've uploaded release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches: https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz Please test, especially if one of your fixes are in this release. You can install both both lib and exe using: cabal install Changelogs: Cabal-1.18.1.5: e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org moved fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to 1.18.1.5 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. cabal-install-1.18.0.6: 79ccaa85bba7957344fb1dca06d84220eff9b73c Bump cabal-install version number to 1.18.0.6 97dc39636bd547782647cb792ceca6c60a7e5ab1 Merge branch '1.18' of https://github.com/snoyberg/cabal into 1.18 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make list fields work like Flags. 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config file #1884 Cabal-1.20.0.3 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number to 1.20.0.4 813ce2fc23da81b7bf07418a28258a962c44713e Bump Cabal version number to 1.20.0.3 cee305209129480f28190ee7026076962ba9ca97 The download dir on haskell.org moved b172747adec9ec8d57d8215e9d1cabb448aa6036 Build C sources with -fPIC when GHC is using dynamic libraries. 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert 97c6a72984931f4ccf628736024d3459a033af6c. 343257e96fab526da27d143b653433f45c6c1401 s/2.15/2.14.4/ cabal-install-1.20.0.4 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number to 1.20.0.4 caf257cd96e766b293943bbac07d766ec2f552dd Self-constraint not included in frozen constraints b19175519de6fc40683527c1104ce2a513a03612 Merge branch '1.20' of https://github.com/snoyberg/cabal into 1.20 1c0d8aafbe42921baa56fc36383f34763f69d327 Revert "Remove redundant network constraint" 58517f76cb2ccb33c007da596ede265f1192d3b8 Remove redundant network constraint a747778c25bd339fed9c9a7c77eb3adbf0f162e0 Support for network-2.6 5fcf3d994e5c5a0f101ac04e092a8beedadcdc8d SavedConfig Monoid instance: make list fields work like Flags. 13f9051d34463037569becf6d3f736a8d8a4570e cabal update: use sandbox config file #1884 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert 97c6a72984931f4ccf628736024d3459a033af6c. aa0a6979f3223387aae830cf1d21b2c21978d767 Read installed package info file as UTF-8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Dec 12 01:25:42 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 12 Dec 2014 02:25:42 +0100 Subject: Including Cabal-1.18.1.5 in GHC 7.8.4 Message-ID: I'm going to make a bugfix release on the Cabal 1.18 branch the next few days. The release candidate is already out. Here are the commits: e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org moved fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to 1.18.1.5 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. The only one of interest is that we now pass -fPIC when needed. Should we include this bugfix release in the GHC release? It's quite difficult for some users to upgrade from the Cabal version that ships with GHC so included the newest one makes sense. P.S. I'm looking to make a 1.22 release soon as well, for inclusion in GHC 7.10. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Dec 12 01:55:46 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 12 Dec 2014 02:55:46 +0100 Subject: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches In-Reply-To: References: Message-ID: Apparently this no longer works: cabal install http://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz http://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz Some change on the web server side means that the web server tries to redirect to an https page, even though cabal-install doesn't support it. On Fri, Dec 12, 2014 at 2:22 AM, Johan Tibell wrote: > I've uploaded release candidates for Cabal/cabal-install patch releases on > the 1.18 and 1.20 branches: > > https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz > > https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz > > https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz > > https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz > > Please test, especially if one of your fixes are in this release. You can > install both both lib and exe using: cabal install > > > Changelogs: > > Cabal-1.18.1.5: > e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org > moved > fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to > 1.18.1.5 > 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when > GHC is using dynamic libraries. > > cabal-install-1.18.0.6: > 79ccaa85bba7957344fb1dca06d84220eff9b73c Bump cabal-install version number > to 1.18.0.6 > 97dc39636bd547782647cb792ceca6c60a7e5ab1 Merge branch '1.18' of > https://github.com/snoyberg/cabal into 1.18 > 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6 > 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make > list fields work like Flags. > 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config > file #1884 > > Cabal-1.20.0.3 > 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number > to 1.20.0.4 > 813ce2fc23da81b7bf07418a28258a962c44713e Bump Cabal version number to > 1.20.0.3 > cee305209129480f28190ee7026076962ba9ca97 The download dir on haskell.org > moved > b172747adec9ec8d57d8215e9d1cabb448aa6036 Build C sources with -fPIC when > GHC is using dynamic libraries. > 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert > 97c6a72984931f4ccf628736024d3459a033af6c. > 343257e96fab526da27d143b653433f45c6c1401 s/2.15/2.14.4/ > > cabal-install-1.20.0.4 > 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number > to 1.20.0.4 > caf257cd96e766b293943bbac07d766ec2f552dd Self-constraint not included in > frozen constraints > b19175519de6fc40683527c1104ce2a513a03612 Merge branch '1.20' of > https://github.com/snoyberg/cabal into 1.20 > 1c0d8aafbe42921baa56fc36383f34763f69d327 Revert "Remove redundant network > constraint" > 58517f76cb2ccb33c007da596ede265f1192d3b8 Remove redundant network > constraint > a747778c25bd339fed9c9a7c77eb3adbf0f162e0 Support for network-2.6 > 5fcf3d994e5c5a0f101ac04e092a8beedadcdc8d SavedConfig Monoid instance: make > list fields work like Flags. > 13f9051d34463037569becf6d3f736a8d8a4570e cabal update: use sandbox config > file #1884 > 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert > 97c6a72984931f4ccf628736024d3459a033af6c. > aa0a6979f3223387aae830cf1d21b2c21978d767 Read installed package info file > as UTF-8 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Dec 12 08:30:27 2014 From: adam at well-typed.com (Adam Gundry) Date: Fri, 12 Dec 2014 08:30:27 +0000 Subject: Serialising evidence generated by typechecker plugins In-Reply-To: References: <54898C8D.9010801@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF3F3FE09C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <548AA7A3.30408@well-typed.com> I did vaguely wonder about doing something like this, but was worried about the complexity. Since you all seem keen, though, I'll have a go and see if I can make it work. I'd imagine using the (plugin module name, axiom name) pair to identify the axiom, and adding a new field to plugins that implements coaxrProves. Re Richard's point: > Suppose plugin P is responsible for producing CoAxiomRule R while > compiling module M. I think it's reasonable to require any module N > that imports M to have access to plugin P. (And, perhaps, to specify > the use of P in GHC options while compiling N.) I agree with N requiring access to P, as a transitive dependency, but I'd rather not have to specify P up front when compiling N. One library's use of a plugin shouldn't force it on all its users! Thanks, Adam On 11/12/14 22:44, Iavor Diatchki wrote: > Hello, > > the reason there's a function there is that the type-nats are using an > infinite family of axioms (e..g, the axiom `AddDef` which can be applied > to any two concrete number, so `AddDef 1 2 : (1 + 2) ~ 3`). > > Do you think it'd be possible to allow plugins to "register" a list of > axioms, so that when we load interfaces, we lookup axioms not only in > the built-in type-nats list, but also in the axioms provided by various > plugins? > > -Iavor > > On Thu, Dec 11, 2014 at 12:46 PM, Simon Peyton Jones > > wrote: > > Go ahead and make suggestions here. Since a CoAxiomRule embodies > essentially arbitrary computation, it's hardly surprising that > there's a fixed range of possibilities. > > I suppose that for extensibilty, any particular plugin could say > "TypeNats:Rule1", "TypeNats:Rule" etc, and recognise that at the > other end. We'd just need generic way to identify a plugin, plus an > Int to say which axiom from that plugin. > > Anyway, it's all to play for. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org > ] On Behalf Of Adam > | Gundry > | Sent: 11 December 2014 12:23 > | To: Iavor Diatchki; Eric Seidel > | Cc: ghc-devs at haskell.org > | Subject: Serialising evidence generated by typechecker plugins > | > | Hi folks, > | > | I've just discovered tcIfaceCoAxiomRule, which is used when > typechecking > | a coercion from an interface file. It turns out that CoAxiomRules are > | represented in interface files by their names, so tcIfaceCoAxiomRule > | looks up this name in a map containing all the built-in > | typeNatCoAxiomRules. > | > | Unfortunately, this lookup fails when a plugin has defined its own > | CoAxiomRule (as both uom-plugin and type-nat-solver do)! This > means that > | if a module uses a plugin and exports some of the evidence > generated via > | an unfolding, importing the module may result in a tcIfaceCoAxiomRule > | panic. > | > | At the moment, both plugins generate fake CoAxiomRules that can prove > | the equality of any types, so one workaround would be to expose this > | ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In > | the future, however, it would be nice if plugins could actually > generate > | bona fide evidence based on their own axioms (e.g. the abelian group > | laws, for uom-plugin). > | > | We can't currently serialise CoAxiomRule directly, because it > contains a > | function in the coaxrProves field. Could we support an alternative > | first-order representation that could be serialised? This probably > | wouldn't be as expressive, in particular it might not cover the > built-in > | axioms that define type-level comparison functions and arithmetic > | operators, but it would allow plugins to axiomatize algebraic > theories. > | > | Any thoughts? > | > | Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Fri Dec 12 08:33:45 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 12 Dec 2014 08:33:45 +0000 Subject: Typechecker tests failures In-Reply-To: <1418017692.2602.2.camel@gmail.com> References: <1417881843.2684.1.camel@gmail.com> <1418017692.2602.2.camel@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3FE67E@DB3PRD3001MB020.064d.mgd.msft.net> Thanks. This was being tracked in Trac #9567, and I have finally gotten around to fixing it. Your proposed change is small, but it simply avoids the crash without fixing the cause. The cause was that contInputType was simply *wrong*. https://ghc.haskell.org/trac/ghc/ticket/9567 Fixed now! Simon | -----Original Message----- | From: Yuras Shumovich [mailto:shumovichy at gmail.com] | Sent: 08 December 2014 05:48 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org Devs | Subject: Re: Typechecker tests failures | | | Simon, | | I tracked T7891 and tc124 failure down to simplifier, namely | `simplExprF1` for `Case`. Core lint catches the bug (requires -O1 at | least), but without -dcore-lint compiler hangs in busy loop. I made it | work with simple patch: | | > diff --git a/compiler/simplCore/Simplify.hs | > b/compiler/simplCore/Simplify.hs index 7611f56..d396b60 100644 | > --- a/compiler/simplCore/Simplify.hs | > +++ b/compiler/simplCore/Simplify.hs | > @@ -950,8 +950,10 @@ simplExprF1 env expr@(Lam {}) cont | > zap b | isTyVar b = b | > | otherwise = zapLamIdInfo b | > | > -simplExprF1 env (Case scrut bndr _ alts) cont | > - = simplExprF env scrut (Select NoDup bndr alts env cont) | > +simplExprF1 env (Case scrut bndr alts_ty alts) cont | > + = do { expr <- simplExprC env scrut (Select NoDup bndr alts env | > + (mkBoringStop alts_ty)) | > + ; rebuild env expr cont } | > | > simplExprF1 env (Let (Rec pairs) body) cont | > = do { env' <- simplRecBndrs env (map fst pairs) | | (I have no idea what most of this code does, but I learned a lot while | investigating this issue :) ) | | The relevant commit is: | | > commit a0b2897ee406e24a05c41768a0fc2395442dfa06 | > Author: Simon Peyton Jones | > Date: Tue May 27 09:09:28 2014 +0100 | > | > Simple refactor of the case-of-case transform | > | > More modular, less code. No change in behaviour. | | The T7861 failed because additional lambda abstraction in Core. Not | sure whether it is important. | | Thanks, | Yuras | | On Sat, 2014-12-06 at 19:04 +0300, Yuras Shumovich wrote: | > Hello, | > | > I was working on #9605, and found a number of failed tests: | > | > Unexpected failures: | > should_compile T7891 [exit code non-0] (hpc,optasm,optllvm) | > should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) | > should_run T7861 [bad exit code] | > (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) | > | > They seem to be unrelated to my work, and they are skipped when | "fast" | > is enabled. | > | > T7891 and tc124 fail with Core Lint errors. | > | > Looks like Phabricator uses "fast" way to validate revisions, so the | > failures were not noticed. | > | > Thanks, | > Yuras | > | > | From adam at well-typed.com Fri Dec 12 08:50:51 2014 From: adam at well-typed.com (Adam Gundry) Date: Fri, 12 Dec 2014 08:50:51 +0000 Subject: Typechecker plugins and 7.10 Message-ID: <548AAC6B.9040700@well-typed.com> Hi Austin, devs, I'm not sure what stage the 7.10 branch split and RC have got to, but if possible I'd like to get Phab:D553 included (my special pleading is that it makes relatively small, self-contained changes that will make it slightly harder to shoot oneself in the foot when writing a plugin). I realise you have to say "no" at some point though! More generally, at Richard's suggestion I propose that (at least for 7.10) we explicitly make no guarantees about the stability of the TcPluginM API, and advertise that we may choose to make breaking changes between minor GHC releases. After all, this feature is highly experimental and tightly coupled to GHC itself. All the best, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Fri Dec 12 12:10:36 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 12 Dec 2014 13:10:36 +0100 Subject: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches In-Reply-To: <87wq5xo780.fsf@gmail.com> References: <87wq5xo780.fsf@gmail.com> Message-ID: Ben, Is this something that worked in cabal-install 1.18.0.5 and that stopped working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target a very few critical bugs. They are not attempts to backport all bugfixes from master. In 1.18 the critical fixes are: 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make list fields work like Flags. 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config file #1884 As for installing, after downloading the two tarballs to a temp dir this works for me: cabal install Cabal-1.18.1.5.tar.gz cabal-install-1.18.0.6.tar.gz -- Johan On Fri, Dec 12, 2014 at 4:52 AM, Ben Gamari wrote: > > Johan Tibell writes: > > > I've uploaded release candidates for Cabal/cabal-install patch releases > on > > the 1.18 and 1.20 branches: > > > > > https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz > > > https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz > > > > > https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz > > > https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz > > > > Please test, especially if one of your fixes are in this release. You can > > install both both lib and exe using: cabal install > > > > > First I'll look at Cabal-1.18.1.5 and cabal-install-1.18.0.6. > > Unfortunately there still seems to be trouble invoking cabal in a tree > previously used by a previous Cabal version. For instance, > > $ tar -zxf cabal-install-1.18.0.6.tar.gz > $ cd cabal-install-1.18.0.6 > $ cabal install > $ cabal install --enable-tests > Warning: The package list for 'hackage.haskell.org' is 71 days old. > Run 'cabal update' to get the latest list of available packages. > Resolving dependencies... > Configuring cabal-install-1.18.0.6... > Building cabal-install-1.18.0.6... > cabal: dist/package.conf.inplace: inappropriate type > Failed to install cabal-install-1.18.0.6 > cabal: Error: some packages failed to install: > cabal-install-1.18.0.6 failed during the building phase. The exception > was: > ExitFailure 1 > > I have noticed this problem in the past as well. Deleting dist/ resolves > the issue. I seem to recall some discussion where it was claimed this > was fixed although I could be wrong. This was reproducible on x86_64 > (building with GHC 7.8.3 and 7.6.3) and ARM. > > After this was resolved I encountered the following, > > $ cabal install --enable-tests > ... > > Preprocessing test suite 'unit-tests' for cabal-install-1.18.0.6... > > Distribution/Client/Targets.hs:100:8: > Could not find module `Network.URI' > It is a member of the hidden package `network-2.4.2.2'. > Perhaps you need to add `network' to the build-depends in your > .cabal file. > It is a member of the hidden package `network-uri-2.6.0.1'. > Perhaps you need to add `network-uri' to the build-depends in your > .cabal file. > Use -v to see a list of the files searched for. > Failed to install cabal-install-1.18.0.6 > cabal: Error: some packages failed to install: > > This is fixed in master. It seems you should probably cherry-pick > 2826c97d11a495085008c4bddf499fcfd05e0df2 onto the release branch. > > After this I was able to run the testsuite. cabal-install was fine; > Cabal failed with, > > TestSuiteExeV10/TestWithHpc: > : [Failed] > expected: 'setup build' should succeed > output: "/opt/exp/haskell-packages/Cabal-1.18.1.5/tests/Setup > configure --user -w /opt/exp/ghc/root-ghc-7.8/bin/ghc --enable-tests > --enable-library-coverage" in PackageTests/TestSuiteExeV10 > Setup: Option --enable-library-coverage is obsolete! Please use > --enable-coverage instead. > > ... > > BuildTestSuiteDetailedV09: > : [Failed] > build failed! > expected: False > but got: True > > I didn't investigate into the cause of these any further. > > I also used the new cabal executable to install Yesod has progressed > quite (on the ARM, even) far and shows no sign failure. > > I'll take a look at the 1.20 releases tomorrow. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Dec 12 12:46:55 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 12 Dec 2014 07:46:55 -0500 Subject: Serialising evidence generated by typechecker plugins In-Reply-To: <548AA7A3.30408@well-typed.com> References: <54898C8D.9010801@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF3F3FE09C@DB3PRD3001MB020.064d.mgd.msft.net> <548AA7A3.30408@well-typed.com> Message-ID: <918B79D6-02CE-4532-9870-525BA9E65CFA@cis.upenn.edu> On Dec 12, 2014, at 3:30 AM, Adam Gundry wrote: > I did vaguely wonder about doing something like this, but was worried > about the complexity. Since you all seem keen, though, I'll have a go > and see if I can make it work. I'd imagine using the (plugin module > name, axiom name) pair to identify the axiom, and adding a new field to > plugins that implements coaxrProves. > I don't think (plugin module name, axiom name) is quite enough. It's possible that the plugin was updated in the meantime, and that could lead to obscure errors. I would prefer (plugin module name, plugin checksum, axiom name), for some appropriate definition of (plugin checksum). Although, as I write this, I realize GHC must have a mechanism for dealing with updated dependencies, because this exact same issue can arise absent plugins. > Re Richard's point: > >> Suppose plugin P is responsible for producing CoAxiomRule R while >> compiling module M. I think it's reasonable to require any module N >> that imports M to have access to plugin P. (And, perhaps, to specify >> the use of P in GHC options while compiling N.) > > I agree with N requiring access to P, as a transitive dependency, but > I'd rather not have to specify P up front when compiling N. One > library's use of a plugin shouldn't force it on all its users! > It seems there are now two ways a module may use a plugin: 1) the module can require the plugin for its own code to typecheck, or 2) the module just depends on another module that uses the plugin. Are these specified differently? It sounds like you want (2) to impose no annotation burden on the user. I've argued in the past that, sometimes, (1) should also require only a small burden (perhaps -XTypecheckerPlugins). Say I am writing a module that depends on several libraries which use fancy types. I don't want to have to look up the names of all the plugins that help solve for the types that I'm using. Instead, I'm happy to tell GHC that it can do fancy, library-specified things and let it figure out what plugins to use. (I do think we should require a language extension here, or perhaps some other command-line flag that doesn't name the plugins used, so that plugins don't represent an unavoidable security hole.) Richard > Thanks, > > Adam > > > On 11/12/14 22:44, Iavor Diatchki wrote: >> Hello, >> >> the reason there's a function there is that the type-nats are using an >> infinite family of axioms (e..g, the axiom `AddDef` which can be applied >> to any two concrete number, so `AddDef 1 2 : (1 + 2) ~ 3`). >> >> Do you think it'd be possible to allow plugins to "register" a list of >> axioms, so that when we load interfaces, we lookup axioms not only in >> the built-in type-nats list, but also in the axioms provided by various >> plugins? >> >> -Iavor >> >> On Thu, Dec 11, 2014 at 12:46 PM, Simon Peyton Jones >> > wrote: >> >> Go ahead and make suggestions here. Since a CoAxiomRule embodies >> essentially arbitrary computation, it's hardly surprising that >> there's a fixed range of possibilities. >> >> I suppose that for extensibilty, any particular plugin could say >> "TypeNats:Rule1", "TypeNats:Rule" etc, and recognise that at the >> other end. We'd just need generic way to identify a plugin, plus an >> Int to say which axiom from that plugin. >> >> Anyway, it's all to play for. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org >> ] On Behalf Of Adam >> | Gundry >> | Sent: 11 December 2014 12:23 >> | To: Iavor Diatchki; Eric Seidel >> | Cc: ghc-devs at haskell.org >> | Subject: Serialising evidence generated by typechecker plugins >> | >> | Hi folks, >> | >> | I've just discovered tcIfaceCoAxiomRule, which is used when >> typechecking >> | a coercion from an interface file. It turns out that CoAxiomRules are >> | represented in interface files by their names, so tcIfaceCoAxiomRule >> | looks up this name in a map containing all the built-in >> | typeNatCoAxiomRules. >> | >> | Unfortunately, this lookup fails when a plugin has defined its own >> | CoAxiomRule (as both uom-plugin and type-nat-solver do)! This >> means that >> | if a module uses a plugin and exports some of the evidence >> generated via >> | an unfolding, importing the module may result in a tcIfaceCoAxiomRule >> | panic. >> | >> | At the moment, both plugins generate fake CoAxiomRules that can prove >> | the equality of any types, so one workaround would be to expose this >> | ability in the TcCoercion type (i.e. add the equivalent of UnivCo). In >> | the future, however, it would be nice if plugins could actually >> generate >> | bona fide evidence based on their own axioms (e.g. the abelian group >> | laws, for uom-plugin). >> | >> | We can't currently serialise CoAxiomRule directly, because it >> contains a >> | function in the coaxrProves field. Could we support an alternative >> | first-order representation that could be serialised? This probably >> | wouldn't be as expressive, in particular it might not cover the >> built-in >> | axioms that define type-level comparison functions and arithmetic >> | operators, but it would allow plugins to axiomatize algebraic >> theories. >> | >> | Any thoughts? >> | >> | Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Fri Dec 12 12:51:08 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 12 Dec 2014 07:51:08 -0500 Subject: Typechecker plugins and 7.10 In-Reply-To: <548AAC6B.9040700@well-typed.com> References: <548AAC6B.9040700@well-typed.com> Message-ID: As I'm referenced here, I'll speak up: yes, I think we should advertise that the plugin interface is purely a technology preview, and very subject to change. I'm sure that as users adopt this powerful new feature, they and we will discover ways that it could be improved, or perhaps ways that it can subvert GHC, or etc. In order to have a tighter feedback loop between devs and users, I think that updating this part of GHC between minor releases is appropriate, for the 7.10 cycle. Hopefully, a year from now, we'll be ready to stabilize and then offer a more concrete implementation for 7.12. Of course, I'm curious to hear others' opinions on this! Thanks, Richard On Dec 12, 2014, at 3:50 AM, Adam Gundry wrote: > Hi Austin, devs, > > I'm not sure what stage the 7.10 branch split and RC have got to, but if > possible I'd like to get Phab:D553 included (my special pleading is that > it makes relatively small, self-contained changes that will make it > slightly harder to shoot oneself in the foot when writing a plugin). I > realise you have to say "no" at some point though! > > More generally, at Richard's suggestion I propose that (at least for > 7.10) we explicitly make no guarantees about the stability of the > TcPluginM API, and advertise that we may choose to make breaking changes > between minor GHC releases. After all, this feature is highly > experimental and tightly coupled to GHC itself. > > All the best, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From ben at smart-cactus.org Fri Dec 12 13:52:22 2014 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 12 Dec 2014 08:52:22 -0500 Subject: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches In-Reply-To: References: <87wq5xo780.fsf@gmail.com> Message-ID: <878uidm0vd.fsf@gmail.com> Johan Tibell writes: > Ben, > > Is this something that worked in cabal-install 1.18.0.5 and that stopped > working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you > expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target > a very few critical bugs. They are not attempts to backport all bugfixes > from master. > Fair enough; ignore the first issue in that case. Nevertheless, given that the network-2.6 fix made it in I think it would be worth cherry-picking the network-uri fix as well so that the release can be properly tested. Things look pretty good to me otherwise. I'll test 1.20 next. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alan.zimm at gmail.com Fri Dec 12 14:22:09 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 12 Dec 2014 16:22:09 +0200 Subject: D538 and compiler performance spec Message-ID: For API annotations I am working in the details of RdrNames, which come in a bewildering variety of syntactic forms. My latest change causes perf/compiler to fail, with bytes allocated value is too high: Expected parsing001(normal) bytes allocated: 587079016 +/-5% Lower bound parsing001(normal) bytes allocated: 557725065 Upper bound parsing001(normal) bytes allocated: 616432967 Actual parsing001(normal) bytes allocated: 704940512 Deviation parsing001(normal) bytes allocated: 20.1 % I am now adding an `AnnVal` to every RdrName, to be able to separate it out from any decoration, such as surrounding backticks or parens. Is this a problem? The alternative would be to add a SourceText field to RdrName. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Fri Dec 12 17:14:14 2014 From: eric at seidel.io (Eric Seidel) Date: Fri, 12 Dec 2014 09:14:14 -0800 Subject: Typechecker plugins and 7.10 In-Reply-To: (Richard Eisenberg's message of "Fri, 12 Dec 2014 07:51:08 -0500") References: <548AAC6B.9040700@well-typed.com> Message-ID: I agree, marking type-checker plugins as experimental and subject to change makes perfect sense given how little experience we have writing them at the moment. Eric Richard Eisenberg writes: > As I'm referenced here, I'll speak up: yes, I think we should advertise that the > plugin interface is purely a technology preview, and very subject to change. I'm > sure that as users adopt this powerful new feature, they and we will discover > ways that it could be improved, or perhaps ways that it can subvert GHC, or > etc. In order to have a tighter feedback loop between devs and users, I think > that updating this part of GHC between minor releases is appropriate, for the > 7.10 cycle. Hopefully, a year from now, we'll be ready to stabilize and then > offer a more concrete implementation for 7.12. > > Of course, I'm curious to hear others' opinions on this! > > Thanks, > Richard > > On Dec 12, 2014, at 3:50 AM, Adam Gundry wrote: > >> Hi Austin, devs, >> >> I'm not sure what stage the 7.10 branch split and RC have got to, but if >> possible I'd like to get Phab:D553 included (my special pleading is that >> it makes relatively small, self-contained changes that will make it >> slightly harder to shoot oneself in the foot when writing a plugin). I >> realise you have to say "no" at some point though! >> >> More generally, at Richard's suggestion I propose that (at least for >> 7.10) we explicitly make no guarantees about the stability of the >> TcPluginM API, and advertise that we may choose to make breaking changes >> between minor GHC releases. After all, this feature is highly >> experimental and tightly coupled to GHC itself. >> >> All the best, >> >> Adam >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Fri Dec 12 21:03:26 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 12 Dec 2014 21:03:26 +0000 Subject: D538 and compiler performance spec In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3FF38E@DB3PRD3001MB020.064d.mgd.msft.net> I am now adding an `AnnVal` to every RdrName, to be able to separate it out from any decoration, such as surrounding backticks or parens. That seems like overkill to me. (a `op` b) is an HsOpApp, and must of course have backticks unless op is an operator like (a + b), in which case it doesn?t. The corner case is something like ((`op`) a b), which will parse as (HsApp (HsApp (HsVar op) (HsVar a)) (HsVar b)). But it would be silly for us to get bent out of shape because of such a vanishingly rare corner case. Instead, if you really want to reflect it faithfully, add a new constructor for ?parens around backticks?). Let?s only take these overheads when there is real reason to do so. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 12 December 2014 14:22 To: ghc-devs at haskell.org Subject: D538 and compiler performance spec For API annotations I am working in the details of RdrNames, which come in a bewildering variety of syntactic forms. My latest change causes perf/compiler to fail, with bytes allocated value is too high: Expected parsing001(normal) bytes allocated: 587079016 +/-5% Lower bound parsing001(normal) bytes allocated: 557725065 Upper bound parsing001(normal) bytes allocated: 616432967 Actual parsing001(normal) bytes allocated: 704940512 Deviation parsing001(normal) bytes allocated: 20.1 % I am now adding an `AnnVal` to every RdrName, to be able to separate it out from any decoration, such as surrounding backticks or parens. Is this a problem? The alternative would be to add a SourceText field to RdrName. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Dec 12 21:20:02 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 12 Dec 2014 23:20:02 +0200 Subject: D538 and compiler performance spec In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3FF38E@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F3FF38E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: The problem is round-tripping cases like this, which are valid ( /// ) :: Int -> Int -> Int a /// b = 3 baz :: Int -> Int -> Int a ` baz ` b = 4 There can be arbitrary spaces between the surrounding parens and the operator name, and between the backquotes and the identifier in the infix version. In each case we simply get a RdrName, which in turn is wrapped in HsVar or whatever. The D538 productions are of the form var :: { Located RdrName } : varid { $1 } | '(' varsym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } and tyvarop :: { Located RdrName } tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } So the location tracks the entire span, but we need annotations for the three individual parts. Note: I did not check how far close to the limit the performance was prior to this change, it may have been the last 1% to take it over. Alan On Fri, Dec 12, 2014 at 11:03 PM, Simon Peyton Jones wrote: > > I am now adding an `AnnVal` to every RdrName, to be able to separate it > out from any decoration, such as surrounding backticks or parens. > > > > That seems like overkill to me. (a `op` b) is an HsOpApp, and must of > course have backticks unless op is an operator like (a + b), in which case > it doesn?t. > > > > The corner case is something like ((`op`) a b), which will parse as (HsApp > (HsApp (HsVar op) (HsVar a)) (HsVar b)). But it would be silly for us to > get bent out of shape because of such a vanishingly rare corner case. > Instead, if you really want to reflect it faithfully, add a new constructor > for ?parens around backticks?). > > > > Let?s only take these overheads when there is real reason to do so. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 12 December 2014 14:22 > *To:* ghc-devs at haskell.org > *Subject:* D538 and compiler performance spec > > > > For API annotations I am working in the details of RdrNames, which come in > a bewildering variety of syntactic forms. > > My latest change causes perf/compiler to fail, with > > bytes allocated value is too high: > Expected parsing001(normal) bytes allocated: 587079016 +/-5% > Lower bound parsing001(normal) bytes allocated: 557725065 > Upper bound parsing001(normal) bytes allocated: 616432967 > Actual parsing001(normal) bytes allocated: 704940512 > Deviation parsing001(normal) bytes allocated: 20.1 % > > I am now adding an `AnnVal` to every RdrName, to be able to separate it > out from any decoration, such as surrounding backticks or parens. > > Is this a problem? The alternative would be to add a SourceText field to > RdrName. > > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Dec 12 21:30:06 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 12 Dec 2014 23:30:06 +0200 Subject: D538 and compiler performance spec In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3FF38E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On reflection, I can try to make it work with annotations just for those fairly rare cases where there are parens/backquotes, and use the location span otherwise. On Fri, Dec 12, 2014 at 11:20 PM, Alan & Kim Zimmerman wrote: > > The problem is round-tripping cases like this, which are valid > > ( /// ) :: Int -> Int -> Int > a /// b = 3 > > baz :: Int -> Int -> Int > a ` baz ` b = 4 > > There can be arbitrary spaces between the surrounding parens and the > operator name, and between the backquotes and the identifier in the infix > version. > > In each case we simply get a RdrName, which in turn is wrapped in HsVar or > whatever. > > The D538 productions are of the form > > var :: { Located RdrName } > : varid { $1 } > | '(' varsym ')' {% ams (sLL $1 $> (unLoc $2)) > [mo $1,mj AnnVal $2,mc $3] } > > and > > tyvarop :: { Located RdrName } > tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2)) > [mj AnnBackquote $1,mj AnnVal $2 > ,mj AnnBackquote $3] } > > So the location tracks the entire span, but we need annotations for the > three individual parts. > > Note: I did not check how far close to the limit the performance was prior > to this change, it may have been the last 1% to take it over. > > Alan > > > On Fri, Dec 12, 2014 at 11:03 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: >> >> I am now adding an `AnnVal` to every RdrName, to be able to separate >> it out from any decoration, such as surrounding backticks or parens. >> >> >> >> That seems like overkill to me. (a `op` b) is an HsOpApp, and must of >> course have backticks unless op is an operator like (a + b), in which case >> it doesn?t. >> >> >> >> The corner case is something like ((`op`) a b), which will parse as >> (HsApp (HsApp (HsVar op) (HsVar a)) (HsVar b)). But it would be silly for >> us to get bent out of shape because of such a vanishingly rare corner >> case. Instead, if you really want to reflect it faithfully, add a new >> constructor for ?parens around backticks?). >> >> >> >> Let?s only take these overheads when there is real reason to do so. >> >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan >> & Kim Zimmerman >> *Sent:* 12 December 2014 14:22 >> *To:* ghc-devs at haskell.org >> *Subject:* D538 and compiler performance spec >> >> >> >> For API annotations I am working in the details of RdrNames, which come >> in a bewildering variety of syntactic forms. >> >> My latest change causes perf/compiler to fail, with >> >> bytes allocated value is too high: >> Expected parsing001(normal) bytes allocated: 587079016 +/-5% >> Lower bound parsing001(normal) bytes allocated: 557725065 >> Upper bound parsing001(normal) bytes allocated: 616432967 >> Actual parsing001(normal) bytes allocated: 704940512 >> Deviation parsing001(normal) bytes allocated: 20.1 % >> >> I am now adding an `AnnVal` to every RdrName, to be able to separate it >> out from any decoration, such as surrounding backticks or parens. >> >> Is this a problem? The alternative would be to add a SourceText field to >> RdrName. >> >> Alan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Sat Dec 13 02:51:32 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 12 Dec 2014 21:51:32 -0500 Subject: performance regressions Message-ID: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> Hi devs, Phab has shown up some performance regressions in my recent commits. See https://phabricator.haskell.org/harbormaster/build/2607/. The failures except for haddock.base are new, and evidently my fault. They didn't show up on Travis. Will look into it shortly, but I doubt over the weekend. I don't think this should hold up the 7.10 fork, however. I have a suspicion as to what caused the problem -- the reimplementation of TcInteract.matchFam. That reimplementation was solely to reduce code repetition between TcInteract.matchFam and FamInstEnv.reduceTyFamApp_maybe. It can safely be rolled back -- just use the implementation of matchFam that existed before my commits. I'll look into this Monday at the latest, but if a remedy is needed sooner, try the technique above. Why would these failures show up on Phab but not on Travis? Sorry about the bother! Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnspies at gmail.com Sat Dec 13 09:06:52 2014 From: dnspies at gmail.com (David Spies) Date: Sat, 13 Dec 2014 02:06:52 -0700 Subject: Program runs out of memory using GHC 7.6.3 Message-ID: I have a program I submitted for a Kattis problem: https://open.kattis.com/problems/digicomp2 But I got memory limit exceeded. I downloaded the test data and ran the program on my own computer without problems. Eventually I found out that when compiling with GHC 7.6.3 (the version Kattis uses) rather than 7.8.3, this program runs out of memory. Can someone explain why it only works on the later compiler? Is there a workaround so that I can submit to Kattis? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.hs Type: text/x-haskell Size: 1870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: input_data.tar.gz Type: application/x-gzip Size: 144538 bytes Desc: not available URL: From mikolaj at well-typed.com Sat Dec 13 10:05:59 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Dec 2014 11:05:59 +0100 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: References: Message-ID: tt may be that GHC 7.8 optimizes the program better. Compile with -O0 and see if it runs out of memory, too. If so, you can just optimize the program by hand. I'd suggest making a heap profilie with -O0 or in GHC 7.6 and finding out where the memory goes. Of course, it's possible you've hit a compiler bug, but it makes sense not to start with that assumption. Have fun, Mikolaj On Sat, Dec 13, 2014 at 10:06 AM, David Spies wrote: > I have a program I submitted for a Kattis problem: > https://open.kattis.com/problems/digicomp2 > But I got memory limit exceeded. I downloaded the test data and ran the > program on my own computer without problems. Eventually I found out that > when compiling with GHC 7.6.3 (the version Kattis uses) rather than 7.8.3, > this program runs out of memory. > Can someone explain why it only works on the later compiler? Is there a > workaround so that I can submit to Kattis? > > Thanks, > David > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From mf at zerobuzz.net Sat Dec 13 10:06:10 2014 From: mf at zerobuzz.net (Matthias Fischmann) Date: Sat, 13 Dec 2014 11:06:10 +0100 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: References: Message-ID: <20141213100610.GJ20726@lig> Hi David, I don't think this is a ghc issue. I suspect you have too many unevaluated function calls lying around (this would cause the runtime to run out of *stack* as opposed to *heap*). Different versions of ghc perform different optimizations on your code, and 7.8 knows a way to fix it that 7.6 doesn't know. This is usually solved by adding strictness: Instead of letting the unevaluated function calls pile up, you force them (e.g. with `print` or `Control.DeepSeq.deepseq`). I would take a closer look at your makeCounts function: you call traverse the input list, and traverse the entire list (starting from each element) again in each round. Either you should find a way to iterate only once and accumulate all the data you need, or you should start optimizing there. hope this helps, cheers, matthias On Sat, Dec 13, 2014 at 02:06:52AM -0700, David Spies wrote: > Date: Sat, 13 Dec 2014 02:06:52 -0700 > From: David Spies > To: "ghc-devs at haskell.org" > Subject: Program runs out of memory using GHC 7.6.3 > > I have a program I submitted for a Kattis problem: > https://open.kattis.com/problems/digicomp2 > But I got memory limit exceeded. I downloaded the test data and ran the > program on my own computer without problems. Eventually I found out that > when compiling with GHC 7.6.3 (the version Kattis uses) rather than 7.8.3, > this program runs out of memory. > Can someone explain why it only works on the later compiler? Is there a > workaround so that I can submit to Kattis? > > Thanks, > David > module Main(main) where > > import Control.Monad > import Data.Array > import qualified Data.ByteString.Char8 as BS > import Data.Int > import Data.Maybe > > readAsInt :: BS.ByteString -> Int > readAsInt = fst . fromJust . BS.readInt > > readVert :: IO Vert > readVert = do > [s, sl, sr] <- liftM BS.words BS.getLine > return $ V (fromBS s) (readAsInt sl) (readAsInt sr) > > main::IO() > main = do > [n, m64] <- liftM (map read . words) getLine :: IO [Int64] > let m = fromIntegral m64 :: Int > verts <- replicateM m readVert > let vside = map getSide verts > let vpar = concat $ zipWith makeAssoc [1..] verts > let parArr = accumArray (flip (:)) [] (1, m) vpar > let counts = makeCounts n m $ elems parArr > let res = zipWith doFlips counts vside > putStrLn $ map toChar res > > doFlips :: Int64 -> Side -> Side > doFlips n > | odd n = flipSide > | otherwise = id > > makeCounts :: Int64 -> Int -> [[(Int, Round)]] -> [Int64] > makeCounts n m l = tail $ elems res > where > res = listArray (0, m) $ 0 : n : map makeCount (tail l) > makeCount :: [(Int, Round)] -> Int64 > makeCount = sum . map countFor > countFor :: (Int, Round) -> Int64 > countFor (i, Up) = ((res ! i) + 1) `quot` 2 > countFor (i, Down) = (res ! i) `quot` 2 > > fromBS :: BS.ByteString -> Side > fromBS = fromChar . BS.head > > fromChar :: Char -> Side > fromChar 'L' = L > fromChar 'R' = R > fromChar _ = error "Bad char" > > toChar :: Side -> Char > toChar L = 'L' > toChar R = 'R' > > makeAssoc :: Int -> Vert -> [(Int, (Int, Round))] > makeAssoc n (V L a b) = filtPos [(a, (n, Up)), (b, (n, Down))] > makeAssoc n (V R a b) = filtPos [(a, (n, Down)), (b, (n, Up))] > > filtPos :: [(Int, a)] -> [(Int, a)] > filtPos = filter ((> 0) . fst) > > data Vert = V !Side !Int !Int > > getSide :: Vert -> Side > getSide (V s _ _) = s > > data Side = L | R > > data Round = Up | Down > > flipSide :: Side -> Side > flipSide L = R > flipSide R = L > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Sat Dec 13 10:10:51 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 13 Dec 2014 12:10:51 +0200 Subject: D538 and compiler performance spec In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F3FF38E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Ok, I backed it out for all but the compound cases and the performance test once more passes, and I can round-trip compound RdrNames. On Fri, Dec 12, 2014 at 11:30 PM, Alan & Kim Zimmerman wrote: > > On reflection, I can try to make it work with annotations just for those > fairly rare cases where there are parens/backquotes, and use the location > span otherwise. > > On Fri, Dec 12, 2014 at 11:20 PM, Alan & Kim Zimmerman < > alan.zimm at gmail.com> wrote: >> >> The problem is round-tripping cases like this, which are valid >> >> ( /// ) :: Int -> Int -> Int >> a /// b = 3 >> >> baz :: Int -> Int -> Int >> a ` baz ` b = 4 >> >> There can be arbitrary spaces between the surrounding parens and the >> operator name, and between the backquotes and the identifier in the infix >> version. >> >> In each case we simply get a RdrName, which in turn is wrapped in HsVar >> or whatever. >> >> The D538 productions are of the form >> >> var :: { Located RdrName } >> : varid { $1 } >> | '(' varsym ')' {% ams (sLL $1 $> (unLoc $2)) >> [mo $1,mj AnnVal $2,mc $3] } >> >> and >> >> tyvarop :: { Located RdrName } >> tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2)) >> [mj AnnBackquote $1,mj AnnVal >> $2 >> ,mj AnnBackquote $3] } >> >> So the location tracks the entire span, but we need annotations for the >> three individual parts. >> >> Note: I did not check how far close to the limit the performance was >> prior to this change, it may have been the last 1% to take it over. >> >> Alan >> >> >> On Fri, Dec 12, 2014 at 11:03 PM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >>> >>> I am now adding an `AnnVal` to every RdrName, to be able to separate >>> it out from any decoration, such as surrounding backticks or parens. >>> >>> >>> >>> That seems like overkill to me. (a `op` b) is an HsOpApp, and must of >>> course have backticks unless op is an operator like (a + b), in which case >>> it doesn?t. >>> >>> >>> >>> The corner case is something like ((`op`) a b), which will parse as >>> (HsApp (HsApp (HsVar op) (HsVar a)) (HsVar b)). But it would be silly for >>> us to get bent out of shape because of such a vanishingly rare corner >>> case. Instead, if you really want to reflect it faithfully, add a new >>> constructor for ?parens around backticks?). >>> >>> >>> >>> Let?s only take these overheads when there is real reason to do so. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan >>> & Kim Zimmerman >>> *Sent:* 12 December 2014 14:22 >>> *To:* ghc-devs at haskell.org >>> *Subject:* D538 and compiler performance spec >>> >>> >>> >>> For API annotations I am working in the details of RdrNames, which come >>> in a bewildering variety of syntactic forms. >>> >>> My latest change causes perf/compiler to fail, with >>> >>> bytes allocated value is too high: >>> Expected parsing001(normal) bytes allocated: 587079016 +/-5% >>> Lower bound parsing001(normal) bytes allocated: 557725065 >>> Upper bound parsing001(normal) bytes allocated: 616432967 >>> Actual parsing001(normal) bytes allocated: 704940512 >>> Deviation parsing001(normal) bytes allocated: 20.1 % >>> >>> I am now adding an `AnnVal` to every RdrName, to be able to separate it >>> out from any decoration, such as surrounding backticks or parens. >>> >>> Is this a problem? The alternative would be to add a SourceText field to >>> RdrName. >>> >>> Alan >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.dominguez at tweag.io Sat Dec 13 11:55:38 2014 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Sat, 13 Dec 2014 09:55:38 -0200 Subject: Fwd: Garbage collection In-Reply-To: <546B63D9.6010600@mathematik.uni-marburg.de> References: <546B63D9.6010600@mathematik.uni-marburg.de> Message-ID: > So technically, your example might need to involve using g (and forceful GC at a certain point during execution) Good observation. > Maybe a stupid question, sorry: The RemoteTable generated using > template-haskell in CH without XStaticPointers would keep CAFs alive. So the > XStaticPointers extension does not entail using such a table? That's correct. The extension is a substitute for the remote table. In addition, it has the compiler do what remote tables demanded from the user: * adding functions to the remote table before they are looked up, * collecting the table pieces from the various modules into a global table. > Another question: Would it be sufficient to desugar "static g" to > g `seq` StaticPtr(StaticName "" "Main" "g") > instead of introducing a stable ptr and all that? This keeps g alive only while the expression is not evaluated to HNF. The solution I proposed is flawed as well, since it relies on the desugared static form being evaluated to HNF for the CAF to be referenced with a StablePtr. Anyway, after this much time we figured out how to implement the static pointer table. > Finally, there is a flag keepCAFs in the runtime which you can set to secure > the CAFs for the entire run. The parallel runtimes for Eden and GUM (as well > as my "packman" serialisation) do this. Good to know about that. Thank you, Facundo > AFter all, g is a CAF, so it is anyway "stable" in some sense, as long as it > is alive. > > However, I conjecture that this only fixes the one-node test, not the actual > use case (sending "static" stuff over the wire). > > Finally, there is a flag keepCAFs in the runtime which you can set to secure > the CAFs for the entire run. The parallel runtimes for Eden and GUM (as well > as my "packman" serialisation) do this. Facundo On Tue, Nov 18, 2014 at 1:20 PM, Jost Berthold wrote: > Hi Facundo, > > You are completely right, the CAF named "g" might be accessed at any time > during the program execution. Parallel Haskell systems with distributed heap > (and runtime-supported serialisation) need to keep all CAFS alive for this > reason. > > Some comments inline along your mail: > >> While working in the StaticPointers language extension [1], we >> found we have some unusual CAFs which can be accessed after some >> periods of time where there is no reference to them. >> >> For instance, the following program when compiled contains no >> reference to `g`. `g` is actually looked up at runtime in symbol >> tables via the call to `deRefStaticPtr`. >> g :: String >> g = "hello" >> >> main = >> deRefStaticPtr (static g) >>= putStrLn > > > The bad scenario is certainly one where CAF g (a static thunk) is evaluated > during execution (i.e. turned into an indirection into the heap), and then > garbage-collected, as it might not be referenced by any (runnable) thread. > This GC does not revert the indirection into a thunk. Why should it, there > are no references to it, right? ;-) > > So technically, your example might need to involve using g (and forceful GC > at a certain point during execution): > > main = putStrLn g >> performGC >> > deRefStaticPtr (static g) >>= putStrLn > >> >> Desugars to: >> >> g :: String >> g = "hello" >> >> main = > > putStrLn g >> performGC >> >> >> deRefStaticPtr (StaticPtr (StaticName "" "Main" "g")) >>= putStrLn > > > During performGC, there would be no reference to g from any thread's stack. > I am of course assuming that g is indeed a thunk, and not statically > evaluated to a string during compilation (I am unsure whether GHC would do > that). > >> In principle, there is nothing stopping the garbage collector from >> reclaiming the closure of `g` before it is dynamically looked up. > > > Maybe a stupid question, sorry: The RemoteTable generated using > template-haskell in CH without XStaticPointers would keep CAFs alive. So the > XStaticPointers extension does not entail using such a table? > >> We are considering using StablePtrs to preserve `g`. So the code >> desugars instead to: >> >> g :: String >> g = "hello" >> >> main = >> deRefStaticPtr (let x = StaticPtr (StaticName "" "Main" "g") >> in unsafePerformIO $ newStablePtr g >> return x >> ) >>= putStrLn >> > > Another question: Would it be sufficient to desugar "static g" to > g `seq` StaticPtr(StaticName "" "Main" "g") > instead of introducing a stable ptr and all that? > AFter all, g is a CAF, so it is anyway "stable" in some sense, as long as it > is alive. > > However, I conjecture that this only fixes the one-node test, not the actual > use case (sending "static" stuff over the wire). > > Finally, there is a flag keepCAFs in the runtime which you can set to secure > the CAFs for the entire run. The parallel runtimes for Eden and GUM (as well > as my "packman" serialisation) do this. > > Yes, obviously, this opens a memory leak. It would be nice to not "keep" but > "revert" the CAFs (ghci does that) but on a "by-need" basis when a simple GC > cannot reclaim enough space; this would plug the mem.leak. This requires a > modification to the GHC runtime system, and it is unclear _which_ CAFs to > prefer when starting to revert. But I think it would be a more generally > useful feature. > However, this discussion (runtime/GC features) leads us straight out of the > design goals of "-XStaticPointers", I guess... > > Best regards, > Jost > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Sat Dec 13 13:32:24 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 13 Dec 2014 14:32:24 +0100 Subject: performance regressions In-Reply-To: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> Message-ID: <1418477544.27954.1.camel@joachim-breitner.de> Hi, Am Freitag, den 12.12.2014, 21:51 -0500 schrieb Richard Eisenberg: > > Phab has shown up some performance regressions in my recent commits. > See https://phabricator.haskell.org/harbormaster/build/2607/. The > failures except for haddock.base are new, and evidently my fault. They > didn't show up on Travis. Will look into it shortly, but I doubt over > the weekend. ghcspeed also observes this: http://ghcspeed-nomeata.rhcloud.com/changes/?rev=7256213843b80d75a86f033be77516a62d56044a&exe=2&env=johan%27s%20buildbot Especially the T9872 benchmarks have a huge increase in allocations. But you seem to be aware of this, so that?s fine. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From eir at cis.upenn.edu Sat Dec 13 15:03:15 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 13 Dec 2014 10:03:15 -0500 Subject: performance regressions In-Reply-To: <1418477544.27954.1.camel@joachim-breitner.de> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> Message-ID: <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> I think I've fixed this. I've pushed the fix to wip/rae, and waiting for validation results before pushing to master. My hunch below was right -- it was the change to matchFam, which essentially evaluated type-level functions more strictly. I've now made it lazier again. I'd like to better understand the tradeoff here, and to see if there's a principled sweet spot. But that will happen in a few days. Expect a push to master soon. Again, sorry for the bother. Richard On Dec 13, 2014, at 8:32 AM, Joachim Breitner wrote: > Hi, > > > Am Freitag, den 12.12.2014, 21:51 -0500 schrieb Richard Eisenberg: >> >> Phab has shown up some performance regressions in my recent commits. >> See https://phabricator.haskell.org/harbormaster/build/2607/. The >> failures except for haddock.base are new, and evidently my fault. They >> didn't show up on Travis. Will look into it shortly, but I doubt over >> the weekend. > > > ghcspeed also observes this: > http://ghcspeed-nomeata.rhcloud.com/changes/?rev=7256213843b80d75a86f033be77516a62d56044a&exe=2&env=johan%27s%20buildbot > > Especially the T9872 benchmarks have a huge increase in allocations. But > you seem to be aware of this, so that?s fine. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From slyich at gmail.com Sat Dec 13 15:19:34 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Sat, 13 Dec 2014 15:19:34 +0000 Subject: more parser conflicts? In-Reply-To: <547EFB2E.7080306@gmail.com> References: <547EFB2E.7080306@gmail.com> Message-ID: <20141213151934.03e1582d@sf> On Wed, 03 Dec 2014 11:59:42 +0000 Simon Marlow wrote: > >> In unrelated work, I saw this scroll across when happy'ing the parser: > >> > >>> shift/reduce conflicts: 60 > >>> reduce/reduce conflicts: 16 > >> > >> These numbers seem quite a bit higher than what I last remember (which > >> is something like 48 and 1, not 60 and 16). Does anyone know why? 4 of reduce/reduce conflicts are result of exact rule copy: https://phabricator.haskell.org/D569 > reduce/reduce conflicts are bad, especially so since they're > undocumented. We don't know whether this introduced parser bugs or not. > Mike - could you look at this please? It was your commit that > introduced the new conflicts. Agreed. 11 more reduce/reduce (of left 12) came from single scary rule added in > commit bc2289e13d9586be087bd8136943dc35a0130c88 > ghc generates more user-friendly error messages exp10 :: { LHsExpr RdrName } ... | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text "parse error in let binding: missing required 'in'" } The other rules add shift/reduce conflicts as follows: -- parsing error messages go below here {- s/r:1 r/r:0 -} | '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1 $5) $ text "parse error in lambda: no expression after '->'" {- s/r:1 r/r:0 -} | '\\' {% parseErrorSDoc (getLoc $1) $ text "parse error: naked lambda expression '\'" } {- s/r:1 r/r:0 -} | 'let' binds 'in' {% parseErrorSDoc (combineLocs $1 $2) $ text "parse error in let binding: missing expression after 'in'" } {- s/r:0 r/r:11 -} | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text "parse error in let binding: missing required 'in'" } {- s/r:0 r/r:0 -} | 'let' {% parseErrorSDoc (getLoc $1) $ text "parse error: naked let binding" } {- s/r:1 r/r:0 -} | 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf (combineLocs $1 $5) "else clause empty" } {- s/r:2 r/r:0 -} | 'if' exp optSemi 'then' exp optSemi {% hintIf (combineLocs $1 $5) "missing required else clause" } {- s/r:1 r/r:0 -} | 'if' exp optSemi 'then' {% hintIf (combineLocs $1 $2) "then clause empty" } {- s/r:2 r/r:0 -} | 'if' exp optSemi {% hintIf (combineLocs $1 $2) "missing required then and else clauses" {- s/r:2 r/r:0 -} | 'if' {% hintIf (getLoc $1) "naked if statement" } {- s/r:0 r/r:0 -} | 'case' exp 'of' {% parseErrorSDoc (combineLocs $1 $2) $ text "parse error in case statement: missing list after '->'" } {- s/r:1 r/r:0 -} | 'case' exp {% parseErrorSDoc (combineLocs $1 $2) $ text "parse error in case statement: missing required 'of'" } {- s/r:1 r/r:0 -} | 'case' {% parseErrorSDoc (getLoc $1) $ text "parse error: naked case statement" } Shift/reduces look harmless (like MultiWayIf ambiguity) as they seem to resolve as shift correctly. -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From eir at cis.upenn.edu Sat Dec 13 15:55:40 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 13 Dec 2014 10:55:40 -0500 Subject: performance regressions In-Reply-To: <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> Message-ID: Fixed, hopefully! On Dec 13, 2014, at 10:03 AM, Richard Eisenberg wrote: > I think I've fixed this. I've pushed the fix to wip/rae, and waiting for validation results before pushing to master. > > My hunch below was right -- it was the change to matchFam, which essentially evaluated type-level functions more strictly. I've now made it lazier again. I'd like to better understand the tradeoff here, and to see if there's a principled sweet spot. But that will happen in a few days. > > Expect a push to master soon. > > Again, sorry for the bother. > > Richard > > On Dec 13, 2014, at 8:32 AM, Joachim Breitner wrote: > >> Hi, >> >> >> Am Freitag, den 12.12.2014, 21:51 -0500 schrieb Richard Eisenberg: >>> >>> Phab has shown up some performance regressions in my recent commits. >>> See https://phabricator.haskell.org/harbormaster/build/2607/. The >>> failures except for haddock.base are new, and evidently my fault. They >>> didn't show up on Travis. Will look into it shortly, but I doubt over >>> the weekend. >> >> >> ghcspeed also observes this: >> http://ghcspeed-nomeata.rhcloud.com/changes/?rev=7256213843b80d75a86f033be77516a62d56044a&exe=2&env=johan%27s%20buildbot >> >> Especially the T9872 benchmarks have a huge increase in allocations. But >> you seem to be aware of this, so that?s fine. >> >> Greetings, >> Joachim >> >> -- >> Joachim ?nomeata? Breitner >> mail at joachim-breitner.de ? http://www.joachim-breitner.de/ >> Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From carter.schonwald at gmail.com Sat Dec 13 19:53:38 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 13 Dec 2014 14:53:38 -0500 Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1 In-Reply-To: References: <87bnnu3ufg.fsf@gnu.org> Message-ID: Thomas and I have found some bugs in HPC on OSX, and we're in the midst of tracking those down, Those fixes should get into 7.8.4 and 7.10 both. Currently HPC on OSX is broken in pretty fundamental ways, and thats not ok! -Carter On Wed, Dec 3, 2014 at 5:53 PM, George Colpitts wrote: > > Would it be possible to get a RC for the Mac up at > https://downloads.haskell.org/~ghc/7.8.4-rc1/ ? > > Thanks > George > > > On Wed, Nov 26, 2014 at 10:31 AM, Herbert Valerio Riedel > wrote: > >> On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote: >> > 2014-11-25 20:46 GMT+01:00 Austin Seipp : >> >> We are pleased to announce the first release candidate for GHC 7.8.4: >> >> >> >> https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...] >> > >> > Would it be possible to get the RC on >> > https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could >> > easily test things on Travis CI. >> >> I'll put a 7.8.4rc .deb up soon (probably right after the GHC 7.10 >> branch has been created) >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Dec 13 20:34:24 2014 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 13 Dec 2014 15:34:24 -0500 Subject: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches In-Reply-To: <878uidm0vd.fsf@gmail.com> References: <87wq5xo780.fsf@gmail.com> <878uidm0vd.fsf@gmail.com> Message-ID: <878uibl25r.fsf@gmail.com> Ben Gamari writes: > Johan Tibell writes: > >> Ben, >> >> Is this something that worked in cabal-install 1.18.0.5 and that stopped >> working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you >> expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target >> a very few critical bugs. They are not attempts to backport all bugfixes >> from master. >> > Fair enough; ignore the first issue in that case. Nevertheless, given > that the network-2.6 fix made it in I think it would be worth > cherry-picking the network-uri fix as well so that the release can be > properly tested. > > Things look pretty good to me otherwise. I'll test 1.20 next. > 1.20 looks good to me. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dnspies at gmail.com Sat Dec 13 21:10:19 2014 From: dnspies at gmail.com (David Spies) Date: Sat, 13 Dec 2014 14:10:19 -0700 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: References: Message-ID: I tried all optimization levels of 7.6.3 and it runs out of memory I tried all optimization levels of 7.8.3 and it doesn't So it must be something the compiler does even without any optimization. On Sat, Dec 13, 2014 at 3:05 AM, Mikolaj Konarski wrote: > > tt may be that GHC 7.8 optimizes the program better. > Compile with -O0 and see if it runs out of memory, too. > If so, you can just optimize the program by hand. > I'd suggest making a heap profilie with -O0 or in GHC 7.6 > and finding out where the memory goes. > > Of course, it's possible you've hit a compiler bug, > but it makes sense not to start with that assumption. > > Have fun, > Mikolaj > > On Sat, Dec 13, 2014 at 10:06 AM, David Spies wrote: > > I have a program I submitted for a Kattis problem: > > https://open.kattis.com/problems/digicomp2 > > But I got memory limit exceeded. I downloaded the test data and ran the > > program on my own computer without problems. Eventually I found out that > > when compiling with GHC 7.6.3 (the version Kattis uses) rather than > 7.8.3, > > this program runs out of memory. > > Can someone explain why it only works on the later compiler? Is there a > > workaround so that I can submit to Kattis? > > > > Thanks, > > David > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnspies at gmail.com Sat Dec 13 21:10:25 2014 From: dnspies at gmail.com (David Spies) Date: Sat, 13 Dec 2014 14:10:25 -0700 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: <20141213100610.GJ20726@lig> References: <20141213100610.GJ20726@lig> Message-ID: I think there's some confusion about makeCounts's behavior. makeCount never traverses the same thing twice. Essentially, the worst-case size of the unevaluated thunks doesn't exceed the total size of the array of lists that was used to create them (and that array itself was created with accumArray which is strict). Nonetheless, I've tried adding strictness all over makeCounts and it reduces the memory usage a little bit, but it still fails a later input instance with OOM. It's not a significant reduction like in GHC 7.8.3 On Sat, Dec 13, 2014 at 3:06 AM, Matthias Fischmann wrote: > > > Hi David, > > I don't think this is a ghc issue. > > I suspect you have too many unevaluated function calls lying around > (this would cause the runtime to run out of *stack* as opposed to > *heap*). Different versions of ghc perform different optimizations on > your code, and 7.8 knows a way to fix it that 7.6 doesn't know. > > This is usually solved by adding strictness: Instead of letting the > unevaluated function calls pile up, you force them (e.g. with `print` > or `Control.DeepSeq.deepseq`). > > I would take a closer look at your makeCounts function: you call > traverse the input list, and traverse the entire list (starting from > each element) again in each round. Either you should find a way to > iterate only once and accumulate all the data you need, or you should > start optimizing there. > > hope this helps, > cheers, > matthias > > > On Sat, Dec 13, 2014 at 02:06:52AM -0700, David Spies wrote: > > Date: Sat, 13 Dec 2014 02:06:52 -0700 > > From: David Spies > > To: "ghc-devs at haskell.org" > > Subject: Program runs out of memory using GHC 7.6.3 > > > > I have a program I submitted for a Kattis problem: > > https://open.kattis.com/problems/digicomp2 > > But I got memory limit exceeded. I downloaded the test data and ran the > > program on my own computer without problems. Eventually I found out that > > when compiling with GHC 7.6.3 (the version Kattis uses) rather than > 7.8.3, > > this program runs out of memory. > > Can someone explain why it only works on the later compiler? Is there a > > workaround so that I can submit to Kattis? > > > > Thanks, > > David > > > module Main(main) where > > > > import Control.Monad > > import Data.Array > > import qualified Data.ByteString.Char8 as BS > > import Data.Int > > import Data.Maybe > > > > readAsInt :: BS.ByteString -> Int > > readAsInt = fst . fromJust . BS.readInt > > > > readVert :: IO Vert > > readVert = do > > [s, sl, sr] <- liftM BS.words BS.getLine > > return $ V (fromBS s) (readAsInt sl) (readAsInt sr) > > > > main::IO() > > main = do > > [n, m64] <- liftM (map read . words) getLine :: IO [Int64] > > let m = fromIntegral m64 :: Int > > verts <- replicateM m readVert > > let vside = map getSide verts > > let vpar = concat $ zipWith makeAssoc [1..] verts > > let parArr = accumArray (flip (:)) [] (1, m) vpar > > let counts = makeCounts n m $ elems parArr > > let res = zipWith doFlips counts vside > > putStrLn $ map toChar res > > > > doFlips :: Int64 -> Side -> Side > > doFlips n > > | odd n = flipSide > > | otherwise = id > > > > makeCounts :: Int64 -> Int -> [[(Int, Round)]] -> [Int64] > > makeCounts n m l = tail $ elems res > > where > > res = listArray (0, m) $ 0 : n : map makeCount (tail l) > > makeCount :: [(Int, Round)] -> Int64 > > makeCount = sum . map countFor > > countFor :: (Int, Round) -> Int64 > > countFor (i, Up) = ((res ! i) + 1) `quot` 2 > > countFor (i, Down) = (res ! i) `quot` 2 > > > > fromBS :: BS.ByteString -> Side > > fromBS = fromChar . BS.head > > > > fromChar :: Char -> Side > > fromChar 'L' = L > > fromChar 'R' = R > > fromChar _ = error "Bad char" > > > > toChar :: Side -> Char > > toChar L = 'L' > > toChar R = 'R' > > > > makeAssoc :: Int -> Vert -> [(Int, (Int, Round))] > > makeAssoc n (V L a b) = filtPos [(a, (n, Up)), (b, (n, Down))] > > makeAssoc n (V R a b) = filtPos [(a, (n, Down)), (b, (n, Up))] > > > > filtPos :: [(Int, a)] -> [(Int, a)] > > filtPos = filter ((> 0) . fst) > > > > data Vert = V !Side !Int !Int > > > > getSide :: Vert -> Side > > getSide (V s _ _) = s > > > > data Side = L | R > > > > data Round = Up | Down > > > > flipSide :: Side -> Side > > flipSide L = R > > flipSide R = L > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnspies at gmail.com Sat Dec 13 21:33:46 2014 From: dnspies at gmail.com (David Spies) Date: Sat, 13 Dec 2014 14:33:46 -0700 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: References: <20141213100610.GJ20726@lig> Message-ID: I tried adding strictness to everything, forcing each line with "evaluate . force" It still runs out of memory and now running with -hc blames the extra memory on "trace elements" which seems somewhat unhelpful. On Sat, Dec 13, 2014 at 2:10 PM, David Spies wrote: > > I think there's some confusion about makeCounts's behavior. makeCount > never traverses the same thing twice. Essentially, the worst-case size of > the unevaluated thunks doesn't exceed the total size of the array of lists > that was used to create them (and that array itself was created with > accumArray which is strict). > Nonetheless, I've tried adding strictness all over makeCounts and it > reduces the memory usage a little bit, but it still fails a later input > instance with OOM. It's not a significant reduction like in GHC 7.8.3 > > > On Sat, Dec 13, 2014 at 3:06 AM, Matthias Fischmann > wrote: >> >> >> Hi David, >> >> I don't think this is a ghc issue. >> >> I suspect you have too many unevaluated function calls lying around >> (this would cause the runtime to run out of *stack* as opposed to >> *heap*). Different versions of ghc perform different optimizations on >> your code, and 7.8 knows a way to fix it that 7.6 doesn't know. >> >> This is usually solved by adding strictness: Instead of letting the >> unevaluated function calls pile up, you force them (e.g. with `print` >> or `Control.DeepSeq.deepseq`). >> >> I would take a closer look at your makeCounts function: you call >> traverse the input list, and traverse the entire list (starting from >> each element) again in each round. Either you should find a way to >> iterate only once and accumulate all the data you need, or you should >> start optimizing there. >> >> hope this helps, >> cheers, >> matthias >> >> >> On Sat, Dec 13, 2014 at 02:06:52AM -0700, David Spies wrote: >> > Date: Sat, 13 Dec 2014 02:06:52 -0700 >> > From: David Spies >> > To: "ghc-devs at haskell.org" >> > Subject: Program runs out of memory using GHC 7.6.3 >> > >> > I have a program I submitted for a Kattis problem: >> > https://open.kattis.com/problems/digicomp2 >> > But I got memory limit exceeded. I downloaded the test data and ran the >> > program on my own computer without problems. Eventually I found out >> that >> > when compiling with GHC 7.6.3 (the version Kattis uses) rather than >> 7.8.3, >> > this program runs out of memory. >> > Can someone explain why it only works on the later compiler? Is there a >> > workaround so that I can submit to Kattis? >> > >> > Thanks, >> > David >> >> > module Main(main) where >> > >> > import Control.Monad >> > import Data.Array >> > import qualified Data.ByteString.Char8 as BS >> > import Data.Int >> > import Data.Maybe >> > >> > readAsInt :: BS.ByteString -> Int >> > readAsInt = fst . fromJust . BS.readInt >> > >> > readVert :: IO Vert >> > readVert = do >> > [s, sl, sr] <- liftM BS.words BS.getLine >> > return $ V (fromBS s) (readAsInt sl) (readAsInt sr) >> > >> > main::IO() >> > main = do >> > [n, m64] <- liftM (map read . words) getLine :: IO [Int64] >> > let m = fromIntegral m64 :: Int >> > verts <- replicateM m readVert >> > let vside = map getSide verts >> > let vpar = concat $ zipWith makeAssoc [1..] verts >> > let parArr = accumArray (flip (:)) [] (1, m) vpar >> > let counts = makeCounts n m $ elems parArr >> > let res = zipWith doFlips counts vside >> > putStrLn $ map toChar res >> > >> > doFlips :: Int64 -> Side -> Side >> > doFlips n >> > | odd n = flipSide >> > | otherwise = id >> > >> > makeCounts :: Int64 -> Int -> [[(Int, Round)]] -> [Int64] >> > makeCounts n m l = tail $ elems res >> > where >> > res = listArray (0, m) $ 0 : n : map makeCount (tail l) >> > makeCount :: [(Int, Round)] -> Int64 >> > makeCount = sum . map countFor >> > countFor :: (Int, Round) -> Int64 >> > countFor (i, Up) = ((res ! i) + 1) `quot` 2 >> > countFor (i, Down) = (res ! i) `quot` 2 >> > >> > fromBS :: BS.ByteString -> Side >> > fromBS = fromChar . BS.head >> > >> > fromChar :: Char -> Side >> > fromChar 'L' = L >> > fromChar 'R' = R >> > fromChar _ = error "Bad char" >> > >> > toChar :: Side -> Char >> > toChar L = 'L' >> > toChar R = 'R' >> > >> > makeAssoc :: Int -> Vert -> [(Int, (Int, Round))] >> > makeAssoc n (V L a b) = filtPos [(a, (n, Up)), (b, (n, Down))] >> > makeAssoc n (V R a b) = filtPos [(a, (n, Down)), (b, (n, Up))] >> > >> > filtPos :: [(Int, a)] -> [(Int, a)] >> > filtPos = filter ((> 0) . fst) >> > >> > data Vert = V !Side !Int !Int >> > >> > getSide :: Vert -> Side >> > getSide (V s _ _) = s >> > >> > data Side = L | R >> > >> > data Round = Up | Down >> > >> > flipSide :: Side -> Side >> > flipSide L = R >> > flipSide R = L >> >> >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sat Dec 13 21:56:18 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Dec 2014 22:56:18 +0100 Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1 In-Reply-To: References: <87bnnu3ufg.fsf@gnu.org> Message-ID: On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald wrote: > Thomas and I have found some bugs in HPC on OSX, and we're in the midst of > tracking those down, You mean these are regressions? If they are introduced in one of the non-blocker fixes in 7.8.4, we can probably just revert them. Anyway, thanks a lot for testing. Cheers, Mikolaj From ttuegel at gmail.com Sat Dec 13 22:02:32 2014 From: ttuegel at gmail.com (Thomas Tuegel) Date: Sat, 13 Dec 2014 16:02:32 -0600 Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1 In-Reply-To: References: <87bnnu3ufg.fsf@gnu.org> Message-ID: On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski wrote: > On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald > wrote: >> Thomas and I have found some bugs in HPC on OSX, and we're in the midst of >> tracking those down, > > You mean these are regressions? If they are introduced > in one of the non-blocker fixes in 7.8.4, we can probably > just revert them. Anyway, thanks a lot for testing. Sorry, these are not regressions. It's really a bug in Cabal which will be fixed in 1.22. When Carter wrote this, we thought the problem was with the GHC side of HPC because of some very vague error messages. -- Thomas Tuegel From mikolaj at well-typed.com Sat Dec 13 22:07:32 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Dec 2014 23:07:32 +0100 Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1 In-Reply-To: References: <87bnnu3ufg.fsf@gnu.org> Message-ID: OK. In that case, let's remember to get *that* version of cabal into 7.8.4. /me conditions himself with chocolate to help the remembering On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel wrote: > On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski > wrote: >> On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald >> wrote: >>> Thomas and I have found some bugs in HPC on OSX, and we're in the midst of >>> tracking those down, >> >> You mean these are regressions? If they are introduced >> in one of the non-blocker fixes in 7.8.4, we can probably >> just revert them. Anyway, thanks a lot for testing. > > Sorry, these are not regressions. It's really a bug in Cabal which > will be fixed in 1.22. When Carter wrote this, we thought the problem > was with the GHC side of HPC because of some very vague error > messages. > > -- > Thomas Tuegel > From mle+hs at mega-nerd.com Sun Dec 14 07:46:03 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 13 Dec 2014 23:46:03 -0800 Subject: Trouble committing In-Reply-To: References: Message-ID: <20141213234603.6807aaaeb1d9c0fbc8c96e4f@mega-nerd.com> Andreas Voellmy wrote: > Hi GHCers, > > I just fixed a bug (#9423) and went through the Phab workflow. Then I did a > fresh checkout from git and ran: > > $ git checkout master > $ arc patch --nobranch D129 > $ git push origin master > > as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on > the last command I get this error: > > fatal: remote error: access denied or repository not exported: /ghc.git > > Maybe I just no longer have commit access to ghc? Andi, Did you get a response to this? I seem to be in the same boat for D570. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From hvr at gnu.org Sun Dec 14 09:51:05 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 14 Dec 2014 10:51:05 +0100 Subject: Trouble committing In-Reply-To: <20141213234603.6807aaaeb1d9c0fbc8c96e4f@mega-nerd.com> (Erik de Castro Lopo's message of "Sat, 13 Dec 2014 23:46:03 -0800") References: <20141213234603.6807aaaeb1d9c0fbc8c96e4f@mega-nerd.com> Message-ID: <87388i4l12.fsf@gnu.org> On 2014-12-14 at 08:46:03 +0100, Erik de Castro Lopo wrote: [...] >> $ git push origin master >> >> as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on >> the last command I get this error: >> >> fatal: remote error: access denied or repository not exported: /ghc.git >> >> Maybe I just no longer have commit access to ghc? > > Andi, > > Did you get a response to this? I seem to be in the same boat for D570. What does the following command output in your case? $ git remote show -n origin | grep URL Fetch URL: git://git.haskell.org/ghc.git Push URL: ssh://git at git.haskell.org/ghc.git From hvr at gnu.org Sun Dec 14 09:53:08 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 14 Dec 2014 10:53:08 +0100 Subject: performance regressions In-Reply-To: (Richard Eisenberg's message of "Sat, 13 Dec 2014 10:55:40 -0500") References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> Message-ID: <87y4qa36d7.fsf@gnu.org> Hello Richard, Can you please push the fix asap to master? This performance failures are causing distracting false alarms (in terms of validation failures) on each pushed commit as well as submitted code-revisions. Thanks, HVR On 2014-12-13 at 16:55:40 +0100, Richard Eisenberg wrote: > Fixed, hopefully! > > On Dec 13, 2014, at 10:03 AM, Richard Eisenberg wrote: > >> I think I've fixed this. I've pushed the fix to wip/rae, and waiting for validation results before pushing to master. >> >> My hunch below was right -- it was the change to matchFam, which >> essentially evaluated type-level functions more strictly. I've now >> made it lazier again. I'd like to better understand the tradeoff >> here, and to see if there's a principled sweet spot. But that will >> happen in a few days. >> >> Expect a push to master soon. >> >> Again, sorry for the bother. From mle+hs at mega-nerd.com Sun Dec 14 10:25:35 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 14 Dec 2014 02:25:35 -0800 Subject: Trouble committing In-Reply-To: <87388i4l12.fsf@gnu.org> References: <20141213234603.6807aaaeb1d9c0fbc8c96e4f@mega-nerd.com> <87388i4l12.fsf@gnu.org> Message-ID: <20141214022535.080594339eb8ccbc6b2b7cc2@mega-nerd.com> Herbert Valerio Riedel wrote: > What does the following command output in your case? > > $ git remote show -n origin | grep URL > Fetch URL: git://git.haskell.org/ghc.git > Push URL: ssh://git at git.haskell.org/ghc.git Fixed it with some help from ezyang who suggested: git remote set-url origin --push ssh://git at git.haskell.org/ghc.git Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From hvriedel at gmail.com Sun Dec 14 10:30:06 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 14 Dec 2014 11:30:06 +0100 Subject: Trouble committing In-Reply-To: <20141214022535.080594339eb8ccbc6b2b7cc2@mega-nerd.com> (Erik de Castro Lopo's message of "Sun, 14 Dec 2014 02:25:35 -0800") References: <20141213234603.6807aaaeb1d9c0fbc8c96e4f@mega-nerd.com> <87388i4l12.fsf@gnu.org> <20141214022535.080594339eb8ccbc6b2b7cc2@mega-nerd.com> Message-ID: <87ppbm34nl.fsf@gmail.com> On 2014-12-14 at 11:25:35 +0100, Erik de Castro Lopo wrote: >> What does the following command output in your case? >> >> $ git remote show -n origin | grep URL >> Fetch URL: git://git.haskell.org/ghc.git >> Push URL: ssh://git at git.haskell.org/ghc.git > > Fixed it with some help from ezyang who suggested: > > git remote set-url origin --push ssh://git at git.haskell.org/ghc.git That works too, but the more general approach (so you don't have to repeat the step above for other ghc.git repos and/or each submodule separately) is described below: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Pushaccess Cheers, HVR From mf at zerobuzz.net Sun Dec 14 11:03:14 2014 From: mf at zerobuzz.net (Matthias Fischmann) Date: Sun, 14 Dec 2014 12:03:14 +0100 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: References: <20141213100610.GJ20726@lig> Message-ID: <20141214110314.GM20726@lig> sorry, you're right, my mistake. makeCounts has no obvious complexity issues. my next guess: the default stack size (+RTS -K) for 7.6.3 is 8M, the default for 7.8.3 is 80% of physical memory (see 7.8.1 release notes). i think this is the reason why the 7.8.3 executable does not run out of stack, whlie the 7.6.3 one does. anyway, if you want to continue this discussion on ghc-dev, you should probably provide some evidence that it is a bug. performance improvements between releases are intentional. (-: thanks for the kattis link, btw! cheers, m. On Sat, Dec 13, 2014 at 02:10:25PM -0700, David Spies wrote: > Date: Sat, 13 Dec 2014 14:10:25 -0700 > From: David Spies > To: Matthias Fischmann > Cc: "ghc-devs at haskell.org" > Subject: Re: Program runs out of memory using GHC 7.6.3 > > I think there's some confusion about makeCounts's behavior. makeCount > never traverses the same thing twice. Essentially, the worst-case size of > the unevaluated thunks doesn't exceed the total size of the array of lists > that was used to create them (and that array itself was created with > accumArray which is strict). > Nonetheless, I've tried adding strictness all over makeCounts and it > reduces the memory usage a little bit, but it still fails a later input > instance with OOM. It's not a significant reduction like in GHC 7.8.3 > > > On Sat, Dec 13, 2014 at 3:06 AM, Matthias Fischmann wrote: > > > > > > Hi David, > > > > I don't think this is a ghc issue. > > > > I suspect you have too many unevaluated function calls lying around > > (this would cause the runtime to run out of *stack* as opposed to > > *heap*). Different versions of ghc perform different optimizations on > > your code, and 7.8 knows a way to fix it that 7.6 doesn't know. > > > > This is usually solved by adding strictness: Instead of letting the > > unevaluated function calls pile up, you force them (e.g. with `print` > > or `Control.DeepSeq.deepseq`). > > > > I would take a closer look at your makeCounts function: you call > > traverse the input list, and traverse the entire list (starting from > > each element) again in each round. Either you should find a way to > > iterate only once and accumulate all the data you need, or you should > > start optimizing there. > > > > hope this helps, > > cheers, > > matthias > > > > > > On Sat, Dec 13, 2014 at 02:06:52AM -0700, David Spies wrote: > > > Date: Sat, 13 Dec 2014 02:06:52 -0700 > > > From: David Spies > > > To: "ghc-devs at haskell.org" > > > Subject: Program runs out of memory using GHC 7.6.3 > > > > > > I have a program I submitted for a Kattis problem: > > > https://open.kattis.com/problems/digicomp2 > > > But I got memory limit exceeded. I downloaded the test data and ran the > > > program on my own computer without problems. Eventually I found out that > > > when compiling with GHC 7.6.3 (the version Kattis uses) rather than > > 7.8.3, > > > this program runs out of memory. > > > Can someone explain why it only works on the later compiler? Is there a > > > workaround so that I can submit to Kattis? > > > > > > Thanks, > > > David > > > > > module Main(main) where > > > > > > import Control.Monad > > > import Data.Array > > > import qualified Data.ByteString.Char8 as BS > > > import Data.Int > > > import Data.Maybe > > > > > > readAsInt :: BS.ByteString -> Int > > > readAsInt = fst . fromJust . BS.readInt > > > > > > readVert :: IO Vert > > > readVert = do > > > [s, sl, sr] <- liftM BS.words BS.getLine > > > return $ V (fromBS s) (readAsInt sl) (readAsInt sr) > > > > > > main::IO() > > > main = do > > > [n, m64] <- liftM (map read . words) getLine :: IO [Int64] > > > let m = fromIntegral m64 :: Int > > > verts <- replicateM m readVert > > > let vside = map getSide verts > > > let vpar = concat $ zipWith makeAssoc [1..] verts > > > let parArr = accumArray (flip (:)) [] (1, m) vpar > > > let counts = makeCounts n m $ elems parArr > > > let res = zipWith doFlips counts vside > > > putStrLn $ map toChar res > > > > > > doFlips :: Int64 -> Side -> Side > > > doFlips n > > > | odd n = flipSide > > > | otherwise = id > > > > > > makeCounts :: Int64 -> Int -> [[(Int, Round)]] -> [Int64] > > > makeCounts n m l = tail $ elems res > > > where > > > res = listArray (0, m) $ 0 : n : map makeCount (tail l) > > > makeCount :: [(Int, Round)] -> Int64 > > > makeCount = sum . map countFor > > > countFor :: (Int, Round) -> Int64 > > > countFor (i, Up) = ((res ! i) + 1) `quot` 2 > > > countFor (i, Down) = (res ! i) `quot` 2 > > > > > > fromBS :: BS.ByteString -> Side > > > fromBS = fromChar . BS.head > > > > > > fromChar :: Char -> Side > > > fromChar 'L' = L > > > fromChar 'R' = R > > > fromChar _ = error "Bad char" > > > > > > toChar :: Side -> Char > > > toChar L = 'L' > > > toChar R = 'R' > > > > > > makeAssoc :: Int -> Vert -> [(Int, (Int, Round))] > > > makeAssoc n (V L a b) = filtPos [(a, (n, Up)), (b, (n, Down))] > > > makeAssoc n (V R a b) = filtPos [(a, (n, Down)), (b, (n, Up))] > > > > > > filtPos :: [(Int, a)] -> [(Int, a)] > > > filtPos = filter ((> 0) . fst) > > > > > > data Vert = V !Side !Int !Int > > > > > > getSide :: Vert -> Side > > > getSide (V s _ _) = s > > > > > > data Side = L | R > > > > > > data Round = Up | Down > > > > > > flipSide :: Side -> Side > > > flipSide L = R > > > flipSide R = L > > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://www.haskell.org/mailman/listinfo/ghc-devs > > From dnspies at gmail.com Sun Dec 14 12:06:57 2014 From: dnspies at gmail.com (David Spies) Date: Sun, 14 Dec 2014 05:06:57 -0700 Subject: Program runs out of memory using GHC 7.6.3 In-Reply-To: <20141214110314.GM20726@lig> References: <20141213100610.GJ20726@lig> <20141214110314.GM20726@lig> Message-ID: Oh, Now I feel really silly for not noticing that that number was 8 MB. I saw the 8 at the beginning all this time and just assumed it meant 8 GB. I'm sorry, In the future I'll post queries like this on the GHC-users mailing list. I'm guessing Kattis doesn't bother to change the default stack size when they run the program. I'll email to let them know. Thank you, David On Sun, Dec 14, 2014 at 4:03 AM, Matthias Fischmann wrote: > > > sorry, you're right, my mistake. makeCounts has no obvious complexity > issues. > > my next guess: the default stack size (+RTS -K) for 7.6.3 is 8M, > the default for 7.8.3 is 80% of physical memory (see 7.8.1 release > notes). i think this is the reason why the 7.8.3 executable does not > run out of stack, whlie the 7.6.3 one does. > > anyway, if you want to continue this discussion on ghc-dev, you should > probably provide some evidence that it is a bug. performance > improvements between releases are intentional. (-: > > thanks for the kattis link, btw! > > cheers, > m. > > > On Sat, Dec 13, 2014 at 02:10:25PM -0700, David Spies wrote: > > Date: Sat, 13 Dec 2014 14:10:25 -0700 > > From: David Spies > > To: Matthias Fischmann > > Cc: "ghc-devs at haskell.org" > > Subject: Re: Program runs out of memory using GHC 7.6.3 > > > > I think there's some confusion about makeCounts's behavior. makeCount > > never traverses the same thing twice. Essentially, the worst-case size > of > > the unevaluated thunks doesn't exceed the total size of the array of > lists > > that was used to create them (and that array itself was created with > > accumArray which is strict). > > Nonetheless, I've tried adding strictness all over makeCounts and it > > reduces the memory usage a little bit, but it still fails a later input > > instance with OOM. It's not a significant reduction like in GHC 7.8.3 > > > > > > On Sat, Dec 13, 2014 at 3:06 AM, Matthias Fischmann > wrote: > > > > > > > > > Hi David, > > > > > > I don't think this is a ghc issue. > > > > > > I suspect you have too many unevaluated function calls lying around > > > (this would cause the runtime to run out of *stack* as opposed to > > > *heap*). Different versions of ghc perform different optimizations on > > > your code, and 7.8 knows a way to fix it that 7.6 doesn't know. > > > > > > This is usually solved by adding strictness: Instead of letting the > > > unevaluated function calls pile up, you force them (e.g. with `print` > > > or `Control.DeepSeq.deepseq`). > > > > > > I would take a closer look at your makeCounts function: you call > > > traverse the input list, and traverse the entire list (starting from > > > each element) again in each round. Either you should find a way to > > > iterate only once and accumulate all the data you need, or you should > > > start optimizing there. > > > > > > hope this helps, > > > cheers, > > > matthias > > > > > > > > > On Sat, Dec 13, 2014 at 02:06:52AM -0700, David Spies wrote: > > > > Date: Sat, 13 Dec 2014 02:06:52 -0700 > > > > From: David Spies > > > > To: "ghc-devs at haskell.org" > > > > Subject: Program runs out of memory using GHC 7.6.3 > > > > > > > > I have a program I submitted for a Kattis problem: > > > > https://open.kattis.com/problems/digicomp2 > > > > But I got memory limit exceeded. I downloaded the test data and ran > the > > > > program on my own computer without problems. Eventually I found out > that > > > > when compiling with GHC 7.6.3 (the version Kattis uses) rather than > > > 7.8.3, > > > > this program runs out of memory. > > > > Can someone explain why it only works on the later compiler? Is > there a > > > > workaround so that I can submit to Kattis? > > > > > > > > Thanks, > > > > David > > > > > > > module Main(main) where > > > > > > > > import Control.Monad > > > > import Data.Array > > > > import qualified Data.ByteString.Char8 as BS > > > > import Data.Int > > > > import Data.Maybe > > > > > > > > readAsInt :: BS.ByteString -> Int > > > > readAsInt = fst . fromJust . BS.readInt > > > > > > > > readVert :: IO Vert > > > > readVert = do > > > > [s, sl, sr] <- liftM BS.words BS.getLine > > > > return $ V (fromBS s) (readAsInt sl) (readAsInt sr) > > > > > > > > main::IO() > > > > main = do > > > > [n, m64] <- liftM (map read . words) getLine :: IO [Int64] > > > > let m = fromIntegral m64 :: Int > > > > verts <- replicateM m readVert > > > > let vside = map getSide verts > > > > let vpar = concat $ zipWith makeAssoc [1..] verts > > > > let parArr = accumArray (flip (:)) [] (1, m) vpar > > > > let counts = makeCounts n m $ elems parArr > > > > let res = zipWith doFlips counts vside > > > > putStrLn $ map toChar res > > > > > > > > doFlips :: Int64 -> Side -> Side > > > > doFlips n > > > > | odd n = flipSide > > > > | otherwise = id > > > > > > > > makeCounts :: Int64 -> Int -> [[(Int, Round)]] -> [Int64] > > > > makeCounts n m l = tail $ elems res > > > > where > > > > res = listArray (0, m) $ 0 : n : map makeCount (tail l) > > > > makeCount :: [(Int, Round)] -> Int64 > > > > makeCount = sum . map countFor > > > > countFor :: (Int, Round) -> Int64 > > > > countFor (i, Up) = ((res ! i) + 1) `quot` 2 > > > > countFor (i, Down) = (res ! i) `quot` 2 > > > > > > > > fromBS :: BS.ByteString -> Side > > > > fromBS = fromChar . BS.head > > > > > > > > fromChar :: Char -> Side > > > > fromChar 'L' = L > > > > fromChar 'R' = R > > > > fromChar _ = error "Bad char" > > > > > > > > toChar :: Side -> Char > > > > toChar L = 'L' > > > > toChar R = 'R' > > > > > > > > makeAssoc :: Int -> Vert -> [(Int, (Int, Round))] > > > > makeAssoc n (V L a b) = filtPos [(a, (n, Up)), (b, (n, Down))] > > > > makeAssoc n (V R a b) = filtPos [(a, (n, Down)), (b, (n, Up))] > > > > > > > > filtPos :: [(Int, a)] -> [(Int, a)] > > > > filtPos = filter ((> 0) . fst) > > > > > > > > data Vert = V !Side !Int !Int > > > > > > > > getSide :: Vert -> Side > > > > getSide (V s _ _) = s > > > > > > > > data Side = L | R > > > > > > > > data Round = Up | Down > > > > > > > > flipSide :: Side -> Side > > > > flipSide L = R > > > > flipSide R = L > > > > > > > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slyich at gmail.com Sun Dec 14 17:07:02 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Sun, 14 Dec 2014 17:07:02 +0000 Subject: more parser conflicts? In-Reply-To: <20141213151934.03e1582d@sf> References: <547EFB2E.7080306@gmail.com> <20141213151934.03e1582d@sf> Message-ID: <20141214170702.073bc699@sf> On Sat, 13 Dec 2014 15:19:34 +0000 Sergei Trofimovich wrote: > On Wed, 03 Dec 2014 11:59:42 +0000 > Simon Marlow wrote: > > > >> In unrelated work, I saw this scroll across when happy'ing the parser: > > >> > > >>> shift/reduce conflicts: 60 > > >>> reduce/reduce conflicts: 16 > > >> > > >> These numbers seem quite a bit higher than what I last remember (which > > >> is something like 48 and 1, not 60 and 16). Does anyone know why? > > 4 of reduce/reduce conflicts are result of exact rule copy: > https://phabricator.haskell.org/D569 > > > reduce/reduce conflicts are bad, especially so since they're > > undocumented. We don't know whether this introduced parser bugs or not. > > Mike - could you look at this please? It was your commit that > > introduced the new conflicts. > > Agreed. > > 11 more reduce/reduce (of left 12) came from single scary rule > added in > > commit bc2289e13d9586be087bd8136943dc35a0130c88 > > ghc generates more user-friendly error messages > > exp10 :: { LHsExpr RdrName } > ... > | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text > "parse error in let binding: missing required 'in'" > } > > The other rules add shift/reduce conflicts as follows: > > -- parsing error messages go below here > {- s/r:1 r/r:0 -} > | '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1 $5) $ text > "parse error in lambda: no expression after '->'" > {- s/r:1 r/r:0 -} > | '\\' {% parseErrorSDoc (getLoc $1) $ text > "parse error: naked lambda expression '\'" > } > {- s/r:1 r/r:0 -} > | 'let' binds 'in' {% parseErrorSDoc (combineLocs $1 $2) $ text > "parse error in let binding: missing expression after 'in'" > } > {- s/r:0 r/r:11 -} > | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text > "parse error in let binding: missing required 'in'" > } > {- s/r:0 r/r:0 -} > | 'let' {% parseErrorSDoc (getLoc $1) $ text > "parse error: naked let binding" > } > {- s/r:1 r/r:0 -} > | 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf (combineLocs $1 $5) "else clause empty" } > {- s/r:2 r/r:0 -} > | 'if' exp optSemi 'then' exp optSemi {% hintIf (combineLocs $1 $5) "missing required else clause" } > {- s/r:1 r/r:0 -} > | 'if' exp optSemi 'then' {% hintIf (combineLocs $1 $2) "then clause empty" } > {- s/r:2 r/r:0 -} > | 'if' exp optSemi {% hintIf (combineLocs $1 $2) "missing required then and else clauses" > {- s/r:2 r/r:0 -} > | 'if' {% hintIf (getLoc $1) "naked if statement" } > {- s/r:0 r/r:0 -} > | 'case' exp 'of' {% parseErrorSDoc (combineLocs $1 $2) $ text > "parse error in case statement: missing list after '->'" > } > {- s/r:1 r/r:0 -} > | 'case' exp {% parseErrorSDoc (combineLocs $1 $2) $ text > "parse error in case statement: missing required 'of'" > } > {- s/r:1 r/r:0 -} > | 'case' {% parseErrorSDoc (getLoc $1) $ text > "parse error: naked case statement" > } > > Shift/reduces look harmless (like MultiWayIf ambiguity) > as they seem to resolve as shift correctly. Proposed fix as: https://phabricator.haskell.org/D571 Simon, is using happy's "error" token the proper way of fixing these error reporting rules? Thanks! -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From mail at joachim-breitner.de Sun Dec 14 20:47:54 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 14 Dec 2014 21:47:54 +0100 Subject: performance regressions In-Reply-To: References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> Message-ID: <1418590074.1468.2.camel@joachim-breitner.de> Hi, Am Samstag, den 13.12.2014, 10:55 -0500 schrieb Richard Eisenberg: > Fixed, hopefully! Mitigated, but still a regression: http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=tests%2Falloc%2FT9872a&env=1&revs=50&equid=on# Is that now a level that we?ll have to live with, or is it still unexpectedly high? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From eir at cis.upenn.edu Mon Dec 15 03:37:58 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 14 Dec 2014 22:37:58 -0500 Subject: performance regressions In-Reply-To: <1418590074.1468.2.camel@joachim-breitner.de> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> <1418590074.1468.2.camel@joachim-breitner.de> Message-ID: <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> I pushed my supposed fix yesterday morning, as I emailed out the "Fixed, hopefully" note. Of course, I now see that it wasn't a full fix. This is all most assuredly my fault. However, I also feel that elements of the infrastructure failed me somewhat, making this error easier for me to commit: - Travis has not picked up on these errors. - Harbormaster has seemed unreliable, finding spurious compile-time errors sometimes, and sometimes just failing to test code that it sees. For example, when I pushed Diff 1901 to D546, Harbormaster never even attempted. Also, when I pushed my "fix", commit 3ec9391711, Harbormaster also skipped, as viewable here: https://phabricator.haskell.org/diffusion/GHC/ So, after pushing yesterday morning, I didn't get any email from Harbormaster saying that it failed, so I thought my fix was indeed a fix. Because my local build was a devel2 build (and that I had only about 20 minutes to work), I was unable to test locally -- all I could tell is that my fix lowered the numbers (as verified by ghcspeed). Having a weekend full of plans, there wasn't really any opportunity for me to do the work necessary to figure out what's going on. It will be first on my docket tomorrow. I suppose one lesson here is that I shouldn't push anything at all non-trivial on a Friday afternoon. But I also hope we can either improve the infrastructure (of course, it's *much* better than it was months ago!) or have realistic expectations of what we can expect from the infrastructure (e.g., trust Harbormaster/Travis when seeking feedback, but always validate locally before actually pushing to master). More tomorrow, Richard On Dec 14, 2014, at 3:47 PM, Joachim Breitner wrote: > Hi, > > Am Samstag, den 13.12.2014, 10:55 -0500 schrieb Richard Eisenberg: >> Fixed, hopefully! > > Mitigated, but still a regression: > > http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=tests%2Falloc%2FT9872a&env=1&revs=50&equid=on# > > Is that now a level that we?ll have to live with, or is it still > unexpectedly high? > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > From mail at joachim-breitner.de Mon Dec 15 08:43:48 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 15 Dec 2014 09:43:48 +0100 Subject: performance regressions In-Reply-To: <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> <1418590074.1468.2.camel@joachim-breitner.de> <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> Message-ID: <1418633028.1489.16.camel@joachim-breitner.de> Hi, Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg: > Of course, I now see that it wasn't a full fix. > > This is all most assuredly my fault. I wouldn?t call it a fault. Where wood is chopped, splinters must fall. (Hopefully correct translation of a German idiom.) We don?t _have_ to catch everything before it hits master, it is already pretty good if we manage to catch and fix regressions later. I guess we could use the known_broken feature of the test suite more quickly, to signal that an issue is being worked on and to avoid others from stumbling over test suite failures. > - Travis has not picked up on these errors. unfortunately, travis is slighly less useful since a few weeks due to T5681 failing (possibly due to the use of LLVM-3.4), but I?m still waiting for an reply on that issue. But it wouldn?t have helped you: Travis generally skips all performance tests. These used to be far less reliable when I set up travis (this got better due to the removal of some of the max_bytes_allocated tests, and also due to harbormaster and ghcspeed monitoring), and also because we still hardly make the 50 minute deadline on Travis. So do not rely on Travis for performance measurements. (This is documented on https://ghc.haskell.org/trac/ghc/wiki/Travis, but it needs to become common knowledge.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Dec 15 10:58:13 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 10:58:13 +0000 Subject: Reachable modules from DynFlags out of date Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> Hum. "Reachable modules from DynFlags out of date" What can I do now? Validated ok on my windows laptop. So I'm sorry but it looks as if I have broken HEAD. Could revert but I'd prefer to fix. I did change some imports. Thanks Simon HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o HC [stage 1] compiler/stage2/build/LlvmCodeGen.o Reachable modules from DynFlags out of date -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Dec 15 11:16:21 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 15 Dec 2014 13:16:21 +0200 Subject: Reachable modules from DynFlags out of date In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: edit compiler/ghc.mk and change the definition of compiler_stage2_dll0_MODULES according to your error message. On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones wrote: > > Hum. ?Reachable modules from DynFlags out of date? What can I do > now? > > Validated ok on my windows laptop. So I?m sorry but it looks as if I have > broken HEAD. Could revert but I?d prefer to fix. > > I did change some imports. > > Thanks > > Simon > > > > HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o > > HC [stage 1] compiler/stage2/build/LlvmCodeGen.o > > Reachable modules from DynFlags out of date > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 15 11:20:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 11:20:03 +0000 Subject: Reachable modules from DynFlags out of date In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F40141B@DB3PRD3001MB020.064d.mgd.msft.net> Yes, but what change would you suggest? The error message doesn?t suggest a particular change to me. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 15 December 2014 11:16 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Reachable modules from DynFlags out of date edit compiler/ghc.mk and change the definition of compiler_stage2_dll0_MODULES according to your error message. On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones > wrote: Hum. ?Reachable modules from DynFlags out of date? What can I do now? Validated ok on my windows laptop. So I?m sorry but it looks as if I have broken HEAD. Could revert but I?d prefer to fix. I did change some imports. Thanks Simon HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o HC [stage 1] compiler/stage2/build/LlvmCodeGen.o Reachable modules from DynFlags out of date _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Dec 15 11:22:10 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 15 Dec 2014 13:22:10 +0200 Subject: Reachable modules from DynFlags out of date In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F40141B@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F40141B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: When I have hit this the error message normally lists the items that should be added or remove. What is the full error message? On Mon, Dec 15, 2014 at 1:20 PM, Simon Peyton Jones wrote: > > Yes, but what change would you suggest? The error message doesn?t > suggest a particular change to me. > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 15 December 2014 11:16 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Reachable modules from DynFlags out of date > > > > edit compiler/ghc.mk and change the definition of > compiler_stage2_dll0_MODULES according to your error message. > > > > On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Hum. ?Reachable modules from DynFlags out of date? What can I do > now? > > Validated ok on my windows laptop. So I?m sorry but it looks as if I have > broken HEAD. Could revert but I?d prefer to fix. > > I did change some imports. > > Thanks > > Simon > > > > HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o > > HC [stage 1] compiler/stage2/build/LlvmCodeGen.o > > Reachable modules from DynFlags out of date > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 15 11:50:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 11:50:35 +0000 Subject: Reachable modules from DynFlags out of date In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F40141B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F4014F5@DB3PRD3001MB020.064d.mgd.msft.net> This is what I have right now https://phabricator.haskell.org/harbormaster/build/2630/ My machine is not talking to the repo today, so I can?t do a local build ? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 15 December 2014 11:22 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Reachable modules from DynFlags out of date When I have hit this the error message normally lists the items that should be added or remove. What is the full error message? On Mon, Dec 15, 2014 at 1:20 PM, Simon Peyton Jones > wrote: Yes, but what change would you suggest? The error message doesn?t suggest a particular change to me. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 15 December 2014 11:16 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Reachable modules from DynFlags out of date edit compiler/ghc.mk and change the definition of compiler_stage2_dll0_MODULES according to your error message. On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones > wrote: Hum. ?Reachable modules from DynFlags out of date? What can I do now? Validated ok on my windows laptop. So I?m sorry but it looks as if I have broken HEAD. Could revert but I?d prefer to fix. I did change some imports. Thanks Simon HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o HC [stage 1] compiler/stage2/build/LlvmCodeGen.o Reachable modules from DynFlags out of date _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Dec 15 11:55:07 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 15 Dec 2014 13:55:07 +0200 Subject: Reachable modules from DynFlags out of date In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F4014F5@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F40141B@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F4014F5@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I suspect you need to add all of Extra modules: AsmCodeGen ByteCodeGen ByteCodeLink CPrim CSE CallArity CgUtils Check CmmBuildInfoTables CmmCommonBlockElim CmmContFlowOpt CmmLayoutStack CmmLex CmmLint CmmLive CmmOpt CmmParse CmmPipeline CmmProcPoint CmmSink CodeOutput Convert CoreMonad CorePrep CoreToStg Coverage Desugar DmdAnal DsArrows DsBinds DsCCall DsExpr DsForeign DsGRHSs DsListComp DsMeta DsUtils DynamicLoading FamInst FlagChecker FloatIn FloatOut FunDeps GraphBase GraphColor GraphOps GraphPpr HaddockUtils HeaderInfo HscMain HscStats Inst Instruction LibFFI LiberateCase Linker Llvm Llvm.AbsSyn Llvm.MetaData Llvm.PpLlvm Llvm.Types LlvmCodeGen LlvmCodeGen.Base LlvmCodeGen.CodeGen LlvmCodeGen.Data LlvmCodeGen.Ppr LlvmCodeGen.Regs LlvmMangler Match MatchCon MatchLit MkIface NCGMonad ObjLink PIC PPC.CodeGen PPC.Cond PPC.Instr PPC.Ppr PPC.RegInfo PPC.Regs Parser Plugins PprBase PprC PprTyThing ProfInit RdrHsSyn RegAlloc.Graph.Main RegAlloc.Graph.Spill RegAlloc.Graph.SpillClean RegAlloc.Graph.SpillCost RegAlloc.Graph.Stats RegAlloc.Graph.TrivColorable RegAlloc.Linear.Base RegAlloc.Linear.FreeRegs RegAlloc.Linear.JoinToTargets RegAlloc.Linear.Main RegAlloc.Linear.PPC.FreeRegs RegAlloc.Linear.SPARC.FreeRegs RegAlloc.Linear.StackMap RegAlloc.Linear.State RegAlloc.Linear.Stats RegAlloc.Linear.X86.FreeRegs RegAlloc.Linear.X86_64.FreeRegs RegAlloc.Liveness RnBinds RnEnv RnExpr RnHsDoc RnNames RnPat RnSource RnSplice RnTypes SAT SCCfinal SPARC.AddrMode SPARC.Base SPARC.CodeGen SPARC.CodeGen.Amode SPARC.CodeGen.Base SPARC.CodeGen.CondCode SPARC.CodeGen.Expand SPARC.CodeGen.Gen32 SPARC.CodeGen.Gen64 SPARC.CodeGen.Sanity SPARC.Cond SPARC.Imm SPARC.Instr SPARC.Ppr SPARC.Regs SPARC.ShortcutJump SPARC.Stack SetLevels SimplCore SimplEnv SimplMonad SimplStg SimplUtils Simplify Size SpecConstr Specialise State StaticPtrTable StgCmm StgCmmBind StgCmmCon StgCmmExpr StgCmmExtCode StgCmmForeign StgCmmHeap StgCmmHpc StgCmmPrim StgLint StgStats SysTools TargetReg TcAnnotations TcArrows TcBinds TcCanonical TcClassDcl TcDefaults TcDeriv TcEnv TcErrors TcExpr TcFlatten TcForeign TcGenDeriv TcGenGenerics TcHsSyn TcHsType TcInstDcls TcInteract TcMType TcMatches TcPat TcPatSyn TcRnDriver TcRules TcSMonad TcSimplify TcSplice TcTyClsDecls TcTyDecls TcUnify TcValidity TidyPgm UnVarGraph UnariseStg Vectorise Vectorise.Builtins Vectorise.Builtins.Base Vectorise.Builtins.Initialise Vectorise.Convert Vectorise.Env Vectorise.Exp Vectorise.Generic.Description Vectorise.Generic.PADict Vectorise.Generic.PAMethods Vectorise.Generic.PData Vectorise.Monad Vectorise.Monad.Base Vectorise.Monad.Global Vectorise.Monad.InstEnv Vectorise.Monad.Local Vectorise.Monad.Naming Vectorise.Type.Classify Vectorise.Type.Env Vectorise.Type.TyConDecl Vectorise.Type.Type Vectorise.Utils Vectorise.Utils.Base Vectorise.Utils.Closure Vectorise.Utils.Hoisting Vectorise.Utils.PADict Vectorise.Utils.Poly Vectorise.Var Vectorise.Vect WorkWrap WwLib X86.CodeGen X86.Cond X86.Instr X86.Ppr X86.RegInfo X86.Regs which sounds a bit extreme. I have only ever had one or two, and normally as a result of creating a new module or adding an import to something. On Mon, Dec 15, 2014 at 1:50 PM, Simon Peyton Jones wrote: > > This is what I have right now > > https://phabricator.haskell.org/harbormaster/build/2630/ > > > > My machine is not talking to the repo today, so I can?t do a local build L > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 15 December 2014 11:22 > > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Reachable modules from DynFlags out of date > > > > When I have hit this the error message normally lists the items that > should be added or remove. > > What is the full error message? > > > > On Mon, Dec 15, 2014 at 1:20 PM, Simon Peyton Jones > wrote: > > Yes, but what change would you suggest? The error message doesn?t > suggest a particular change to me. > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 15 December 2014 11:16 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Reachable modules from DynFlags out of date > > > > edit compiler/ghc.mk and change the definition of > compiler_stage2_dll0_MODULES according to your error message. > > > > On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Hum. ?Reachable modules from DynFlags out of date? What can I do > now? > > Validated ok on my windows laptop. So I?m sorry but it looks as if I have > broken HEAD. Could revert but I?d prefer to fix. > > I did change some imports. > > Thanks > > Simon > > > > HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o > > HC [stage 1] compiler/stage2/build/LlvmCodeGen.o > > Reachable modules from DynFlags out of date > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 15 13:42:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 13:42:18 +0000 Subject: Implicit Locations in GHC In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F401673@DB3PRD3001MB020.064d.mgd.msft.net> Eric I'd love to see it happen. High payoff, low pain. See https://ghc.haskell.org/trac/ghc/ticket/9049 No existing branch that I know of. I'm copying some other people who might be interested. Let me know how I can help. Simon | -----Original Message----- | From: Eric Seidel [mailto:eric at seidel.io] | Sent: 12 December 2014 22:11 | To: Simon Peyton Jones | Subject: Implicit Locations in GHC | | Hi Simon, | | I just noticed your wiki page | | | https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocati | ons | | Interestingly, I talked to Iavor a few weeks back about the exact same | idea, and briefly started working on a branch before being consumed by | various work things.. | | Anyway, I think I may have some extra free time coming up, and I'd be | happy to throw some of it at implementing this proposal. Is there an | existing branch that I should look at? | | Eric From jan.stolarek at p.lodz.pl Mon Dec 15 14:23:22 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 15 Dec 2014 15:23:22 +0100 Subject: Reachable modules from DynFlags out of date In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF3F4014F5@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <201412151523.22860.jan.stolarek@p.lodz.pl> > I suspect you need to add all of I believe Simon needs to figure out the diff, ie. which modules are displayed in the dependency list but are missing in the compiler/ghc.mk file. I recall I had to done the same in one of my commits: https://github.com/jstolarek/ghc/commit/53948f915140396acd1b80c6a7a252b2d1e12635#diff-ba0ee6a425ab9ec6d7a2ef6c394ba455 Janek From simonpj at microsoft.com Mon Dec 15 14:41:54 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 14:41:54 +0000 Subject: Reachable modules from DynFlags out of date In-Reply-To: <87y4q9jac1.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> <87y4q9jac1.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F4017B7@DB3PRD3001MB020.064d.mgd.msft.net> | ...do you mind if I revert that one (to unbreak GHC HEAD), and you re- | push that commit once it's sorted out? yes, go ahead. I just wish I *understood* what was going on. Sorry about this S | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 15 December 2014 13:45 | To: Simon Peyton Jones | Subject: Re: Reachable modules from DynFlags out of date | | Hello Simon, | | On 2014-12-15 at 11:58:13 +0100, Simon Peyton Jones wrote: | > Hum. "Reachable modules from DynFlags out of date" What can I do | now? | > Validated ok on my windows laptop. So I'm sorry but it looks as if | I | > have broken HEAD. Could revert but I'd prefer to fix. | > I did change some imports. | | ...do you mind if I revert that one (to unbreak GHC HEAD), and you re- | push that commit once it's sorted out? | | Cheers, | hvr From simonpj at microsoft.com Mon Dec 15 15:25:24 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 15:25:24 +0000 Subject: Reachable modules from DynFlags out of date In-Reply-To: <87y4q9jac1.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF3F401383@DB3PRD3001MB020.064d.mgd.msft.net> <87y4q9jac1.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F401981@DB3PRD3001MB020.064d.mgd.msft.net> Aha. I think I have it. "Hooks" shouldn't import DsMonad. Working on it now | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 15 December 2014 13:45 | To: Simon Peyton Jones | Subject: Re: Reachable modules from DynFlags out of date | | Hello Simon, | | On 2014-12-15 at 11:58:13 +0100, Simon Peyton Jones wrote: | > Hum. "Reachable modules from DynFlags out of date" What can I do | now? | > Validated ok on my windows laptop. So I'm sorry but it looks as if | I | > have broken HEAD. Could revert but I'd prefer to fix. | > I did change some imports. | | ...do you mind if I revert that one (to unbreak GHC HEAD), and you re- | push that commit once it's sorted out? | | Cheers, | hvr From austin at well-typed.com Mon Dec 15 15:28:32 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Dec 2014 09:28:32 -0600 Subject: Last call for 7.8.4 Message-ID: Hello *, I've just pushed a final round of patches to the 7.8 branch, including the notorious Cabal fix for the -fPIC bug that was discussed earlier in the week, and a handful of other bugfixes for ARM among other things (/cc Joachim :) I am planning on making the final 7.8.4 release this week; barring any pending minor issues (e.g. build wibbles) in the tree (which I do not think should be needed), the only thing I will commit is A) release notes and B) the version number changes. There will not likely be a 7.8.4-rc2, so this is a last call for any bugs you'd like to see fixed. I may have missed something -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Mon Dec 15 16:16:09 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 15 Dec 2014 17:16:09 +0100 Subject: Last call for 7.8.4 In-Reply-To: References: Message-ID: I will make the actual cabal 1.18 release today as the RCs looked good. On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp wrote: > > Hello *, > > I've just pushed a final round of patches to the 7.8 branch, including > the notorious Cabal fix for the -fPIC bug that was discussed earlier > in the week, and a handful of other bugfixes for ARM among other > things (/cc Joachim :) > > I am planning on making the final 7.8.4 release this week; barring any > pending minor issues (e.g. build wibbles) in the tree (which I do not > think should be needed), the only thing I will commit is A) release > notes and B) the version number changes. > > There will not likely be a 7.8.4-rc2, so this is a last call for any > bugs you'd like to see fixed. I may have missed something > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Dec 15 16:33:01 2014 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 15 Dec 2014 11:33:01 -0500 Subject: performance regressions In-Reply-To: <1418659306.13183.9.camel@debian.org> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> <1418590074.1468.2.camel@joachim-breitner.de> <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> <1418633028.1489.16.camel@joachim-breitner.de> <87388glxas.fsf@gmail.com> <1418659306.13183.9.camel@debian.org> Message-ID: <87zjaokh4y.fsf@gmail.com> Joachim Breitner writes: > Hi, > > Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari: >> >> - Travis has not picked up on these errors. >> > >> > unfortunately, travis is slighly less useful since a few weeks due to >> > T5681 failing (possibly due to the use of LLVM-3.4), but I?m still >> > waiting for an reply on that issue. >> > >> You aren't looking for a response from me on this, are you? I just >> checked and I don't seem to have any outstanding messages from you but >> it's entirely possible I overlooked something. > > this is independent of our arm issues, and I think a tad older; I did > not direct it to anyone specific. > > But I guess you are likely a person that can tell what?s wrong here: > > Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner: >> Compile failed (status 256) errors were: >> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages: >> >> /tmp/ghc16123_0/ghc16123_5.s:26:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:46:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:66:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:86:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:106:0: >> Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section} >> >> /tmp/ghc16123_0/ghc16123_5.s:126:0: >> Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section} >> >> *** unexpected failure for T5681(optllvm) >> >> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt >> >> Any ideas? > > Is it possible that this is due the llvm version used? Do we support 3.4 > in GHC HEAD? > > Using LLVM tools > llc : /usr/local/clang-3.4/bin/llc > opt : /usr/local/clang-3.4/bin/opt > > (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html > does not talk about GHC HEAD explicitly. Should I look at the 7.10 > row? Does that mean that 3.4 is not supported? Shouldn?t the build > system, or at least the compiler, fail harder and more helpfully in > this case?) > LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track of which section symbols with Internal linkage belong. I haven't had a chance to delve into this too deeply, however given that both 3.3 and 3.5 behave as expected I'm pretty sure this a bug. There are a few options here, a. Mark the `$def` symbols as ExternallyVisible, working around the issue at the expense of exposing internal symbols to the outside world. b. Mark LLVM 3.4 as unsupported At the moment I'm leaning towards (b) since I haven't had a chance to think through the implications of (a); if nothing else I suspect this wouldn't help the DLL symbol table size issues on Windows. Giving up on LLVM 3.4 might be unfortunate for a good number of users, however. Ultimately this underlines the need to package LLVM with GHC. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Dec 15 17:18:25 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 17:18:25 +0000 Subject: more parser conflicts? In-Reply-To: <20141213151934.03e1582d@sf> References: <547EFB2E.7080306@gmail.com> <20141213151934.03e1582d@sf> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F401D17@DB3PRD3001MB020.064d.mgd.msft.net> It would be great to have a patch that documents all this Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Sergei Trofimovich | Sent: 13 December 2014 15:20 | To: GHC Devs | Cc: Simon Marlow; Dr. ERDI Gergo; Mike Izbicki | Subject: Re: more parser conflicts? | | On Wed, 03 Dec 2014 11:59:42 +0000 | Simon Marlow wrote: | | > >> In unrelated work, I saw this scroll across when happy'ing the | parser: | > >> | > >>> shift/reduce conflicts: 60 | > >>> reduce/reduce conflicts: 16 | > >> | > >> These numbers seem quite a bit higher than what I last remember | > >> (which is something like 48 and 1, not 60 and 16). Does anyone | know why? | | 4 of reduce/reduce conflicts are result of exact rule copy: | https://phabricator.haskell.org/D569 | | > reduce/reduce conflicts are bad, especially so since they're | > undocumented. We don't know whether this introduced parser bugs or | not. | > Mike - could you look at this please? It was your commit that | > introduced the new conflicts. | | Agreed. | | 11 more reduce/reduce (of left 12) came from single scary rule added | in | > commit bc2289e13d9586be087bd8136943dc35a0130c88 | > ghc generates more user-friendly error messages | | exp10 :: { LHsExpr RdrName } | ... | | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text | "parse error in let binding: missing | required 'in'" | } | | The other rules add shift/reduce conflicts as follows: | | -- parsing error messages go below here | {- s/r:1 r/r:0 -} | | '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1 | $5) $ text | "parse error in | lambda: no expression after '->'" | {- s/r:1 r/r:0 -} | | '\\' {% parseErrorSDoc | (getLoc $1) $ text | "parse error: | naked lambda expression '\'" | } | {- s/r:1 r/r:0 -} | | 'let' binds 'in' {% parseErrorSDoc | (combineLocs $1 $2) $ text | "parse error in | let binding: missing expression after 'in'" | } | {- s/r:0 r/r:11 -} | | 'let' binds {% parseErrorSDoc | (combineLocs $1 $2) $ text | "parse error | in let binding: missing required 'in'" | } | {- s/r:0 r/r:0 -} | | 'let' {% parseErrorSDoc | (getLoc $1) $ text | "parse error: | naked let binding" | } | {- s/r:1 r/r:0 -} | | 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf | (combineLocs $1 $5) "else clause empty" } | {- s/r:2 r/r:0 -} | | 'if' exp optSemi 'then' exp optSemi {% hintIf | (combineLocs $1 $5) "missing required else clause" } | {- s/r:1 r/r:0 -} | | 'if' exp optSemi 'then' {% hintIf | (combineLocs $1 $2) "then clause empty" } | {- s/r:2 r/r:0 -} | | 'if' exp optSemi {% hintIf | (combineLocs $1 $2) "missing required then and else clauses" | {- s/r:2 r/r:0 -} | | 'if' {% hintIf (getLoc | $1) "naked if statement" } | {- s/r:0 r/r:0 -} | | 'case' exp 'of' {% parseErrorSDoc | (combineLocs $1 $2) $ text | "parse error | in case statement: missing list after '->'" | } | {- s/r:1 r/r:0 -} | | 'case' exp {% parseErrorSDoc | (combineLocs $1 $2) $ text | "parse error in | case statement: missing required 'of'" | } | {- s/r:1 r/r:0 -} | | 'case' {% parseErrorSDoc | (getLoc $1) $ text | "parse error: | naked case statement" | } | | Shift/reduces look harmless (like MultiWayIf ambiguity) as they seem | to resolve as shift correctly. | | -- | | Sergei From ggreif at gmail.com Mon Dec 15 17:27:08 2014 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 15 Dec 2014 18:27:08 +0100 Subject: [commit: ghc] master: Improve documentation of syntax for promoted lists (a972bdd) In-Reply-To: <20141215170805.21CC13A300@ghc.haskell.org> References: <20141215170805.21CC13A300@ghc.haskell.org> Message-ID: Hmm, shouldn't that be -XDataKinds (instead of -XTypeOperators)? also: umambiguous ---> unambiguous becuase ---> because Cheers, Gabor On 12/15/14, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/a972bddfc8115d80d774383a55202a293dc68595/ghc > >>--------------------------------------------------------------- > > commit a972bddfc8115d80d774383a55202a293dc68595 > Author: Simon Peyton Jones > Date: Mon Dec 15 17:08:29 2014 +0000 > > Improve documentation of syntax for promoted lists > > THe documentation in 7.9.4 of promoted list and tuple types was > misleading, which led to Trac #9882. This patch makes explicit > that only type-level with two or more elements can have the > quote omitted. > > >>--------------------------------------------------------------- > > a972bddfc8115d80d774383a55202a293dc68595 > compiler/parser/Parser.y | 8 ++++++-- > docs/users_guide/glasgow_exts.xml | 19 ++++++++++++++++--- > 2 files changed, 22 insertions(+), 5 deletions(-) > > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > index bffe6e1..235d34a 100644 > --- a/compiler/parser/Parser.y > +++ b/compiler/parser/Parser.y > @@ -1483,6 +1483,10 @@ atype :: { LHsType RdrName } > [mo $2,mc $4] } > | SIMPLEQUOTE var { sLL $1 $> $ HsTyVar $ > unLoc $2 } > > + -- Two or more [ty, ty, ty] must be a promoted list type, just as > + -- if you had written '[ty, ty, ty] > + -- (One means a list type, zero means the list type constructor, > + -- so you have to quote those.) > | '[' ctype ',' comma_types1 ']' {% ams (sLL $1 $> $ > HsExplicitListTy > placeHolderKind ($2 : > $4)) > [mo $1, mj AnnComma $3,mc > $5] } > @@ -1503,11 +1507,11 @@ inst_types1 :: { [LHsType RdrName] } > | inst_type ',' inst_types1 {% addAnnotation (gl $1) AnnComma > (gl $2) > >> return ($1 : $3) } > > -comma_types0 :: { [LHsType RdrName] } > +comma_types0 :: { [LHsType RdrName] } -- Zero or more: ty,ty,ty > : comma_types1 { $1 } > | {- empty -} { [] } > > -comma_types1 :: { [LHsType RdrName] } > +comma_types1 :: { [LHsType RdrName] } -- One or more: ty,ty,ty > : ctype { [$1] } > | ctype ',' comma_types1 {% addAnnotation (gl $1) AnnComma > (gl $2) > >> return ($1 : $3) } > diff --git a/docs/users_guide/glasgow_exts.xml > b/docs/users_guide/glasgow_exts.xml > index e12703f..7edca07 100644 > --- a/docs/users_guide/glasgow_exts.xml > +++ b/docs/users_guide/glasgow_exts.xml > @@ -6882,9 +6882,9 @@ is a single quote. > > > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > From simonpj at microsoft.com Mon Dec 15 17:39:30 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 17:39:30 +0000 Subject: [commit: ghc] master: Improve documentation of syntax for promoted lists (a972bdd) In-Reply-To: References: <20141215170805.21CC13A300@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F401E86@DB3PRD3001MB020.064d.mgd.msft.net> Ah yes, thanks; TypeOperators is needed for the (':), but DataKinds for everything else. I'll modify. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Gabor Greif | Sent: 15 December 2014 17:27 | To: ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Improve documentation of syntax for | promoted lists (a972bdd) | | Hmm, shouldn't that be -XDataKinds (instead of -XTypeOperators)? | | | also: | umambiguous ---> unambiguous | becuase ---> because | | Cheers, | | Gabor | | On 12/15/14, git at git.haskell.org wrote: | > Repository : ssh://git at git.haskell.org/ghc | > | > On branch : master | > Link : | > | http://ghc.haskell.org/trac/ghc/changeset/a972bddfc8115d80d774383a5520 | > 2a293dc68595/ghc | > | >>--------------------------------------------------------------- | > | > commit a972bddfc8115d80d774383a55202a293dc68595 | > Author: Simon Peyton Jones | > Date: Mon Dec 15 17:08:29 2014 +0000 | > | > Improve documentation of syntax for promoted lists | > | > THe documentation in 7.9.4 of promoted list and tuple types was | > misleading, which led to Trac #9882. This patch makes explicit | > that only type-level with two or more elements can have the | > quote omitted. | > | > | >>--------------------------------------------------------------- | > | > a972bddfc8115d80d774383a55202a293dc68595 | > compiler/parser/Parser.y | 8 ++++++-- | > docs/users_guide/glasgow_exts.xml | 19 ++++++++++++++++--- | > 2 files changed, 22 insertions(+), 5 deletions(-) | > | > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y | index | > bffe6e1..235d34a 100644 | > --- a/compiler/parser/Parser.y | > +++ b/compiler/parser/Parser.y | > @@ -1483,6 +1483,10 @@ atype :: { LHsType RdrName } | > [mo $2,mc | $4] } | > | SIMPLEQUOTE var { sLL $1 $> $ | HsTyVar $ | > unLoc $2 } | > | > + -- Two or more [ty, ty, ty] must be a promoted list type, | just as | > + -- if you had written '[ty, ty, ty] | > + -- (One means a list type, zero means the list type | constructor, | > + -- so you have to quote those.) | > | '[' ctype ',' comma_types1 ']' {% ams (sLL $1 $> $ | > HsExplicitListTy | > | placeHolderKind ($2 : | > $4)) | > [mo $1, mj | AnnComma | > $3,mc $5] } @@ -1503,11 +1507,11 @@ inst_types1 :: { [LHsType | RdrName] | > } | > | inst_type ',' inst_types1 {% addAnnotation (gl $1) | AnnComma | > (gl $2) | > >> return ($1 : $3) } | > | > -comma_types0 :: { [LHsType RdrName] } | > +comma_types0 :: { [LHsType RdrName] } -- Zero or more: ty,ty,ty | > : comma_types1 { $1 } | > | {- empty -} { [] } | > | > -comma_types1 :: { [LHsType RdrName] } | > +comma_types1 :: { [LHsType RdrName] } -- One or more: ty,ty,ty | > : ctype { [$1] } | > | ctype ',' comma_types1 {% addAnnotation (gl $1) | AnnComma | > (gl $2) | > >> return ($1 : $3) } | diff | > --git a/docs/users_guide/glasgow_exts.xml | > b/docs/users_guide/glasgow_exts.xml | > index e12703f..7edca07 100644 | > --- a/docs/users_guide/glasgow_exts.xml | > +++ b/docs/users_guide/glasgow_exts.xml | > @@ -6882,9 +6882,9 @@ is a single quote. | > | > | > | > | > _______________________________________________ | > ghc-commits mailing list | > ghc-commits at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-commits | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Dec 15 17:42:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Dec 2014 17:42:03 +0000 Subject: =?utf-8?B?UkU6IFtEaWZmdXNpb25dIFtCdWlsZCBGYWlsZWRdIHJHSEMzZjg3ODY2YWQ1?= =?utf-8?B?MzY6IEZpeCBkbGwtc3BsaXQgcHJvYmxlbSB3aXRoIHBhdGNoICdNYWtlIENv?= =?utf-8?B?cmUgTGludCBjaGVjayBmb3IgbG9jYWxseS1ib3VuZOKApg==?= In-Reply-To: <20141215172818.81003.36459@phabricator.haskell.org> References: <20141215172818.81003.36459@phabricator.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F401EAE@DB3PRD3001MB020.064d.mgd.msft.net> This failure is in STM!! I don't think that can be my fault :-( | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 15 December 2014 17:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound? | | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound?! | | USERS | simonpj (Author) | GHC - Core/System FC (Auditor) | GHC - Driver (Auditor) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC3f87866ad536 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type | checker/inferencer From austin at well-typed.com Mon Dec 15 17:43:27 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Dec 2014 11:43:27 -0600 Subject: =?UTF-8?Q?Re=3A_=5BDiffusion=5D_=5BBuild_Failed=5D_rGHC3f87866ad536=3A_Fix?= =?UTF-8?Q?_dll=2Dsplit_problem_with_patch_=27Make_Core_Lint_check_for_loca?= =?UTF-8?Q?lly=2Dbound=E2=80=A6?= In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F401EAE@DB3PRD3001MB020.064d.mgd.msft.net> References: <20141215172818.81003.36459@phabricator.haskell.org> <618BE556AADD624C9C918AA5D5911BEF3F401EAE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yeah, this was what I was referring to when we were talking when I said "I'm going to kick myself if I broke the build" this morning :) I broke the build. Therefore, I will fix it and then kick myself. Fix incoming. On Mon, Dec 15, 2014 at 11:42 AM, Simon Peyton Jones wrote: > This failure is in STM!! I don't think that can be my fault :-( > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 15 December 2014 17:28 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split > | problem with patch 'Make Core Lint check for locally-bound? > | > | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split > | problem with patch 'Make Core Lint check for locally-bound?! > | > | USERS > | simonpj (Author) > | GHC - Core/System FC (Auditor) > | GHC - Driver (Auditor) > | GHC - Type checker/inferencer (Auditor) > | > | COMMIT > | https://phabricator.haskell.org/rGHC3f87866ad536 > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type > | checker/inferencer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Mon Dec 15 17:53:30 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Dec 2014 11:53:30 -0600 Subject: =?UTF-8?Q?Re=3A_=5BDiffusion=5D_=5BBuild_Failed=5D_rGHC3f87866ad536=3A_Fix?= =?UTF-8?Q?_dll=2Dsplit_problem_with_patch_=27Make_Core_Lint_check_for_loca?= =?UTF-8?Q?lly=2Dbound=E2=80=A6?= In-Reply-To: References: <20141215172818.81003.36459@phabricator.haskell.org> <618BE556AADD624C9C918AA5D5911BEF3F401EAE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Should be fixed, sorry for the annoyance! On Mon, Dec 15, 2014 at 11:43 AM, Austin Seipp wrote: > Yeah, this was what I was referring to when we were talking when I > said "I'm going to kick myself if I broke the build" this morning :) > > I broke the build. Therefore, I will fix it and then kick myself. > > Fix incoming. > > On Mon, Dec 15, 2014 at 11:42 AM, Simon Peyton Jones > wrote: >> This failure is in STM!! I don't think that can be my fault :-( >> >> | -----Original Message----- >> | From: noreply at phabricator.haskell.org >> | [mailto:noreply at phabricator.haskell.org] >> | Sent: 15 December 2014 17:28 >> | To: Simon Peyton Jones >> | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split >> | problem with patch 'Make Core Lint check for locally-bound? >> | >> | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split >> | problem with patch 'Make Core Lint check for locally-bound?! >> | >> | USERS >> | simonpj (Author) >> | GHC - Core/System FC (Auditor) >> | GHC - Driver (Auditor) >> | GHC - Type checker/inferencer (Auditor) >> | >> | COMMIT >> | https://phabricator.haskell.org/rGHC3f87866ad536 >> | >> | EMAIL PREFERENCES >> | https://phabricator.haskell.org/settings/panel/emailpreferences/ >> | >> | To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type >> | checker/inferencer >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From kolmodin at gmail.com Mon Dec 15 19:05:29 2014 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Mon, 15 Dec 2014 23:05:29 +0400 Subject: Last call for 7.8.4 In-Reply-To: References: Message-ID: 2014-12-15 18:28 GMT+03:00 Austin Seipp : > > Hello *, > > I've just pushed a final round of patches to the 7.8 branch, including > the notorious Cabal fix for the -fPIC bug that was discussed earlier > in the week, and a handful of other bugfixes for ARM among other > things (/cc Joachim :) > Please also consider https://phabricator.haskell.org/D554 Fixes a small but annoying bug with bash completion for 7.8. Should be very low risk as it only affects the --show-options flag. > I am planning on making the final 7.8.4 release this week; barring any > pending minor issues (e.g. build wibbles) in the tree (which I do not > think should be needed), the only thing I will commit is A) release > notes and B) the version number changes. > > There will not likely be a 7.8.4-rc2, so this is a last call for any > bugs you'd like to see fixed. I may have missed something > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Dec 15 21:15:40 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 15 Dec 2014 23:15:40 +0200 Subject: API Annotatons in a FunBind Message-ID: After individual FunBinds have been parsed, they are combined in getMonoBind. In the process, all the original FunBind fun_id's bar one are discarded, including its location. This causes a problem for source-to-source conversions of functions such as the following (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys Where there are compound RdrNames, and each has different spacing. I am proposing to add a (Maybe (Located id)) to the Match datatype to deal with this. data Match id body = Match Maybe (Located id) -- fun_id in subsequent function equations [LPat id] -- The patterns (Maybe (LHsType id)) -- A type signature for the result of the match -- Nothing after typechecking (GRHSs id body) Is this a problem? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Dec 15 23:00:36 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 16 Dec 2014 00:00:36 +0100 Subject: Last call for 7.8.4 In-Reply-To: References: Message-ID: Cabal 1.18.1.5 is out. On Mon, Dec 15, 2014 at 5:16 PM, Johan Tibell wrote: > > I will make the actual cabal 1.18 release today as the RCs looked good. > > On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp > wrote: >> >> Hello *, >> >> I've just pushed a final round of patches to the 7.8 branch, including >> the notorious Cabal fix for the -fPIC bug that was discussed earlier >> in the week, and a handful of other bugfixes for ARM among other >> things (/cc Joachim :) >> >> I am planning on making the final 7.8.4 release this week; barring any >> pending minor issues (e.g. build wibbles) in the tree (which I do not >> think should be needed), the only thing I will commit is A) release >> notes and B) the version number changes. >> >> There will not likely be a 7.8.4-rc2, so this is a last call for any >> bugs you'd like to see fixed. I may have missed something >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > -------------- next parFrom eir at cis.upenn.edu Tue Dec 16 04:48:35 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Dec 2014 23:48:35 -0500 Subject: performance regressions In-Reply-To: <87zjaokh4y.fsf@gmail.com> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> <1418590074.1468.2.camel@joachim-breitner.de> <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> <1418633028.1489.16.camel@joachim-breitner.de> <87388glxas.fsf@gmail.com> <1418659306.13183.9.camel@debian.org> <87zjaokh4y.fsf@gmail.com> Message-ID: I've made progress, but still need some help. It turns out that a monadic combinator (that I wrote) is mostly responsible: > zipWithAndUnzipM :: Monad m > => (a -> b -> m (c, d)) -> [a] -> [b] -> m ([c], [d]) > zipWithAndUnzipM f (x:xs) (y:ys) > = do { (c, d) <- f x y > ; (cs, ds) <- zipWithAndUnzipM f xs ys > ; return (c:cs, d:ds) } > zipWithAndUnzipM _ _ _ = return ([], []) > Using this combinator instead of writing the algorithm directly cost me 30% allocation overhead! Can anyone tell me: why? Have I made some horrible mistake in the implementation? And, relatedly: how can I fix this? I want to learn from this experience how to avoid this problem next time... Unfortunately, my commit causes 50% overhead, not 30%, so I'm not out of the woods yet. Hopefully, another 20% of good news tomorrow. Thanks! Richard On Dec 15, 2014, at 11:33 AM, Ben Gamari wrote: > Joachim Breitner writes: > >> Hi, >> >> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari: >>>>> - Travis has not picked up on these errors. >>>> >>>> unfortunately, travis is slighly less useful since a few weeks due to >>>> T5681 failing (possibly due to the use of LLVM-3.4), but I?m still >>>> waiting for an reply on that issue. >>>> >>> You aren't looking for a response from me on this, are you? I just >>> checked and I don't seem to have any outstanding messages from you but >>> it's entirely possible I overlooked something. >> >> this is independent of our arm issues, and I think a tad older; I did >> not direct it to anyone specific. >> >> But I guess you are likely a person that can tell what?s wrong here: >> >> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner: >>> Compile failed (status 256) errors were: >>> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages: >>> >>> /tmp/ghc16123_0/ghc16123_5.s:26:0: >>> Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section} >>> >>> /tmp/ghc16123_0/ghc16123_5.s:46:0: >>> Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section} >>> >>> /tmp/ghc16123_0/ghc16123_5.s:66:0: >>> Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section} >>> >>> /tmp/ghc16123_0/ghc16123_5.s:86:0: >>> Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section} >>> >>> /tmp/ghc16123_0/ghc16123_5.s:106:0: >>> Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section} >>> >>> /tmp/ghc16123_0/ghc16123_5.s:126:0: >>> Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section} >>> >>> *** unexpected failure for T5681(optllvm) >>> >>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt >>> >>> Any ideas? >> >> Is it possible that this is due the llvm version used? Do we support 3.4 >> in GHC HEAD? >> >> Using LLVM tools >> llc : /usr/local/clang-3.4/bin/llc >> opt : /usr/local/clang-3.4/bin/opt >> >> (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html >> does not talk about GHC HEAD explicitly. Should I look at the 7.10 >> row? Does that mean that 3.4 is not supported? Shouldn?t the build >> system, or at least the compiler, fail harder and more helpfully in >> this case?) >> > LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track > of which section symbols with Internal linkage belong. I haven't had a > chance to delve into this too deeply, however given that both 3.3 and > 3.5 behave as expected I'm pretty sure this a bug. There are a few > options here, > > a. Mark the `$def` symbols as ExternallyVisible, working around the > issue at the expense of exposing internal symbols to the outside > world. > > b. Mark LLVM 3.4 as unsupported > > At the moment I'm leaning towards (b) since I haven't had a chance to > think through the implications of (a); if nothing else I suspect this > wouldn't help the DLL symbol table size issues on Windows. Giving up on > LLVM 3.4 might be unfortunate for a good number of users, however. > > Ultimately this underlines the need to package LLVM with GHC. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Tue Dec 16 07:59:41 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 16 Dec 2014 08:59:41 +0100 Subject: performance regressions In-Reply-To: References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> Message-ID: <201412160859.41292.jan.stolarek@p.lodz.pl> > Using this combinator instead of writing the algorithm directly cost me 30% > allocation overhead! What does your algorithm look like when you write it directly? Something like this: flatten_many fmode roles tys = unzip `liftM` mapM go (zip roles tys) where go (Nominal,ty) = flatten_one (fmode { fe_eq_rel = NomEq }) ty go (Representational,ty) = flatten_one (fmode { fe_eq_rel = ReprEq }) ty go (Phantom, ty) = -- See Note [Phantoms in the flattener] return (ty, mkTcPhantomCo ty ty) ? Maybe this has something to do with `zipWithAndUnzipM` not being tail-recursive vs. direct version being able to fuse intermediate lists? Janek From mail at joachim-breitner.de Tue Dec 16 09:01:30 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 16 Dec 2014 10:01:30 +0100 Subject: performance regressions In-Reply-To: References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> <1418590074.1468.2.camel@joachim-breitner.de> <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> <1418633028.1489.16.camel@joachim-breitner.de> <87388glxas.fsf@gmail.com> <1418659306.13183.9.camel@debian.org> <87zjaokh4y.fsf@gmail.com> Message-ID: <1418720490.1446.1.camel@joachim-breitner.de> Hi, Am Montag, den 15.12.2014, 23:48 -0500 schrieb Richard Eisenberg: > Can anyone tell me: why? Have I made some horrible mistake in the implementation? > And, relatedly: how can I fix this? I want to learn from this experience how to avoid this problem next time... another guess (without looking at the code, sorry): Are they in the same module? I.e., can GHC specialize the code to your particular Monad? Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From alan.zimm at gmail.com Tue Dec 16 10:51:21 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 16 Dec 2014 12:51:21 +0200 Subject: Are empty statement lists allowed in recursive do? Possible bug Message-ID: I am trying to work out empirically whether empty statement lists are allowed in a stmtlist, and one of the points these are used in Parser.y is for recursive do. If I try to load the following ---------------- {-# LANGUAGE RecursiveDo #-} bar :: IO () bar = do rec {} return () ----------------------- into GHCI, I get a "Prelude.head: empty list" panic. I think this is related to `rnRecStmtsAndThen` If I try --------------------- bar :: IO () bar = do do {} return () ----------------------- I get a warning about empty do statements not being allowed. Hence the question as to wether recursive do should be allowed to have an empty statement list. I am trying to manage the API annotations for semicolons in statement lists, and the current way it is being parsed makes this difficult, I would prefer to simplify it to something like how import decls are parsed, which can also have multiple semicolons in between. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Dec 16 13:31:40 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Dec 2014 13:31:40 +0000 Subject: FW: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <057.4389e9bda1c3a08261b134912416f320@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> <057.4389e9bda1c3a08261b134912416f320@haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F402B3F@DB3PRD3001MB020.064d.mgd.msft.net> Devs I wish there was a way to convert Trac identities to people's name and email addresses. (For committers there is, https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but no one else.) As Eric says, I think most people would be happy to do that. I like addressing real people. And syncing up with separate email conversations is also a challenge. Simon -----Original Message----- From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of GHC Sent: 16 December 2014 10:46 Cc: ghc-tickets at haskell.org Subject: Re: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+---------------------------------- -------------------------------------+--- Comment (by gridaphobe): simonpj: This is Eric Seidel (eric at seidel.io). I've told trac my name and email, but it doesn't seem to expose them to others! I'd be happy to tick a "make my name+email public" box if there's one I'm missing somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets at haskell.org http://www.haskell.org/mailman/listinfo/ghc-tickets From simonpj at microsoft.com Tue Dec 16 13:49:05 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Dec 2014 13:49:05 +0000 Subject: performance regressions In-Reply-To: References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <1418477544.27954.1.camel@joachim-breitner.de> <4A18E34C-CA29-4080-AFF4-5CF920237D1F@cis.upenn.edu> <1418590074.1468.2.camel@joachim-breitner.de> <8C85280E-7A32-4607-B5A0-DDD85B34EC3F@cis.upenn.edu> <1418633028.1489.16.camel@joachim-breitner.de> <87388glxas.fsf@gmail.com> <1418659306.13183.9.camel@debian.org> <87zjaokh4y.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F402BDC@DB3PRD3001MB020.064d.mgd.msft.net> | Using this combinator instead of writing the algorithm directly cost | me 30% allocation overhead! That seems surprising. I'd build a profiled compiler (GhcProfiled=YES) and see what it says. If it increases allocation by 30% overall, there must be a LOT of calls to this function. Should there be so many? S | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 16 December 2014 04:49 | To: Ben Gamari | Cc: Joachim Breitner; ghc-devs at haskell.org | Subject: Re: performance regressions | | I've made progress, but still need some help. | | It turns out that a monadic combinator (that I wrote) is mostly | responsible: | | > zipWithAndUnzipM :: Monad m | > => (a -> b -> m (c, d)) -> [a] -> [b] -> m ([c], | [d]) | > zipWithAndUnzipM f (x:xs) (y:ys) | > = do { (c, d) <- f x y | > ; (cs, ds) <- zipWithAndUnzipM f xs ys | > ; return (c:cs, d:ds) } | > zipWithAndUnzipM _ _ _ = return ([], []) | > | | Using this combinator instead of writing the algorithm directly cost | me 30% allocation overhead! | | Can anyone tell me: why? Have I made some horrible mistake in the | implementation? | And, relatedly: how can I fix this? I want to learn from this | experience how to avoid this problem next time... | | Unfortunately, my commit causes 50% overhead, not 30%, so I'm not out | of the woods yet. Hopefully, another 20% of good news tomorrow. | | Thanks! | Richard | | On Dec 15, 2014, at 11:33 AM, Ben Gamari wrote: | | > Joachim Breitner writes: | > | >> Hi, | >> | >> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari: | >>>>> - Travis has not picked up on these errors. | >>>> | >>>> unfortunately, travis is slighly less useful since a few weeks | due | >>>> to | >>>> T5681 failing (possibly due to the use of LLVM-3.4), but I'm | still | >>>> waiting for an reply on that issue. | >>>> | >>> You aren't looking for a response from me on this, are you? I just | >>> checked and I don't seem to have any outstanding messages from you | >>> but it's entirely possible I overlooked something. | >> | >> this is independent of our arm issues, and I think a tad older; I | did | >> not direct it to anyone specific. | >> | >> But I guess you are likely a person that can tell what's wrong | here: | >> | >> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner: | >>> Compile failed (status 256) errors were: | >>> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages: | >>> | >>> /tmp/ghc16123_0/ghc16123_5.s:26:0: | >>> Error: can't resolve `.rodata' {.rodata section} - | >>> `Main_zdwwork_info$def' {.text section} | >>> | >>> /tmp/ghc16123_0/ghc16123_5.s:46:0: | >>> Error: can't resolve `.rodata' {.rodata section} - | >>> `Main_work_info$def' {.text section} | >>> | >>> /tmp/ghc16123_0/ghc16123_5.s:66:0: | >>> Error: can't resolve `.rodata' {.rodata section} - | >>> `Main_main1_info$def' {.text section} | >>> | >>> /tmp/ghc16123_0/ghc16123_5.s:86:0: | >>> Error: can't resolve `.rodata' {.rodata section} - | >>> `Main_main_info$def' {.text section} | >>> | >>> /tmp/ghc16123_0/ghc16123_5.s:106:0: | >>> Error: can't resolve `.rodata' {.rodata section} - | >>> `Main_main2_info$def' {.text section} | >>> | >>> /tmp/ghc16123_0/ghc16123_5.s:126:0: | >>> Error: can't resolve `.rodata' {.rodata section} - | >>> `ZCMain_main_info$def' {.text section} | >>> | >>> *** unexpected failure for T5681(optllvm) | >>> | >>> https://s3.amazonaws.com/archive.travis- | ci.org/jobs/42557559/log.txt | >>> | >>> Any ideas? | >> | >> Is it possible that this is due the llvm version used? Do we | support | >> 3.4 in GHC HEAD? | >> | >> Using LLVM tools | >> llc : /usr/local/clang-3.4/bin/llc | >> opt : /usr/local/clang-3.4/bin/opt | >> | >> (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm- | backend. | >> html does not talk about GHC HEAD explicitly. Should I look at the | >> 7.10 row? Does that mean that 3.4 is not supported? Shouldn't the | >> build system, or at least the compiler, fail harder and more | >> helpfully in this case?) | >> | > LLVM 3.4 appears to have an unfortunate behavior whereby it will | lose | > track of which section symbols with Internal linkage belong. I | > haven't had a chance to delve into this too deeply, however given | that | > both 3.3 and | > 3.5 behave as expected I'm pretty sure this a bug. There are a few | > options here, | > | > a. Mark the `$def` symbols as ExternallyVisible, working around the | > issue at the expense of exposing internal symbols to the outside | > world. | > | > b. Mark LLVM 3.4 as unsupported | > | > At the moment I'm leaning towards (b) since I haven't had a chance | to | > think through the implications of (a); if nothing else I suspect | this | > wouldn't help the DLL symbol table size issues on Windows. Giving up | > on LLVM 3.4 might be unfortunate for a good number of users, | however. | > | > Ultimately this underlines the need to package LLVM with GHC. | > | > Cheers, | > | > - Ben | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Tue Dec 16 13:58:16 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 16 Dec 2014 14:58:16 +0100 Subject: Customizing Phab Message-ID: <201412161458.16201.jan.stolarek@p.lodz.pl> After working with Phab for a while I realize I'd like to customize layout of a revision. When I work with a revision I most often read comments and source code and write my replies (often based on comments). The problem is that comments are located at the top of a page whereas the text field for writing a reply is located at the bottom. I wonder if there is a way to: a) collapse "Revision Update History", "Local Commits", "Table of Contents" and "Open Revisions Affecting These Files"? b) or move them below "Leap Into Action" section ? I can't find any such settings so I suppose that's not possible by default. Is there any way to extend Phab's functionality do allow customizing layout in a way described above? Janek From eir at cis.upenn.edu Tue Dec 16 14:59:20 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 16 Dec 2014 09:59:20 -0500 Subject: performance regressions In-Reply-To: <201412160859.41292.jan.stolarek@p.lodz.pl> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> Message-ID: <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> On Dec 16, 2014, at 2:59 AM, Jan Stolarek wrote: > What does your algorithm look like when you write it directly? Something like this: > > flatten_many fmode roles tys > = unzip `liftM` mapM go (zip roles tys) > where > go (Nominal,ty) = flatten_one (fmode { fe_eq_rel = NomEq }) ty > go (Representational,ty) = flatten_one (fmode { fe_eq_rel = ReprEq }) ty > go (Phantom, ty) = -- See Note [Phantoms in the flattener] > return (ty, mkTcPhantomCo ty ty) > > ? > > Maybe this has something to do with `zipWithAndUnzipM` not being tail-recursive vs. direct version > being able to fuse intermediate lists? My direct version is even uglier: > flatten_many fmode roles tys > = go roles tys > where > go (Nominal:rs) (ty:tys) > = do { (xi, co) <- flatten_one (setFEEqRel fmode NomEq) ty > ; (xis, cos) <- go rs tys > ; return (xi:xis, co:cos) } > go (Representational:rs) (ty:tys) > = do { (xi, co) <- flatten_one (setFEEqRel fmode ReprEq) ty > ; (xis, cos) <- go rs tys > ; return (xi:xis, co:cos) } > go (Phantom:rs) (ty:tys) > = do { (xis, cos) <- go rs tys > ; -- See Note [Phantoms in the flattener] > return (ty:xis, mkTcPhantomCo ty ty:cos) } > go _ _ = return ([], []) I could refactor to make it better, but I would be worried that the version you wrote would suffer from the same problems as zipWithAndUnzipM. Will check to see, though. On Dec 16, 2014, at 4:01 AM, Joachim Breitner wrote: > another guess (without looking at the code, sorry): Are they in the same > module? I.e., can GHC specialize the code to your particular Monad? No, they're not in the same module. I could also try moving the zipWithAndUnzipM function to the same module, and even specializing it by hand to the right monad. Could that be preventing the fusing? On Dec 16, 2014, at 8:49 AM, Simon Peyton Jones wrote: > That seems surprising. I'd build a profiled compiler (GhcProfiled=YES) and see what it says. > > If it increases allocation by 30% overall, there must be a LOT of calls to this function. Should there be so many? I've been working from a profiled compiler. That's how I found that this function was the culprit -- it certainly wasn't my first guess! Yes, there are A LOT of calls: 7,106,808 to be exact. (The test case is perf/compiler/T9872a; the function is flatten_many). The number of calls doesn't vary from before my commit, though, so the raw number isn't the problem -- it's the allocation. I'll try turning some of these knobs to see where the difference is. Thanks, Richard From mail at joachim-breitner.de Tue Dec 16 15:41:58 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 16 Dec 2014 16:41:58 +0100 Subject: performance regressions In-Reply-To: <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> Message-ID: <1418744518.1446.4.camel@joachim-breitner.de> Hi, Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard Eisenberg: > On Dec 16, 2014, at 4:01 AM, Joachim Breitner wrote: > > > another guess (without looking at the code, sorry): Are they in the same > > module? I.e., can GHC specialize the code to your particular Monad? > No, they're not in the same module. I could also try moving the > zipWithAndUnzipM function to the same module, and even specializing it > by hand to the right monad. I did mean zipWithAndUnzipM, so maybe yes: Try that. (I find it hard to believe that any polymorphic monadic code should perform well, with those many calls to an unknown (>>=) with a function parameter, but maybe I?m too pessimistic here.) > Could that be preventing the fusing? There is not going to be any fusing here, at least not list fusion; that would require your code to be written in terms of functions with fusion rules. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From greg at gregweber.info Tue Dec 16 16:15:13 2014 From: greg at gregweber.info (Greg Weber) Date: Tue, 16 Dec 2014 08:15:13 -0800 Subject: Customizing Phab In-Reply-To: <201412161458.16201.jan.stolarek@p.lodz.pl> References: <201412161458.16201.jan.stolarek@p.lodz.pl> Message-ID: This is the most obvious UI problem with phab for me. github solves this nicely by using tabs. On Tue, Dec 16, 2014 at 5:58 AM, Jan Stolarek wrote: > > After working with Phab for a while I realize I'd like to customize layout > of a revision. When I > work with a revision I most often read comments and source code and write > my replies (often based > on comments). The problem is that comments are located at the top of a > page whereas the text > field for writing a reply is located at the bottom. I wonder if there is a > way to: > > a) collapse "Revision Update History", "Local Commits", "Table of > Contents" and "Open Revisions > Affecting These Files"? > b) or move them below "Leap Into Action" section ? > > I can't find any such settings so I suppose that's not possible by > default. Is there any way to > extend Phab's functionality do allow customizing layout in a way described > above? > > Janek > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Tue Dec 16 16:44:19 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 16 Dec 2014 17:44:19 +0100 Subject: Customizing Phab In-Reply-To: <201412161458.16201.jan.stolarek@p.lodz.pl> (Jan Stolarek's message of "Tue, 16 Dec 2014 14:58:16 +0100") References: <201412161458.16201.jan.stolarek@p.lodz.pl> Message-ID: <877fxr4k9o.fsf@gmail.com> On 2014-12-16 at 14:58:16 +0100, Jan Stolarek wrote: [...] > I can't find any such settings so I suppose that's not possible by > default. Is there any way to extend Phab's functionality do allow > customizing layout in a way described above? Not a direct answer to your question, but have you tried the 'z' hotkey (or "keyboard shortcut") while in a revision? It "cycles comment panel haunting modes" (see '?' hotkey for a list of other useful hotkeys). HTH, hvr From jan.stolarek at p.lodz.pl Tue Dec 16 18:05:27 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 16 Dec 2014 19:05:27 +0100 Subject: Customizing Phab In-Reply-To: <877fxr4k9o.fsf@gmail.com> References: <201412161458.16201.jan.stolarek@p.lodz.pl> <877fxr4k9o.fsf@gmail.com> Message-ID: <201412161905.27610.jan.stolarek@p.lodz.pl> > Not a direct answer to your question, but have you tried the 'z' hotkey > (or "keyboard shortcut") while in a revision? It "cycles comment panel > haunting modes" (see '?' hotkey for a list of other useful hotkeys). I wasn't aware of that. This helps to some extent. Being able to hide unused panels would still be nice. Janek From austin at well-typed.com Tue Dec 16 21:11:26 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 16 Dec 2014 15:11:26 -0600 Subject: GHC Weekly News - 2014/12/16 Message-ID: Hi *, time for another piece of the GHC weekly news! - Joachim Breitner has gotten the new GHC 7.8.4 package to tentatively build on ARM quite easily for Debian. Austin also took the liberty of merging all the needed patches; they'll be part of the 7.8.4 release https://www.haskell.org/pipermail/ghc-devs/2014-December/007608.html - Greg Weber announced he's taken the time to set up a Docker image for GHC development - if you're on Linux, Greg's image should help you get up to speed with a GHC development environment in minutes! https://www.haskell.org/pipermail/ghc-devs/2014-December/007606.html - Lennart Kolmodin has spent time working on autocompletion for GHC, and 7.10 will ship with bash completion scripts - which package maintainers and distributions can now ship for their users. Thank you Lennart! https://www.haskell.org/pipermail/ghc-devs/2014-December/007614.html - Adam Gundry has a question about the new type checker plugin infrastructure; in particular - how do we deal with the serialization of type checker evidence that plugins may want to create or pass around on their own? Richard, Simon and Iavor weigh in. https://www.haskell.org/pipermail/ghc-devs/2014-December/007626.html - For the past few days, Richard Eisenberg has been hunting a performance regression in the compiler. After profiling, discussion on IRC and elsewhere, Richard has finally made some headway, and discovered one of the 'hot spots' in his patch. Unfortunately the battle isn't quite over just yet, and the hunt for a few more % increase remains. https://www.haskell.org/pipermail/ghc-devs/2014-December/007645.html - David Spies has hit a very strange situation with GHC 7.8.3 running out of memory. But it turned out this was a change in 7.8, in relation to how stacks were managed. Phew! https://www.haskell.org/pipermail/ghc-devs/2014-December/007646.html - Austin made a final call for 7.8.4 bugfixes. He plans on making the final release this week, if nobody has any other major complaints. https://www.haskell.org/pipermail/ghc-devs/2014-December/007684.html Finally, in a slight change, we'll also be covering some notes from this week's meeting between GHC HQ (Austin, Simon PJ, SimonM, Herbert and Mikolaj), including... - The 7.10 RC1 looks like it's scheduled to occur this week still; all of our libraries and submodules are up-to-date, and we've taken the time to alert all of our maintainers about this. Thanks to Herbert for taking control of this! - We'll soon be implementing a new 'push hook' for the `ghc.git` repository: no more trailing whitespace. Since we've recently detabbed, and de-lhs-ified the tree, a knock-on effect was deleting trailing whitespace. Now that we've done a lot of this, we should take the time to enforce it - so they can't slip back in. - Austin will be landing Phab:D169 and Phab:D396 soon to get it into 7.10.1 RC1. - This week, Austin managed to secure two sponsors for GHC/Haskell.org. We've been given a wonderful set of ARM buildbots (running in the cloud!) and a new, incredibly powerful POWER8 machine to use (with over 170 hardware threads available, for scalability testing). Hooray for our friends at Online.net and RunAbove.com for helping us out! Closed tickets this week include: #9871, #9808, #9870, #9605, #9874, #9872, #9090, #9404, #8240, #9567, #9566, #9583, #9117, #9882, #9884, #9372, #7942, #8951, #9817, #9620, #9336, #9523, #9552, #8988, #9390, #9415, #9371, #7143, #9563, #8778, #4428, #4896, #9393, #9169, #7015, #8943, #8621, #9132, #9857, #8024, #9831, and #9888. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From alan.zimm at gmail.com Tue Dec 16 21:37:35 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 16 Dec 2014 23:37:35 +0200 Subject: API Annotations D538 call for review Message-ID: Hi All https://phabricator.haskell.org/D538 is now ready for review/merge. It contains a number of small changes based on actually using the API annotations in ghc-exactprint [1] which is now able to perfectly reproduce the original source using only the ParsedSource AST and API annotations. [1] https://github.com/alanz/ghc-exactprint/tree/wip Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Dec 16 21:45:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 16 Dec 2014 16:45:36 -0500 Subject: performance regressions In-Reply-To: <1418744518.1446.4.camel@joachim-breitner.de> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> Message-ID: I've learned several very interesting things in this analysis. - Inlining polymorphic methods is very important. Here are some data points to back up that claim: * Original implementation using zipWithAndUnzipM: 8,472,613,440 bytes allocated in the heap * Adding {-# INLINE #-} to the definition thereof: 6,639,253,488 bytes allocated in the heap * Using `inline` at call site to force inlining: 6,281,539,792 bytes allocated in the heap The middle step above allowed GHC to specialize zipWithAndUnzipM to my particular monad, but GHC didn't see fit to actually inline the function. Using `inline` forced it, to good effect. (I did not collect data on code sizes, but it wouldn't be hard to.) By comparison: * Hand-written recursion: 6,587,809,112 bytes allocated in the heap Interestingly, this is *not* the best result! Conclusion: We should probably add INLINE pragmas to Util and MonadUtils. - I then looked at rejiggering the algorithm to keep the common case fast. This had a side effect of changing the zipWithAndUnzipM to mapAndUnzipM, from Control.Monad. To my surprise, this brought disaster! * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes allocated in the heap * Hand-written recursion: 5,848,602,848 bytes allocated in the heap That last number is better than the numbers above because of the algorithm streamlining. But, the inadequacy of mapAndUnzipM surprised me -- it already has an INLINE pragma in Control.Monad of course. Looking at -ddump-simpl, it seems that mapAndUnzipM was indeed getting inlined, but a call to `map` remained, perhaps causing extra allocation. Conclusion: We should examine the implementation of mapAndUnzipM (and similar functions) in Control.Monad. Is it as fast as possible? In the end, I was unable to bring the allocation numbers down to where they were before my work. This is because the flattener now deals in roles. Most of its behavior is the same between nominal and representational roles, so it seems silly (though very possible) to specialize the code to nominal to keep that path fast. Instead, I identified one key spot and made that go fast. Thus, there is a 7% bump to memory usage on very-type-family-heavy code, compared to before my commit on Friday. (On more ordinary code, there is no noticeable change.) Validating my patch locally now; will push when that's done. Thanks, Richard On Dec 16, 2014, at 10:41 AM, Joachim Breitner wrote: > Hi, > > > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard Eisenberg: >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner wrote: >> >>> another guess (without looking at the code, sorry): Are they in the same >>> module? I.e., can GHC specialize the code to your particular Monad? > >> No, they're not in the same module. I could also try moving the >> zipWithAndUnzipM function to the same module, and even specializing it >> by hand to the right monad. > > I did mean zipWithAndUnzipM, so maybe yes: Try that. > > (I find it hard to believe that any polymorphic monadic code should > perform well, with those many calls to an unknown (>>=) with a function > parameter, but maybe I?m too pessimistic here.) > > >> Could that be preventing the fusing? > > There is not going to be any fusing here, at least not list fusion; that > would require your code to be written in terms of functions with fusion > rules. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Wed Dec 17 05:15:11 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 17 Dec 2014 00:15:11 -0500 Subject: performance regressions In-Reply-To: References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> Message-ID: Would specialize pragmas also have these performance improvements, or is inline needed? On Tue, Dec 16, 2014 at 4:45 PM, Richard Eisenberg wrote: > > I've learned several very interesting things in this analysis. > > - Inlining polymorphic methods is very important. Here are some data > points to back up that claim: > * Original implementation using zipWithAndUnzipM: 8,472,613,440 > bytes allocated in the heap > * Adding {-# INLINE #-} to the definition thereof: 6,639,253,488 > bytes allocated in the heap > * Using `inline` at call site to force inlining: 6,281,539,792 > bytes allocated in the heap > > The middle step above allowed GHC to specialize zipWithAndUnzipM to my > particular monad, but GHC didn't see fit to actually inline the function. > Using `inline` forced it, to good effect. (I did not collect data on code > sizes, but it wouldn't be hard to.) > > By comparison: > * Hand-written recursion: 6,587,809,112 bytes allocated in the heap > Interestingly, this is *not* the best result! > > Conclusion: We should probably add INLINE pragmas to Util and MonadUtils. > > > - I then looked at rejiggering the algorithm to keep the common case fast. > This had a side effect of changing the zipWithAndUnzipM to mapAndUnzipM, > from Control.Monad. To my surprise, this brought disaster! > * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes allocated > in the heap > * Hand-written recursion: 5,848,602,848 bytes allocated > in the heap > > That last number is better than the numbers above because of the algorithm > streamlining. But, the inadequacy of mapAndUnzipM surprised me -- it > already has an INLINE pragma in Control.Monad of course. Looking at > -ddump-simpl, it seems that mapAndUnzipM was indeed getting inlined, but a > call to `map` remained, perhaps causing extra allocation. > > Conclusion: We should examine the implementation of mapAndUnzipM (and > similar functions) in Control.Monad. Is it as fast as possible? > > > > In the end, I was unable to bring the allocation numbers down to where > they were before my work. This is because the flattener now deals in roles. > Most of its behavior is the same between nominal and representational > roles, so it seems silly (though very possible) to specialize the code to > nominal to keep that path fast. Instead, I identified one key spot and made > that go fast. > > Thus, there is a 7% bump to memory usage on very-type-family-heavy code, > compared to before my commit on Friday. (On more ordinary code, there is no > noticeable change.) > > Validating my patch locally now; will push when that's done. > > Thanks, > Richard > > On Dec 16, 2014, at 10:41 AM, Joachim Breitner > wrote: > > > Hi, > > > > > > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard Eisenberg: > >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner > wrote: > >> > >>> another guess (without looking at the code, sorry): Are they in the > same > >>> module? I.e., can GHC specialize the code to your particular Monad? > > > >> No, they're not in the same module. I could also try moving the > >> zipWithAndUnzipM function to the same module, and even specializing it > >> by hand to the right monad. > > > > I did mean zipWithAndUnzipM, so maybe yes: Try that. > > > > (I find it hard to believe that any polymorphic monadic code should > > perform well, with those many calls to an unknown (>>=) with a function > > parameter, but maybe I?m too pessimistic here.) > > > > > >> Could that be preventing the fusing? > > > > There is not going to be any fusing here, at least not list fusion; that > > would require your code to be written in terms of functions with fusion > > rules. > > > > Greetings, > > Joachim > > > > -- > > Joachim ?nomeata? Breitner > > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > > Debian Developer: nomeata at debian.org > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Dec 17 09:15:07 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 17 Dec 2014 09:15:07 +0000 Subject: performance regressions In-Reply-To: References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F40363A@DB3PRD3001MB020.064d.mgd.msft.net> If you use INLINEABLE, that should make the function specialisable to a particular monad, even if it's in a different module. You shouldn't need INLINE for that. I don't understand the difference between cases (2) and (3). I am still suspicious of why there are so many calls to this one function that it, alone, is allocating a significant proportion of compilation of the entire run of GHC. Are you sure there isn't an algorithmic improvement to be had, to simply reduce the number of calls? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 16 December 2014 21:46 | To: Joachim Breitner | Cc: ghc-devs at haskell.org | Subject: Re: performance regressions | | I've learned several very interesting things in this analysis. | | - Inlining polymorphic methods is very important. Here are some data | points to back up that claim: | * Original implementation using zipWithAndUnzipM: 8,472,613,440 | bytes allocated in the heap | * Adding {-# INLINE #-} to the definition thereof: 6,639,253,488 | bytes allocated in the heap | * Using `inline` at call site to force inlining: 6,281,539,792 | bytes allocated in the heap | | The middle step above allowed GHC to specialize zipWithAndUnzipM to my | particular monad, but GHC didn't see fit to actually inline the | function. Using `inline` forced it, to good effect. (I did not collect | data on code sizes, but it wouldn't be hard to.) | | By comparison: | * Hand-written recursion: 6,587,809,112 bytes allocated in the | heap | Interestingly, this is *not* the best result! | | Conclusion: We should probably add INLINE pragmas to Util and | MonadUtils. | | | - I then looked at rejiggering the algorithm to keep the common case | fast. This had a side effect of changing the zipWithAndUnzipM to | mapAndUnzipM, from Control.Monad. To my surprise, this brought | disaster! | * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes | allocated in the heap | * Hand-written recursion: 5,848,602,848 bytes | allocated in the heap | | That last number is better than the numbers above because of the | algorithm streamlining. But, the inadequacy of mapAndUnzipM surprised | me -- it already has an INLINE pragma in Control.Monad of course. | Looking at -ddump-simpl, it seems that mapAndUnzipM was indeed getting | inlined, but a call to `map` remained, perhaps causing extra | allocation. | | Conclusion: We should examine the implementation of mapAndUnzipM (and | similar functions) in Control.Monad. Is it as fast as possible? | | | | In the end, I was unable to bring the allocation numbers down to where | they were before my work. This is because the flattener now deals in | roles. Most of its behavior is the same between nominal and | representational roles, so it seems silly (though very possible) to | specialize the code to nominal to keep that path fast. Instead, I | identified one key spot and made that go fast. | | Thus, there is a 7% bump to memory usage on very-type-family-heavy | code, compared to before my commit on Friday. (On more ordinary code, | there is no noticeable change.) | | Validating my patch locally now; will push when that's done. | | Thanks, | Richard | | On Dec 16, 2014, at 10:41 AM, Joachim Breitner wrote: | | > Hi, | > | > | > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard Eisenberg: | >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner wrote: | >> | >>> another guess (without looking at the code, sorry): Are they in | the | >>> same module? I.e., can GHC specialize the code to your particular | Monad? | > | >> No, they're not in the same module. I could also try moving the | >> zipWithAndUnzipM function to the same module, and even specializing | >> it by hand to the right monad. | > | > I did mean zipWithAndUnzipM, so maybe yes: Try that. | > | > (I find it hard to believe that any polymorphic monadic code should | > perform well, with those many calls to an unknown (>>=) with a | > function parameter, but maybe I'm too pessimistic here.) | > | > | >> Could that be preventing the fusing? | > | > There is not going to be any fusing here, at least not list fusion; | > that would require your code to be written in terms of functions | with | > fusion rules. | > | > Greetings, | > Joachim | > | > -- | > Joachim "nomeata" Breitner | > mail at joachim-breitner.de * http://www.joachim-breitner.de/ | > Jabber: nomeata at joachim-breitner.de * GPG-Key: 0xF0FBF51F Debian | > Developer: nomeata at debian.org | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Wed Dec 17 11:02:10 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 17 Dec 2014 11:02:10 +0000 Subject: type-checker regression in GHC HEAD? In-Reply-To: <871tny4muo.fsf@gmail.com> References: <87h9wv5065.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF3F402B62@DB3PRD3001MB020.064d.mgd.msft.net> <87bnn34rp6.fsf@gmail.com> <871tny4muo.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F403826@DB3PRD3001MB020.064d.mgd.msft.net> Ah yes! A palpable bug thank you. Fixing.. S | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 17 December 2014 10:01 | To: Simon Peyton Jones | Cc: Edward Kmett; Austin Seipp | Subject: Re: type-checker regression in GHC HEAD? | | Hello Simon, | | ...does that repro-case work for you? shall I create a Trac ticket as | well? I consider this one quite critical for this week's GHC 7.10.1 | RC, if it can't compile `lens` :-/ | | Cheers, | hvr | | On 2014-12-16 at 15:03:49 +0100, Herbert Valerio Riedel wrote: | > On 2014-12-16 at 14:33:00 +0100, Simon Peyton Jones wrote: | >> No immediate bells. | >> | >> Is it possible to reproduce it without compiling all lens's zillion | >> dependencies? | > | > it's actually easier to isolate than expected: | > | > {-# LANGUAGE UndecidableInstances #-} | > | > import Control.Applicative | > import Control.Category | > import Prelude hiding ((.),id) | > | > newtype FocusingPlus w k s a = FocusingPlus { unfocusingPlus :: k | > (s, w) a } | > | > instance Functor (k (s, w)) => Functor (FocusingPlus w k s) where | > fmap f (FocusingPlus as) = FocusingPlus (fmap f as) | > | > instance Applicative (k (s, w)) => Applicative (FocusingPlus w k | s) where | > pure = FocusingPlus . pure | > FocusingPlus kf <*> FocusingPlus ka = FocusingPlus (kf <*> ka) | > | > | > works with GHC 7.8, fails with GHC HEAD w/ | > | > repro.hs:13:25: | > Couldn't match type ?f0? with ?k (s, w)? | > ?f0? is untouchable inside the constraints () bound by the | type signature for pure :: a -> FocusingPlus w k s a at repro.hs:13:3- | 6 | > Expected type: a -> k (s, w) a | > Actual type: a -> f0 a | > Relevant bindings include pure :: a -> FocusingPlus w k s a | (bound at repro.hs:13:3) | > In the second argument of ?(.)?, namely ?pure? | > In the expression: FocusingPlus . pure | > Failed, modules loaded: none. | | -- | "Elegance is not optional" -- Richard O'Keefe From eir at cis.upenn.edu Wed Dec 17 15:55:57 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 17 Dec 2014 10:55:57 -0500 Subject: performance regressions In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F40363A@DB3PRD3001MB020.064d.mgd.msft.net> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F40363A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5E06850B-012A-41A6-9E04-5E1B4F88D5E2@cis.upenn.edu> By unsubstantiated guess is that INLINEABLE would have the same effect as INLINE here, as GHC doesn't see fit to actually inline the function, even with INLINE -- the big improvement seen between (1) and (2) is actually specialization, not inlining. The jump from (2) to (3) is actual inlining. Thus, it seems that GHC's heuristics for inlining aren't working out for the best here. I've pushed my changes, though I agree with Simon that more research may uncover even more improvements here. I didn't focus on the number of calls because that number didn't regress. Will look into this soon. Richard On Dec 17, 2014, at 4:15 AM, Simon Peyton Jones wrote: > If you use INLINEABLE, that should make the function specialisable to a particular monad, even if it's in a different module. You shouldn't need INLINE for that. > > I don't understand the difference between cases (2) and (3). > > I am still suspicious of why there are so many calls to this one function that it, alone, is allocating a significant proportion of compilation of the entire run of GHC. Are you sure there isn't an algorithmic improvement to be had, to simply reduce the number of calls? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 16 December 2014 21:46 > | To: Joachim Breitner > | Cc: ghc-devs at haskell.org > | Subject: Re: performance regressions > | > | I've learned several very interesting things in this analysis. > | > | - Inlining polymorphic methods is very important. Here are some data > | points to back up that claim: > | * Original implementation using zipWithAndUnzipM: 8,472,613,440 > | bytes allocated in the heap > | * Adding {-# INLINE #-} to the definition thereof: 6,639,253,488 > | bytes allocated in the heap > | * Using `inline` at call site to force inlining: 6,281,539,792 > | bytes allocated in the heap > | > | The middle step above allowed GHC to specialize zipWithAndUnzipM to my > | particular monad, but GHC didn't see fit to actually inline the > | function. Using `inline` forced it, to good effect. (I did not collect > | data on code sizes, but it wouldn't be hard to.) > | > | By comparison: > | * Hand-written recursion: 6,587,809,112 bytes allocated in the > | heap > | Interestingly, this is *not* the best result! > | > | Conclusion: We should probably add INLINE pragmas to Util and > | MonadUtils. > | > | > | - I then looked at rejiggering the algorithm to keep the common case > | fast. This had a side effect of changing the zipWithAndUnzipM to > | mapAndUnzipM, from Control.Monad. To my surprise, this brought > | disaster! > | * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes > | allocated in the heap > | * Hand-written recursion: 5,848,602,848 bytes > | allocated in the heap > | > | That last number is better than the numbers above because of the > | algorithm streamlining. But, the inadequacy of mapAndUnzipM surprised > | me -- it already has an INLINE pragma in Control.Monad of course. > | Looking at -ddump-simpl, it seems that mapAndUnzipM was indeed getting > | inlined, but a call to `map` remained, perhaps causing extra > | allocation. > | > | Conclusion: We should examine the implementation of mapAndUnzipM (and > | similar functions) in Control.Monad. Is it as fast as possible? > | > | > | > | In the end, I was unable to bring the allocation numbers down to where > | they were before my work. This is because the flattener now deals in > | roles. Most of its behavior is the same between nominal and > | representational roles, so it seems silly (though very possible) to > | specialize the code to nominal to keep that path fast. Instead, I > | identified one key spot and made that go fast. > | > | Thus, there is a 7% bump to memory usage on very-type-family-heavy > | code, compared to before my commit on Friday. (On more ordinary code, > | there is no noticeable change.) > | > | Validating my patch locally now; will push when that's done. > | > | Thanks, > | Richard > | > | On Dec 16, 2014, at 10:41 AM, Joachim Breitner | breitner.de> wrote: > | > | > Hi, > | > > | > > | > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard Eisenberg: > | >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner | breitner.de> wrote: > | >> > | >>> another guess (without looking at the code, sorry): Are they in > | the > | >>> same module? I.e., can GHC specialize the code to your particular > | Monad? > | > > | >> No, they're not in the same module. I could also try moving the > | >> zipWithAndUnzipM function to the same module, and even specializing > | >> it by hand to the right monad. > | > > | > I did mean zipWithAndUnzipM, so maybe yes: Try that. > | > > | > (I find it hard to believe that any polymorphic monadic code should > | > perform well, with those many calls to an unknown (>>=) with a > | > function parameter, but maybe I'm too pessimistic here.) > | > > | > > | >> Could that be preventing the fusing? > | > > | > There is not going to be any fusing here, at least not list fusion; > | > that would require your code to be written in terms of functions > | with > | > fusion rules. > | > > | > Greetings, > | > Joachim > | > > | > -- > | > Joachim "nomeata" Breitner > | > mail at joachim-breitner.de * http://www.joachim-breitner.de/ > | > Jabber: nomeata at joachim-breitner.de * GPG-Key: 0xF0FBF51F Debian > | > Developer: nomeata at debian.org > | > > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Wed Dec 17 15:59:22 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 17 Dec 2014 15:59:22 +0000 Subject: performance regressions In-Reply-To: <5E06850B-012A-41A6-9E04-5E1B4F88D5E2@cis.upenn.edu> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F40363A@DB3PRD3001MB020.064d.mgd.msft.net> <5E06850B-012A-41A6-9E04-5E1B4F88D5E2@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F40403F@DB3PRD3001MB020.064d.mgd.msft.net> I still would like to understand why INLINE does not make it inline. That's weird. Eg way to reproduce. Simion | -----Original Message----- | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] | Sent: 17 December 2014 15:56 | To: Simon Peyton Jones | Cc: Joachim Breitner; ghc-devs at haskell.org | Subject: Re: performance regressions | | By unsubstantiated guess is that INLINEABLE would have the same effect | as INLINE here, as GHC doesn't see fit to actually inline the | function, even with INLINE -- the big improvement seen between (1) and | (2) is actually specialization, not inlining. The jump from (2) to (3) | is actual inlining. Thus, it seems that GHC's heuristics for inlining | aren't working out for the best here. | | I've pushed my changes, though I agree with Simon that more research | may uncover even more improvements here. I didn't focus on the number | of calls because that number didn't regress. Will look into this soon. | | Richard | | On Dec 17, 2014, at 4:15 AM, Simon Peyton Jones | wrote: | | > If you use INLINEABLE, that should make the function specialisable | to a particular monad, even if it's in a different module. You | shouldn't need INLINE for that. | > | > I don't understand the difference between cases (2) and (3). | > | > I am still suspicious of why there are so many calls to this one | function that it, alone, is allocating a significant proportion of | compilation of the entire run of GHC. Are you sure there isn't an | algorithmic improvement to be had, to simply reduce the number of | calls? | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Richard Eisenberg | > | Sent: 16 December 2014 21:46 | > | To: Joachim Breitner | > | Cc: ghc-devs at haskell.org | > | Subject: Re: performance regressions | > | | > | I've learned several very interesting things in this analysis. | > | | > | - Inlining polymorphic methods is very important. Here are some | > | data points to back up that claim: | > | * Original implementation using zipWithAndUnzipM: | 8,472,613,440 | > | bytes allocated in the heap | > | * Adding {-# INLINE #-} to the definition thereof: | 6,639,253,488 | > | bytes allocated in the heap | > | * Using `inline` at call site to force inlining: | 6,281,539,792 | > | bytes allocated in the heap | > | | > | The middle step above allowed GHC to specialize zipWithAndUnzipM | to | > | my particular monad, but GHC didn't see fit to actually inline | the | > | function. Using `inline` forced it, to good effect. (I did not | > | collect data on code sizes, but it wouldn't be hard to.) | > | | > | By comparison: | > | * Hand-written recursion: 6,587,809,112 bytes allocated in | the | > | heap | > | Interestingly, this is *not* the best result! | > | | > | Conclusion: We should probably add INLINE pragmas to Util and | > | MonadUtils. | > | | > | | > | - I then looked at rejiggering the algorithm to keep the common | > | case fast. This had a side effect of changing the | zipWithAndUnzipM | > | to mapAndUnzipM, from Control.Monad. To my surprise, this brought | > | disaster! | > | * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes | > | allocated in the heap | > | * Hand-written recursion: 5,848,602,848 bytes | > | allocated in the heap | > | | > | That last number is better than the numbers above because of the | > | algorithm streamlining. But, the inadequacy of mapAndUnzipM | > | surprised me -- it already has an INLINE pragma in Control.Monad | of course. | > | Looking at -ddump-simpl, it seems that mapAndUnzipM was indeed | > | getting inlined, but a call to `map` remained, perhaps causing | > | extra allocation. | > | | > | Conclusion: We should examine the implementation of mapAndUnzipM | > | (and similar functions) in Control.Monad. Is it as fast as | possible? | > | | > | | > | | > | In the end, I was unable to bring the allocation numbers down to | > | where they were before my work. This is because the flattener now | > | deals in roles. Most of its behavior is the same between nominal | > | and representational roles, so it seems silly (though very | > | possible) to specialize the code to nominal to keep that path | fast. | > | Instead, I identified one key spot and made that go fast. | > | | > | Thus, there is a 7% bump to memory usage on very-type-family- | heavy | > | code, compared to before my commit on Friday. (On more ordinary | > | code, there is no noticeable change.) | > | | > | Validating my patch locally now; will push when that's done. | > | | > | Thanks, | > | Richard | > | | > | On Dec 16, 2014, at 10:41 AM, Joachim Breitner | breitner.de> wrote: | > | | > | > Hi, | > | > | > | > | > | > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard | Eisenberg: | > | >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner | breitner.de> wrote: | > | >> | > | >>> another guess (without looking at the code, sorry): Are they | in | > | the >>> same module? I.e., can GHC specialize the code to your | > | particular Monad? | > | > | > | >> No, they're not in the same module. I could also try moving | the | > | >> zipWithAndUnzipM function to the same module, and even | > | specializing >> it by hand to the right monad. | > | > | > | > I did mean zipWithAndUnzipM, so maybe yes: Try that. | > | > | > | > (I find it hard to believe that any polymorphic monadic code | > | should > perform well, with those many calls to an unknown (>>=) | > | with a > function parameter, but maybe I'm too pessimistic here.) | > | > > >> Could that be preventing the fusing? | > | > | > | > There is not going to be any fusing here, at least not list | > | fusion; > that would require your code to be written in terms of | > | functions with > fusion rules. | > | > | > | > Greetings, | > | > Joachim | > | > | > | > -- | > | > Joachim "nomeata" Breitner | > | > mail at joachim-breitner.de * http://www.joachim-breitner.de/ > | > | Jabber: nomeata at joachim-breitner.de * GPG-Key: 0xF0FBF51F Debian | > | > Developer: nomeata at debian.org > > | > | _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs | > From simonpj at microsoft.com Wed Dec 17 16:37:01 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 17 Dec 2014 16:37:01 +0000 Subject: GHC Weekly News - 2014/12/16 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F4040E8@DB3PRD3001MB020.064d.mgd.msft.net> Austin, you may want to say when 7.8.4 will come out. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Austin Seipp | Sent: 16 December 2014 21:11 | To: ghc-devs at haskell.org | Subject: GHC Weekly News - 2014/12/16 | | Hi *, time for another piece of the GHC weekly news! | | - Joachim Breitner has gotten the new GHC 7.8.4 package to | tentatively build on ARM quite easily for Debian. Austin also took the | liberty of merging all the needed patches; they'll be part of the | 7.8.4 release https://www.haskell.org/pipermail/ghc-devs/2014- | December/007608.html | | - Greg Weber announced he's taken the time to set up a Docker image | for GHC development - if you're on Linux, Greg's image should help you | get up to speed with a GHC development environment in minutes! | https://www.haskell.org/pipermail/ghc-devs/2014-December/007606.html | | - Lennart Kolmodin has spent time working on autocompletion for GHC, | and 7.10 will ship with bash completion scripts - which package | maintainers and distributions can now ship for their users. Thank you | Lennart! https://www.haskell.org/pipermail/ghc-devs/2014- | December/007614.html | | - Adam Gundry has a question about the new type checker plugin | infrastructure; in particular - how do we deal with the serialization | of type checker evidence that plugins may want to create or pass | around on their own? Richard, Simon and Iavor weigh in. | https://www.haskell.org/pipermail/ghc-devs/2014-December/007626.html | | - For the past few days, Richard Eisenberg has been hunting a | performance regression in the compiler. After profiling, discussion on | IRC and elsewhere, Richard has finally made some headway, and | discovered one of the 'hot spots' in his patch. Unfortunately the | battle isn't quite over just yet, and the hunt for a few more % | increase remains. | https://www.haskell.org/pipermail/ghc-devs/2014-December/007645.html | | - David Spies has hit a very strange situation with GHC 7.8.3 | running out of memory. But it turned out this was a change in 7.8, in | relation to how stacks were managed. Phew! | https://www.haskell.org/pipermail/ghc-devs/2014-December/007646.html | | - Austin made a final call for 7.8.4 bugfixes. He plans on making | the final release this week, if nobody has any other major complaints. | https://www.haskell.org/pipermail/ghc-devs/2014-December/007684.html | | Finally, in a slight change, we'll also be covering some notes from | this week's meeting between GHC HQ (Austin, Simon PJ, SimonM, Herbert | and Mikolaj), including... | | - The 7.10 RC1 looks like it's scheduled to occur this week still; | all of our libraries and submodules are up-to-date, and we've taken | the time to alert all of our maintainers about this. Thanks to Herbert | for taking control of this! | | - We'll soon be implementing a new 'push hook' for the `ghc.git` | repository: no more trailing whitespace. Since we've recently | detabbed, and de-lhs-ified the tree, a knock-on effect was deleting | trailing whitespace. Now that we've done a lot of this, we should take | the time to enforce it - so they can't slip back in. | | - Austin will be landing Phab:D169 and Phab:D396 soon to get it into | 7.10.1 RC1. | | - This week, Austin managed to secure two sponsors for | GHC/Haskell.org. We've been given a wonderful set of ARM buildbots | (running in the cloud!) and a new, incredibly powerful POWER8 machine | to use (with over 170 hardware threads available, for scalability | testing). Hooray for our friends at Online.net and RunAbove.com for | helping us out! | | Closed tickets this week include: #9871, #9808, #9870, #9605, #9874, | #9872, #9090, #9404, #8240, #9567, #9566, #9583, #9117, #9882, #9884, | #9372, #7942, #8951, #9817, #9620, #9336, #9523, #9552, #8988, #9390, | #9415, #9371, #7143, #9563, #8778, #4428, #4896, #9393, #9169, #7015, | #8943, #8621, #9132, #9857, #8024, #9831, and #9888. | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From jwlato at gmail.com Wed Dec 17 17:11:11 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 17 Dec 2014 17:11:11 +0000 Subject: performance regressions References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F40363A@DB3PRD3001MB020.064d.mgd.msft.net> <5E06850B-012A-41A6-9E04-5E1B4F88D5E2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF3F40403F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Is it possible INLINE didn't inline the function because it's recursive? If it were my function, I'd probably try a manual worker /wrapper. On 07:59, Wed, Dec 17, 2014 Simon Peyton Jones wrote: > I still would like to understand why INLINE does not make it inline. > That's weird. > > Eg way to reproduce. > > Simion > > | -----Original Message----- > | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] > | Sent: 17 December 2014 15:56 > | To: Simon Peyton Jones > | Cc: Joachim Breitner; ghc-devs at haskell.org > | Subject: Re: performance regressions > | > | By unsubstantiated guess is that INLINEABLE would have the same effect > | as INLINE here, as GHC doesn't see fit to actually inline the > | function, even with INLINE -- the big improvement seen between (1) and > | (2) is actually specialization, not inlining. The jump from (2) to (3) > | is actual inlining. Thus, it seems that GHC's heuristics for inlining > | aren't working out for the best here. > | > | I've pushed my changes, though I agree with Simon that more research > | may uncover even more improvements here. I didn't focus on the number > | of calls because that number didn't regress. Will look into this soon. > | > | Richard > | > | On Dec 17, 2014, at 4:15 AM, Simon Peyton Jones > | wrote: > | > | > If you use INLINEABLE, that should make the function specialisable > | to a particular monad, even if it's in a different module. You > | shouldn't need INLINE for that. > | > > | > I don't understand the difference between cases (2) and (3). > | > > | > I am still suspicious of why there are so many calls to this one > | function that it, alone, is allocating a significant proportion of > | compilation of the entire run of GHC. Are you sure there isn't an > | algorithmic improvement to be had, to simply reduce the number of > | calls? > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | > | Richard Eisenberg > | > | Sent: 16 December 2014 21:46 > | > | To: Joachim Breitner > | > | Cc: ghc-devs at haskell.org > | > | Subject: Re: performance regressions > | > | > | > | I've learned several very interesting things in this analysis. > | > | > | > | - Inlining polymorphic methods is very important. Here are some > | > | data points to back up that claim: > | > | * Original implementation using zipWithAndUnzipM: > | 8,472,613,440 > | > | bytes allocated in the heap > | > | * Adding {-# INLINE #-} to the definition thereof: > | 6,639,253,488 > | > | bytes allocated in the heap > | > | * Using `inline` at call site to force inlining: > | 6,281,539,792 > | > | bytes allocated in the heap > | > | > | > | The middle step above allowed GHC to specialize zipWithAndUnzipM > | to > | > | my particular monad, but GHC didn't see fit to actually inline > | the > | > | function. Using `inline` forced it, to good effect. (I did not > | > | collect data on code sizes, but it wouldn't be hard to.) > | > | > | > | By comparison: > | > | * Hand-written recursion: 6,587,809,112 bytes allocated in > | the > | > | heap > | > | Interestingly, this is *not* the best result! > | > | > | > | Conclusion: We should probably add INLINE pragmas to Util and > | > | MonadUtils. > | > | > | > | > | > | - I then looked at rejiggering the algorithm to keep the common > | > | case fast. This had a side effect of changing the > | zipWithAndUnzipM > | > | to mapAndUnzipM, from Control.Monad. To my surprise, this brought > | > | disaster! > | > | * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes > | > | allocated in the heap > | > | * Hand-written recursion: 5,848,602,848 bytes > | > | allocated in the heap > | > | > | > | That last number is better than the numbers above because of the > | > | algorithm streamlining. But, the inadequacy of mapAndUnzipM > | > | surprised me -- it already has an INLINE pragma in Control.Monad > | of course. > | > | Looking at -ddump-simpl, it seems that mapAndUnzipM was indeed > | > | getting inlined, but a call to `map` remained, perhaps causing > | > | extra allocation. > | > | > | > | Conclusion: We should examine the implementation of mapAndUnzipM > | > | (and similar functions) in Control.Monad. Is it as fast as > | possible? > | > | > | > | > | > | > | > | In the end, I was unable to bring the allocation numbers down to > | > | where they were before my work. This is because the flattener now > | > | deals in roles. Most of its behavior is the same between nominal > | > | and representational roles, so it seems silly (though very > | > | possible) to specialize the code to nominal to keep that path > | fast. > | > | Instead, I identified one key spot and made that go fast. > | > | > | > | Thus, there is a 7% bump to memory usage on very-type-family- > | heavy > | > | code, compared to before my commit on Friday. (On more ordinary > | > | code, there is no noticeable change.) > | > | > | > | Validating my patch locally now; will push when that's done. > | > | > | > | Thanks, > | > | Richard > | > | > | > | On Dec 16, 2014, at 10:41 AM, Joachim Breitner | > | breitner.de> wrote: > | > | > | > | > Hi, > | > | > > | > | > > | > | > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard > | Eisenberg: > | > | >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner | > | breitner.de> wrote: > | > | >> > | > | >>> another guess (without looking at the code, sorry): Are they > | in > | > | the >>> same module? I.e., can GHC specialize the code to your > | > | particular Monad? > | > | > > | > | >> No, they're not in the same module. I could also try moving > | the > | > | >> zipWithAndUnzipM function to the same module, and even > | > | specializing >> it by hand to the right monad. > | > | > > | > | > I did mean zipWithAndUnzipM, so maybe yes: Try that. > | > | > > | > | > (I find it hard to believe that any polymorphic monadic code > | > | should > perform well, with those many calls to an unknown (>>=) > | > | with a > function parameter, but maybe I'm too pessimistic here.) > | > | > > >> Could that be preventing the fusing? > | > | > > | > | > There is not going to be any fusing here, at least not list > | > | fusion; > that would require your code to be written in terms of > | > | functions with > fusion rules. > | > | > > | > | > Greetings, > | > | > Joachim > | > | > > | > | > -- > | > | > Joachim "nomeata" Breitner > | > | > mail at joachim-breitner.de * http://www.joachim-breitner.de/ > > | > | Jabber: nomeata at joachim-breitner.de * GPG-Key: 0xF0FBF51F Debian > | > | > Developer: nomeata at debian.org > > > | > | _______________________________________________ > | > | > ghc-devs mailing list > | > | > ghc-devs at haskell.org > | > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > | > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs > | > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Dec 17 17:20:01 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 17 Dec 2014 18:20:01 +0100 Subject: performance regressions In-Reply-To: (Richard Eisenberg's message of "Tue, 16 Dec 2014 16:45:36 -0500") References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> Message-ID: <87wq5q2ny6.fsf@gmail.com> On 2014-12-16 at 22:45:36 +0100, Richard Eisenberg wrote: > I've learned several very interesting things in this analysis. > > - Inlining polymorphic methods is very important. otoh, there are cases where marking methods INLINE have catastrophic effects; the following https://github.com/kolmodin/binary/commit/48c02966512a67b018fcdf093fab8d34bddf9a69 was necessary a few months ago, as otherwise GHC HEAD's compile-time memory usage would explode: https://ghc.haskell.org/trac/ghc/ticket/9630 From jan.stolarek at p.lodz.pl Wed Dec 17 17:29:39 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 17 Dec 2014 18:29:39 +0100 Subject: Understanding DsMeta module Message-ID: <201412171829.39422.jan.stolarek@p.lodz.pl> I'm implementing Template Haskell support for injective type families and I'm struggling to understand DsMeta module. It seems that all functions in that module delegate their calls to functions in Language.Haskell.TH.Lib via wired-in names and the `DsMeta.rep2` function. I'm puzzled by this design and I'd appreciate if someone could explain why things are done this way. Take this function example: repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) repPlainTV (MkC nm) = rep2 plainTVName [nm] where `plainTvName` is a name of `Language.Haskell.TH.Lib.plainTV`: plainTV :: Name -> TyVarBndr plainTV = PlainTV Why not implement repPlainTV like this: ? repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm) Janek From eir at cis.upenn.edu Wed Dec 17 19:24:18 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 17 Dec 2014 14:24:18 -0500 Subject: Understanding DsMeta module In-Reply-To: <201412171829.39422.jan.stolarek@p.lodz.pl> References: <201412171829.39422.jan.stolarek@p.lodz.pl> Message-ID: <719597D7-66C1-466D-966C-DFD9AB5821FD@cis.upenn.edu> On Dec 17, 2014, at 12:29 PM, Jan Stolarek wrote: > > Why not implement repPlainTV like this: ? > > repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) > repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm) > In short, that's ill typed. We have > newtype Core a = MkC CoreExpr The idea behind this type is that its (phantom) type parameter tracks the type of the expression stored within. Of course, the thing within is always just a core expression. TH.PlainTV takes a TH.Name and produces a TH.TyVarBndr. But, nm is a CoreExpr and MkC is expecting a CoreExpr, so your suggestion wouldn't type check. The higher-level answer is that you're mixing levels. The goal in DsMeta is *not* to create the TH AST. It's to create *core expressions* that create the TH AST. Does this help? Richard From jan.stolarek at p.lodz.pl Wed Dec 17 19:33:39 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 17 Dec 2014 20:33:39 +0100 Subject: Understanding DsMeta module In-Reply-To: <719597D7-66C1-466D-966C-DFD9AB5821FD@cis.upenn.edu> References: <201412171829.39422.jan.stolarek@p.lodz.pl> <719597D7-66C1-466D-966C-DFD9AB5821FD@cis.upenn.edu> Message-ID: <201412172033.39810.jan.stolarek@p.lodz.pl> Thanks. That helps but I still don't understand why the calls are delegated to template-haskell library. Couldn't all of this be done locally? Janek Dnia ?roda, 17 grudnia 2014, Richard Eisenberg napisa?: > On Dec 17, 2014, at 12:29 PM, Jan Stolarek wrote: > > Why not implement repPlainTV like this: ? > > > > repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) > > repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm) > > In short, that's ill typed. We have > > > newtype Core a = MkC CoreExpr > > The idea behind this type is that its (phantom) type parameter tracks the > type of the expression stored within. Of course, the thing within is always > just a core expression. TH.PlainTV takes a TH.Name and produces a > TH.TyVarBndr. But, nm is a CoreExpr and MkC is expecting a CoreExpr, so > your suggestion wouldn't type check. > > The higher-level answer is that you're mixing levels. The goal in DsMeta is > *not* to create the TH AST. It's to create *core expressions* that create > the TH AST. > > Does this help? > > Richard From eir at cis.upenn.edu Wed Dec 17 19:35:03 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 17 Dec 2014 14:35:03 -0500 Subject: Understanding DsMeta module In-Reply-To: <201412172033.39810.jan.stolarek@p.lodz.pl> References: <201412171829.39422.jan.stolarek@p.lodz.pl> <719597D7-66C1-466D-966C-DFD9AB5821FD@cis.upenn.edu> <201412172033.39810.jan.stolarek@p.lodz.pl> Message-ID: But you need an expression that, say, produces a PlainTV. Where are you going to find an expression that does this without using the template-haskell library? On Dec 17, 2014, at 2:33 PM, Jan Stolarek wrote: > Thanks. That helps but I still don't understand why the calls are delegated to template-haskell > library. Couldn't all of this be done locally? > > Janek > > Dnia ?roda, 17 grudnia 2014, Richard Eisenberg napisa?: >> On Dec 17, 2014, at 12:29 PM, Jan Stolarek wrote: >>> Why not implement repPlainTV like this: ? >>> >>> repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) >>> repPlainTV (MkC nm) = return $ MkC (TH.PlainTV nm) >> >> In short, that's ill typed. We have >> >>> newtype Core a = MkC CoreExpr >> >> The idea behind this type is that its (phantom) type parameter tracks the >> type of the expression stored within. Of course, the thing within is always >> just a core expression. TH.PlainTV takes a TH.Name and produces a >> TH.TyVarBndr. But, nm is a CoreExpr and MkC is expecting a CoreExpr, so >> your suggestion wouldn't type check. >> >> The higher-level answer is that you're mixing levels. The goal in DsMeta is >> *not* to create the TH AST. It's to create *core expressions* that create >> the TH AST. >> >> Does this help? >> >> Richard > > > From austin at well-typed.com Thu Dec 18 05:08:20 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 17 Dec 2014 23:08:20 -0600 Subject: Random holiday fun: Vote for buildbot naming conventions! Message-ID: Hi *, Everyone has been working hard getting things ready for the branch/RC later this week - and that's really appreciated! As always, GHC wouldn't be what it is without you. But it's the holidays - that's stressful for some, and real time consuming for others. So to keep things light and a little interesting, and if you have a minute as an experiment, I'd like to ask you all something: What naming conventions should we use for GHC buildbots? We've been adding more bots recently, and we've just gotten hold of some new hardware this week. Currently, GHC buildbots don't have any reserved name or identifier, or DNS entries. I'd like to change that - we mostly refer to them by IP, but this is annoying A) to remember and B) to tell other people. We'll likely begin to lease out these machines to developers so they can test and debug - meaning they'll be mentioned more. I'd like to propose a theme for naming buildbots - this theme would be used to populate DNS entries under the *.ghc.haskell.org domain. The question is: what naming convention do we use? So I created a poll for this. You can see that poll and vote for your favorite options on Phabricator: - https://phabricator.haskell.org/V3 It's an approval vote rather than a plurality; so feel free to select multiple choices. The winner with the most votes will get selected. Note: the selection of options is relatively random and pre-selected; there is an upper limit on the number of choices - 10 max - so I merely picked some categories I thought would work and be generic enough. I imagine this vote will be open for about a week or so. I'd like it if developers could vote on their favorites, or simply leave comments on the vote for further suggestion - we could institute a vote with better names. Thanks all - and be sure to have happy holidays. P.S I did not know RFC 1178 existed before today. Seems like there's one for everything... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From carter.schonwald at gmail.com Thu Dec 18 06:15:07 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 18 Dec 2014 01:15:07 -0500 Subject: are patterns synonyms definable in GHCI? Message-ID: Hey all, I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Dec 18 08:52:09 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 18 Dec 2014 09:52:09 +0100 Subject: Right way to turn off dynamic linking in build.mk Message-ID: Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) This line make me worry that if I don't put DYNAMIC_GHC_PROGRAMS = NO in the right place in build.mk it wont "take". There's also this one: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif Seeing this makes me wonder if DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO is enough or if the build system still sniffs out the fact that my platform supports dynamic linking. Could someone please give an authoritative answer to how to turn off dynamic linking? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Thu Dec 18 09:50:03 2014 From: adam at well-typed.com (Adam Gundry) Date: Thu, 18 Dec 2014 09:50:03 +0000 Subject: [Diffusion] [Build Failed] rGHC726ea08a6e58: Amend TcPluginM interface In-Reply-To: <20141218092540.80981.66488@phabricator.haskell.org> References: <20141218092540.80981.66488@phabricator.haskell.org> Message-ID: <5492A34B.1050108@well-typed.com> On 18/12/14 09:25, Phabricator wrote: > Harbormaster failed to build B2694: rGHC726ea08a6e58: Amend TcPluginM interface! Sigh. It seems perf/compiler T3294 is failing on Harbormaster, but it validated fine locally on x86_64. I doubt my commit is responsible, and suspect this is just a wobbly test, but it's hard to know without the full build log. Is there a way to get full logs for failing Harbormaster builds? They seem to be uploaded only if the build succeeds. Thanks, Adam > USERS > adamgundry (Author) > GHC - Driver (Auditor) > GHC - Type checker/inferencer (Auditor) > > COMMIT > https://phabricator.haskell.org/rGHC726ea08a6e58 > > EMAIL PREFERENCES > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > To: adamgundry, GHC - Driver, GHC - Type checker/inferencer -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Thu Dec 18 10:07:08 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Dec 2014 10:07:08 +0000 Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F404713@DB3PRD3001MB020.064d.mgd.msft.net> File a Trac ticket! From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Carter Schonwald Sent: 18 December 2014 06:15 To: ghc-devs at haskell.org Subject: are patterns synonyms definable in GHCI? Hey all, I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 18 10:28:10 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Dec 2014 10:28:10 +0000 Subject: Understanding DsMeta module In-Reply-To: <201412172033.39810.jan.stolarek@p.lodz.pl> References: <201412171829.39422.jan.stolarek@p.lodz.pl> <719597D7-66C1-466D-966C-DFD9AB5821FD@cis.upenn.edu> <201412172033.39810.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F404854@DB3PRD3001MB020.064d.mgd.msft.net> | Thanks. That helps but I still don't understand why the calls are | delegated to template-haskell library. Couldn't all of this be done | locally? No. If you have f :: Int -> Q Exp then f is a function that, when run, produces a data structure that is the syntax tree (in the data type of Language.Haskell.TH) of some expression. Later, in some other module entirely, you may call f, thus foo = $(f 5) Now GHC dynamically links the module that defines f, executes f's code, which returns a syntax tree (in the data type of Language.Haskell.TH). This is converted to HsSyn and replaces the $(f 5). So the code for f must be code that, when executed, produces a data structure. The business of DsMeta is to produce such code. If, once you grok this, you'd like to add a page to the GHC Commentary, to explain it, that would be great. It does take a while to get your head around. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan | Stolarek | Sent: 17 December 2014 19:34 | To: Richard Eisenberg | Cc: ghc-devs at haskell.org | Subject: Re: Understanding DsMeta module | | Thanks. That helps but I still don't understand why the calls are | delegated to template-haskell library. Couldn't all of this be done | locally? | | Janek | | Dnia ?roda, 17 grudnia 2014, Richard Eisenberg napisa?: | > On Dec 17, 2014, at 12:29 PM, Jan Stolarek | wrote: | > > Why not implement repPlainTV like this: ? | > > | > > repPlainTV :: Core TH.Name -> DsM (Core TH.TyVarBndr) repPlainTV | > > (MkC nm) = return $ MkC (TH.PlainTV nm) | > | > In short, that's ill typed. We have | > | > > newtype Core a = MkC CoreExpr | > | > The idea behind this type is that its (phantom) type parameter | tracks | > the type of the expression stored within. Of course, the thing | within | > is always just a core expression. TH.PlainTV takes a TH.Name and | > produces a TH.TyVarBndr. But, nm is a CoreExpr and MkC is expecting | a | > CoreExpr, so your suggestion wouldn't type check. | > | > The higher-level answer is that you're mixing levels. The goal in | > DsMeta is | > *not* to create the TH AST. It's to create *core expressions* that | > create the TH AST. | > | > Does this help? | > | > Richard | | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Dec 18 10:44:04 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Dec 2014 10:44:04 +0000 Subject: Status updates In-Reply-To: <20140909203209.02eec146@sf> References: <20140909203209.02eec146@sf> Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F4048B7@DB3PRD3001MB020.064d.mgd.msft.net> Sergei Thank you for all these. I believe I have (finally) nailed them all! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Sergei Trofimovich | Sent: 09 September 2014 18:32 | To: ghc-devs at haskell.org | Subject: Re: Status updates | | On Tue, 9 Sep 2014 08:34:03 -0500 | Austin Seipp wrote: | | > - Sergei spent some time filing bugs that we should fix in the | > testsuite, because they fail --slow validate. I believe these are | two | > of them: | > | > - https://ghc.haskell.org/trac/ghc/ticket/9567 | > - https://ghc.haskell.org/trac/ghc/ticket/9566 | | Yeah, I believe the complete list for --slow is only 5 failures: | | https://ghc.haskell.org/trac/ghc/ticket/9565 - dead loop in simplifier | https://ghc.haskell.org/trac/ghc/ticket/9424 - debugged ghc does not | unload Show instances after data redefinition (or not :]) | https://ghc.haskell.org/trac/ghc/ticket/9426 - something similar with | redefinition in ghci | https://ghc.haskell.org/trac/ghc/ticket/9566 - corelint error in | simplifier | https://ghc.haskell.org/trac/ghc/ticket/9567 - another corelint error | in simplifier | | -- | | Sergei From gergo at erdi.hu Thu Dec 18 10:51:49 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Thu, 18 Dec 2014 18:51:49 +0800 (SGT) Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: On Thu, 18 Dec 2014, Carter Schonwald wrote: > Hey all,I was trying to define some pattern synonyms in ghci recently, and that doesnt > seem to work. Is that something slated to be fix in 7.10 or something? I thought GHCi accepts things that would be valid in a 'do' section? So e.g. x = () doesn't work in GHCi, but let x = () does. Pattern synonyms don't work for the exact same reason: they are not valid inside a 'do' block. From simonpj at microsoft.com Thu Dec 18 11:13:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Dec 2014 11:13:00 +0000 Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F404941@DB3PRD3001MB020.064d.mgd.msft.net> But GHCi does support data type declarations ghci> data T = A | B so presumably it ought also to support pattern synonym declarations. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 18 December 2014 10:52 | To: Carter Schonwald | Cc: ghc-devs at haskell.org | Subject: Re: are patterns synonyms definable in GHCI? | | On Thu, 18 Dec 2014, Carter Schonwald wrote: | | > Hey all,I was trying to define some pattern synonyms in ghci | recently, | > and that doesnt seem to work. Is that something slated to be fix in | 7.10 or something? | | I thought GHCi accepts things that would be valid in a 'do' section? | So e.g. | | x = () | | doesn't work in GHCi, but | | let x = () | | does. | | Pattern synonyms don't work for the exact same reason: they are not | valid inside a 'do' block. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From ekmett at gmail.com Thu Dec 18 11:14:01 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 18 Dec 2014 06:14:01 -0500 Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: ghci also accepts a number of other things. You can define data types, type synonyms, classes, instances, so pattern synonyms would seem to fall into scope. On Thu, Dec 18, 2014 at 5:51 AM, Dr. ERDI Gergo wrote: > > On Thu, 18 Dec 2014, Carter Schonwald wrote: > > Hey all,I was trying to define some pattern synonyms in ghci recently, >> and that doesnt >> seem to work. Is that something slated to be fix in 7.10 or something? >> > > I thought GHCi accepts things that would be valid in a 'do' section? So > e.g. > > x = () > > doesn't work in GHCi, but > > let x = () > > does. > > Pattern synonyms don't work for the exact same reason: they are not valid > inside a 'do' block. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Dec 18 11:16:27 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 18 Dec 2014 13:16:27 +0200 Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: <5492B78B.9000309@ro-che.info> On 18/12/14 12:51, Dr. ERDI Gergo wrote: > On Thu, 18 Dec 2014, Carter Schonwald wrote: > >> Hey all,I was trying to define some pattern synonyms in ghci recently, >> and that doesnt >> seem to work. Is that something slated to be fix in 7.10 or something? > > I thought GHCi accepts things that would be valid in a 'do' section? So > e.g. > > x = () > > doesn't work in GHCi, but > > let x = () > > does. > > Pattern synonyms don't work for the exact same reason: they are not > valid inside a 'do' block. That's not true. Since 7.6, IIRC, you can define data types and instances in ghci. See also https://ghc.haskell.org/trac/ghc/ticket/7253 Roman From gergo at erdi.hu Thu Dec 18 11:29:40 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Thu, 18 Dec 2014 19:29:40 +0800 (SGT) Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: On Thu, 18 Dec 2014, Edward Kmett wrote: > ghci also accepts a number of other things. > You can define data types, type synonyms, classes, instances, so pattern synonyms > would seem to fall into scope. Wow, I didn't know about this feature. In that case, yes, I agree, pattern synonyms should be supported in GHCi :) From gergo at erdi.hu Thu Dec 18 11:35:26 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Thu, 18 Dec 2014 19:35:26 +0800 (SGT) Subject: are patterns synonyms definable in GHCI? In-Reply-To: References: Message-ID: On Thu, 18 Dec 2014, Dr. ERDI Gergo wrote: > Wow, I didn't know about this feature. In that case, yes, I agree, pattern > synonyms should be supported in GHCi :) Filed as #9900. -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' Eg?r: az elef?nt jap?n v?ltozata From jan.stolarek at p.lodz.pl Thu Dec 18 17:18:05 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Dec 2014 18:18:05 +0100 Subject: Can we rename completion to autocomplete In-Reply-To: <87ppbyl3jy.fsf@gmail.com> References: <1417770099-sup-4642@sabre> <87ppbyl3jy.fsf@gmail.com> Message-ID: <201412181818.05803.jan.stolarek@p.lodz.pl> Bump. Any decisions on this one? If not then I'll move that folder somewhere else because it's getting in the way. Janek From austin at well-typed.com Thu Dec 18 17:21:19 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 18 Dec 2014 11:21:19 -0600 Subject: Can we rename completion to autocomplete In-Reply-To: <201412181818.05803.jan.stolarek@p.lodz.pl> References: <1417770099-sup-4642@sabre> <87ppbyl3jy.fsf@gmail.com> <201412181818.05803.jan.stolarek@p.lodz.pl> Message-ID: I'd say just move it under utils/. We really need to organize the top-folder more, but that's for another day. On Thu, Dec 18, 2014 at 11:18 AM, Jan Stolarek wrote: > Bump. Any decisions on this one? If not then I'll move that folder somewhere else because it's > getting in the way. > > Janek > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From jan.stolarek at p.lodz.pl Thu Dec 18 17:26:51 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Dec 2014 18:26:51 +0100 Subject: RFC: Remove -fwarn-unticked-promoted-constructors from -Wall Message-ID: <201412181826.51409.jan.stolarek@p.lodz.pl> We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 and D534). This warning is enabled with -Wall but I think that this is not a good idea. I strongly propose to remove it with -Wall. Rationale: 1. I feel that ticks add unnecessary noise: prDictOfPReprInstTyCon :: Type -> CoAxiom 'Unbranched -> [Type] -> VM CoreExpr To me it feels awkward to have Unbranched with a tick but CoreExpr without a tick (both are types after all). Moreover, ticks also trip many syntax highlighters, which further degrades code readability. 2. I've been refactoring some of GHC code to use promoted types instead of empty data types (see CoAxiom.BranchList). This would have been a fairly local change, except that I have to add ticks in every place that mentiones promoted types. That's a Royal Pain and a "good" example how this warning can get in people's way. Janek From eir at cis.upenn.edu Thu Dec 18 17:38:23 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 18 Dec 2014 12:38:23 -0500 Subject: RFC: Remove -fwarn-unticked-promoted-constructors from -Wall In-Reply-To: <201412181826.51409.jan.stolarek@p.lodz.pl> References: <201412181826.51409.jan.stolarek@p.lodz.pl> Message-ID: <6CE8DB6F-DFAC-48EA-99C7-2A0715A59107@cis.upenn.edu> For what it's worth, I don't have a strong feeling either way here. Arguments in favor of keeping -fwarn-unticked-promoted-constructors in -Wall: 1. It's weird having GHC look in one namespace (types) and then look in another (terms) only when the first one fails. In other scenarios, ambiguity is an error. 2. If I have my way (https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell), this problem will only get worse. 3. Whenever presenting code involving promoted constructors, I put the tick marks in everywhere, as I think it makes the code easier to understand. 4. There is an easy workaround: > type Unbranched = 'Unbranched Arguments against keeping -fwarn-unticked-promoted-constructors in -Wall: 1,2. As Janek. 3. If you've made a mistake around using a type where a promoted data constructor is meant, or vice versa, it's very likely you have an error in your code. This will lead to a perhaps-obscure, perhaps-confusing error message instead of a nice clean warning, which is suppressed when there are errors. Adding this all up, I can't really decide which is best. Richard On Dec 18, 2014, at 12:26 PM, Jan Stolarek wrote: > We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 and D534). This > warning is enabled with -Wall but I think that this is not a good idea. I strongly propose to > remove it with -Wall. > > Rationale: > 1. I feel that ticks add unnecessary noise: > > prDictOfPReprInstTyCon :: Type -> CoAxiom 'Unbranched -> [Type] -> VM CoreExpr > > To me it feels awkward to have Unbranched with a tick but CoreExpr without a tick (both are types > after all). Moreover, ticks also trip many syntax highlighters, which further degrades code > readability. > > 2. I've been refactoring some of GHC code to use promoted types instead of empty data types (see > CoAxiom.BranchList). This would have been a fairly local change, except that I have to add ticks > in every place that mentiones promoted types. That's a Royal Pain and a "good" example how this > warning can get in people's way. > > Janek > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Thu Dec 18 17:47:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 18 Dec 2014 12:47:58 -0500 Subject: Random holiday fun: Vote for buildbot naming conventions! In-Reply-To: References: Message-ID: dont forget you can vote for more than one! On Thu, Dec 18, 2014 at 12:08 AM, Austin Seipp wrote: > > Hi *, > > Everyone has been working hard getting things ready for the branch/RC > later this week - and that's really appreciated! As always, GHC > wouldn't be what it is without you. > > But it's the holidays - that's stressful for some, and real time > consuming for others. So to keep things light and a little > interesting, and if you have a minute as an experiment, I'd like to > ask you all something: > > What naming conventions should we use for GHC buildbots? We've been > adding more bots recently, and we've just gotten hold of some new > hardware this week. > > Currently, GHC buildbots don't have any reserved name or identifier, > or DNS entries. I'd like to change that - we mostly refer to them by > IP, but this is annoying A) to remember and B) to tell other people. > We'll likely begin to lease out these machines to developers so they > can test and debug - meaning they'll be mentioned more. > > I'd like to propose a theme for naming buildbots - this theme would be > used to populate DNS entries under the *.ghc.haskell.org domain. > > The question is: what naming convention do we use? > > So I created a poll for this. You can see that poll and vote for your > favorite options on Phabricator: > > - https://phabricator.haskell.org/V3 > > It's an approval vote rather than a plurality; so feel free to select > multiple choices. The winner with the most votes will get selected. > > Note: the selection of options is relatively random and pre-selected; > there is an upper limit on the number of choices - 10 max - so I > merely picked some categories I thought would work and be generic > enough. > > I imagine this vote will be open for about a week or so. I'd like it > if developers could vote on their favorites, or simply leave comments > on the vote for further suggestion - we could institute a vote with > better names. > > Thanks all - and be sure to have happy holidays. > > P.S I did not know RFC 1178 existed before today. Seems like there's > one for everything... > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Thu Dec 18 21:37:01 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 18 Dec 2014 13:37:01 -0800 Subject: GHC Weekly News - 2014/12/16 In-Reply-To: References: Message-ID: <20141218133701.5ee26bf7f1c287c5bafe830c@mega-nerd.com> Austin Seipp wrote: > - This week, Austin managed to secure two sponsors for > GHC/Haskell.org. We've been given a wonderful set of ARM buildbots > (running in the cloud!) and a new, incredibly powerful POWER8 machine > to use (with over 170 hardware threads available, for scalability > testing). Hooray for our friends at Online.net and RunAbove.com for > helping us out! Austin, Any chance you could tell us a little more about these machines, in particular the Arm machines? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From simonpj at microsoft.com Fri Dec 19 10:07:33 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 19 Dec 2014 10:07:33 +0000 Subject: Which language extensions to register for Cabal 1.22? In-Reply-To: <87388c38sl.fsf@gmail.com> References: <87388c38sl.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF5627C2A1@DBXPRD3001MB024.064d.mgd.msft.net> | ...which of the following language extensions (which are mentioned in | T4437) are deemed stable enough to be registered in Cabal for GHC | 7.10? I'm not sure what criteria you'd like to use! PatternSynonyms, PartialTypeSignatures, and NamedWildCards are all pretty stable and should go in. StaticPointers will definitely continue to be there in future; but the details of the API may change, and the current implementation is very much a prototype. DeriveAnyClass: I defer to Pedro Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 18 December 2014 22:14 | To: Simon Peyton Jones | Cc: Johan Tibell; Austin Seipp; Duncan Coutts | Subject: Which language extensions to register for Cabal 1.22? | | Hello Simon, | | ...which of the following language extensions (which are mentioned in | T4437) are deemed stable enough to be registered in Cabal for GHC | 7.10? | | - "DeriveAnyClass" | - "PatternSynonyms" | - "PartialTypeSignatures" | - "NamedWildcards" | - "StaticPointers" | | Cheers, | hvr From jan.stolarek at p.lodz.pl Fri Dec 19 10:53:12 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 19 Dec 2014 11:53:12 +0100 Subject: Can we rename completion to autocomplete In-Reply-To: References: <1417770099-sup-4642@sabre> <201412181818.05803.jan.stolarek@p.lodz.pl> Message-ID: <201412191153.13025.jan.stolarek@p.lodz.pl> Done. I moved completion/ directory to utils/ Janek Dnia czwartek, 18 grudnia 2014, Austin Seipp napisa?: > I'd say just move it under utils/. We really need to organize the > top-folder more, but that's for another day. > > On Thu, Dec 18, 2014 at 11:18 AM, Jan Stolarek wrote: > > Bump. Any decisions on this one? If not then I'll move that folder > > somewhere else because it's getting in the way. > > > > Janek > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs From rasfar at gmail.com Fri Dec 19 13:07:33 2014 From: rasfar at gmail.com (Andrew Seniuk) Date: Fri, 19 Dec 2014 07:07:33 -0600 Subject: ANN: deepseq-bounded, seqaid, leaky Message-ID: This trio of related packages explores strictness control in a variety of ways. deepseq-bounded provides classes and generic functions to artificially force evaluation, to extents controlled by static or dynamic configuration. seqaid puts that into practise, providing a GHC plugin to auto-instrument your package with a strictness harness, which is dynamically optimisable during runtime. This is supported directly in the GHC compilation pipeline, without requiring (or performing!) any edits to your sources. leaky is a minimal, prototypic executable that leaks space under current state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). deepseq-bounded hackage: https://hackage.haskell.org/package/deepseq-bounded homepage: http://www.fremissant.net/deepseq-bounded seqaid hackage: https://hackage.haskell.org/package/seqaid homepage: http://www.fremissant.net/seqaid leaky hackage: https://hackage.haskell.org/package/leaky homepage: http://www.fremissant.net/leaky Reddit discussion for the three together: http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_leaky/ Easiest way to try them all, is to install seqaid and run the demo: cabal install seqaid seqaid demo This tests seqaid on a local copy of the leaky source package. It turned out to be routine to extend deepseq-bounded and seqaid to dynamically configurable parallelisation (paraid?). Many other wrappers could be explored, too! Maybe seqaid should be renamed to koolaid or something... It's a pretty complicated system, and just first release, so there's bound to be lots of problems. I've not set up a bug tracker, but will maintain a casual list of bugs and feature requests at http://www.fremissant.net/seqaid/trac and will set up a proper tracker if there's interest. Any isssues (or comments), I'm here, or on the reddit discussion (or email). Andrew Seniuk rasfar on #haskell -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasfar at gmail.com Fri Dec 19 14:01:12 2014 From: rasfar at gmail.com (Andrew Seniuk) Date: Fri, 19 Dec 2014 08:01:12 -0600 Subject: ANN: deepseq-bounded, seqaid, leaky In-Reply-To: References: Message-ID: Sorry, that was my first Reddit post and I messed up. Please use this link http://www.reddit.com/r/haskell/comments/2pscxh/ann_deepseqbounded_seqaid_leaky/ -Andrew On Fri, Dec 19, 2014 at 7:07 AM, Andrew Seniuk wrote: > This trio of related packages explores strictness control in a variety of > ways. > > deepseq-bounded provides classes and generic functions to artificially > force evaluation, to extents controlled by static or dynamic configuration. > > seqaid puts that into practise, providing a GHC plugin to auto-instrument > your package with a strictness harness, which is dynamically optimisable > during runtime. This is supported directly in the GHC compilation > pipeline, without requiring (or performing!) any edits to your sources. > > leaky is a minimal, prototypic executable that leaks space under current > state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). > > deepseq-bounded > hackage: https://hackage.haskell.org/package/deepseq-bounded > homepage: http://www.fremissant.net/deepseq-bounded > > seqaid > hackage: https://hackage.haskell.org/package/seqaid > homepage: http://www.fremissant.net/seqaid > > leaky > hackage: https://hackage.haskell.org/package/leaky > homepage: http://www.fremissant.net/leaky > > Reddit discussion for the three together: > > http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_leaky/ > > Easiest way to try them all, is to install seqaid and run the demo: > > cabal install seqaid > seqaid demo > > This tests seqaid on a local copy of the leaky source package. > > It turned out to be routine to extend deepseq-bounded and seqaid to > dynamically configurable parallelisation (paraid?). Many other wrappers > could be explored, too! Maybe seqaid should be renamed to koolaid or > something... > > It's a pretty complicated system, and just first release, so there's bound > to be lots of problems. I've not set up a bug tracker, but will maintain a > casual list of bugs and feature requests at > > http://www.fremissant.net/seqaid/trac > > and will set up a proper tracker if there's interest. > > Any isssues (or comments), I'm here, or on the reddit discussion (or > email). > > Andrew Seniuk > rasfar on #haskell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Dec 19 16:27:12 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 19 Dec 2014 11:27:12 -0500 Subject: performance regressions In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F40403F@DB3PRD3001MB020.064d.mgd.msft.net> References: <289F091E-E18E-416A-A649-AA58C6BB3349@cis.upenn.edu> <87zjaokh4y.fsf@gmail.com> <201412160859.41292.jan.stolarek@p.lodz.pl> <8F6D2FFD-8778-4575-9689-791985EBAD75@cis.upenn.edu> <1418744518.1446.4.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF3F40363A@DB3PRD3001MB020.064d.mgd.msft.net> <5E06850B-012A-41A6-9E04-5E1B4F88D5E2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF3F40403F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5240C251-252C-448D-B7DD-C3F7460E25B6@cis.upenn.edu> I've gained a little more insight here, but only a little. INLINE doesn't work because zipWithAndUnzipM is recursive. Oddly, using worker/wrapper made allocations go *up*, so that's somehow not the answer. When I use `inline`, GHC will inline the function once; recursive calls remain. This seems to the local minimum in allocations. Using `inline` gives roughly a 7% allocation level change on this pathological case. To reproduce, just compile HEAD's TcFlatten with and without the call to `inline`. You can see, using -ddump-simpl, what GHC is doing. Then, you can check the allocation numbers by compiling perf/compiler/T9872a.hs. My tests were all using the default build settings, with an unmodified build.mk, as that seemed to be the most performant setting. In other news, a slight change to the algorithm (see #9872, comment 23) makes a 50% improvement. Will hopefully commit tonight, after a full local validation run. Richard On Dec 17, 2014, at 10:59 AM, Simon Peyton Jones wrote: > I still would like to understand why INLINE does not make it inline. That's weird. > > Eg way to reproduce. > > Simion > > | -----Original Message----- > | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] > | Sent: 17 December 2014 15:56 > | To: Simon Peyton Jones > | Cc: Joachim Breitner; ghc-devs at haskell.org > | Subject: Re: performance regressions > | > | By unsubstantiated guess is that INLINEABLE would have the same effect > | as INLINE here, as GHC doesn't see fit to actually inline the > | function, even with INLINE -- the big improvement seen between (1) and > | (2) is actually specialization, not inlining. The jump from (2) to (3) > | is actual inlining. Thus, it seems that GHC's heuristics for inlining > | aren't working out for the best here. > | > | I've pushed my changes, though I agree with Simon that more research > | may uncover even more improvements here. I didn't focus on the number > | of calls because that number didn't regress. Will look into this soon. > | > | Richard > | > | On Dec 17, 2014, at 4:15 AM, Simon Peyton Jones > | wrote: > | > | > If you use INLINEABLE, that should make the function specialisable > | to a particular monad, even if it's in a different module. You > | shouldn't need INLINE for that. > | > > | > I don't understand the difference between cases (2) and (3). > | > > | > I am still suspicious of why there are so many calls to this one > | function that it, alone, is allocating a significant proportion of > | compilation of the entire run of GHC. Are you sure there isn't an > | algorithmic improvement to be had, to simply reduce the number of > | calls? > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | > | Richard Eisenberg > | > | Sent: 16 December 2014 21:46 > | > | To: Joachim Breitner > | > | Cc: ghc-devs at haskell.org > | > | Subject: Re: performance regressions > | > | > | > | I've learned several very interesting things in this analysis. > | > | > | > | - Inlining polymorphic methods is very important. Here are some > | > | data points to back up that claim: > | > | * Original implementation using zipWithAndUnzipM: > | 8,472,613,440 > | > | bytes allocated in the heap > | > | * Adding {-# INLINE #-} to the definition thereof: > | 6,639,253,488 > | > | bytes allocated in the heap > | > | * Using `inline` at call site to force inlining: > | 6,281,539,792 > | > | bytes allocated in the heap > | > | > | > | The middle step above allowed GHC to specialize zipWithAndUnzipM > | to > | > | my particular monad, but GHC didn't see fit to actually inline > | the > | > | function. Using `inline` forced it, to good effect. (I did not > | > | collect data on code sizes, but it wouldn't be hard to.) > | > | > | > | By comparison: > | > | * Hand-written recursion: 6,587,809,112 bytes allocated in > | the > | > | heap > | > | Interestingly, this is *not* the best result! > | > | > | > | Conclusion: We should probably add INLINE pragmas to Util and > | > | MonadUtils. > | > | > | > | > | > | - I then looked at rejiggering the algorithm to keep the common > | > | case fast. This had a side effect of changing the > | zipWithAndUnzipM > | > | to mapAndUnzipM, from Control.Monad. To my surprise, this brought > | > | disaster! > | > | * Using `inline` and mapAndUnzipM: 7,463,047,432 bytes > | > | allocated in the heap > | > | * Hand-written recursion: 5,848,602,848 bytes > | > | allocated in the heap > | > | > | > | That last number is better than the numbers above because of the > | > | algorithm streamlining. But, the inadequacy of mapAndUnzipM > | > | surprised me -- it already has an INLINE pragma in Control.Monad > | of course. > | > | Looking at -ddump-simpl, it seems that mapAndUnzipM was indeed > | > | getting inlined, but a call to `map` remained, perhaps causing > | > | extra allocation. > | > | > | > | Conclusion: We should examine the implementation of mapAndUnzipM > | > | (and similar functions) in Control.Monad. Is it as fast as > | possible? > | > | > | > | > | > | > | > | In the end, I was unable to bring the allocation numbers down to > | > | where they were before my work. This is because the flattener now > | > | deals in roles. Most of its behavior is the same between nominal > | > | and representational roles, so it seems silly (though very > | > | possible) to specialize the code to nominal to keep that path > | fast. > | > | Instead, I identified one key spot and made that go fast. > | > | > | > | Thus, there is a 7% bump to memory usage on very-type-family- > | heavy > | > | code, compared to before my commit on Friday. (On more ordinary > | > | code, there is no noticeable change.) > | > | > | > | Validating my patch locally now; will push when that's done. > | > | > | > | Thanks, > | > | Richard > | > | > | > | On Dec 16, 2014, at 10:41 AM, Joachim Breitner | > | breitner.de> wrote: > | > | > | > | > Hi, > | > | > > | > | > > | > | > Am Dienstag, den 16.12.2014, 09:59 -0500 schrieb Richard > | Eisenberg: > | > | >> On Dec 16, 2014, at 4:01 AM, Joachim Breitner | > | breitner.de> wrote: > | > | >> > | > | >>> another guess (without looking at the code, sorry): Are they > | in > | > | the >>> same module? I.e., can GHC specialize the code to your > | > | particular Monad? > | > | > > | > | >> No, they're not in the same module. I could also try moving > | the > | > | >> zipWithAndUnzipM function to the same module, and even > | > | specializing >> it by hand to the right monad. > | > | > > | > | > I did mean zipWithAndUnzipM, so maybe yes: Try that. > | > | > > | > | > (I find it hard to believe that any polymorphic monadic code > | > | should > perform well, with those many calls to an unknown (>>=) > | > | with a > function parameter, but maybe I'm too pessimistic here.) > | > | > > >> Could that be preventing the fusing? > | > | > > | > | > There is not going to be any fusing here, at least not list > | > | fusion; > that would require your code to be written in terms of > | > | functions with > fusion rules. > | > | > > | > | > Greetings, > | > | > Joachim > | > | > > | > | > -- > | > | > Joachim "nomeata" Breitner > | > | > mail at joachim-breitner.de * http://www.joachim-breitner.de/ > > | > | Jabber: nomeata at joachim-breitner.de * GPG-Key: 0xF0FBF51F Debian > | > | > Developer: nomeata at debian.org > > > | > | _______________________________________________ > | > | > ghc-devs mailing list > | > | > ghc-devs at haskell.org > | > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > | > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs > | > > > From dreixel at gmail.com Fri Dec 19 18:04:36 2014 From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=) Date: Fri, 19 Dec 2014 18:04:36 +0000 Subject: Which language extensions to register for Cabal 1.22? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF5627C2A1@DBXPRD3001MB024.064d.mgd.msft.net> References: <87388c38sl.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF5627C2A1@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: I'm not sure what the criteria are either, but I guess DeriveAnyClass is comparable to the other extensions mentioned. Cheers, Pedro On Fri, Dec 19, 2014 at 10:07 AM, Simon Peyton Jones wrote: > > | ...which of the following language extensions (which are mentioned in > | T4437) are deemed stable enough to be registered in Cabal for GHC > | 7.10? > > I'm not sure what criteria you'd like to use! > > PatternSynonyms, PartialTypeSignatures, and NamedWildCards are all pretty > stable and should go in. > > StaticPointers will definitely continue to be there in future; but the > details of the API may change, and the current implementation is very much > a prototype. > > DeriveAnyClass: I defer to Pedro > > Simon > > | -----Original Message----- > | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] > | Sent: 18 December 2014 22:14 > | To: Simon Peyton Jones > | Cc: Johan Tibell; Austin Seipp; Duncan Coutts > | Subject: Which language extensions to register for Cabal 1.22? > | > | Hello Simon, > | > | ...which of the following language extensions (which are mentioned in > | T4437) are deemed stable enough to be registered in Cabal for GHC > | 7.10? > | > | - "DeriveAnyClass" > | - "PatternSynonyms" > | - "PartialTypeSignatures" > | - "NamedWildcards" > | - "StaticPointers" > | > | Cheers, > | hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.dessiatov at gmail.com Fri Dec 19 19:07:46 2014 From: anton.dessiatov at gmail.com (Anton Dessiatov) Date: Sat, 20 Dec 2014 01:07:46 +0600 Subject: GHC Heap Profiler time axis Message-ID: <414A9B689F8647A880CBD2FDE1BE9DDD@futurama.local> Hello, GHC hackers! Reposting this message from haskell-caf?, because it seems like this mailing list is closer to the subject. For the last 2 days I?m debugging something that looks like a space leak. My program is a rather long-running network service. When I first used heap profiler I was a bit confused with its output that showed that my program was running for only about 0.3-0.4 seconds when I launched it idling for about a minute. That was confusing enough for me to dig into GHC sources trying to figure out the reason behind this and I found that values of the sample times are taken from the mut_user_time function, which returns a time that process spent in user-mode code (outside the kernel) minus time spent on garbage collection. This introduces great amount of unpredictable non-linearity of the heap profile graph x axis, which I personally consider very counterintuitive. So my question is does anybody know why is it done this way? Wouldn?t it be better if x axis would just show a time elapsed since the process started? Kind regards, Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Fri Dec 19 21:24:25 2014 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 19 Dec 2014 21:24:25 +0000 Subject: Linker problem with HPC and TemplateHaskell Message-ID: Hi, I'm getting the following error message when compiling a Yesod application (which uses Template Haskell rather a lot) with -fhpc: /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when making a shared object; recompile with -fPIC Steps to reproduce: 1. Run 'yesod init' to make a new scaffold. Call it 'testsite' and select 'simple' for no database. 2. Run: cd testsite sed Settings.hs -i -e 's/staticRoot conf.*/staticRoot conf = "foo"/' # GHC doesn't like this line ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings -XMultiParamTypeClasses -XTypeFamilies -fhpc -O1 Running the ghc line again completes successfully. It seems that there is a missing ./Settings.dyn_o in the gcc command line that ghc calls, the first time through. It's there the second time so the link succeeds. No idea what that might mean. It's not a problem at -O0. I'm using 7.8.3 so this might be fixed now. Not sure what else might help! Any advice gratefully received. Cheers, David From ezyang at mit.edu Fri Dec 19 21:32:08 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 19 Dec 2014 16:32:08 -0500 Subject: Linker problem with HPC and TemplateHaskell In-Reply-To: References: Message-ID: <1419024711-sup-33@sabre> Sounds like a bug. File a ticket? If you can see if you can repro on GHC HEAD that would also be helpful. Edward Excerpts from David Turner's message of 2014-12-19 16:24:25 -0500: > Hi, > > I'm getting the following error message when compiling a Yesod > application (which uses Template Haskell rather a lot) with -fhpc: > > /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against > undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when > making a shared object; recompile with -fPIC > > Steps to reproduce: > > 1. Run 'yesod init' to make a new scaffold. Call it 'testsite' and > select 'simple' for no database. > 2. Run: > > cd testsite > sed Settings.hs -i -e 's/staticRoot conf.*/staticRoot conf = "foo"/' # > GHC doesn't like this line > ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings > -XMultiParamTypeClasses -XTypeFamilies -fhpc -O1 > > Running the ghc line again completes successfully. > > It seems that there is a missing ./Settings.dyn_o in the gcc command > line that ghc calls, the first time through. It's there the second > time so the link succeeds. No idea what that might mean. > > It's not a problem at -O0. > > I'm using 7.8.3 so this might be fixed now. > > Not sure what else might help! Any advice gratefully received. > > Cheers, > > David From dct25-561bs at mythic-beasts.com Fri Dec 19 21:58:36 2014 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 19 Dec 2014 21:58:36 +0000 Subject: Linker problem with HPC and TemplateHaskell In-Reply-To: <1419024711-sup-33@sabre> References: <1419024711-sup-33@sabre> Message-ID: Ok, I've opened https://ghc.haskell.org/trac/ghc/ticket/9909 I won't be able to repro on HEAD in the near future, I'm afraid. Many thanks, On 19 December 2014 at 21:32, Edward Z. Yang wrote: > Sounds like a bug. File a ticket? If you can see if you can > repro on GHC HEAD that would also be helpful. > > Edward > > Excerpts from David Turner's message of 2014-12-19 16:24:25 -0500: >> Hi, >> >> I'm getting the following error message when compiling a Yesod >> application (which uses Template Haskell rather a lot) with -fhpc: >> >> /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against >> undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when >> making a shared object; recompile with -fPIC >> >> Steps to reproduce: >> >> 1. Run 'yesod init' to make a new scaffold. Call it 'testsite' and >> select 'simple' for no database. >> 2. Run: >> >> cd testsite >> sed Settings.hs -i -e 's/staticRoot conf.*/staticRoot conf = "foo"/' # >> GHC doesn't like this line >> ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings >> -XMultiParamTypeClasses -XTypeFamilies -fhpc -O1 >> >> Running the ghc line again completes successfully. >> >> It seems that there is a missing ./Settings.dyn_o in the gcc command >> line that ghc calls, the first time through. It's there the second >> time so the link succeeds. No idea what that might mean. >> >> It's not a problem at -O0. >> >> I'm using 7.8.3 so this might be fixed now. >> >> Not sure what else might help! Any advice gratefully received. >> >> Cheers, >> >> David From gintautas.miliauskas at gmail.com Sun Dec 21 08:42:00 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Sun, 21 Dec 2014 09:42:00 +0100 Subject: Automating GHC build for Windows In-Reply-To: References: <1413916715.326367.181663173.2FBCEE30@webmail.messagingengine.com> Message-ID: Any progress on the Windows builder? The last build on the status page is back from October, so I take it the answer is in the negative :( Sorry for completely disappearing from the radar. I started my new job in December, and have had very little free time so far. I also don't have access to a proper Windows machine since I have been traveling quite a bit. Not sure when that is going to change :( On Tue, Nov 4, 2014 at 11:42 PM, P?li G?bor J?nos wrote: > 2014-11-04 23:16 GMT+01:00 P?li G?bor J?nos : > > it says that the same dist-boot\setup-configXXXX.tmp file is > > about to renamed (to dist-boot\setup-config) twice after each other > > (perhaps from different threads?)! [..] > > > > Well, I guess this can easily cause the problems I have seen so far... > > I can also imagine that this bug is present on other systems as well, > > but does not cause any harm (for some reason) so it is basically > > invisible. > > > > However, first it would be nice if somebody else could confirm that it > > is indeed the case. > > Yeah, for what it is worth, this also happens on my FreeBSD builder > too, but it works fine despite of that. > -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From gintautas.miliauskas at gmail.com Sun Dec 21 08:54:05 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Sun, 21 Dec 2014 09:54:05 +0100 Subject: Perl for Windows and GHC Message-ID: Hi, apologies again about disappearing completely. I started a new job recently and have been flying all over the place. I'm happy to see that D339 (auto-download mingw, upgrade version of gcc) has been merged, but there is an issue that needs followup. Austin mentioned that we need a Perl distribution for a proper GHC runtime. This is not a problem while running in msys2, since msys provides a perl binary, but this makes packaging a self-sufficient GHC distribution harder, AFAIU. Can we punt on this and let the Haskell Platform folks figure out how to package Perl properly (that's the only context where it's necessary, right?), or is this an urgent issue? If the latter, should we roll back D339 until it's resolved? If we really need to package perl, the PortableZIP edition of Strawberry Perl should work, I think. It's on the heavy side (92MB) and would probably need to be trimmed beforehand though. Are there any utilities other than ghc-split which rely on perl at ghc runtime? If not, are there any plans to convert ghc-split to a sane language? I would sign up if I knew I would have the time... :( -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sun Dec 21 09:06:33 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 21 Dec 2014 10:06:33 +0100 Subject: Perl for Windows and GHC In-Reply-To: (Gintautas Miliauskas's message of "Sun, 21 Dec 2014 09:54:05 +0100") References: Message-ID: <873889qsme.fsf@gmail.com> On 2014-12-21 at 09:54:05 +0100, Gintautas Miliauskas wrote: [...] > Are there any utilities other than ghc-split which rely on perl at ghc > runtime? If not, are there any plans to convert ghc-split to a sane > language? I would sign up if I knew I would have the time... :( https://ghc.haskell.org/trac/ghc/ticket/9832 :-) From gergo at erdi.hu Sun Dec 21 12:47:43 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Sun, 21 Dec 2014 20:47:43 +0800 (SGT) Subject: Triggering a Harbourmaster build on a given commit Message-ID: Hi, Given a concrete commit on a non-master branch (e.g. https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1), how do I manually trigger a Harbourmaster build + validation? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' A man's best friend is his dogma. From rasfar at gmail.com Sun Dec 21 22:20:30 2014 From: rasfar at gmail.com (Andrew Seniuk) Date: Sun, 21 Dec 2014 16:20:30 -0600 Subject: ANN: deepseq-bounded, seqaid, leaky In-Reply-To: References: Message-ID: Finally, in case the lack of constraints on dependencies put anyone off, please note that all deps in all three projects now have minimum and maximum bounds. Also, I should take this chance to note that there were no cache controls in the homepages linked above, so please force reloads in your browser to see latest versions. (The pages /now/ have caching prevention so this should not be necessary again.) And, it's nice to share your thoughts, don't you think? -Andrew On Fri, Dec 19, 2014 at 8:01 AM, Andrew Seniuk wrote: > Sorry, that was my first Reddit post and I messed up. > > Please use this link > http://www.reddit.com/r/haskell/comments/2pscxh/ann_deepseqbounded_seqaid_leaky/ > > -Andrew > > On Fri, Dec 19, 2014 at 7:07 AM, Andrew Seniuk wrote: > >> This trio of related packages explores strictness control in a variety of >> ways. >> >> deepseq-bounded provides classes and generic functions to artificially >> force evaluation, to extents controlled by static or dynamic configuration. >> >> seqaid puts that into practise, providing a GHC plugin to auto-instrument >> your package with a strictness harness, which is dynamically optimisable >> during runtime. This is supported directly in the GHC compilation >> pipeline, without requiring (or performing!) any edits to your sources. >> >> leaky is a minimal, prototypic executable that leaks space under current >> state-of-the-art compilation (GHC 7.8.3 -O2, at the present time). >> >> deepseq-bounded >> hackage: https://hackage.haskell.org/package/deepseq-bounded >> homepage: http://www.fremissant.net/deepseq-bounded >> >> seqaid >> hackage: https://hackage.haskell.org/package/seqaid >> homepage: http://www.fremissant.net/seqaid >> >> leaky >> hackage: https://hackage.haskell.org/package/leaky >> homepage: http://www.fremissant.net/leaky >> >> Reddit discussion for the three together: >> >> http://www.reddit.com/r/haskell/comments/2ps8f5/ann_deepseqbounded_seqaid_leaky/ >> >> Easiest way to try them all, is to install seqaid and run the demo: >> >> cabal install seqaid >> seqaid demo >> >> This tests seqaid on a local copy of the leaky source package. >> >> It turned out to be routine to extend deepseq-bounded and seqaid to >> dynamically configurable parallelisation (paraid?). Many other wrappers >> could be explored, too! Maybe seqaid should be renamed to koolaid or >> something... >> >> It's a pretty complicated system, and just first release, so there's >> bound to be lots of problems. I've not set up a bug tracker, but will >> maintain a casual list of bugs and feature requests at >> >> http://www.fremissant.net/seqaid/trac >> >> and will set up a proper tracker if there's interest. >> >> Any isssues (or comments), I'm here, or on the reddit discussion (or >> email). >> >> Andrew Seniuk >> rasfar on #haskell >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Dec 22 12:39:27 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 22 Dec 2014 13:39:27 +0100 Subject: How do I investigate parser conflicts? Message-ID: <201412221339.27916.jan.stolarek@p.lodz.pl> I noticed that changes I made to the Parser on my branch increase the number of reduce/reduce conflicts. Are there any tools/techniques/etc I can use to investigate this? Or do I just have to use trial and error (possibly guided with some knowledge of parsing)? Specifically, is there any way I can check which productions are causing conflicts? Janek From simonpj at microsoft.com Mon Dec 22 12:42:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Dec 2014 12:42:35 +0000 Subject: How do I investigate parser conflicts? In-Reply-To: <201412221339.27916.jan.stolarek@p.lodz.pl> References: <201412221339.27916.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF56280C4C@DBXPRD3001MB024.064d.mgd.msft.net> Yes! Use the --info flag for Happy https://www.haskell.org/happy/doc/html/sec-invoking.html Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan | Stolarek | Sent: 22 December 2014 12:39 | To: ghc-devs at haskell.org | Subject: How do I investigate parser conflicts? | | I noticed that changes I made to the Parser on my branch increase the | number of reduce/reduce conflicts. Are there any tools/techniques/etc | I can use to investigate this? Or do I just have to use trial and | error (possibly guided with some knowledge of parsing)? Specifically, | is there any way I can check which productions are causing conflicts? | | Janek | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From gergo at erdi.hu Mon Dec 22 12:44:06 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Mon, 22 Dec 2014 20:44:06 +0800 (SGT) Subject: How do I investigate parser conflicts? In-Reply-To: <201412221339.27916.jan.stolarek@p.lodz.pl> References: <201412221339.27916.jan.stolarek@p.lodz.pl> Message-ID: On Mon, 22 Dec 2014, Jan Stolarek wrote: > I noticed that changes I made to the Parser on my branch increase the number of reduce/reduce > conflicts. Are there any tools/techniques/etc I can use to investigate this? Or do I just have to > use trial and error (possibly guided with some knowledge of parsing)? Specifically, is there any > way I can check which productions are causing conflicts? Have you tried looking at the output produced by the -i flag of Happy? From jan.stolarek at p.lodz.pl Mon Dec 22 13:15:59 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 22 Dec 2014 14:15:59 +0100 Subject: How do I investigate parser conflicts? In-Reply-To: References: <201412221339.27916.jan.stolarek@p.lodz.pl> Message-ID: <201412221415.59516.jan.stolarek@p.lodz.pl> Yes, that's probably what I was looking for. Thanks. Janek PS. Only 55K lines of log to analyze... From mail at joachim-breitner.de Mon Dec 22 14:38:44 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 22 Dec 2014 15:38:44 +0100 Subject: The GHC 7.8.4 debian package now builds on arm In-Reply-To: <1418119560.3339.29.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> <5485C51D.3000200@centrum.cz> <1418053481.1441.51.camel@joachim-breitner.de> <87vblmay8a.fsf@gmail.com> <1418119560.3339.29.camel@joachim-breitner.de> Message-ID: <1419259124.23107.34.camel@joachim-breitner.de> Hi Ben, it seems the story is not over yet. For some reason, building out-of-tree libraries (like mtl) does not build .so files on arm*: https://buildd.debian.org/status/fetch.php?pkg=haskell-mtl&arch=armhf&ver=2.1.3.1-1&stamp=1418087332 which later causes breakage: [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.o ) [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.p_o ) https://buildd.debian.org/status/fetch.php?pkg=haskell-binary-shared&arch=armhf&ver=0.8.3-2&stamp=1419258130 Do you have any rough guesses what might be causing this? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Dec 22 14:39:57 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Dec 2014 14:39:57 +0000 Subject: Fatal: Reference is not a tree Message-ID: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> Dear devs When doing 'arc patch' I got fatal: reference is not a tree: d809f9d656780273f4f79e7a9fb934f783f79702 Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in submodule path 'utils/haddock' Should I worry? Simon simonpj at cam-05-unx:~/code/HEAD-2$ arc patch D202 arc patch D202 You have untracked files in this working copy. Working copy: /home/simonpj/code/HEAD-2/ Untracked files in working copy: flat-skol-diff foo foo2 index.html.1 index.html.2 index.html.3 resume spj-patch spj-patch-save testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown-linux_ghc.mk testsuite/tests/simplCore/should_compile/T8538.hs testsuite/tests/simplCore/should_compile/T9073.hs tmp-patch untch-patch Since you don't have '.gitignore' rules for these files and have not listed them in '.git/info/exclude', you may have forgotten to 'git add' them to your commit. Do you want to amend these files to the commit? [y/N] n n Created and checked out branch arcpatch-D202. Checking patch compiler/basicTypes/MkId.hs... Checking patch compiler/basicTypes/NameEnv.hs... Checking patch compiler/basicTypes/VarSet.hs... Checking patch compiler/deSugar/DsMeta.hs... Checking patch compiler/hsSyn/Convert.hs... Checking patch compiler/hsSyn/HsDecls.hs... Checking patch compiler/hsSyn/PlaceHolder.hs... Checking patch compiler/iface/BuildTyCl.hs... Checking patch compiler/iface/IfaceSyn.hs... Checking patch compiler/iface/MkIface.hs... Checking patch compiler/iface/TcIface.hs... Checking patch compiler/main/GHC.hs... Checking patch compiler/main/HscTypes.hs... Checking patch compiler/parser/ApiAnnotation.hs... Checking patch compiler/parser/Parser.y... Checking patch compiler/parser/RdrHsSyn.hs... Checking patch compiler/prelude/TysPrim.hs... Checking patch compiler/rename/RnSource.hs... Checking patch compiler/rename/RnTypes.hs... Checking patch compiler/typecheck/FamInst.hs... Checking patch compiler/typecheck/TcEnv.hs... Checking patch compiler/typecheck/TcEvidence.hs... Checking patch compiler/typecheck/TcInstDcls.hs... Checking patch compiler/typecheck/TcRnDriver.hs... Checking patch compiler/typecheck/TcRnMonad.hs... Checking patch compiler/typecheck/TcSplice.hs... Checking patch compiler/typecheck/TcTyClsDecls.hs... Checking patch compiler/typecheck/TcTypeNats.hs... Checking patch compiler/typecheck/TcValidity.hs... Checking patch compiler/types/CoAxiom.hs... Checking patch compiler/types/Coercion.hs... Checking patch compiler/types/FamInstEnv.hs... Checking patch compiler/types/Kind.hs... Checking patch compiler/types/OptCoercion.hs... Checking patch compiler/types/TyCon.hs... Checking patch compiler/types/TypeRep.hs... Checking patch compiler/types/TypeRep.hs-boot... Checking patch compiler/utils/Outputable.hs... Checking patch compiler/vectorise/Vectorise/Generic/PADict.hs... Checking patch compiler/vectorise/Vectorise/Generic/PAMethods.hs... Checking patch compiler/vectorise/Vectorise/Type/Env.hs... Checking patch compiler/vectorise/Vectorise/Utils/PADict.hs... Checking patch libraries/template-haskell/Language/Haskell/TH.hs... Checking patch libraries/template-haskell/Language/Haskell/TH/Lib.hs... Checking patch libraries/template-haskell/Language/Haskell/TH/Ppr.hs... Checking patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs... Checking patch libraries/template-haskell/Language/Haskell/TH/Syntax.hs... Checking patch testsuite/tests/ghci/scripts/T6018ghci.script... Checking patch testsuite/tests/ghci/scripts/T6018ghci.stdout... Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.script... Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr... Checking patch testsuite/tests/ghci/scripts/T6018ghcirnfail.script... Checking patch testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr... Checking patch testsuite/tests/ghci/scripts/all.T... Checking patch testsuite/tests/rename/should_fail/T6018rnfail.hs... Checking patch testsuite/tests/rename/should_fail/T6018rnfail.stderr... Checking patch testsuite/tests/rename/should_fail/all.T... Checking patch testsuite/tests/typecheck/should_compile/T6018.hs... Checking patch testsuite/tests/typecheck/should_compile/T6018.hs-boot... Checking patch testsuite/tests/typecheck/should_compile/T6018.stderr... Checking patch testsuite/tests/typecheck/should_compile/T6018a.hs... Checking patch testsuite/tests/typecheck/should_compile/all.T... Checking patch testsuite/tests/typecheck/should_fail/T6018Afail.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018Bfail.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018Cfail.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018Dfail.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018fail.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018fail.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed1.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr... /tmp/62xml2q9glk44k0o/14486-pNEMxf:4283: new blank line at EOF. + Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed2.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed3.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed4.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed5.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr... /tmp/62xml2q9glk44k0o/14486-pNEMxf:4399: new blank line at EOF. + Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed6.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed7.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed8.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed9.hs... Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr... Checking patch testsuite/tests/typecheck/should_fail/all.T... Checking patch utils/haddock... warning: unable to rmdir utils/haddock: Directory not empty Applied patch compiler/basicTypes/MkId.hs cleanly. Applied patch compiler/basicTypes/NameEnv.hs cleanly. Applied patch compiler/basicTypes/VarSet.hs cleanly. Applied patch compiler/deSugar/DsMeta.hs cleanly. Applied patch compiler/hsSyn/Convert.hs cleanly. Applied patch compiler/hsSyn/HsDecls.hs cleanly. Applied patch compiler/hsSyn/PlaceHolder.hs cleanly. Applied patch compiler/iface/BuildTyCl.hs cleanly. Applied patch compiler/iface/IfaceSyn.hs cleanly. Applied patch compiler/iface/MkIface.hs cleanly. Applied patch compiler/iface/TcIface.hs cleanly. Applied patch compiler/main/GHC.hs cleanly. Applied patch compiler/main/HscTypes.hs cleanly. Applied patch compiler/parser/ApiAnnotation.hs cleanly. Applied patch compiler/parser/Parser.y cleanly. Applied patch compiler/parser/RdrHsSyn.hs cleanly. Applied patch compiler/prelude/TysPrim.hs cleanly. Applied patch compiler/rename/RnSource.hs cleanly. Applied patch compiler/rename/RnTypes.hs cleanly. Applied patch compiler/typecheck/FamInst.hs cleanly. Applied patch compiler/typecheck/TcEnv.hs cleanly. Applied patch compiler/typecheck/TcEvidence.hs cleanly. Applied patch compiler/typecheck/TcInstDcls.hs cleanly. Applied patch compiler/typecheck/TcRnDriver.hs cleanly. Applied patch compiler/typecheck/TcRnMonad.hs cleanly. Applied patch compiler/typecheck/TcSplice.hs cleanly. Applied patch compiler/typecheck/TcTyClsDecls.hs cleanly. Applied patch compiler/typecheck/TcTypeNats.hs cleanly. Applied patch compiler/typecheck/TcValidity.hs cleanly. Applied patch compiler/types/CoAxiom.hs cleanly. Applied patch compiler/types/Coercion.hs cleanly. Applied patch compiler/types/FamInstEnv.hs cleanly. Applied patch compiler/types/Kind.hs cleanly. Applied patch compiler/types/OptCoercion.hs cleanly. Applied patch compiler/types/TyCon.hs cleanly. Applied patch compiler/types/TypeRep.hs cleanly. Applied patch compiler/types/TypeRep.hs-boot cleanly. Applied patch compiler/utils/Outputable.hs cleanly. Applied patch compiler/vectorise/Vectorise/Generic/PADict.hs cleanly. Applied patch compiler/vectorise/Vectorise/Generic/PAMethods.hs cleanly. Applied patch compiler/vectorise/Vectorise/Type/Env.hs cleanly. Applied patch compiler/vectorise/Vectorise/Utils/PADict.hs cleanly. Applied patch libraries/template-haskell/Language/Haskell/TH.hs cleanly. Applied patch libraries/template-haskell/Language/Haskell/TH/Lib.hs cleanly. Applied patch libraries/template-haskell/Language/Haskell/TH/Ppr.hs cleanly. Applied patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs cleanly. Applied patch libraries/template-haskell/Language/Haskell/TH/Syntax.hs cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.script cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.stdout cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcifail.script cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcirnfail.script cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr cleanly. Applied patch testsuite/tests/ghci/scripts/all.T cleanly. Applied patch testsuite/tests/rename/should_fail/T6018rnfail.hs cleanly. Applied patch testsuite/tests/rename/should_fail/T6018rnfail.stderr cleanly. Applied patch testsuite/tests/rename/should_fail/all.T cleanly. Applied patch testsuite/tests/typecheck/should_compile/T6018.hs cleanly. Applied patch testsuite/tests/typecheck/should_compile/T6018.hs-boot cleanly. Applied patch testsuite/tests/typecheck/should_compile/T6018.stderr cleanly. Applied patch testsuite/tests/typecheck/should_compile/T6018a.hs cleanly. Applied patch testsuite/tests/typecheck/should_compile/all.T cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018Afail.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018Bfail.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018Cfail.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018Dfail.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018fail.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018fail.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed1.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed2.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed3.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed4.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed5.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed6.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed7.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed8.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed9.hs cleanly. Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr cleanly. Applied patch testsuite/tests/typecheck/should_fail/all.T cleanly. Applied patch utils/haddock cleanly. warning: 2 lines add whitespace errors. Submodule 'libffi-tarballs' () registered for path 'libffi-tarballs' Submodule 'libraries/Cabal' () registered for path 'libraries/Cabal' Submodule 'libraries/Win32' () registered for path 'libraries/Win32' Submodule 'libraries/array' () registered for path 'libraries/array' Submodule 'libraries/binary' () registered for path 'libraries/binary' Submodule 'libraries/bytestring' () registered for path 'libraries/bytestring' Submodule 'libraries/containers' () registered for path 'libraries/containers' Submodule 'libraries/deepseq' () registered for path 'libraries/deepseq' Submodule 'libraries/directory' () registered for path 'libraries/directory' Submodule 'libraries/dph' () registered for path 'libraries/dph' Submodule 'libraries/filepath' () registered for path 'libraries/filepath' Submodule 'libraries/haskeline' () registered for path 'libraries/haskeline' Submodule 'libraries/hoopl' () registered for path 'libraries/hoopl' Submodule 'libraries/hpc' () registered for path 'libraries/hpc' Submodule 'libraries/parallel' () registered for path 'libraries/parallel' Submodule 'libraries/pretty' () registered for path 'libraries/pretty' Submodule 'libraries/primitive' () registered for path 'libraries/primitive' Submodule 'libraries/process' () registered for path 'libraries/process' Submodule 'libraries/random' () registered for path 'libraries/random' Submodule 'libraries/stm' () registered for path 'libraries/stm' Submodule 'libraries/terminfo' () registered for path 'libraries/terminfo' Submodule 'libraries/time' () registered for path 'libraries/time' Submodule 'libraries/transformers' () registered for path 'libraries/transformers' Submodule 'libraries/unix' () registered for path 'libraries/unix' Submodule 'libraries/vector' () registered for path 'libraries/vector' Submodule 'libraries/xhtml' () registered for path 'libraries/xhtml' Submodule 'nofib' () registered for path 'nofib' Submodule 'utils/haddock' () registered for path 'utils/haddock' Submodule 'utils/hsc2hs' () registered for path 'utils/hsc2hs' Submodule path 'libraries/Cabal': checked out '82d2fe1f5083e56f0b2d2c2409a3f673a56a5fe4' Submodule path 'libraries/containers': checked out 'ddf4e4a7abbfb81161251437a6a5bbe8167a7cde' Submodule path 'libraries/directory': checked out 'bcb8c40b5e0a17030bcc085b46bf8718ea713107' Submodule path 'libraries/hoopl': checked out 'a90a3af92be400af8912555bce21b041a1c48ad4' Submodule path 'libraries/pretty': checked out '110b105c491387a73dd37b4f86a686ed131767b2' Submodule path 'libraries/random': checked out '180aa65507d5b7c63d9f438ff908774bafc88d0d' fatal: reference is not a tree: d809f9d656780273f4f79e7a9fb934f783f79702 Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in submodule path 'utils/haddock' OKAY Successfully committed patch. simonpj at cam-05-unx:~/code/HEAD-2$ git fetch git fetch simonpj at cam-05-unx:~/code/HEAD-2$ git submodule update git submodule update simonpj at cam-05-unx:~/code/HEAD-2$ git status git status # On branch arcpatch-D202 # Untracked files: # (use "git add ..." to include in what will be committed) # # flat-skol-diff # foo # foo2 # index.html.1 # index.html.2 # index.html.3 # resume # spj-patch # spj-patch-save # testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown-linux_ghc.mk # testsuite/tests/simplCore/should_compile/T8538.hs # testsuite/tests/simplCore/should_compile/T9073.hs # tmp-patch # untch-patch nothing added to commit but untracked files present (use "git add" to track) simonpj at cam-05-unx:~/code/HEAD-2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Dec 22 14:59:48 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 22 Dec 2014 15:59:48 +0100 Subject: Fatal: Reference is not a tree In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: <201412221559.48264.jan.stolarek@p.lodz.pl> That's because I updated haddock submodule but that update was not pushed to Phab. I was able to do a quick build of my patch without updating haddock so it should only be a problem if you try to validate. That said, is there a way I can push changes in a submodule to a phab revision? Janek Dnia poniedzia?ek, 22 grudnia 2014, Simon Peyton Jones napisa?: > Dear devs > > When doing 'arc patch' I got > > fatal: reference is not a tree: d809f9d656780273f4f79e7a9fb934f783f79702 > Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in submodule > path 'utils/haddock' > > Should I worry? > > Simon > > > simonpj at cam-05-unx:~/code/HEAD-2$ arc patch D202 > arc patch D202 > You have untracked files in this working copy. > > Working copy: /home/simonpj/code/HEAD-2/ > > Untracked files in working copy: > flat-skol-diff > foo > foo2 > index.html.1 > index.html.2 > index.html.3 > resume > spj-patch > spj-patch-save > testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown-linux_ghc.mk > testsuite/tests/simplCore/should_compile/T8538.hs > testsuite/tests/simplCore/should_compile/T9073.hs > tmp-patch > untch-patch > > Since you don't have '.gitignore' rules for these files and have not listed > them in '.git/info/exclude', you may have forgotten to 'git add' them to > your commit. > > > Do you want to amend these files to the commit? [y/N] n > n > > Created and checked out branch arcpatch-D202. > Checking patch compiler/basicTypes/MkId.hs... > Checking patch compiler/basicTypes/NameEnv.hs... > Checking patch compiler/basicTypes/VarSet.hs... > Checking patch compiler/deSugar/DsMeta.hs... > Checking patch compiler/hsSyn/Convert.hs... > Checking patch compiler/hsSyn/HsDecls.hs... > Checking patch compiler/hsSyn/PlaceHolder.hs... > Checking patch compiler/iface/BuildTyCl.hs... > Checking patch compiler/iface/IfaceSyn.hs... > Checking patch compiler/iface/MkIface.hs... > Checking patch compiler/iface/TcIface.hs... > Checking patch compiler/main/GHC.hs... > Checking patch compiler/main/HscTypes.hs... > Checking patch compiler/parser/ApiAnnotation.hs... > Checking patch compiler/parser/Parser.y... > Checking patch compiler/parser/RdrHsSyn.hs... > Checking patch compiler/prelude/TysPrim.hs... > Checking patch compiler/rename/RnSource.hs... > Checking patch compiler/rename/RnTypes.hs... > Checking patch compiler/typecheck/FamInst.hs... > Checking patch compiler/typecheck/TcEnv.hs... > Checking patch compiler/typecheck/TcEvidence.hs... > Checking patch compiler/typecheck/TcInstDcls.hs... > Checking patch compiler/typecheck/TcRnDriver.hs... > Checking patch compiler/typecheck/TcRnMonad.hs... > Checking patch compiler/typecheck/TcSplice.hs... > Checking patch compiler/typecheck/TcTyClsDecls.hs... > Checking patch compiler/typecheck/TcTypeNats.hs... > Checking patch compiler/typecheck/TcValidity.hs... > Checking patch compiler/types/CoAxiom.hs... > Checking patch compiler/types/Coercion.hs... > Checking patch compiler/types/FamInstEnv.hs... > Checking patch compiler/types/Kind.hs... > Checking patch compiler/types/OptCoercion.hs... > Checking patch compiler/types/TyCon.hs... > Checking patch compiler/types/TypeRep.hs... > Checking patch compiler/types/TypeRep.hs-boot... > Checking patch compiler/utils/Outputable.hs... > Checking patch compiler/vectorise/Vectorise/Generic/PADict.hs... > Checking patch compiler/vectorise/Vectorise/Generic/PAMethods.hs... > Checking patch compiler/vectorise/Vectorise/Type/Env.hs... > Checking patch compiler/vectorise/Vectorise/Utils/PADict.hs... > Checking patch libraries/template-haskell/Language/Haskell/TH.hs... > Checking patch libraries/template-haskell/Language/Haskell/TH/Lib.hs... > Checking patch libraries/template-haskell/Language/Haskell/TH/Ppr.hs... > Checking patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs... > Checking patch libraries/template-haskell/Language/Haskell/TH/Syntax.hs... > Checking patch testsuite/tests/ghci/scripts/T6018ghci.script... > Checking patch testsuite/tests/ghci/scripts/T6018ghci.stdout... > Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.script... > Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr... > Checking patch testsuite/tests/ghci/scripts/T6018ghcirnfail.script... > Checking patch testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr... > Checking patch testsuite/tests/ghci/scripts/all.T... > Checking patch testsuite/tests/rename/should_fail/T6018rnfail.hs... > Checking patch testsuite/tests/rename/should_fail/T6018rnfail.stderr... > Checking patch testsuite/tests/rename/should_fail/all.T... > Checking patch testsuite/tests/typecheck/should_compile/T6018.hs... > Checking patch testsuite/tests/typecheck/should_compile/T6018.hs-boot... > Checking patch testsuite/tests/typecheck/should_compile/T6018.stderr... > Checking patch testsuite/tests/typecheck/should_compile/T6018a.hs... > Checking patch testsuite/tests/typecheck/should_compile/all.T... > Checking patch testsuite/tests/typecheck/should_fail/T6018Afail.hs... > Checking patch testsuite/tests/typecheck/should_fail/T6018Bfail.hs... > Checking patch testsuite/tests/typecheck/should_fail/T6018Cfail.hs... > Checking patch testsuite/tests/typecheck/should_fail/T6018Dfail.hs... > Checking patch testsuite/tests/typecheck/should_fail/T6018fail.hs... > Checking patch testsuite/tests/typecheck/should_fail/T6018fail.stderr... > Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed1.hs... > Checking patch > testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr... > /tmp/62xml2q9glk44k0o/14486-pNEMxf:4283: new blank line at EOF. > + > Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed2.hs... > Checking patch > testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed3.hs... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr... > Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed4.hs... > Checking patch > testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed5.hs... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr... > /tmp/62xml2q9glk44k0o/14486-pNEMxf:4399: new blank line at EOF. > + > Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed6.hs... > Checking patch > testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed7.hs... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr... > Checking patch testsuite/tests/typecheck/should_fail/T6018failclosed8.hs... > Checking patch > testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed9.hs... Checking > patch testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr... > Checking patch testsuite/tests/typecheck/should_fail/all.T... > Checking patch utils/haddock... > warning: unable to rmdir utils/haddock: Directory not empty > Applied patch compiler/basicTypes/MkId.hs cleanly. > Applied patch compiler/basicTypes/NameEnv.hs cleanly. > Applied patch compiler/basicTypes/VarSet.hs cleanly. > Applied patch compiler/deSugar/DsMeta.hs cleanly. > Applied patch compiler/hsSyn/Convert.hs cleanly. > Applied patch compiler/hsSyn/HsDecls.hs cleanly. > Applied patch compiler/hsSyn/PlaceHolder.hs cleanly. > Applied patch compiler/iface/BuildTyCl.hs cleanly. > Applied patch compiler/iface/IfaceSyn.hs cleanly. > Applied patch compiler/iface/MkIface.hs cleanly. > Applied patch compiler/iface/TcIface.hs cleanly. > Applied patch compiler/main/GHC.hs cleanly. > Applied patch compiler/main/HscTypes.hs cleanly. > Applied patch compiler/parser/ApiAnnotation.hs cleanly. > Applied patch compiler/parser/Parser.y cleanly. > Applied patch compiler/parser/RdrHsSyn.hs cleanly. > Applied patch compiler/prelude/TysPrim.hs cleanly. > Applied patch compiler/rename/RnSource.hs cleanly. > Applied patch compiler/rename/RnTypes.hs cleanly. > Applied patch compiler/typecheck/FamInst.hs cleanly. > Applied patch compiler/typecheck/TcEnv.hs cleanly. > Applied patch compiler/typecheck/TcEvidence.hs cleanly. > Applied patch compiler/typecheck/TcInstDcls.hs cleanly. > Applied patch compiler/typecheck/TcRnDriver.hs cleanly. > Applied patch compiler/typecheck/TcRnMonad.hs cleanly. > Applied patch compiler/typecheck/TcSplice.hs cleanly. > Applied patch compiler/typecheck/TcTyClsDecls.hs cleanly. > Applied patch compiler/typecheck/TcTypeNats.hs cleanly. > Applied patch compiler/typecheck/TcValidity.hs cleanly. > Applied patch compiler/types/CoAxiom.hs cleanly. > Applied patch compiler/types/Coercion.hs cleanly. > Applied patch compiler/types/FamInstEnv.hs cleanly. > Applied patch compiler/types/Kind.hs cleanly. > Applied patch compiler/types/OptCoercion.hs cleanly. > Applied patch compiler/types/TyCon.hs cleanly. > Applied patch compiler/types/TypeRep.hs cleanly. > Applied patch compiler/types/TypeRep.hs-boot cleanly. > Applied patch compiler/utils/Outputable.hs cleanly. > Applied patch compiler/vectorise/Vectorise/Generic/PADict.hs cleanly. > Applied patch compiler/vectorise/Vectorise/Generic/PAMethods.hs cleanly. > Applied patch compiler/vectorise/Vectorise/Type/Env.hs cleanly. > Applied patch compiler/vectorise/Vectorise/Utils/PADict.hs cleanly. > Applied patch libraries/template-haskell/Language/Haskell/TH.hs cleanly. > Applied patch libraries/template-haskell/Language/Haskell/TH/Lib.hs > cleanly. Applied patch > libraries/template-haskell/Language/Haskell/TH/Ppr.hs cleanly. Applied > patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs cleanly. > Applied patch libraries/template-haskell/Language/Haskell/TH/Syntax.hs > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.script > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.stdout > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcifail.script > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcirnfail.script > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr > cleanly. Applied patch testsuite/tests/ghci/scripts/all.T cleanly. > Applied patch testsuite/tests/rename/should_fail/T6018rnfail.hs cleanly. > Applied patch testsuite/tests/rename/should_fail/T6018rnfail.stderr > cleanly. Applied patch testsuite/tests/rename/should_fail/all.T cleanly. > Applied patch testsuite/tests/typecheck/should_compile/T6018.hs cleanly. > Applied patch testsuite/tests/typecheck/should_compile/T6018.hs-boot > cleanly. Applied patch > testsuite/tests/typecheck/should_compile/T6018.stderr cleanly. Applied > patch testsuite/tests/typecheck/should_compile/T6018a.hs cleanly. Applied > patch testsuite/tests/typecheck/should_compile/all.T cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018Afail.hs cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018Bfail.hs cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018Cfail.hs cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018Dfail.hs cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018fail.hs cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018fail.stderr cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed1.hs cleanly. > Applied patch testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed2.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed3.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed4.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed5.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed6.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed7.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed8.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr > cleanly. Applied patch > testsuite/tests/typecheck/should_fail/T6018failclosed9.hs cleanly. Applied > patch testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr > cleanly. Applied patch testsuite/tests/typecheck/should_fail/all.T cleanly. > Applied patch utils/haddock cleanly. > warning: 2 lines add whitespace errors. > Submodule 'libffi-tarballs' () registered for path 'libffi-tarballs' > Submodule 'libraries/Cabal' () registered for path 'libraries/Cabal' > Submodule 'libraries/Win32' () registered for path 'libraries/Win32' > Submodule 'libraries/array' () registered for path 'libraries/array' > Submodule 'libraries/binary' () registered for path 'libraries/binary' > Submodule 'libraries/bytestring' () registered for path > 'libraries/bytestring' Submodule 'libraries/containers' () registered for > path 'libraries/containers' Submodule 'libraries/deepseq' () registered for > path 'libraries/deepseq' Submodule 'libraries/directory' () registered for > path 'libraries/directory' Submodule 'libraries/dph' () registered for path > 'libraries/dph' > Submodule 'libraries/filepath' () registered for path 'libraries/filepath' > Submodule 'libraries/haskeline' () registered for path > 'libraries/haskeline' Submodule 'libraries/hoopl' () registered for path > 'libraries/hoopl' Submodule 'libraries/hpc' () registered for path > 'libraries/hpc' > Submodule 'libraries/parallel' () registered for path 'libraries/parallel' > Submodule 'libraries/pretty' () registered for path 'libraries/pretty' > Submodule 'libraries/primitive' () registered for path > 'libraries/primitive' Submodule 'libraries/process' () registered for path > 'libraries/process' Submodule 'libraries/random' () registered for path > 'libraries/random' Submodule 'libraries/stm' () registered for path > 'libraries/stm' > Submodule 'libraries/terminfo' () registered for path 'libraries/terminfo' > Submodule 'libraries/time' () registered for path 'libraries/time' > Submodule 'libraries/transformers' () registered for path > 'libraries/transformers' Submodule 'libraries/unix' () registered for path > 'libraries/unix' Submodule 'libraries/vector' () registered for path > 'libraries/vector' Submodule 'libraries/xhtml' () registered for path > 'libraries/xhtml' Submodule 'nofib' () registered for path 'nofib' > Submodule 'utils/haddock' () registered for path 'utils/haddock' > Submodule 'utils/hsc2hs' () registered for path 'utils/hsc2hs' > Submodule path 'libraries/Cabal': checked out > '82d2fe1f5083e56f0b2d2c2409a3f673a56a5fe4' Submodule path > 'libraries/containers': checked out > 'ddf4e4a7abbfb81161251437a6a5bbe8167a7cde' Submodule path > 'libraries/directory': checked out > 'bcb8c40b5e0a17030bcc085b46bf8718ea713107' Submodule path > 'libraries/hoopl': checked out 'a90a3af92be400af8912555bce21b041a1c48ad4' > Submodule path 'libraries/pretty': checked out > '110b105c491387a73dd37b4f86a686ed131767b2' Submodule path > 'libraries/random': checked out '180aa65507d5b7c63d9f438ff908774bafc88d0d' > fatal: reference is not a tree: d809f9d656780273f4f79e7a9fb934f783f79702 > Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in submodule > path 'utils/haddock' OKAY Successfully committed patch. > simonpj at cam-05-unx:~/code/HEAD-2$ git fetch > git fetch > simonpj at cam-05-unx:~/code/HEAD-2$ git submodule update > git submodule update > simonpj at cam-05-unx:~/code/HEAD-2$ git status > git status > # On branch arcpatch-D202 > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # flat-skol-diff > # foo > # foo2 > # index.html.1 > # index.html.2 > # index.html.3 > # resume > # spj-patch > # spj-patch-save > # > testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown-linux_ghc.mk # > testsuite/tests/simplCore/should_compile/T8538.hs > # testsuite/tests/simplCore/should_compile/T9073.hs > # tmp-patch > # untch-patch > nothing added to commit but untracked files present (use "git add" to > track) simonpj at cam-05-unx:~/code/HEAD-2$ From austin at well-typed.com Mon Dec 22 15:04:51 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 22 Dec 2014 09:04:51 -0600 Subject: Triggering a Harbourmaster build on a given commit In-Reply-To: References: Message-ID: Unfortunately it's a bit hidden in the UI. I'll try to explain: 1) Go to https://phabricator.haskell.org/harbormaster 2) On the left side, click on 'Manage Build Plans' 3) Click on 'Plan 2 - GHC Continuous Integration', which builds commits 4) On the right-hand side, click 'Run Plan Manually' 5) In the box, enter the 'object name'. NOTE: the object name is DIFFERENT than the raw commit SHA1. In Phabricator, a 'commit object' is identified fully by the repository callsign plus the SHA1. In your case, you want to test commit 20acaa7785. Therefore, the full object name would be 'rGHC20acaa785', just like it appears in the URL you posted. This should do the job. Hope that helps! On Sun, Dec 21, 2014 at 6:47 AM, Dr. ERDI Gergo wrote: > Hi, > > Given a concrete commit on a non-master branch (e.g. > https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1), > how do I manually trigger a Harbourmaster build + validation? > > Thanks, > Gergo > > -- > > .--= ULLA! =-----------------. > \ http://gergo.erdi.hu \ > `---= gergo at erdi.hu =-------' > A man's best friend is his dogma. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Mon Dec 22 15:05:02 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Dec 2014 15:05:02 +0000 Subject: Fatal: Reference is not a tree In-Reply-To: <201412221559.48264.jan.stolarek@p.lodz.pl> References: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> <201412221559.48264.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF56280F66@DBXPRD3001MB024.064d.mgd.msft.net> | That said, is there a way I can push changes in a submodule to a phab | revision? I have no idea! | -----Original Message----- | From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl] | Sent: 22 December 2014 15:00 | To: ghc-devs at haskell.org | Cc: Simon Peyton Jones | Subject: Re: Fatal: Reference is not a tree | | That's because I updated haddock submodule but that update was not | pushed to Phab. I was able to do a quick build of my patch without | updating haddock so it should only be a problem if you try to | validate. | | That said, is there a way I can push changes in a submodule to a phab | revision? | | Janek | | Dnia poniedzia?ek, 22 grudnia 2014, Simon Peyton Jones napisa?: | > Dear devs | > | > When doing 'arc patch' I got | > | > fatal: reference is not a tree: | > d809f9d656780273f4f79e7a9fb934f783f79702 | > Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in | > submodule path 'utils/haddock' | > | > Should I worry? | > | > Simon | > | > | > simonpj at cam-05-unx:~/code/HEAD-2$ arc patch D202 arc patch D202 You | > have untracked files in this working copy. | > | > Working copy: /home/simonpj/code/HEAD-2/ | > | > Untracked files in working copy: | > flat-skol-diff | > foo | > foo2 | > index.html.1 | > index.html.2 | > index.html.3 | > resume | > spj-patch | > spj-patch-save | > testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown- | linux_ghc.mk | > testsuite/tests/simplCore/should_compile/T8538.hs | > testsuite/tests/simplCore/should_compile/T9073.hs | > tmp-patch | > untch-patch | > | > Since you don't have '.gitignore' rules for these files and have not | > listed them in '.git/info/exclude', you may have forgotten to 'git | > add' them to your commit. | > | > | > Do you want to amend these files to the commit? [y/N] n n | > | > Created and checked out branch arcpatch-D202. | > Checking patch compiler/basicTypes/MkId.hs... | > Checking patch compiler/basicTypes/NameEnv.hs... | > Checking patch compiler/basicTypes/VarSet.hs... | > Checking patch compiler/deSugar/DsMeta.hs... | > Checking patch compiler/hsSyn/Convert.hs... | > Checking patch compiler/hsSyn/HsDecls.hs... | > Checking patch compiler/hsSyn/PlaceHolder.hs... | > Checking patch compiler/iface/BuildTyCl.hs... | > Checking patch compiler/iface/IfaceSyn.hs... | > Checking patch compiler/iface/MkIface.hs... | > Checking patch compiler/iface/TcIface.hs... | > Checking patch compiler/main/GHC.hs... | > Checking patch compiler/main/HscTypes.hs... | > Checking patch compiler/parser/ApiAnnotation.hs... | > Checking patch compiler/parser/Parser.y... | > Checking patch compiler/parser/RdrHsSyn.hs... | > Checking patch compiler/prelude/TysPrim.hs... | > Checking patch compiler/rename/RnSource.hs... | > Checking patch compiler/rename/RnTypes.hs... | > Checking patch compiler/typecheck/FamInst.hs... | > Checking patch compiler/typecheck/TcEnv.hs... | > Checking patch compiler/typecheck/TcEvidence.hs... | > Checking patch compiler/typecheck/TcInstDcls.hs... | > Checking patch compiler/typecheck/TcRnDriver.hs... | > Checking patch compiler/typecheck/TcRnMonad.hs... | > Checking patch compiler/typecheck/TcSplice.hs... | > Checking patch compiler/typecheck/TcTyClsDecls.hs... | > Checking patch compiler/typecheck/TcTypeNats.hs... | > Checking patch compiler/typecheck/TcValidity.hs... | > Checking patch compiler/types/CoAxiom.hs... | > Checking patch compiler/types/Coercion.hs... | > Checking patch compiler/types/FamInstEnv.hs... | > Checking patch compiler/types/Kind.hs... | > Checking patch compiler/types/OptCoercion.hs... | > Checking patch compiler/types/TyCon.hs... | > Checking patch compiler/types/TypeRep.hs... | > Checking patch compiler/types/TypeRep.hs-boot... | > Checking patch compiler/utils/Outputable.hs... | > Checking patch compiler/vectorise/Vectorise/Generic/PADict.hs... | > Checking patch compiler/vectorise/Vectorise/Generic/PAMethods.hs... | > Checking patch compiler/vectorise/Vectorise/Type/Env.hs... | > Checking patch compiler/vectorise/Vectorise/Utils/PADict.hs... | > Checking patch libraries/template-haskell/Language/Haskell/TH.hs... | > Checking patch libraries/template- | haskell/Language/Haskell/TH/Lib.hs... | > Checking patch libraries/template- | haskell/Language/Haskell/TH/Ppr.hs... | > Checking patch libraries/template- | haskell/Language/Haskell/TH/PprLib.hs... | > Checking patch libraries/template- | haskell/Language/Haskell/TH/Syntax.hs... | > Checking patch testsuite/tests/ghci/scripts/T6018ghci.script... | > Checking patch testsuite/tests/ghci/scripts/T6018ghci.stdout... | > Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.script... | > Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr... | > Checking patch | testsuite/tests/ghci/scripts/T6018ghcirnfail.script... | > Checking patch | testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr... | > Checking patch testsuite/tests/ghci/scripts/all.T... | > Checking patch testsuite/tests/rename/should_fail/T6018rnfail.hs... | > Checking patch | testsuite/tests/rename/should_fail/T6018rnfail.stderr... | > Checking patch testsuite/tests/rename/should_fail/all.T... | > Checking patch testsuite/tests/typecheck/should_compile/T6018.hs... | > Checking patch testsuite/tests/typecheck/should_compile/T6018.hs- | boot... | > Checking patch | testsuite/tests/typecheck/should_compile/T6018.stderr... | > Checking patch testsuite/tests/typecheck/should_compile/T6018a.hs... | > Checking patch testsuite/tests/typecheck/should_compile/all.T... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018Afail.hs... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018Bfail.hs... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018Cfail.hs... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018Dfail.hs... | > Checking patch testsuite/tests/typecheck/should_fail/T6018fail.hs... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018fail.stderr... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed1.hs... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr... | > /tmp/62xml2q9glk44k0o/14486-pNEMxf:4283: new blank line at EOF. | > + | > Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed2.hs... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed3.hs... | Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed4.hs... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed5.hs... | Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr... | > /tmp/62xml2q9glk44k0o/14486-pNEMxf:4399: new blank line at EOF. | > + | > Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed6.hs... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed7.hs... | Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr... | > Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed8.hs... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr... | > Checking patch | > testsuite/tests/typecheck/should_fail/T6018failclosed9.hs... | Checking patch | testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr... | > Checking patch testsuite/tests/typecheck/should_fail/all.T... | > Checking patch utils/haddock... | > warning: unable to rmdir utils/haddock: Directory not empty Applied | > patch compiler/basicTypes/MkId.hs cleanly. | > Applied patch compiler/basicTypes/NameEnv.hs cleanly. | > Applied patch compiler/basicTypes/VarSet.hs cleanly. | > Applied patch compiler/deSugar/DsMeta.hs cleanly. | > Applied patch compiler/hsSyn/Convert.hs cleanly. | > Applied patch compiler/hsSyn/HsDecls.hs cleanly. | > Applied patch compiler/hsSyn/PlaceHolder.hs cleanly. | > Applied patch compiler/iface/BuildTyCl.hs cleanly. | > Applied patch compiler/iface/IfaceSyn.hs cleanly. | > Applied patch compiler/iface/MkIface.hs cleanly. | > Applied patch compiler/iface/TcIface.hs cleanly. | > Applied patch compiler/main/GHC.hs cleanly. | > Applied patch compiler/main/HscTypes.hs cleanly. | > Applied patch compiler/parser/ApiAnnotation.hs cleanly. | > Applied patch compiler/parser/Parser.y cleanly. | > Applied patch compiler/parser/RdrHsSyn.hs cleanly. | > Applied patch compiler/prelude/TysPrim.hs cleanly. | > Applied patch compiler/rename/RnSource.hs cleanly. | > Applied patch compiler/rename/RnTypes.hs cleanly. | > Applied patch compiler/typecheck/FamInst.hs cleanly. | > Applied patch compiler/typecheck/TcEnv.hs cleanly. | > Applied patch compiler/typecheck/TcEvidence.hs cleanly. | > Applied patch compiler/typecheck/TcInstDcls.hs cleanly. | > Applied patch compiler/typecheck/TcRnDriver.hs cleanly. | > Applied patch compiler/typecheck/TcRnMonad.hs cleanly. | > Applied patch compiler/typecheck/TcSplice.hs cleanly. | > Applied patch compiler/typecheck/TcTyClsDecls.hs cleanly. | > Applied patch compiler/typecheck/TcTypeNats.hs cleanly. | > Applied patch compiler/typecheck/TcValidity.hs cleanly. | > Applied patch compiler/types/CoAxiom.hs cleanly. | > Applied patch compiler/types/Coercion.hs cleanly. | > Applied patch compiler/types/FamInstEnv.hs cleanly. | > Applied patch compiler/types/Kind.hs cleanly. | > Applied patch compiler/types/OptCoercion.hs cleanly. | > Applied patch compiler/types/TyCon.hs cleanly. | > Applied patch compiler/types/TypeRep.hs cleanly. | > Applied patch compiler/types/TypeRep.hs-boot cleanly. | > Applied patch compiler/utils/Outputable.hs cleanly. | > Applied patch compiler/vectorise/Vectorise/Generic/PADict.hs | cleanly. | > Applied patch compiler/vectorise/Vectorise/Generic/PAMethods.hs | cleanly. | > Applied patch compiler/vectorise/Vectorise/Type/Env.hs cleanly. | > Applied patch compiler/vectorise/Vectorise/Utils/PADict.hs cleanly. | > Applied patch libraries/template-haskell/Language/Haskell/TH.hs | cleanly. | > Applied patch libraries/template-haskell/Language/Haskell/TH/Lib.hs | > cleanly. Applied patch | > libraries/template-haskell/Language/Haskell/TH/Ppr.hs cleanly. | Applied | > patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs | cleanly. | > Applied patch libraries/template- | haskell/Language/Haskell/TH/Syntax.hs | > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.script | > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.stdout | > cleanly. Applied patch | > testsuite/tests/ghci/scripts/T6018ghcifail.script | > cleanly. Applied patch | > testsuite/tests/ghci/scripts/T6018ghcifail.stderr | > cleanly. Applied patch | > testsuite/tests/ghci/scripts/T6018ghcirnfail.script | > cleanly. Applied patch | > testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr | > cleanly. Applied patch testsuite/tests/ghci/scripts/all.T cleanly. | > Applied patch testsuite/tests/rename/should_fail/T6018rnfail.hs | cleanly. | > Applied patch testsuite/tests/rename/should_fail/T6018rnfail.stderr | > cleanly. Applied patch testsuite/tests/rename/should_fail/all.T | cleanly. | > Applied patch testsuite/tests/typecheck/should_compile/T6018.hs | cleanly. | > Applied patch testsuite/tests/typecheck/should_compile/T6018.hs-boot | > cleanly. Applied patch | > testsuite/tests/typecheck/should_compile/T6018.stderr cleanly. | Applied | > patch testsuite/tests/typecheck/should_compile/T6018a.hs cleanly. | > Applied patch testsuite/tests/typecheck/should_compile/all.T | cleanly. | > Applied patch testsuite/tests/typecheck/should_fail/T6018Afail.hs | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018Bfail.hs cleanly. Applied | > patch testsuite/tests/typecheck/should_fail/T6018Cfail.hs cleanly. | > Applied patch testsuite/tests/typecheck/should_fail/T6018Dfail.hs | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018fail.hs cleanly. Applied | patch testsuite/tests/typecheck/should_fail/T6018fail.stderr cleanly. | Applied patch | testsuite/tests/typecheck/should_fail/T6018failclosed1.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed2.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed3.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed4.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed5.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed6.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed7.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed8.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr | > cleanly. Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed9.hs cleanly. | > Applied patch | > testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr | > cleanly. Applied patch testsuite/tests/typecheck/should_fail/all.T | cleanly. | > Applied patch utils/haddock cleanly. | > warning: 2 lines add whitespace errors. | > Submodule 'libffi-tarballs' () registered for path 'libffi-tarballs' | > Submodule 'libraries/Cabal' () registered for path 'libraries/Cabal' | > Submodule 'libraries/Win32' () registered for path 'libraries/Win32' | > Submodule 'libraries/array' () registered for path 'libraries/array' | > Submodule 'libraries/binary' () registered for path | 'libraries/binary' | > Submodule 'libraries/bytestring' () registered for path | > 'libraries/bytestring' Submodule 'libraries/containers' () | registered | > for path 'libraries/containers' Submodule 'libraries/deepseq' () | > registered for path 'libraries/deepseq' Submodule | > 'libraries/directory' () registered for path 'libraries/directory' | > Submodule 'libraries/dph' () registered for path 'libraries/dph' | > Submodule 'libraries/filepath' () registered for path | 'libraries/filepath' | > Submodule 'libraries/haskeline' () registered for path | > 'libraries/haskeline' Submodule 'libraries/hoopl' () registered for | > path 'libraries/hoopl' Submodule 'libraries/hpc' () registered for | > path 'libraries/hpc' | > Submodule 'libraries/parallel' () registered for path | 'libraries/parallel' | > Submodule 'libraries/pretty' () registered for path | 'libraries/pretty' | > Submodule 'libraries/primitive' () registered for path | > 'libraries/primitive' Submodule 'libraries/process' () registered | for | > path 'libraries/process' Submodule 'libraries/random' () registered | > for path 'libraries/random' Submodule 'libraries/stm' () registered | > for path 'libraries/stm' | > Submodule 'libraries/terminfo' () registered for path | 'libraries/terminfo' | > Submodule 'libraries/time' () registered for path 'libraries/time' | > Submodule 'libraries/transformers' () registered for path | > 'libraries/transformers' Submodule 'libraries/unix' () registered | for | > path 'libraries/unix' Submodule 'libraries/vector' () registered for | > path 'libraries/vector' Submodule 'libraries/xhtml' () registered | for | > path 'libraries/xhtml' Submodule 'nofib' () registered for path | 'nofib' | > Submodule 'utils/haddock' () registered for path 'utils/haddock' | > Submodule 'utils/hsc2hs' () registered for path 'utils/hsc2hs' | > Submodule path 'libraries/Cabal': checked out | > '82d2fe1f5083e56f0b2d2c2409a3f673a56a5fe4' Submodule path | > 'libraries/containers': checked out | > 'ddf4e4a7abbfb81161251437a6a5bbe8167a7cde' Submodule path | > 'libraries/directory': checked out | > 'bcb8c40b5e0a17030bcc085b46bf8718ea713107' Submodule path | > 'libraries/hoopl': checked out | 'a90a3af92be400af8912555bce21b041a1c48ad4' | > Submodule path 'libraries/pretty': checked out | > '110b105c491387a73dd37b4f86a686ed131767b2' Submodule path | > 'libraries/random': checked out | '180aa65507d5b7c63d9f438ff908774bafc88d0d' | > fatal: reference is not a tree: | > d809f9d656780273f4f79e7a9fb934f783f79702 | > Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in | > submodule path 'utils/haddock' OKAY Successfully committed patch. | > simonpj at cam-05-unx:~/code/HEAD-2$ git fetch git fetch | > simonpj at cam-05-unx:~/code/HEAD-2$ git submodule update git submodule | > update simonpj at cam-05-unx:~/code/HEAD-2$ git status git status # On | > branch arcpatch-D202 # Untracked files: | > # (use "git add ..." to include in what will be committed) | > # | > # flat-skol-diff | > # foo | > # foo2 | > # index.html.1 | > # index.html.2 | > # index.html.3 | > # resume | > # spj-patch | > # spj-patch-save | > # | > testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown- | linux_ghc.mk # | > testsuite/tests/simplCore/should_compile/T8538.hs | > # testsuite/tests/simplCore/should_compile/T9073.hs | > # tmp-patch | > # untch-patch | > nothing added to commit but untracked files present (use "git add" | to | > track) simonpj at cam-05-unx:~/code/HEAD-2$ | From austin at well-typed.com Mon Dec 22 15:09:46 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 22 Dec 2014 09:09:46 -0600 Subject: Fatal: Reference is not a tree In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF56280F66@DBXPRD3001MB024.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> <201412221559.48264.jan.stolarek@p.lodz.pl> <618BE556AADD624C9C918AA5D5911BEF56280F66@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: Haddock is on Phabricator and has an .arcconfig file. All you need to do is submit a revision like normally, just run 'arc diff' in the Haddock directory. Also, since you have push access to the repository, you can always just push your Haddock changes to a branch; for example, commit them to 'wip/my-cool-thing' and push that branch publicly. Then point your utils/haddock to that SHA1, and 'arc diff'. The rest should work just fine when you run 'arc patch' or 'arc diff', or when Harbormaster builds it. On Mon, Dec 22, 2014 at 9:05 AM, Simon Peyton Jones wrote: > | That said, is there a way I can push changes in a submodule to a phab > | revision? > > I have no idea! > > | -----Original Message----- > | From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl] > | Sent: 22 December 2014 15:00 > | To: ghc-devs at haskell.org > | Cc: Simon Peyton Jones > | Subject: Re: Fatal: Reference is not a tree > | > | That's because I updated haddock submodule but that update was not > | pushed to Phab. I was able to do a quick build of my patch without > | updating haddock so it should only be a problem if you try to > | validate. > | > | That said, is there a way I can push changes in a submodule to a phab > | revision? > | > | Janek > | > | Dnia poniedzia?ek, 22 grudnia 2014, Simon Peyton Jones napisa?: > | > Dear devs > | > > | > When doing 'arc patch' I got > | > > | > fatal: reference is not a tree: > | > d809f9d656780273f4f79e7a9fb934f783f79702 > | > Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in > | > submodule path 'utils/haddock' > | > > | > Should I worry? > | > > | > Simon > | > > | > > | > simonpj at cam-05-unx:~/code/HEAD-2$ arc patch D202 arc patch D202 You > | > have untracked files in this working copy. > | > > | > Working copy: /home/simonpj/code/HEAD-2/ > | > > | > Untracked files in working copy: > | > flat-skol-diff > | > foo > | > foo2 > | > index.html.1 > | > index.html.2 > | > index.html.3 > | > resume > | > spj-patch > | > spj-patch-save > | > testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown- > | linux_ghc.mk > | > testsuite/tests/simplCore/should_compile/T8538.hs > | > testsuite/tests/simplCore/should_compile/T9073.hs > | > tmp-patch > | > untch-patch > | > > | > Since you don't have '.gitignore' rules for these files and have not > | > listed them in '.git/info/exclude', you may have forgotten to 'git > | > add' them to your commit. > | > > | > > | > Do you want to amend these files to the commit? [y/N] n n > | > > | > Created and checked out branch arcpatch-D202. > | > Checking patch compiler/basicTypes/MkId.hs... > | > Checking patch compiler/basicTypes/NameEnv.hs... > | > Checking patch compiler/basicTypes/VarSet.hs... > | > Checking patch compiler/deSugar/DsMeta.hs... > | > Checking patch compiler/hsSyn/Convert.hs... > | > Checking patch compiler/hsSyn/HsDecls.hs... > | > Checking patch compiler/hsSyn/PlaceHolder.hs... > | > Checking patch compiler/iface/BuildTyCl.hs... > | > Checking patch compiler/iface/IfaceSyn.hs... > | > Checking patch compiler/iface/MkIface.hs... > | > Checking patch compiler/iface/TcIface.hs... > | > Checking patch compiler/main/GHC.hs... > | > Checking patch compiler/main/HscTypes.hs... > | > Checking patch compiler/parser/ApiAnnotation.hs... > | > Checking patch compiler/parser/Parser.y... > | > Checking patch compiler/parser/RdrHsSyn.hs... > | > Checking patch compiler/prelude/TysPrim.hs... > | > Checking patch compiler/rename/RnSource.hs... > | > Checking patch compiler/rename/RnTypes.hs... > | > Checking patch compiler/typecheck/FamInst.hs... > | > Checking patch compiler/typecheck/TcEnv.hs... > | > Checking patch compiler/typecheck/TcEvidence.hs... > | > Checking patch compiler/typecheck/TcInstDcls.hs... > | > Checking patch compiler/typecheck/TcRnDriver.hs... > | > Checking patch compiler/typecheck/TcRnMonad.hs... > | > Checking patch compiler/typecheck/TcSplice.hs... > | > Checking patch compiler/typecheck/TcTyClsDecls.hs... > | > Checking patch compiler/typecheck/TcTypeNats.hs... > | > Checking patch compiler/typecheck/TcValidity.hs... > | > Checking patch compiler/types/CoAxiom.hs... > | > Checking patch compiler/types/Coercion.hs... > | > Checking patch compiler/types/FamInstEnv.hs... > | > Checking patch compiler/types/Kind.hs... > | > Checking patch compiler/types/OptCoercion.hs... > | > Checking patch compiler/types/TyCon.hs... > | > Checking patch compiler/types/TypeRep.hs... > | > Checking patch compiler/types/TypeRep.hs-boot... > | > Checking patch compiler/utils/Outputable.hs... > | > Checking patch compiler/vectorise/Vectorise/Generic/PADict.hs... > | > Checking patch compiler/vectorise/Vectorise/Generic/PAMethods.hs... > | > Checking patch compiler/vectorise/Vectorise/Type/Env.hs... > | > Checking patch compiler/vectorise/Vectorise/Utils/PADict.hs... > | > Checking patch libraries/template-haskell/Language/Haskell/TH.hs... > | > Checking patch libraries/template- > | haskell/Language/Haskell/TH/Lib.hs... > | > Checking patch libraries/template- > | haskell/Language/Haskell/TH/Ppr.hs... > | > Checking patch libraries/template- > | haskell/Language/Haskell/TH/PprLib.hs... > | > Checking patch libraries/template- > | haskell/Language/Haskell/TH/Syntax.hs... > | > Checking patch testsuite/tests/ghci/scripts/T6018ghci.script... > | > Checking patch testsuite/tests/ghci/scripts/T6018ghci.stdout... > | > Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.script... > | > Checking patch testsuite/tests/ghci/scripts/T6018ghcifail.stderr... > | > Checking patch > | testsuite/tests/ghci/scripts/T6018ghcirnfail.script... > | > Checking patch > | testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr... > | > Checking patch testsuite/tests/ghci/scripts/all.T... > | > Checking patch testsuite/tests/rename/should_fail/T6018rnfail.hs... > | > Checking patch > | testsuite/tests/rename/should_fail/T6018rnfail.stderr... > | > Checking patch testsuite/tests/rename/should_fail/all.T... > | > Checking patch testsuite/tests/typecheck/should_compile/T6018.hs... > | > Checking patch testsuite/tests/typecheck/should_compile/T6018.hs- > | boot... > | > Checking patch > | testsuite/tests/typecheck/should_compile/T6018.stderr... > | > Checking patch testsuite/tests/typecheck/should_compile/T6018a.hs... > | > Checking patch testsuite/tests/typecheck/should_compile/all.T... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018Afail.hs... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018Bfail.hs... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018Cfail.hs... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018Dfail.hs... > | > Checking patch testsuite/tests/typecheck/should_fail/T6018fail.hs... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018fail.stderr... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed1.hs... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr... > | > /tmp/62xml2q9glk44k0o/14486-pNEMxf:4283: new blank line at EOF. > | > + > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed2.hs... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed3.hs... > | Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed4.hs... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed5.hs... > | Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr... > | > /tmp/62xml2q9glk44k0o/14486-pNEMxf:4399: new blank line at EOF. > | > + > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed6.hs... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed7.hs... > | Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr... > | > Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed8.hs... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr... > | > Checking patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed9.hs... > | Checking patch > | testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr... > | > Checking patch testsuite/tests/typecheck/should_fail/all.T... > | > Checking patch utils/haddock... > | > warning: unable to rmdir utils/haddock: Directory not empty Applied > | > patch compiler/basicTypes/MkId.hs cleanly. > | > Applied patch compiler/basicTypes/NameEnv.hs cleanly. > | > Applied patch compiler/basicTypes/VarSet.hs cleanly. > | > Applied patch compiler/deSugar/DsMeta.hs cleanly. > | > Applied patch compiler/hsSyn/Convert.hs cleanly. > | > Applied patch compiler/hsSyn/HsDecls.hs cleanly. > | > Applied patch compiler/hsSyn/PlaceHolder.hs cleanly. > | > Applied patch compiler/iface/BuildTyCl.hs cleanly. > | > Applied patch compiler/iface/IfaceSyn.hs cleanly. > | > Applied patch compiler/iface/MkIface.hs cleanly. > | > Applied patch compiler/iface/TcIface.hs cleanly. > | > Applied patch compiler/main/GHC.hs cleanly. > | > Applied patch compiler/main/HscTypes.hs cleanly. > | > Applied patch compiler/parser/ApiAnnotation.hs cleanly. > | > Applied patch compiler/parser/Parser.y cleanly. > | > Applied patch compiler/parser/RdrHsSyn.hs cleanly. > | > Applied patch compiler/prelude/TysPrim.hs cleanly. > | > Applied patch compiler/rename/RnSource.hs cleanly. > | > Applied patch compiler/rename/RnTypes.hs cleanly. > | > Applied patch compiler/typecheck/FamInst.hs cleanly. > | > Applied patch compiler/typecheck/TcEnv.hs cleanly. > | > Applied patch compiler/typecheck/TcEvidence.hs cleanly. > | > Applied patch compiler/typecheck/TcInstDcls.hs cleanly. > | > Applied patch compiler/typecheck/TcRnDriver.hs cleanly. > | > Applied patch compiler/typecheck/TcRnMonad.hs cleanly. > | > Applied patch compiler/typecheck/TcSplice.hs cleanly. > | > Applied patch compiler/typecheck/TcTyClsDecls.hs cleanly. > | > Applied patch compiler/typecheck/TcTypeNats.hs cleanly. > | > Applied patch compiler/typecheck/TcValidity.hs cleanly. > | > Applied patch compiler/types/CoAxiom.hs cleanly. > | > Applied patch compiler/types/Coercion.hs cleanly. > | > Applied patch compiler/types/FamInstEnv.hs cleanly. > | > Applied patch compiler/types/Kind.hs cleanly. > | > Applied patch compiler/types/OptCoercion.hs cleanly. > | > Applied patch compiler/types/TyCon.hs cleanly. > | > Applied patch compiler/types/TypeRep.hs cleanly. > | > Applied patch compiler/types/TypeRep.hs-boot cleanly. > | > Applied patch compiler/utils/Outputable.hs cleanly. > | > Applied patch compiler/vectorise/Vectorise/Generic/PADict.hs > | cleanly. > | > Applied patch compiler/vectorise/Vectorise/Generic/PAMethods.hs > | cleanly. > | > Applied patch compiler/vectorise/Vectorise/Type/Env.hs cleanly. > | > Applied patch compiler/vectorise/Vectorise/Utils/PADict.hs cleanly. > | > Applied patch libraries/template-haskell/Language/Haskell/TH.hs > | cleanly. > | > Applied patch libraries/template-haskell/Language/Haskell/TH/Lib.hs > | > cleanly. Applied patch > | > libraries/template-haskell/Language/Haskell/TH/Ppr.hs cleanly. > | Applied > | > patch libraries/template-haskell/Language/Haskell/TH/PprLib.hs > | cleanly. > | > Applied patch libraries/template- > | haskell/Language/Haskell/TH/Syntax.hs > | > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.script > | > cleanly. Applied patch testsuite/tests/ghci/scripts/T6018ghci.stdout > | > cleanly. Applied patch > | > testsuite/tests/ghci/scripts/T6018ghcifail.script > | > cleanly. Applied patch > | > testsuite/tests/ghci/scripts/T6018ghcifail.stderr > | > cleanly. Applied patch > | > testsuite/tests/ghci/scripts/T6018ghcirnfail.script > | > cleanly. Applied patch > | > testsuite/tests/ghci/scripts/T6018ghcirnfail.stderr > | > cleanly. Applied patch testsuite/tests/ghci/scripts/all.T cleanly. > | > Applied patch testsuite/tests/rename/should_fail/T6018rnfail.hs > | cleanly. > | > Applied patch testsuite/tests/rename/should_fail/T6018rnfail.stderr > | > cleanly. Applied patch testsuite/tests/rename/should_fail/all.T > | cleanly. > | > Applied patch testsuite/tests/typecheck/should_compile/T6018.hs > | cleanly. > | > Applied patch testsuite/tests/typecheck/should_compile/T6018.hs-boot > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_compile/T6018.stderr cleanly. > | Applied > | > patch testsuite/tests/typecheck/should_compile/T6018a.hs cleanly. > | > Applied patch testsuite/tests/typecheck/should_compile/all.T > | cleanly. > | > Applied patch testsuite/tests/typecheck/should_fail/T6018Afail.hs > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018Bfail.hs cleanly. Applied > | > patch testsuite/tests/typecheck/should_fail/T6018Cfail.hs cleanly. > | > Applied patch testsuite/tests/typecheck/should_fail/T6018Dfail.hs > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018fail.hs cleanly. Applied > | patch testsuite/tests/typecheck/should_fail/T6018fail.stderr cleanly. > | Applied patch > | testsuite/tests/typecheck/should_fail/T6018failclosed1.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed1.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed2.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed2.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed3.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed3.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed4.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed4.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed5.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed5.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed6.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed6.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed7.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed7.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed8.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed8.stderr > | > cleanly. Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed9.hs cleanly. > | > Applied patch > | > testsuite/tests/typecheck/should_fail/T6018failclosed9.stderr > | > cleanly. Applied patch testsuite/tests/typecheck/should_fail/all.T > | cleanly. > | > Applied patch utils/haddock cleanly. > | > warning: 2 lines add whitespace errors. > | > Submodule 'libffi-tarballs' () registered for path 'libffi-tarballs' > | > Submodule 'libraries/Cabal' () registered for path 'libraries/Cabal' > | > Submodule 'libraries/Win32' () registered for path 'libraries/Win32' > | > Submodule 'libraries/array' () registered for path 'libraries/array' > | > Submodule 'libraries/binary' () registered for path > | 'libraries/binary' > | > Submodule 'libraries/bytestring' () registered for path > | > 'libraries/bytestring' Submodule 'libraries/containers' () > | registered > | > for path 'libraries/containers' Submodule 'libraries/deepseq' () > | > registered for path 'libraries/deepseq' Submodule > | > 'libraries/directory' () registered for path 'libraries/directory' > | > Submodule 'libraries/dph' () registered for path 'libraries/dph' > | > Submodule 'libraries/filepath' () registered for path > | 'libraries/filepath' > | > Submodule 'libraries/haskeline' () registered for path > | > 'libraries/haskeline' Submodule 'libraries/hoopl' () registered for > | > path 'libraries/hoopl' Submodule 'libraries/hpc' () registered for > | > path 'libraries/hpc' > | > Submodule 'libraries/parallel' () registered for path > | 'libraries/parallel' > | > Submodule 'libraries/pretty' () registered for path > | 'libraries/pretty' > | > Submodule 'libraries/primitive' () registered for path > | > 'libraries/primitive' Submodule 'libraries/process' () registered > | for > | > path 'libraries/process' Submodule 'libraries/random' () registered > | > for path 'libraries/random' Submodule 'libraries/stm' () registered > | > for path 'libraries/stm' > | > Submodule 'libraries/terminfo' () registered for path > | 'libraries/terminfo' > | > Submodule 'libraries/time' () registered for path 'libraries/time' > | > Submodule 'libraries/transformers' () registered for path > | > 'libraries/transformers' Submodule 'libraries/unix' () registered > | for > | > path 'libraries/unix' Submodule 'libraries/vector' () registered for > | > path 'libraries/vector' Submodule 'libraries/xhtml' () registered > | for > | > path 'libraries/xhtml' Submodule 'nofib' () registered for path > | 'nofib' > | > Submodule 'utils/haddock' () registered for path 'utils/haddock' > | > Submodule 'utils/hsc2hs' () registered for path 'utils/hsc2hs' > | > Submodule path 'libraries/Cabal': checked out > | > '82d2fe1f5083e56f0b2d2c2409a3f673a56a5fe4' Submodule path > | > 'libraries/containers': checked out > | > 'ddf4e4a7abbfb81161251437a6a5bbe8167a7cde' Submodule path > | > 'libraries/directory': checked out > | > 'bcb8c40b5e0a17030bcc085b46bf8718ea713107' Submodule path > | > 'libraries/hoopl': checked out > | 'a90a3af92be400af8912555bce21b041a1c48ad4' > | > Submodule path 'libraries/pretty': checked out > | > '110b105c491387a73dd37b4f86a686ed131767b2' Submodule path > | > 'libraries/random': checked out > | '180aa65507d5b7c63d9f438ff908774bafc88d0d' > | > fatal: reference is not a tree: > | > d809f9d656780273f4f79e7a9fb934f783f79702 > | > Unable to checkout 'd809f9d656780273f4f79e7a9fb934f783f79702' in > | > submodule path 'utils/haddock' OKAY Successfully committed patch. > | > simonpj at cam-05-unx:~/code/HEAD-2$ git fetch git fetch > | > simonpj at cam-05-unx:~/code/HEAD-2$ git submodule update git submodule > | > update simonpj at cam-05-unx:~/code/HEAD-2$ git status git status # On > | > branch arcpatch-D202 # Untracked files: > | > # (use "git add ..." to include in what will be committed) > | > # > | > # flat-skol-diff > | > # foo > | > # foo2 > | > # index.html.1 > | > # index.html.2 > | > # index.html.3 > | > # resume > | > # spj-patch > | > # spj-patch-save > | > # > | > testsuite/mk/ghcconfig_home_simonmar_fp_bin_x86_64-unknown- > | linux_ghc.mk # > | > testsuite/tests/simplCore/should_compile/T8538.hs > | > # testsuite/tests/simplCore/should_compile/T9073.hs > | > # tmp-patch > | > # untch-patch > | > nothing added to commit but untracked files present (use "git add" > | to > | > track) simonpj at cam-05-unx:~/code/HEAD-2$ > | > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Mon Dec 22 15:45:22 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 22 Dec 2014 16:45:22 +0100 Subject: The GHC 7.8.4 debian package now builds on arm In-Reply-To: <1419259124.23107.34.camel@joachim-breitner.de> References: <878uiuhpns.fsf@gmail.com> <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com> <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com> <1417384496.3101.21.camel@joachim-breitner.de> <87y4qsfdw1.fsf@gmail.com> <1417423368.1448.3.camel@joachim-breitner.de> <1417440483.2364.0.camel@joachim-breitner.de> <87h9xffd5v.fsf@gmail.com> <1417732622.11267.9.camel@joachim-breitner.de> <1417807503.3959.14.camel@joachim-breitner.de> <1417877940.1501.17.camel@joachim-breitner.de> <1417879142.1501.18.camel@joachim-breitner.de> <1417946830.13556.2.camel@joachim-breitner.de> <8761dmcm7t.fsf@gmail.com> <1418050147.1441.47.camel@joachim-breitner.de> <5485C51D.3000200@centrum.cz> <1418053481.1441.51.camel@joachim-breitner.de> <87vblmay8a.fsf@gmail.com> <1418119560.3339.29.camel@joachim-breitner.de> <1419259124.23107.34.camel@joachim-breitner.de> Message-ID: <1419263122.23107.35.camel@joachim-breitner.de> Hi, Am Montag, den 22.12.2014, 15:38 +0100 schrieb Joachim Breitner: > it seems the story is not over yet. For some reason, building > out-of-tree libraries (like mtl) does not build .so files on arm*: > > https://buildd.debian.org/status/fetch.php?pkg=haskell-mtl&arch=armhf&ver=2.1.3.1-1&stamp=1418087332 > > which later causes breakage: > [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.o ) > [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.p_o ) > https://buildd.debian.org/status/fetch.php?pkg=haskell-binary-shared&arch=armhf&ver=0.8.3-2&stamp=1419258130 > > Do you have any rough guesses what might be causing this? nevermind. I guess I built that with a previous upload of GHC that still had ghc on the NoSharedLibsPlatformList. A rebuild should fix that. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gergo at erdi.hu Mon Dec 22 15:44:43 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Mon, 22 Dec 2014 23:44:43 +0800 (SGT) Subject: Triggering a Harbourmaster build on a given commit In-Reply-To: References: Message-ID: Hi, Thanks for the detailed instructions -- it looks like something that should be on some wiki somewhere! However, I got stuck on step 4: it says I do not have permission to manage Harbormaster build plans and I need an adult^Wadministrator. How do I proceed? Thanks, Gergo On Mon, 22 Dec 2014, Austin Seipp wrote: > Unfortunately it's a bit hidden in the UI. I'll try to explain: > > 1) Go to https://phabricator.haskell.org/harbormaster > > 2) On the left side, click on 'Manage Build Plans' > > 3) Click on 'Plan 2 - GHC Continuous Integration', which builds commits > > 4) On the right-hand side, click 'Run Plan Manually' > > 5) In the box, enter the 'object name'. NOTE: the object name is > DIFFERENT than the raw commit SHA1. In Phabricator, a 'commit object' > is identified fully by the repository callsign plus the SHA1. In your > case, you want to test commit 20acaa7785. Therefore, the full object > name would be 'rGHC20acaa785', just like it appears in the URL you > posted. > > This should do the job. Hope that helps! > > On Sun, Dec 21, 2014 at 6:47 AM, Dr. ERDI Gergo wrote: >> Hi, >> >> Given a concrete commit on a non-master branch (e.g. >> https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1), >> how do I manually trigger a Harbourmaster build + validation? >> >> Thanks, >> Gergo >> >> -- >> >> .--= ULLA! =-----------------. >> \ http://gergo.erdi.hu \ >> `---= gergo at erdi.hu =-------' >> A man's best friend is his dogma. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' ?vakodj a klis?kt?l: tizenkett? bel?l?k egy tucat! From austin at well-typed.com Mon Dec 22 15:52:04 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 22 Dec 2014 09:52:04 -0600 Subject: Triggering a Harbourmaster build on a given commit In-Reply-To: References: Message-ID: Bah, this is some bunk permission error. I'll try to fix it shortly. In the mean time, I ran it for you: https://phabricator.haskell.org/B2742 On Mon, Dec 22, 2014 at 9:44 AM, Dr. ERDI Gergo wrote: > Hi, > > Thanks for the detailed instructions -- it looks like something that should > be on some wiki somewhere! > > However, I got stuck on step 4: it says I do not have permission to manage > Harbormaster build plans and I need an adult^Wadministrator. How do I > proceed? > > Thanks, > Gergo > > > On Mon, 22 Dec 2014, Austin Seipp wrote: > >> Unfortunately it's a bit hidden in the UI. I'll try to explain: >> >> 1) Go to https://phabricator.haskell.org/harbormaster >> >> 2) On the left side, click on 'Manage Build Plans' >> >> 3) Click on 'Plan 2 - GHC Continuous Integration', which builds commits >> >> 4) On the right-hand side, click 'Run Plan Manually' >> >> 5) In the box, enter the 'object name'. NOTE: the object name is >> DIFFERENT than the raw commit SHA1. In Phabricator, a 'commit object' >> is identified fully by the repository callsign plus the SHA1. In your >> case, you want to test commit 20acaa7785. Therefore, the full object >> name would be 'rGHC20acaa785', just like it appears in the URL you >> posted. >> >> This should do the job. Hope that helps! >> >> On Sun, Dec 21, 2014 at 6:47 AM, Dr. ERDI Gergo wrote: >>> >>> Hi, >>> >>> Given a concrete commit on a non-master branch (e.g. >>> >>> https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1), >>> how do I manually trigger a Harbourmaster build + validation? >>> >>> Thanks, >>> Gergo >>> >>> -- >>> >>> .--= ULLA! =-----------------. >>> \ http://gergo.erdi.hu \ >>> `---= gergo at erdi.hu =-------' >>> A man's best friend is his dogma. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> >> > > -- > > .--= ULLA! =-----------------. > \ http://gergo.erdi.hu \ > `---= gergo at erdi.hu =-------' > ?vakodj a klis?kt?l: tizenkett? bel?l?k egy tucat! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From jan.stolarek at p.lodz.pl Mon Dec 22 17:22:29 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 22 Dec 2014 18:22:29 +0100 Subject: Fatal: Reference is not a tree In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF56280F66@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: <201412221822.29971.jan.stolarek@p.lodz.pl> > Haddock is on Phabricator and has an .arcconfig file. All you need to > do is submit a revision like normally, just run 'arc diff' in the > Haddock directory. But this will create a separate revision for haddock, right? My changes in haddock are related to revision I am working on. What I would want to do is somehow have my haddock changes uploaded as part of the diff. > Also, since you have push access to the repository, you can always > just push your Haddock changes to a branch; for example, commit them > to 'wip/my-cool-thing' and push that branch publicly. Then point your > utils/haddock to that SHA1, and 'arc diff'. The rest should work just > fine when you run 'arc patch' or 'arc diff', or when Harbormaster > builds it. Ok, I suppose this will suffice. Janek From austin at well-typed.com Mon Dec 22 17:32:11 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 22 Dec 2014 11:32:11 -0600 Subject: Fatal: Reference is not a tree In-Reply-To: <201412221822.29971.jan.stolarek@p.lodz.pl> References: <618BE556AADD624C9C918AA5D5911BEF56280F25@DBXPRD3001MB024.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF56280F66@DBXPRD3001MB024.064d.mgd.msft.net> <201412221822.29971.jan.stolarek@p.lodz.pl> Message-ID: On Mon, Dec 22, 2014 at 11:22 AM, Jan Stolarek wrote: >> Haddock is on Phabricator and has an .arcconfig file. All you need to >> do is submit a revision like normally, just run 'arc diff' in the >> Haddock directory. > But this will create a separate revision for haddock, right? My changes in haddock are related to > revision I am working on. What I would want to do is somehow have my haddock changes uploaded as > part of the diff. This simply isn't possible when using submodules with any code review tool I know of, because submodules do not contain content, only *pointers* to content elsewhere in another repository. To accomplish what you want you we would instead need to use 'git subtree' instead of submodules, which essentially allows multiple git repositories to live under a unified umbrella. But that comes with some other problems (the least of which is that 'git subtree' is not an official Git tool; it is a 'contrib' tool). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From gergo at erdi.hu Mon Dec 22 23:23:47 2014 From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=) Date: Tue, 23 Dec 2014 07:23:47 +0800 Subject: Triggering a Harbourmaster build on a given commit In-Reply-To: References: Message-ID: Thanks! On Dec 22, 2014 11:53 PM, "Austin Seipp" wrote: > Bah, this is some bunk permission error. I'll try to fix it shortly. > In the mean time, I ran it for you: > > https://phabricator.haskell.org/B2742 > > On Mon, Dec 22, 2014 at 9:44 AM, Dr. ERDI Gergo wrote: > > Hi, > > > > Thanks for the detailed instructions -- it looks like something that > should > > be on some wiki somewhere! > > > > However, I got stuck on step 4: it says I do not have permission to > manage > > Harbormaster build plans and I need an adult^Wadministrator. How do I > > proceed? > > > > Thanks, > > Gergo > > > > > > On Mon, 22 Dec 2014, Austin Seipp wrote: > > > >> Unfortunately it's a bit hidden in the UI. I'll try to explain: > >> > >> 1) Go to https://phabricator.haskell.org/harbormaster > >> > >> 2) On the left side, click on 'Manage Build Plans' > >> > >> 3) Click on 'Plan 2 - GHC Continuous Integration', which builds commits > >> > >> 4) On the right-hand side, click 'Run Plan Manually' > >> > >> 5) In the box, enter the 'object name'. NOTE: the object name is > >> DIFFERENT than the raw commit SHA1. In Phabricator, a 'commit object' > >> is identified fully by the repository callsign plus the SHA1. In your > >> case, you want to test commit 20acaa7785. Therefore, the full object > >> name would be 'rGHC20acaa785', just like it appears in the URL you > >> posted. > >> > >> This should do the job. Hope that helps! > >> > >> On Sun, Dec 21, 2014 at 6:47 AM, Dr. ERDI Gergo wrote: > >>> > >>> Hi, > >>> > >>> Given a concrete commit on a non-master branch (e.g. > >>> > >>> > https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1 > ), > >>> how do I manually trigger a Harbourmaster build + validation? > >>> > >>> Thanks, > >>> Gergo > >>> > >>> -- > >>> > >>> .--= ULLA! =-----------------. > >>> \ http://gergo.erdi.hu \ > >>> `---= gergo at erdi.hu =-------' > >>> A man's best friend is his dogma. > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>> > >> > >> > >> > >> > > > > -- > > > > .--= ULLA! =-----------------. > > \ http://gergo.erdi.hu \ > > `---= gergo at erdi.hu =-------' > > ?vakodj a klis?kt?l: tizenkett? bel?l?k egy tucat! > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Dec 23 03:22:48 2014 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 22 Dec 2014 22:22:48 -0500 Subject: stg_init_finish Message-ID: <87oaqvgid3.fsf@gmail.com> Hi Simon, A few of us are puzzling over a cross-compilation bug, #9920. stg_init_finish appears to be loading a zero Sp from the saved thread state. None of us have been able to figure out how execution makes it to stg_init_finish. The only references to the symbol are its definition in StgStartup.cmm and a header declaration in MiscClosures.h. Could you perhaps shed some light on how execution is supposed to flow during RTS initialization? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From hvr at gnu.org Tue Dec 23 10:41:58 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 23 Dec 2014 11:41:58 +0100 Subject: GHC 7.10.1 / cabal-install 1.22 Ubuntu-PPA pre-RC snapshots available! Message-ID: <87a92ebqbt.fsf@gnu.org> To early adopters & multi-ghc-travis users, I've uploaded pre-RC snapshots for GHC 7.10.1 and cabal-install 1.22 to my GHC PPA[1], so you can start extending your .travis.yml files w/ CABALVER=1.22 GHCVER=7.10.1 There are no official RCs yet for GHC 7.10/cabal-install 1.22, these are merely snapshots from the respective Git branches which I'll keep updating regularly (every 1-3 days) till the final proper release for GHC 7.10.1 and cabal-install 1.22.0.0 occur, at which point those packages (`ghc-7.10-*` & `cabal-install-1.22`) will install the final release versions. The usual official release-candidates (including respective announcements) for GHC & cabal will follow soon. So please, help us finding issues/bugs with these pre-RC snapshots of GHC & cabal-install. Obviously, it's desirable to become aware of any serious issues ASAP, as opposed to shortly before the planned final release date... As these are Git snapshots, when reporting bugs/issues, please also provide the snapshot's Git commit id (which uniquely identifies the GHC source-tree state), which can be queried via a new GHC CLI option, e.g.: $ ghc --print-project-git-commit-id a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a Here's an example build using 7.10.1 to show those packages actually work: https://travis-ci.org/haskell/unix/builds/44919992 [1]: https://github.com/hvr/multi-ghc-travis https://launchpad.net/~hvr/+archive/ubuntu/ghc Cheers, hvr PS: If you happen to run into compile errors for Hackage packages which claim to work with GHC 7.10.1 (e.g. by allowing `base-4.8`), I'd be interested to hear about it. From alan.zimm at gmail.com Tue Dec 23 11:50:41 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Dec 2014 13:50:41 +0200 Subject: Phabricator builds with haddock changes fail Message-ID: It seems that phabricator is not picking up haddock commits for builds. I rebased my D538 diff, with matching haddock submodule Subproject commit 54c5e7cd0b5844712301cacc826a6b112dbc1090 However, the build fails with an error in haddock which is explictly patched in the haddock repo. Up until last week this process worked fine, and was recently recommended on this mailing list. Has something changed now that it is a RC? Failing build: https://phabricator.haskell.org/harbormaster/build/2762/ Changed line in haddock branch https://github.com/haskell/haddock/commit/54c5e7cd0b5844712301cacc826a6b112dbc1090#diff-d1a2c44392a66d2e7a0c9706a8ef6186R107 Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Dec 23 11:59:45 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Dec 2014 11:59:45 +0000 Subject: API Annotatons in a FunBind In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> If you do this ? Please make Match into a record (it ought to be already) ? Put a Note on the fun_id field, with an example like the one you give I?m not really sure if Haskell lets you mix infix and prefix notation for the same function definition, as you have done. The Report is silent on this question. I?m inclined to think ?no?. Currently a FunBind has a fun_infix field saying whether the definition uses infix notation. That is fine if ?no? above. If all are prefix or infix, do you still need the new field in Match? Would it matter only for operators where you want to know where to put the parens? Even in normal code, how are you distinguishing (+ ) from ( +) or whatever? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 15 December 2014 21:16 To: ghc-devs at haskell.org Subject: API Annotatons in a FunBind After individual FunBinds have been parsed, they are combined in getMonoBind. In the process, all the original FunBind fun_id's bar one are discarded, including its location. This causes a problem for source-to-source conversions of functions such as the following (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys Where there are compound RdrNames, and each has different spacing. I am proposing to add a (Maybe (Located id)) to the Match datatype to deal with this. data Match id body = Match Maybe (Located id) -- fun_id in subsequent function equations [LPat id] -- The patterns (Maybe (LHsType id)) -- A type signature for the result of the match -- Nothing after typechecking (GRHSs id body) Is this a problem? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Tue Dec 23 12:16:20 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Dec 2014 14:16:20 +0200 Subject: API Annotatons in a FunBind In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Tue, Dec 23, 2014 at 1:59 PM, Simon Peyton Jones wrote: > If you do this > > ? Please make Match into a record (it ought to be already) > Ok > ? Put a Note on the fun_id field, with an example like the one > you give > Ok > > > I?m not really sure if Haskell lets you mix infix and prefix notation for > the same function definition, as you have done. The Report is silent on > this question. I?m inclined to think ?no?. > > > Currently a FunBind has a fun_infix field saying whether the definition > uses infix notation. That is fine if ?no? above. > > > > If all are prefix or infix, do you still need the new field in Match? > Would it matter only for operators where you want to know where to put the > parens? Even in normal code, how are you distinguishing (+ ) from ( +) or > whatever? > The example I gave is an empirical test, it is currently accepted by GHC. The function as a whole is infix, it is just the alternate representation can be used for the individual Match definitions. There are straightforward rules as to whether a given fun_id needs parens or backquotes. The problem is that with source-to-source conversions the original must be reproduced exactly, and the code author has freedom to put arbitrary whitespace between the surrounding parens/backquotes and the actual identifier. Hence the original fun_id is needed as an anchor for the API annotations. Also, there is currently no location information for the fun_id for an infix definition, which can move around depending on the size of the left operand, and the choices made for whitespace. In earlier versions of HaRe we were forced to scan through the rich token stream for a match to pick up this information. Alan > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 15 December 2014 21:16 > *To:* ghc-devs at haskell.org > *Subject:* API Annotatons in a FunBind > > > > After individual FunBinds have been parsed, they are combined in > getMonoBind. > > In the process, all the original FunBind fun_id's bar one are discarded, > including its location. > > This causes a problem for source-to-source conversions of functions such > as the following > > (&&& ) [] [] = [] > xs &&& [] = xs > ( &&& ) [] ys = ys > > Where there are compound RdrNames, and each has different spacing. > > I am proposing to add a (Maybe (Located id)) to the Match datatype to deal > with this. > > > data Match id body > = Match > > Maybe (Located id) -- fun_id in subsequent function equations > > [LPat id] -- The patterns > (Maybe (LHsType id)) -- A type signature for the result of the > match > -- Nothing after typechecking > (GRHSs id body) > > Is this a problem? > > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Dec 23 13:12:39 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 23 Dec 2014 07:12:39 -0600 Subject: ANNOUNCE: GHC version 7.8.4 Message-ID: ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4. This is an important bugfix release relative to 7.8.3 (with over 30 defects fixed), so we highly recommend upgrading from the previous 7.8 releases. The full release notes are here: https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ On https://downloads.haskell.org/~ghc/7.8.4/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Tue Dec 23 13:25:47 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Dec 2014 13:25:47 +0000 Subject: API Annotatons in a FunBind In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF5628A024@DB3PRD3001MB020.064d.mgd.msft.net> Also, there is currently no location information for the fun_id for an infix definition, which can move around depending on the size of the left operand, and the choices made for whitespace. Good point. So is the field only needed for an equation in infix form? Can we get rid of fun_infix, and replace with a mabe_infix field in the Match, used only for (a) FunBind that is (b) infix? In ordinary expressions I still don?t understand how you distinguish map ( +) xs from map (+ ) xs Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 23 December 2014 12:16 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: API Annotatons in a FunBind On Tue, Dec 23, 2014 at 1:59 PM, Simon Peyton Jones > wrote: If you do this ? Please make Match into a record (it ought to be already) Ok ? Put a Note on the fun_id field, with an example like the one you give Ok I?m not really sure if Haskell lets you mix infix and prefix notation for the same function definition, as you have done. The Report is silent on this question. I?m inclined to think ?no?. Currently a FunBind has a fun_infix field saying whether the definition uses infix notation. That is fine if ?no? above. If all are prefix or infix, do you still need the new field in Match? Would it matter only for operators where you want to know where to put the parens? Even in normal code, how are you distinguishing (+ ) from ( +) or whatever? The example I gave is an empirical test, it is currently accepted by GHC. The function as a whole is infix, it is just the alternate representation can be used for the individual Match definitions. There are straightforward rules as to whether a given fun_id needs parens or backquotes. The problem is that with source-to-source conversions the original must be reproduced exactly, and the code author has freedom to put arbitrary whitespace between the surrounding parens/backquotes and the actual identifier. Hence the original fun_id is needed as an anchor for the API annotations. Also, there is currently no location information for the fun_id for an infix definition, which can move around depending on the size of the left operand, and the choices made for whitespace. In earlier versions of HaRe we were forced to scan through the rich token stream for a match to pick up this information. Alan Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 15 December 2014 21:16 To: ghc-devs at haskell.org Subject: API Annotatons in a FunBind After individual FunBinds have been parsed, they are combined in getMonoBind. In the process, all the original FunBind fun_id's bar one are discarded, including its location. This causes a problem for source-to-source conversions of functions such as the following (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys Where there are compound RdrNames, and each has different spacing. I am proposing to add a (Maybe (Located id)) to the Match datatype to deal with this. data Match id body = Match Maybe (Located id) -- fun_id in subsequent function equations [LPat id] -- The patterns (Maybe (LHsType id)) -- A type signature for the result of the match -- Nothing after typechecking (GRHSs id body) Is this a problem? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Tue Dec 23 13:49:01 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Dec 2014 15:49:01 +0200 Subject: API Annotatons in a FunBind In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF5628A024@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF5628A024@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I suspect it will be possible to move the fun_id and is_infix information directly into the Match, since it seems to be used via a MatchWrapper for a Match each time. Should I attempt this, and if so should it be in D538? I am really keen to get this into 7.10, so do not want to push big changes through it it means missing the boat. In terms of the variations of ( + ), the whole thing is parsed as a RdrName, and carries API annotations. For interest, I dug through Parser.y when making test cases for ghc-exactprint and identified the following cases which all produce a RdrName, and have corresponding API Annotations. | 'type' qcname {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2))) [mj AnnType $1,mj AnnVal $2] } | '(' qconsym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } | '(' consym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } | '`' conid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } | '`' varid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } | '`' qvarid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } | '(' ')' {% ams (sLL $1 $> $ getRdrName unitTyCon) [mo $1,mc $2] } | '(#' '#)' {% ams (sLL $1 $> $ getRdrName unboxedUnitTyCon) [mo $1,mc $2] } | '(' commas ')' {% ams (sLL $1 $> $ getRdrName (tupleTyCon BoxedTuple (snd $2 + 1))) (mo $1:mc $3:(mcommas (fst $2))) } | '(#' commas '#)' {% ams (sLL $1 $> $ getRdrName (tupleTyCon UnboxedTuple (snd $2 + 1))) (mo $1:mc $3:(mcommas (fst $2))) } | '(' '->' ')' {% ams (sLL $1 $> $ getRdrName funTyCon) [mo $1,mj AnnRarrow $2,mc $3] } | '[' ']' {% ams (sLL $1 $> $ listTyCon_RDR) [mo $1,mc $2] } | '[:' ':]' {% ams (sLL $1 $> $ parrTyCon_RDR) [mo $1,mc $2] } | '(' '~#' ')' {% ams (sLL $1 $> $ getRdrName eqPrimTyCon) [mo $1,mj AnnTildehsh $2,mc $3] } | '(' qtyconsym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } | '(' '~' ')' {% ams (sLL $1 $> $ eqTyCon_RDR) [mo $1,mj AnnTilde $2,mc $3] } tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } Alan On Tue, Dec 23, 2014 at 3:25 PM, Simon Peyton Jones wrote: > Also, there is currently no location information for the fun_id for an > infix definition, which can move around depending on the size of the left > operand, and the choices made for whitespace. > > > > Good point. So is the field only needed for an equation in infix form? > Can we get rid of fun_infix, and replace with a mabe_infix field in the > Match, used only for (a) FunBind that is (b) infix? > > > > In ordinary expressions I still don?t understand how you distinguish > > map ( +) xs > > from > > map (+ ) xs > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 23 December 2014 12:16 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: API Annotatons in a FunBind > > > > > > On Tue, Dec 23, 2014 at 1:59 PM, Simon Peyton Jones > wrote: > > If you do this > > ? Please make Match into a record (it ought to be already) > > Ok > > ? Put a Note on the fun_id field, with an example like the one > you give > > Ok > > > > I?m not really sure if Haskell lets you mix infix and prefix notation for > the same function definition, as you have done. The Report is silent on > this question. I?m inclined to think ?no?. > > > > Currently a FunBind has a fun_infix field saying whether the definition > uses infix notation. That is fine if ?no? above. > > > > If all are prefix or infix, do you still need the new field in Match? > Would it matter only for operators where you want to know where to put the > parens? Even in normal code, how are you distinguishing (+ ) from ( +) or > whatever? > > > > > > The example I gave is an empirical test, it is currently accepted by GHC. > The function as a whole is infix, it is just the alternate representation > can be used for the individual Match definitions. > > There are straightforward rules as to whether a given fun_id needs parens > or backquotes. The problem is that with source-to-source conversions the > original must be reproduced exactly, and the code author has freedom to put > arbitrary whitespace between the surrounding parens/backquotes and the > actual identifier. Hence the original fun_id is needed as an anchor for > the API annotations. > > Also, there is currently no location information for the fun_id for an > infix definition, which can move around depending on the size of the left > operand, and the choices made for whitespace. > > > > In earlier versions of HaRe we were forced to scan through the rich token > stream for a match to pick up this information. > > Alan > > > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 15 December 2014 21:16 > *To:* ghc-devs at haskell.org > *Subject:* API Annotatons in a FunBind > > > > After individual FunBinds have been parsed, they are combined in > getMonoBind. > > In the process, all the original FunBind fun_id's bar one are discarded, > including its location. > > This causes a problem for source-to-source conversions of functions such > as the following > > (&&& ) [] [] = [] > xs &&& [] = xs > ( &&& ) [] ys = ys > > Where there are compound RdrNames, and each has different spacing. > > I am proposing to add a (Maybe (Located id)) to the Match datatype to deal > with this. > > > data Match id body > = Match > > Maybe (Located id) -- fun_id in subsequent function equations > > [LPat id] -- The patterns > (Maybe (LHsType id)) -- A type signature for the result of the > match > -- Nothing after typechecking > (GRHSs id body) > > Is this a problem? > > Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Dec 23 14:36:16 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 23 Dec 2014 08:36:16 -0600 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 Message-ID: We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. We expect another RC to occur during January of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Tue Dec 23 14:38:27 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Dec 2014 14:38:27 +0000 Subject: API Annotatons in a FunBind In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF5628A024@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF5628A1AA@DB3PRD3001MB020.064d.mgd.msft.net> As you?ll see 7.10 RC1 is out. The 7.10 boat has been advertised as sailing for weeks now. Of course everyone very reasonably wants their thing in, but if we keep agreeing, 7.10 will never appear. If you are absolutely desperate to have something in that isn?t in yet, please say so in the most specific and concrete terms possible. (I assume this Match stuff is not in the desperate category.) Anything big, pervasive, or destabilising is unlikely to get in for the reasons above. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 23 December 2014 13:49 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: API Annotatons in a FunBind I suspect it will be possible to move the fun_id and is_infix information directly into the Match, since it seems to be used via a MatchWrapper for a Match each time. Should I attempt this, and if so should it be in D538? I am really keen to get this into 7.10, so do not want to push big changes through it it means missing the boat. In terms of the variations of ( + ), the whole thing is parsed as a RdrName, and carries API annotations. For interest, I dug through Parser.y when making test cases for ghc-exactprint and identified the following cases which all produce a RdrName, and have corresponding API Annotations. | 'type' qcname {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2))) [mj AnnType $1,mj AnnVal $2] } | '(' qconsym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } | '(' consym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } | '`' conid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } | '`' varid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } | '`' qvarid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } | '(' ')' {% ams (sLL $1 $> $ getRdrName unitTyCon) [mo $1,mc $2] } | '(#' '#)' {% ams (sLL $1 $> $ getRdrName unboxedUnitTyCon) [mo $1,mc $2] } | '(' commas ')' {% ams (sLL $1 $> $ getRdrName (tupleTyCon BoxedTuple (snd $2 + 1))) (mo $1:mc $3:(mcommas (fst $2))) } | '(#' commas '#)' {% ams (sLL $1 $> $ getRdrName (tupleTyCon UnboxedTuple (snd $2 + 1))) (mo $1:mc $3:(mcommas (fst $2))) } | '(' '->' ')' {% ams (sLL $1 $> $ getRdrName funTyCon) [mo $1,mj AnnRarrow $2,mc $3] } | '[' ']' {% ams (sLL $1 $> $ listTyCon_RDR) [mo $1,mc $2] } | '[:' ':]' {% ams (sLL $1 $> $ parrTyCon_RDR) [mo $1,mc $2] } | '(' '~#' ')' {% ams (sLL $1 $> $ getRdrName eqPrimTyCon) [mo $1,mj AnnTildehsh $2,mc $3] } | '(' qtyconsym ')' {% ams (sLL $1 $> (unLoc $2)) [mo $1,mj AnnVal $2,mc $3] } | '(' '~' ')' {% ams (sLL $1 $> $ eqTyCon_RDR) [mo $1,mj AnnTilde $2,mc $3] } tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2)) [mj AnnBackquote $1,mj AnnVal $2 ,mj AnnBackquote $3] } Alan On Tue, Dec 23, 2014 at 3:25 PM, Simon Peyton Jones > wrote: Also, there is currently no location information for the fun_id for an infix definition, which can move around depending on the size of the left operand, and the choices made for whitespace. Good point. So is the field only needed for an equation in infix form? Can we get rid of fun_infix, and replace with a mabe_infix field in the Match, used only for (a) FunBind that is (b) infix? In ordinary expressions I still don?t understand how you distinguish map ( +) xs from map (+ ) xs Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 23 December 2014 12:16 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: API Annotatons in a FunBind On Tue, Dec 23, 2014 at 1:59 PM, Simon Peyton Jones > wrote: If you do this ? Please make Match into a record (it ought to be already) Ok ? Put a Note on the fun_id field, with an example like the one you give Ok I?m not really sure if Haskell lets you mix infix and prefix notation for the same function definition, as you have done. The Report is silent on this question. I?m inclined to think ?no?. Currently a FunBind has a fun_infix field saying whether the definition uses infix notation. That is fine if ?no? above. If all are prefix or infix, do you still need the new field in Match? Would it matter only for operators where you want to know where to put the parens? Even in normal code, how are you distinguishing (+ ) from ( +) or whatever? The example I gave is an empirical test, it is currently accepted by GHC. The function as a whole is infix, it is just the alternate representation can be used for the individual Match definitions. There are straightforward rules as to whether a given fun_id needs parens or backquotes. The problem is that with source-to-source conversions the original must be reproduced exactly, and the code author has freedom to put arbitrary whitespace between the surrounding parens/backquotes and the actual identifier. Hence the original fun_id is needed as an anchor for the API annotations. Also, there is currently no location information for the fun_id for an infix definition, which can move around depending on the size of the left operand, and the choices made for whitespace. In earlier versions of HaRe we were forced to scan through the rich token stream for a match to pick up this information. Alan Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 15 December 2014 21:16 To: ghc-devs at haskell.org Subject: API Annotatons in a FunBind After individual FunBinds have been parsed, they are combined in getMonoBind. In the process, all the original FunBind fun_id's bar one are discarded, including its location. This causes a problem for source-to-source conversions of functions such as the following (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys Where there are compound RdrNames, and each has different spacing. I am proposing to add a (Maybe (Located id)) to the Match datatype to deal with this. data Match id body = Match Maybe (Located id) -- fun_id in subsequent function equations [LPat id] -- The patterns (Maybe (LHsType id)) -- A type signature for the result of the match -- Nothing after typechecking (GRHSs id body) Is this a problem? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Dec 23 14:39:26 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 23 Dec 2014 08:39:26 -0600 Subject: HEADS UP: Tickets have been triaged a bit Message-ID: Hi *, As many of you will probably notice, I have bulk modified a lot of Trac tickets and moved their milestone out. You might be wondering why; the reasoning is that since 7.10.1 RC1 is out (see other email), we need to start prioritizing what gets done. So, I moved all tickets that were a) set to 7.10.1 milestone, b) not closed, and c) had below 'high priority', to the 7.12.1 milestone. There are some tickets in 'normal' that probably should be moved back. If you're CC'd on a ticket and think it should be fixed for 7.10.1, please: - Set the milestone back to 7.10.1 - And if you can, take ownership! GHC HQ will probably only have time to organize efforts to take on the most high priority tickets - so any help you can offer is always appreciated. You can see the current list of tickets here. We'll put notes on the page at the top as time goes on to keep people up to date. https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From alan.zimm at gmail.com Tue Dec 23 14:50:22 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Dec 2014 16:50:22 +0200 Subject: API Annotatons in a FunBind In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF5628A1AA@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF56288EB5@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF5628A024@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF5628A1AA@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: The stuff I am desperate about is in D538. The diff came about through implementing the functionality to actually use the API annotations, and it showed up a number of shortcomings, each of which was trivial to fix and does not have an impact on the rest. The biggest of these is adding the fun_id,is_infix to the Match, which can safely be ignored by anything except API annotations. Effectively, without D538 the API annotations will not be usable in GHC 7.10 I do not believe it is any of big, pervasive, or destabilising. The largest part of the diff is in fact adding detailed haddock documentation. The various elements in this change are: ------------------------------------ HsTyLit now has SourceText Update documentation of HsSyn to reflect which annotations are attached to which element. Ensure that the parser always keeps HsSCC and HsTickPragma values, to be ignored in the desugar phase if not needed Bringing in SourceText for pragmas Add Location in NPlusKPat Add Location in FunDep Make RecCon payload Located Explicitly add AnnVal to RdrName where it is compound Add Location in IPBind Add Location to name in IEThingAbs Add Maybe (Located id,Bool) to Match to track fun_id,infix. This includes converting Match into a record and adding a note about why the fun_id needs to be replicated in the Match. Add Location in KindedTyVar Sort out semi-colons for parsing - import statements - stmts - decls - decls_cls - decls_inst -------------------------------------- So it is basically adding Located wrappers, SourceText fields, documentation, and the extra stuff in Match. Alan On Tue, Dec 23, 2014 at 4:38 PM, Simon Peyton Jones wrote: > As you?ll see 7.10 RC1 is out. The 7.10 boat has been advertised as > sailing for weeks now. Of course everyone very reasonably wants their > thing in, but if we keep agreeing, 7.10 will never appear. > > > > If you are *absolutely desperate* to have something in that isn?t in yet, > please say so in the most specific and concrete terms possible. (I assume > this Match stuff is not in the desperate category.) > > > > Anything big, pervasive, or destabilising is unlikely to get in for the > reasons above. > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 23 December 2014 13:49 > > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: API Annotatons in a FunBind > > > > I suspect it will be possible to move the fun_id and is_infix information > directly into the Match, since it seems to be used via a MatchWrapper for a > Match each time. > > Should I attempt this, and if so should it be in D538? I am really keen to > get this into 7.10, so do not want to push big changes through it it means > missing the boat. > > > > In terms of the variations of ( + ), the whole thing is parsed as a > RdrName, and carries API annotations. > > For interest, I dug through Parser.y when making test cases for > ghc-exactprint and identified the following cases which all produce a > RdrName, and have corresponding API Annotations. > > | 'type' qcname {% amms (mkTypeImpExp (sLL $1 $> > (unLoc $2))) > [mj AnnType $1,mj AnnVal $2] } > > | '(' qconsym ')' {% ams (sLL $1 $> (unLoc $2)) > [mo $1,mj AnnVal $2,mc $3] } > > | '(' consym ')' {% ams (sLL $1 $> (unLoc $2)) > [mo $1,mj AnnVal $2,mc $3] } > > | '`' conid '`' {% ams (sLL $1 $> (unLoc $2)) > [mj AnnBackquote $1,mj AnnVal $2 > ,mj AnnBackquote $3] } > > | '`' varid '`' {% ams (sLL $1 $> (unLoc $2)) > [mj AnnBackquote $1,mj AnnVal $2 > ,mj AnnBackquote $3] } > | '`' qvarid '`' {% ams (sLL $1 $> (unLoc $2)) > [mj AnnBackquote $1,mj AnnVal $2 > ,mj AnnBackquote $3] } > > | '(' ')' {% ams (sLL $1 $> $ getRdrName > unitTyCon) > [mo $1,mc $2] } > | '(#' '#)' {% ams (sLL $1 $> $ getRdrName > unboxedUnitTyCon) > [mo $1,mc $2] } > > > | '(' commas ')' {% ams (sLL $1 $> $ getRdrName (tupleTyCon > BoxedTuple > (snd $2 + 1))) > (mo $1:mc $3:(mcommas (fst $2))) } > | '(#' commas '#)' {% ams (sLL $1 $> $ getRdrName (tupleTyCon > UnboxedTuple > (snd $2 + 1))) > (mo $1:mc $3:(mcommas (fst $2))) } > | '(' '->' ')' {% ams (sLL $1 $> $ getRdrName funTyCon) > [mo $1,mj AnnRarrow $2,mc $3] } > | '[' ']' {% ams (sLL $1 $> $ listTyCon_RDR) [mo > $1,mc $2] } > | '[:' ':]' {% ams (sLL $1 $> $ parrTyCon_RDR) [mo > $1,mc $2] } > | '(' '~#' ')' {% ams (sLL $1 $> $ getRdrName eqPrimTyCon) > [mo $1,mj AnnTildehsh $2,mc $3] } > > | '(' qtyconsym ')' {% ams (sLL $1 $> (unLoc $2)) > [mo $1,mj AnnVal $2,mc $3] } > | '(' '~' ')' {% ams (sLL $1 $> $ eqTyCon_RDR) > [mo $1,mj AnnTilde $2,mc > $3] } > > tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2)) > [mj AnnBackquote $1,mj AnnVal $2 > ,mj AnnBackquote $3] } > > Alan > > > > On Tue, Dec 23, 2014 at 3:25 PM, Simon Peyton Jones > wrote: > > Also, there is currently no location information for the fun_id for an > infix definition, which can move around depending on the size of the left > operand, and the choices made for whitespace. > > > > Good point. So is the field only needed for an equation in infix form? > Can we get rid of fun_infix, and replace with a mabe_infix field in the > Match, used only for (a) FunBind that is (b) infix? > > > > In ordinary expressions I still don?t understand how you distinguish > > map ( +) xs > > from > > map (+ ) xs > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 23 December 2014 12:16 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: API Annotatons in a FunBind > > > > > > On Tue, Dec 23, 2014 at 1:59 PM, Simon Peyton Jones > wrote: > > If you do this > > ? Please make Match into a record (it ought to be already) > > Ok > > ? Put a Note on the fun_id field, with an example like the one > you give > > Ok > > > > I?m not really sure if Haskell lets you mix infix and prefix notation for > the same function definition, as you have done. The Report is silent on > this question. I?m inclined to think ?no?. > > > > Currently a FunBind has a fun_infix field saying whether the definition > uses infix notation. That is fine if ?no? above. > > > > If all are prefix or infix, do you still need the new field in Match? > Would it matter only for operators where you want to know where to put the > parens? Even in normal code, how are you distinguishing (+ ) from ( +) or > whatever? > > > > > > The example I gave is an empirical test, it is currently accepted by GHC. > The function as a whole is infix, it is just the alternate representation > can be used for the individual Match definitions. > > There are straightforward rules as to whether a given fun_id needs parens > or backquotes. The problem is that with source-to-source conversions the > original must be reproduced exactly, and the code author has freedom to put > arbitrary whitespace between the surrounding parens/backquotes and the > actual identifier. Hence the original fun_id is needed as an anchor for > the API annotations. > > Also, there is currently no location information for the fun_id for an > infix definition, which can move around depending on the size of the left > operand, and the choices made for whitespace. > > > > In earlier versions of HaRe we were forced to scan through the rich token > stream for a match to pick up this information. > > Alan > > > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 15 December 2014 21:16 > *To:* ghc-devs at haskell.org > *Subject:* API Annotatons in a FunBind > > > > After individual FunBinds have been parsed, they are combined in > getMonoBind. > > In the process, all the original FunBind fun_id's bar one are discarded, > including its location. > > This causes a problem for source-to-source conversions of functions such > as the following > > (&&& ) [] [] = [] > xs &&& [] = xs > ( &&& ) [] ys = ys > > Where there are compound RdrNames, and each has different spacing. > > I am proposing to add a (Maybe (Located id)) to the Match datatype to deal > with this. > > > data Match id body > = Match > > Maybe (Located id) -- fun_id in subsequent function equations > > [LPat id] -- The patterns > (Maybe (LHsType id)) -- A type signature for the result of the > match > -- Nothing after typechecking > (GRHSs id body) > > Is this a problem? > > Alan > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Dec 23 17:47:24 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 23 Dec 2014 12:47:24 -0500 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: Heres a OS X build that should work with >= 10.7 http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 and the sha 512 shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd ghc-7.8.4-x86_64-apple-darwin.tar.bz2 On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 > ============================================================== > > The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4. > > This is an important bugfix release relative to 7.8.3 (with over 30 > defects fixed), so we highly recommend upgrading from the previous 7.8 > releases. > > The full release notes are here: > > > https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://ghc.haskell.org/trac/ghc/wiki/Platforms > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > > > Hashes & Signatures > ~~~~~~~~~~~~~~~~~ > > On https://downloads.haskell.org/~ghc/7.8.4/ you will find a signed > copy of the SHA256 hashes for the tarballs, using my GPG key (keyid > 0x3B58D86F). > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Dec 24 02:12:00 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 24 Dec 2014 11:12:00 +0900 (JST) Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: References: Message-ID: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> Hi, If I understand correctly, OverloadedRecordFields has not been merged yet. Are there any chances to merge it into GHC 7.10.1? --Kazu > We are pleased to announce the first release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc1/ > > This includes the source tarball and bindists for 64bit/32bit Linux > and Windows. Binary builds for other platforms will be available > shortly. (CentOS 6.5 binaries are not available at this time like they > were for 7.8.x). These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 release sometime in February of 2015. We > expect another RC to occur during January of 2015. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From greg at gregweber.info Wed Dec 24 03:35:35 2014 From: greg at gregweber.info (Greg Weber) Date: Tue, 23 Dec 2014 19:35:35 -0800 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> References: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> Message-ID: No, it is a big change and the merge window is closed now. This question was just asked on reddit: http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/ On Tue, Dec 23, 2014 at 6:12 PM, Kazu Yamamoto wrote: > Hi, > > If I understand correctly, OverloadedRecordFields has not been merged > yet. Are there any chances to merge it into GHC 7.10.1? > > --Kazu > > > We are pleased to announce the first release candidate for GHC 7.10.1: > > > > https://downloads.haskell.org/~ghc/7.10.1-rc1/ > > > > This includes the source tarball and bindists for 64bit/32bit Linux > > and Windows. Binary builds for other platforms will be available > > shortly. (CentOS 6.5 binaries are not available at this time like they > > were for 7.8.x). These binaries and tarballs have an accompanying > > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > > > We plan to make the 7.10.1 release sometime in February of 2015. We > > expect another RC to occur during January of 2015. > > > > Please test as much as possible; bugs are much cheaper if we find them > > before the release! > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Dec 24 04:32:20 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 24 Dec 2014 13:32:20 +0900 (JST) Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: References: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> Message-ID: <20141224.133220.1032171133533014509.kazu@iij.ad.jp> > No, it is a big change and the merge window is closed now. This question > was just asked on reddit: > http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/ Greg, thank you for this info. But it is really disappointing. I was silent about this because it is promised that ORF is included in GHC 7.10. If I knew that active feedback was necessary, I could be vocal. --Kazu From dct25-561bs at mythic-beasts.com Wed Dec 24 12:42:37 2014 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Wed, 24 Dec 2014 12:42:37 +0000 Subject: Linker problem with HPC and TemplateHaskell In-Reply-To: References: <1419024711-sup-33@sabre> Message-ID: Turns out this was already a known issue: https://ghc.haskell.org/trac/ghc/ticket/9762 and a fix is now on the way for 7.10.1. In the meantime, adding -fomit-interface-pragmas works for me. Thanks, David On 19 December 2014 at 21:58, David Turner wrote: > Ok, I've opened https://ghc.haskell.org/trac/ghc/ticket/9909 > > I won't be able to repro on HEAD in the near future, I'm afraid. > > Many thanks, > > On 19 December 2014 at 21:32, Edward Z. Yang wrote: >> Sounds like a bug. File a ticket? If you can see if you can >> repro on GHC HEAD that would also be helpful. >> >> Edward >> >> Excerpts from David Turner's message of 2014-12-19 16:24:25 -0500: >>> Hi, >>> >>> I'm getting the following error message when compiling a Yesod >>> application (which uses Template Haskell rather a lot) with -fhpc: >>> >>> /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against >>> undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when >>> making a shared object; recompile with -fPIC >>> >>> Steps to reproduce: >>> >>> 1. Run 'yesod init' to make a new scaffold. Call it 'testsite' and >>> select 'simple' for no database. >>> 2. Run: >>> >>> cd testsite >>> sed Settings.hs -i -e 's/staticRoot conf.*/staticRoot conf = "foo"/' # >>> GHC doesn't like this line >>> ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings >>> -XMultiParamTypeClasses -XTypeFamilies -fhpc -O1 >>> >>> Running the ghc line again completes successfully. >>> >>> It seems that there is a missing ./Settings.dyn_o in the gcc command >>> line that ghc calls, the first time through. It's there the second >>> time so the link succeeds. No idea what that might mean. >>> >>> It's not a problem at -O0. >>> >>> I'm using 7.8.3 so this might be fixed now. >>> >>> Not sure what else might help! Any advice gratefully received. >>> >>> Cheers, >>> >>> David From lonetiger at gmail.com Wed Dec 24 13:24:52 2014 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 24 Dec 2014 13:24:52 +0000 Subject: =?utf-8?Q?Re:_ANNOUNCE:_GHC_7.10.1_Release_Candidate_1?= In-Reply-To: References: Message-ID: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com> Hi, I?ve had some issues building this (and the git HEAD), it seems that the config.guess and config.sub in the libffi tarball is old, it doesn?t detect the platform when building with msys2. I had to unpack the tarfile and update the files, after this it correctly built. Then I proceeded to try to make a shared library and got the following warning: ManualCheck.hs:18:1: Warning: the 'stdcall' calling convention is unsupported on this platform, treating as ccall When checking declaration: foreign export stdcall "testFoo" testFooA :: CInt -> IO (FooPtr) Does this mean that GHC no longer supports stdcall on windows? or could this be related to issue I had building? Regards, Tamar From: Austin Seipp Sent: ?Tuesday?, ?December? ?23?, ?2014 ?15?:?36 To: ghc-devs at haskell.org, glasgow-haskell-users at haskell.org We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. We expect another RC to occur during January of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Wed Dec 24 14:15:27 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Wed, 24 Dec 2014 14:15:27 +0000 (UTC) Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 References: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> <20141224.133220.1032171133533014509.kazu@iij.ad.jp> Message-ID: Kazu Yamamoto iij.ad.jp> writes: > > > No, it is a big change and the merge window is closed now. This question > > was just asked on reddit: > > http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/ > > Greg, thank you for this info. But it is really disappointing. > > I was silent about this because it is promised that ORF is included in > GHC 7.10. If I knew that active feedback was necessary, I could be > vocal. > > --Kazu > Hi Kazu, You are not the only one that is disappointed. Records have long been a wart in Haskell (and by long I mean 25+ years). Perhaps the readers of this list could read the reddit comments and propose a way forward? Dominic. From alfredo.dinapoli at gmail.com Wed Dec 24 15:52:52 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Wed, 24 Dec 2014 16:52:52 +0100 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: Thanks Carter! I have just asked basically about it on Reddit, in the announce thread. I'll give it a spin, and if it works I will share the link (if you are ok with that!) on the same Reddit post. Alfredo On Tuesday, 23 December 2014, Carter Schonwald wrote: > Heres a OS X build that should work with >= 10.7 > http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > > and the sha 512 > shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp wrote: > > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 > ============================================================== > > The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4. > > This is an important bugfix release relative to 7.8.3 (with over 30 > defects fixed), so we highly recommend upgrading from the previous 7.8 > releases. > > The full release notes are here: > > https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://ghc.haskell.org/trac/ghc/wiki/Platforms > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bu -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Dec 24 15:57:06 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 24 Dec 2014 10:57:06 -0500 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: sure, please verify first. (also make sure haddock etc works for you, i had to remove a haddock binary from ~/.cabal/bin before haddocks were building correctly for me) On Wed, Dec 24, 2014 at 10:52 AM, Alfredo Di Napoli < alfredo.dinapoli at gmail.com> wrote: > Thanks Carter! > > I have just asked basically about it on Reddit, in the announce thread. > I'll give it a spin, and if it works I will share the link (if you are ok > with that!) on the > same Reddit post. > > Alfredo > > > On Tuesday, 23 December 2014, Carter Schonwald > wrote: > > Heres a OS X build that should work with >= 10.7 > > > http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > > > > and the sha 512 > > shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > > > c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd > ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > > On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp > wrote: > > > > ============================================================== > > The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 > > ============================================================== > > > > The GHC Team is pleased to announce a new patchlevel release of GHC, > 7.8.4. > > > > This is an important bugfix release relative to 7.8.3 (with over 30 > > defects fixed), so we highly recommend upgrading from the previous 7.8 > > releases. > > > > The full release notes are here: > > > > > https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html > > > > How to get it > > ~~~~~~~~~~~~~ > > > > The easy way is to go to the web page, which should be self-explanatory: > > > > https://www.haskell.org/ghc/ > > > > We supply binary builds in the native package format for many > > platforms, and the source distribution is available from the same > > place. > > > > Packages will appear as they are built - if the package for your > > system isn't available yet, please try again later. > > > > > > Background > > ~~~~~~~~~~ > > > > Haskell is a standard lazy functional programming language. > > > > GHC is a state-of-the-art programming suite for Haskell. Included is > > an optimising compiler generating good code for a variety of > > platforms, together with an interactive system for convenient, quick > > development. The distribution includes space and time profiling > > facilities, a large collection of libraries, and support for various > > language extensions, including concurrency, exceptions, and foreign > > language interfaces (C, whatever). GHC is distributed under a > > BSD-style open source license. > > > > A wide variety of Haskell related resources (tutorials, libraries, > > specifications, documentation, compilers, interpreters, references, > > contact information, links to research groups) are available from the > > Haskell home page (see below). > > > > > > On-line GHC-related resources > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Relevant URLs on the World-Wide Web: > > > > GHC home page http://www.haskell.org/ghc/ > > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > > Haskell home page http://www.haskell.org/ > > > > > > Supported Platforms > > ~~~~~~~~~~~~~~~~~~~ > > > > The list of platforms we support, and the people responsible for them, > > is here: > > > > http://ghc.haskell.org/trac/ghc/wiki/Platforms > > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > > > > Ports to other platforms are possible with varying degrees of > > difficulty. The Building Guide describes how to go about porting to a > > new platform: > > > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > > > > Developers > > ~~~~~~~~~~ > > > > We welcome new contributors. Instructions on accessing our source > > code repository, and getting started with hacking on GHC, are > > available from the GHC's developer's site run by Trac: > > > > http://ghc.haskell.org/trac/ghc/ > > > > > > Mailing lists > > ~~~~~~~~~~~~~ > > > > We run mailing lists for GHC users and bug reports; to subscribe, use > > the web interfaces at > > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > > There are several other haskell and ghc-related mailing lists on > > www.haskell.org; for the full list, see > > > > http://www.haskell.org/mailman/listinfo/ > > > > Some GHC developers hang out on #haskell on IRC, too: > > > > http://www.haskell.org/haskellwiki/IRC_channel > > > > Please report bu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.dinapoli at gmail.com Wed Dec 24 16:40:55 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Wed, 24 Dec 2014 17:40:55 +0100 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: The installation succeedeed and GHC is working correctly. But yes, "cabal haddock" seems to have some difficulty in the new version, but I can't judge if it's my sandboxed environment (we use "hub" at work) or the failure you mentioned. Calling "haddock" alone works (using the previously installed on my system), "cabal haddock" does not: ? mandrill [master] ? haddock src/Network/API/Mandrill.hs Haddock coverage: Warning: main:Network.API.Mandrill: Could not find documentation for exported module: M Warning: Couldn't find .haddock for export Control.Monad.IO.Class.liftIO 88% ( 7 / 8) in 'Network.API.Mandrill' Warning: Network.API.Mandrill: could not find link destinations for: Control.Monad.IO.Class.MonadIO Network.API.Mandrill.Types.MandrillMessage Network.API.Mandrill.Trans.MandrillT Network.API.Mandrill.Types.MandrillResponse Network.API.Mandrill.Messages.Types.MessagesResponse Text.Email.Parser.EmailAddress Data.Text.Internal.Text Text.Blaze.Html.Html GHC.Types.IO ? mandrill [master] ? cabal haddock cabal-1.20.0.0: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.20.0.0). cabal haddock: /usr/hs/tools/cabal-1.20.0.0 failure (return code=1) On Wednesday, 24 December 2014, Carter Schonwald wrote: > sure, please verify first. (also make sure haddock etc works for you, i had to remove a haddock binary from ~/.cabal/bin before haddocks were building correctly for me) > On Wed, Dec 24, 2014 at 10:52 AM, Alfredo Di Napoli < alfredo.dinapoli at gmail.com> wrote: > > Thanks Carter! > > I have just asked basically about it on Reddit, in the announce thread. > I'll give it a spin, and if it works I will share the link (if you are ok with that!) on the > same Reddit post. > > Alfredo > > On Tuesday, 23 December 2014, Carter Schonwald wrote: >> Heres a OS X build that should work with >= 10.7 >> http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >> >> and the sha 512 >> shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >> c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >> On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp wrote: >> >> ============================================================== >> The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 >> ============================================================== >> >> The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4. >> >> This is an important bugfix release relative to 7.8.3 (with over 30 >> defects fixed), so we highly recommend upgrading from the previous 7.8 >> releases. >> >> The full release notes are here: >> >> https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html >> >> How to get it >> ~~~~~~~~~~~~~ >> >> The easy way is to go to the web page, which should be self-explanatory: >> >> https://www.haskell.org/ghc/ >> >> We supply binary builds in the native package format for many >> platforms, and the source distribution is available from the same >> place. >> >> Packages will appear as they are built - if the package for your >> system isn't available yet, please try again later. >> >> >> Background >> ~~~~~~~~~~ >> >> Haskell is a standard lazy functional programming language. >> >> GHC is a state-of-the-art programming suite for Haskell. Included is >> an optimising compiler generating good code for a variety of >> platforms, together with an interactive system for convenient, quick >> development. The distribution includes space and time profiling >> facilities, a large collection of libraries, and support for various >> language extensions, including concurrency, exceptions, and foreign >> language interfaces (C, whatever). GHC is distributed under a >> BSD-style open source license. >> >> A wide variety of Haskell related resources (tutorials, libraries, >> specifications, documentation, compilers, interpreters, references, >> contact information, links to research groups) are available from the >> Haskell home page (see below). >> >> >> On-line GHC-related resources >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Relevant URLs on the World-Wide Web: >> >> GHC home page http://www.haskell.org/ghc/ >> GHC developers' home page http://ghc.haskell.org/trac/ghc/ >> Haskell home page http://www.haskell.org/ >> >> >> Supported Platforms >> ~~~~~~~~~~~~~~~~~~~ >> >> The list of platforms we support, and the people responsible for them, >> is here: >> >> http://ghc.haskell.org/trac/ghc/wiki/Platforms >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners >> >> Ports to other platforms are possible with varying degrees of >> difficulty. The Building Guide describes how -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Dec 24 17:56:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 24 Dec 2014 12:56:37 -0500 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: try rm ~/.cabal/bin/haddock and then type which haddock and you should be getting the /usr/local/bin/haddock or whatever, then stuff should work fine On Wed, Dec 24, 2014 at 11:40 AM, Alfredo Di Napoli < alfredo.dinapoli at gmail.com> wrote: > The installation succeedeed and GHC is working correctly. > But yes, "cabal haddock" seems to have some difficulty in the new version, > but I can't judge if it's my sandboxed environment (we use "hub" at work) > or the failure you mentioned. > > Calling "haddock" alone works (using the previously installed on my > system), "cabal haddock" does not: > > ? mandrill [master] ? haddock src/Network/API/Mandrill.hs > Haddock coverage: > Warning: main:Network.API.Mandrill: Could not find documentation for > exported module: M > Warning: Couldn't find .haddock for export Control.Monad.IO.Class.liftIO > 88% ( 7 / 8) in 'Network.API.Mandrill' > Warning: Network.API.Mandrill: could not find link destinations for: > Control.Monad.IO.Class.MonadIO > Network.API.Mandrill.Types.MandrillMessage > Network.API.Mandrill.Trans.MandrillT > Network.API.Mandrill.Types.MandrillResponse > Network.API.Mandrill.Messages.Types.MessagesResponse > Text.Email.Parser.EmailAddress Data.Text.Internal.Text Text.Blaze.Html.Html > GHC.Types.IO > > ? mandrill [master] ? cabal haddock > cabal-1.20.0.0: You need to re-run the 'configure' command. The version of > Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.20.0.0). > cabal haddock: /usr/hs/tools/cabal-1.20.0.0 failure (return code=1) > > > On Wednesday, 24 December 2014, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > > sure, please verify first. (also make sure haddock etc works for you, i > had to remove a haddock binary from ~/.cabal/bin before haddocks were > building correctly for me) > > On Wed, Dec 24, 2014 at 10:52 AM, Alfredo Di Napoli < > alfredo.dinapoli at gmail.com> wrote: > > > > Thanks Carter! > > > > I have just asked basically about it on Reddit, in the announce thread. > > I'll give it a spin, and if it works I will share the link (if you are > ok with that!) on the > > same Reddit post. > > > > Alfredo > > > > On Tuesday, 23 December 2014, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Heres a OS X build that should work with >= 10.7 > >> > http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > >> > >> and the sha 512 > >> shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > >> > c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd > ghc-7.8.4-x86_64-apple-darwin.tar.bz2 > >> On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp > wrote: > >> > >> ============================================================== > >> The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 > >> ============================================================== > >> > >> The GHC Team is pleased to announce a new patchlevel release of GHC, > 7.8.4. > >> > >> This is an important bugfix release relative to 7.8.3 (with over 30 > >> defects fixed), so we highly recommend upgrading from the previous 7.8 > >> releases. > >> > >> The full release notes are here: > >> > >> > https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html > >> > >> How to get it > >> ~~~~~~~~~~~~~ > >> > >> The easy way is to go to the web page, which should be self-explanatory: > >> > >> https://www.haskell.org/ghc/ > >> > >> We supply binary builds in the native package format for many > >> platforms, and the source distribution is available from the same > >> place. > >> > >> Packages will appear as they are built - if the package for your > >> system isn't available yet, please try again later. > >> > >> > >> Background > >> ~~~~~~~~~~ > >> > >> Haskell is a standard lazy functional programming language. > >> > >> GHC is a state-of-the-art programming suite for Haskell. Included is > >> an optimising compiler generating good code for a variety of > >> platforms, together with an interactive system for convenient, quick > >> development. The distribution includes space and time profiling > >> facilities, a large collection of libraries, and support for various > >> language extensions, including concurrency, exceptions, and foreign > >> language interfaces (C, whatever). GHC is distributed under a > >> BSD-style open source license. > >> > >> A wide variety of Haskell related resources (tutorials, libraries, > >> specifications, documentation, compilers, interpreters, references, > >> contact information, links to research groups) are available from the > >> Haskell home page (see below). > >> > >> > >> On-line GHC-related resources > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > >> Relevant URLs on the World-Wide Web: > >> > >> GHC home page http://www.haskell.org/ghc/ > >> GHC developers' home page http://ghc.haskell.org/trac/ghc/ > >> Haskell home page http://www.haskell.org/ > >> > >> > >> Supported Platforms > >> ~~~~~~~~~~~~~~~~~~~ > >> > >> The list of platforms we support, and the people responsible for them, > >> is here: > >> > >> http://ghc.haskell.org/trac/ghc/wiki/Platforms > >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > >> > >> Ports to other platforms are possible with varying degrees of > >> difficulty. The Building Guide describes how > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Dec 24 17:56:50 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 24 Dec 2014 12:56:50 -0500 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: or worse case, just cabal install haddock and that will work fine On Wed, Dec 24, 2014 at 12:56 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > try rm ~/.cabal/bin/haddock > and then type which haddock and you should be getting the > /usr/local/bin/haddock or whatever, then stuff should work fine > > On Wed, Dec 24, 2014 at 11:40 AM, Alfredo Di Napoli < > alfredo.dinapoli at gmail.com> wrote: > >> The installation succeedeed and GHC is working correctly. >> But yes, "cabal haddock" seems to have some difficulty in the new >> version, but I can't judge if it's my sandboxed environment (we use "hub" >> at work) or the failure you mentioned. >> >> Calling "haddock" alone works (using the previously installed on my >> system), "cabal haddock" does not: >> >> ? mandrill [master] ? haddock src/Network/API/Mandrill.hs >> Haddock coverage: >> Warning: main:Network.API.Mandrill: Could not find documentation for >> exported module: M >> Warning: Couldn't find .haddock for export Control.Monad.IO.Class.liftIO >> 88% ( 7 / 8) in 'Network.API.Mandrill' >> Warning: Network.API.Mandrill: could not find link destinations for: >> Control.Monad.IO.Class.MonadIO >> Network.API.Mandrill.Types.MandrillMessage >> Network.API.Mandrill.Trans.MandrillT >> Network.API.Mandrill.Types.MandrillResponse >> Network.API.Mandrill.Messages.Types.MessagesResponse >> Text.Email.Parser.EmailAddress Data.Text.Internal.Text Text.Blaze.Html.Html >> GHC.Types.IO >> >> ? mandrill [master] ? cabal haddock >> cabal-1.20.0.0: You need to re-run the 'configure' command. The version of >> Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.20.0.0). >> cabal haddock: /usr/hs/tools/cabal-1.20.0.0 failure (return code=1) >> >> >> On Wednesday, 24 December 2014, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> > sure, please verify first. (also make sure haddock etc works for you, >> i had to remove a haddock binary from ~/.cabal/bin before haddocks were >> building correctly for me) >> > On Wed, Dec 24, 2014 at 10:52 AM, Alfredo Di Napoli < >> alfredo.dinapoli at gmail.com> wrote: >> > >> > Thanks Carter! >> > >> > I have just asked basically about it on Reddit, in the announce thread. >> > I'll give it a spin, and if it works I will share the link (if you are >> ok with that!) on the >> > same Reddit post. >> > >> > Alfredo >> > >> > On Tuesday, 23 December 2014, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >> Heres a OS X build that should work with >= 10.7 >> >> >> http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >> >> >> >> and the sha 512 >> >> shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >> >> >> c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd >> ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >> >> On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp >> wrote: >> >> >> >> ============================================================== >> >> The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 >> >> ============================================================== >> >> >> >> The GHC Team is pleased to announce a new patchlevel release of GHC, >> 7.8.4. >> >> >> >> This is an important bugfix release relative to 7.8.3 (with over 30 >> >> defects fixed), so we highly recommend upgrading from the previous 7.8 >> >> releases. >> >> >> >> The full release notes are here: >> >> >> >> >> https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html >> >> >> >> How to get it >> >> ~~~~~~~~~~~~~ >> >> >> >> The easy way is to go to the web page, which should be >> self-explanatory: >> >> >> >> https://www.haskell.org/ghc/ >> >> >> >> We supply binary builds in the native package format for many >> >> platforms, and the source distribution is available from the same >> >> place. >> >> >> >> Packages will appear as they are built - if the package for your >> >> system isn't available yet, please try again later. >> >> >> >> >> >> Background >> >> ~~~~~~~~~~ >> >> >> >> Haskell is a standard lazy functional programming language. >> >> >> >> GHC is a state-of-the-art programming suite for Haskell. Included is >> >> an optimising compiler generating good code for a variety of >> >> platforms, together with an interactive system for convenient, quick >> >> development. The distribution includes space and time profiling >> >> facilities, a large collection of libraries, and support for various >> >> language extensions, including concurrency, exceptions, and foreign >> >> language interfaces (C, whatever). GHC is distributed under a >> >> BSD-style open source license. >> >> >> >> A wide variety of Haskell related resources (tutorials, libraries, >> >> specifications, documentation, compilers, interpreters, references, >> >> contact information, links to research groups) are available from the >> >> Haskell home page (see below). >> >> >> >> >> >> On-line GHC-related resources >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> Relevant URLs on the World-Wide Web: >> >> >> >> GHC home page http://www.haskell.org/ghc/ >> >> GHC developers' home page http://ghc.haskell.org/trac/ghc/ >> >> Haskell home page http://www.haskell.org/ >> >> >> >> >> >> Supported Platforms >> >> ~~~~~~~~~~~~~~~~~~~ >> >> >> >> The list of platforms we support, and the people responsible for them, >> >> is here: >> >> >> >> http://ghc.haskell.org/trac/ghc/wiki/Platforms >> >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners >> >> >> >> Ports to other platforms are possible with varying degrees of >> >> difficulty. The Building Guide describes how >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz at gmail.com Wed Dec 24 19:27:27 2014 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Wed, 24 Dec 2014 20:27:27 +0100 Subject: ghc-7.10.1-rc1 build GC log messages Message-ID: Building ghc-7.10.1-rc1, I see the following new messages: HC [stage 1] compiler/stage2/build/Dwarf.p_o <> Is this a debug log or normal from now on during a ghc build? I don't mind, but I just wanted to make sure it's not a mistakenly enabled debug flag somewhere. From kazu at iij.ad.jp Thu Dec 25 00:26:46 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 25 Dec 2014 09:26:46 +0900 (JST) Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: References: <20141224.133220.1032171133533014509.kazu@iij.ad.jp> Message-ID: <20141225.092646.1983018343320588235.kazu@iij.ad.jp> > Perhaps the readers of this list could read the reddit comments > and propose a way forward? I tried to compile orf-new on Mac (Yosemite). orf-new cannot be compiled even after "git submodule update --init". After modifying some code (e.g. ASSERT macros), it still fails on CMM part. I think that the best way is to rebase orf-new to master. But this causes so many conflicts. I'm not sure that I can take time to fix the conflicts because I need to write a pepar at this moment. --Kazu From slyich at gmail.com Thu Dec 25 11:15:14 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Thu, 25 Dec 2014 11:15:14 +0000 Subject: ghc-7.10.1-rc1 build GC log messages In-Reply-To: References: Message-ID: <20141225111514.466f25b9@sf> On Wed, 24 Dec 2014 20:27:27 +0100 Tuncer Ayaz wrote: > Building ghc-7.10.1-rc1, I see the following new messages: > > HC [stage 1] compiler/stage2/build/Dwarf.p_o > < residency (8 samples), 103M in use, 0.00 INIT (0.00 elapsed), 0.88 MUT > (1.10 elapsed), 0.76 GC (0.77 elapsed) :ghc>> > > Is this a debug log or normal from now on during a ghc build? > I don't mind, but I just wanted to make sure it's not a mistakenly > enabled debug flag somewhere. It is a normal flag and was present long ago on build system: mk/config.mk.in: GhcHcOpts=-Rghc-timing but happened to break a couple of releases ago. Was fixed in https://ghc.haskell.org/trac/ghc/ticket/8787 You can disable it by putting GhcHcOpts= in mk/build.mk. -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From tuncer.ayaz at gmail.com Thu Dec 25 16:09:03 2014 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Thu, 25 Dec 2014 17:09:03 +0100 Subject: ghc-7.10.1-rc1 build GC log messages In-Reply-To: <20141225111514.466f25b9@sf> References: <20141225111514.466f25b9@sf> Message-ID: On Thu, Dec 25, 2014 at 12:15 PM, Sergei Trofimovich wrote: > On Wed, 24 Dec 2014 20:27:27 +0100 Tuncer Ayaz wrote: > > > Building ghc-7.10.1-rc1, I see the following new messages: > > > > HC [stage 1] compiler/stage2/build/Dwarf.p_o > > < > residency (8 samples), 103M in use, 0.00 INIT (0.00 elapsed), 0.88 > > MUT (1.10 elapsed), 0.76 GC (0.77 elapsed) :ghc>> > > > > Is this a debug log or normal from now on during a ghc build? I > > don't mind, but I just wanted to make sure it's not a mistakenly > > enabled debug flag somewhere. > > It is a normal flag and was present long ago on build system: > mk/config.mk.in: > GhcHcOpts=-Rghc-timing > but happened to break a couple of releases ago. > Was fixed in https://ghc.haskell.org/trac/ghc/ticket/8787 > > You can disable it by putting > GhcHcOpts= > in mk/build.mk. I see. From rwbarton at gmail.com Fri Dec 26 20:22:35 2014 From: rwbarton at gmail.com (Reid Barton) Date: Fri, 26 Dec 2014 15:22:35 -0500 Subject: Failing tests: literals T5681 annotations In-Reply-To: <1417561089.344.1.camel@joachim-breitner.de> References: <1416652515.1406.1.camel@joachim-breitner.de> <1416930493.21627.3.camel@joachim-breitner.de> <1417374073.3101.10.camel@joachim-breitner.de> <1417561089.344.1.camel@joachim-breitner.de> Message-ID: On Tue, Dec 2, 2014 at 5:58 PM, Joachim Breitner wrote: > Hi, > > > Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner: > > I?m still seeing this failure: > > > > Compile failed (status 256) errors were: > > /tmp/ghc16123_0/ghc16123_5.s: Assembler messages: > > > > /tmp/ghc16123_0/ghc16123_5.s:26:0: > > Error: can't resolve `.rodata' {.rodata section} - > `Main_zdwwork_info$def' {.text section} > > > > /tmp/ghc16123_0/ghc16123_5.s:46:0: > > Error: can't resolve `.rodata' {.rodata section} - > `Main_work_info$def' {.text section} > > > > /tmp/ghc16123_0/ghc16123_5.s:66:0: > > Error: can't resolve `.rodata' {.rodata section} - > `Main_main1_info$def' {.text section} > > > > /tmp/ghc16123_0/ghc16123_5.s:86:0: > > Error: can't resolve `.rodata' {.rodata section} - > `Main_main_info$def' {.text section} > > > > /tmp/ghc16123_0/ghc16123_5.s:106:0: > > Error: can't resolve `.rodata' {.rodata section} - > `Main_main2_info$def' {.text section} > > > > /tmp/ghc16123_0/ghc16123_5.s:126:0: > > Error: can't resolve `.rodata' {.rodata section} - > `ZCMain_main_info$def' {.text section} > > > > *** unexpected failure for T5681(optllvm) > > > > > > https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt > > > > Any ideas? > > is it possible that this is due the llvm version used? Do we support 3.4 > in GHC HEAD? > > Using LLVM tools > llc : /usr/local/clang-3.4/bin/llc > opt : /usr/local/clang-3.4/bin/opt > This appears to affect all programs built with llvm-3.4. I filed a ticket ( http://ghc.haskell.org/trac/ghc/ticket/9929). Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Sat Dec 27 08:28:45 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 27 Dec 2014 00:28:45 -0800 Subject: Status and future of the LLVM backend In-Reply-To: <878uiuhpns.fsf@gmail.com> References: <878uiuhpns.fsf@gmail.com> Message-ID: <20141227002845.98cb1678a328088e03316266@mega-nerd.com> Ben Gamari wrote: > I've written down some thoughts on the current status and future > direction of the LLVM backend here [1]. Have a look when you get a chance. > > To summarize, > > * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework > when the `$def` symbols are marked as internal > > * ARM is broken (again) due to a bug in the GHC calling convention > implementation; an LLVM fix is waiting to be merged > > * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 > support will likely need to wait until 7.12 > > * Austin's LLVM packaging proposal seems very much like the right way > forward > > * Anticipating this proposal, I have started collecting [2] > optimization passes I've recently been working on amd64-linux to armhf-linux and aarch64-linux cross-compilers. In addition to the above: * LLVM 3.6 that Ben mentions above has not yet been released and is still a work in progress. A commit to the LLVM tree made as recently as December 17th means LLVM head no longer compiles LLVM IR code generated by GHC (metadata issue mentioned in #9920). * LLVM uses C/C++ asserts liberally and these asserts get compiled out during optimised builds (eg for Linux distributions). The removal of these asserts results in llvm binaries that *silently* generate incorrect binaries (see #9920 which is Ben's second bullet point above). For instance, I built an amd64-linux to aarch64-linux cross compiler which generated executables that crashed immediately. When I switched to a debug version of LLVM, LLVM's opt and llc suddenly started showing assertion failures all over. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From hvr at gnu.org Sat Dec 27 12:51:24 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sat, 27 Dec 2014 13:51:24 +0100 Subject: GHC 7.10.x migration guide Message-ID: <87egrljlwz.fsf@gnu.org> Hello! I've started collecting the most common compile-errors (and their respective fixes) I have encountered while compiling Hackage packages with GHC 7.10 in https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 Feel free to contribute to this migration guide. HTH, hvr From ezyang at mit.edu Sat Dec 27 15:16:45 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 27 Dec 2014 10:16:45 -0500 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com> References: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com> Message-ID: <1419693186-sup-7586@sabre> Hello lonetiger, I don't think any relevant logic changed in 7.10; however, this commit may be relevant: commit 8fb03bfd768ea0d5c666bbe07a50cb05214bbe92 Author: Ian Lynagh Sun Mar 18 11:42:31 2012 Committer: Ian Lynagh Sun Mar 18 11:42:31 2012 Original File: compiler/typecheck/TcForeign.lhs If we say we're treating StdCall as CCall, then actually do so But this warning should have applied even on older versions of GHC. Are you running x86_64 Windows? stdcall is specific to x86_32. Edward Excerpts from lonetiger's message of 2014-12-24 08:24:52 -0500: > Hi, > > > I?ve had some issues building this (and the git HEAD), it seems that the config.guess and config.sub in the libffi tarball is old, it doesn?t detect the platform when building with msys2. I had to unpack the tarfile and update the files, after this it correctly built. > > > Then I proceeded to try to make a shared library and got the following warning: > > > ManualCheck.hs:18:1: Warning: > the 'stdcall' calling convention is unsupported on this platform, > treating as ccall > When checking declaration: > foreign export stdcall "testFoo" testFooA :: CInt -> IO (FooPtr) > > > > Does this mean that GHC no longer supports stdcall on windows? or could this be related to issue I had building? > > > Regards, > > Tamar > > > > > > From: Austin Seipp > Sent: ?Tuesday?, ?December? ?23?, ?2014 ?15?:?36 > To: ghc-devs at haskell.org, glasgow-haskell-users at haskell.org > > > > > > We are pleased to announce the first release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc1/ > > This includes the source tarball and bindists for 64bit/32bit Linux > and Windows. Binary builds for other platforms will be available > shortly. (CentOS 6.5 binaries are not available at this time like they > were for 7.8.x). These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 release sometime in February of 2015. We > expect another RC to occur during January of 2015. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > From lonetiger at gmail.com Sat Dec 27 16:38:11 2014 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Sat, 27 Dec 2014 16:38:11 +0000 Subject: =?utf-8?Q?Re:_ANNOUNCE:_GHC_7.10.1_Release_Candidate_1?= In-Reply-To: <1419693186-sup-7586@sabre> References: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com>,<1419693186-sup-7586@sabre> Message-ID: <549ee120.2860b40a.2f71.45b8@mx.google.com> Hi Edward, You?re right, this is my mistake, I am compiling x86_64 Windows, I have not updated my tools to work on it yet so I?ve been using the x86_32 binaries and didn?t noticed that my msys2 was compiling a 64bit version. That explains the warning, sorry for the false alarm! Regards, Tamar From: Edward Z. Yang Sent: ?Saturday?, ?December? ?27?, ?2014 ?16?:?16 To: lonetiger Cc: Austin Seipp, ghc-devs at haskell.org, glasgow-haskell-users@ Hello lonetiger, I don't think any relevant logic changed in 7.10; however, this commit may be relevant: commit 8fb03bfd768ea0d5c666bbe07a50cb05214bbe92 Author: Ian Lynagh Sun Mar 18 11:42:31 2012 Committer: Ian Lynagh Sun Mar 18 11:42:31 2012 Original File: compiler/typecheck/TcForeign.lhs If we say we're treating StdCall as CCall, then actually do so But this warning should have applied even on older versions of GHC. Are you running x86_64 Windows? stdcall is specific to x86_32. Edward Excerpts from lonetiger's message of 2014-12-24 08:24:52 -0500: > Hi, > > > I?ve had some issues building this (and the git HEAD), it seems that the config.guess and config.sub in the libffi tarball is old, it doesn?t detect the platform when building with msys2. I had to unpack the tarfile and update the files, after this it correctly built. > > > Then I proceeded to try to make a shared library and got the following warning: > > > ManualCheck.hs:18:1: Warning: > the 'stdcall' calling convention is unsupported on this platform, > treating as ccall > When checking declaration: > foreign export stdcall "testFoo" testFooA :: CInt -> IO (FooPtr) > > > > Does this mean that GHC no longer supports stdcall on windows? or could this be related to issue I had building? > > > Regards, > > Tamar > > > > > > From: Austin Seipp > Sent: ?Tuesday?, ?December? ?23?, ?2014 ?15?:?36 > To: ghc-devs at haskell.org, glasgow-haskell-users at haskell.org > > > > > > We are pleased to announce the first release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc1/ > > This includes the source tarball and bindists for 64bit/32bit Linux > and Windows. Binary builds for other platforms will be available > shortly. (CentOS 6.5 binaries are not available at this time like they > were for 7.8.x). These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 release sometime in February of 2015. We > expect another RC to occur during January of 2015. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengang31 at gmail.com Sun Dec 28 03:41:45 2014 From: chengang31 at gmail.com (cg) Date: Sun, 28 Dec 2014 11:41:45 +0800 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com> References: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com> Message-ID: > *From:* Austin Seipp > *Sent:* ?Tuesday?, ?December? ?23?, ?2014 ?15?:?36 > *To:* ghc-devs at haskell.org , > glasgow-haskell-users at haskell.org > > We are pleased to announce the first release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc1/ > Besides downloading a tarball, can I checkout it using git? I tried using sync-all as described on wiki [1] to checkout it: ./sync-all checkout ghc-7.10 but it seems it doesn't work, there are error message like: error: pathspec 'ghc-7.10' did not match any file(s) known to git. [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases From hvriedel at gmail.com Sun Dec 28 07:49:55 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 28 Dec 2014 08:49:55 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: (cg's message of "Sun, 28 Dec 2014 11:41:45 +0800") References: <549abfa5.4458b40a.5c8e.ffff896b@mx.google.com> Message-ID: <87egrk5i3g.fsf@gmail.com> On 2014-12-28 at 04:41:45 +0100, cg wrote: [...] > Besides downloading a tarball, can I checkout it using git? > > I tried using sync-all as described on wiki [1] to checkout it: > > ./sync-all checkout ghc-7.10 > > but it seems it doesn't work, there are error message like: > error: pathspec 'ghc-7.10' did not match any file(s) known to git. Rather follow https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingabranchGHC7.9orlater and/or https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules i.e. git clone -b ghc-7.10 --recursive git://git.haskell.org/ghc.git or (if you have already a GHC 7.9.x tree cloned out), use git checkout ghc-7.10 && git submodule update --init to switch to the ghc-7.10 branch (and update the submodules) HTH, hvr From mle+hs at mega-nerd.com Sun Dec 28 10:33:21 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 28 Dec 2014 02:33:21 -0800 Subject: GHC ARM64 calling convention Message-ID: <20141228023321.07c60c02e62df50725224dbd@mega-nerd.com> Hi Luke, I found your llvm git tree which contains a patch [0] implementing the GHC calling convention for GHC. I also notice that: a) It has not been submitted upstream. b) It can be cherry picked and applied on top of current llvm HEAD. c) It can be applied to the llvm 3.5 tree and most importantly of all d) It actually works. With this patch applied to the llvm 3.5 tree, I was able to build an x86_64-linux to aarch64-linux cross-compiler which was able to build a simple "hello world" program that actually ran correctly. Are you in the process of trying to get this patch into LLVM? Do you need any help? Cheers, Erik [0] https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1d01 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From lukexipd at gmail.com Sun Dec 28 12:25:40 2014 From: lukexipd at gmail.com (Luke Iannini) Date: Sun, 28 Dec 2014 04:25:40 -0800 Subject: GHC ARM64 calling convention In-Reply-To: <20141228023321.07c60c02e62df50725224dbd@mega-nerd.com> References: <20141228023321.07c60c02e62df50725224dbd@mega-nerd.com> Message-ID: Hi Erik! Really glad you found it. I did actually submit it to the LLVM team a couple months ago; the relevant email from Tim Northover is here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/243180.html He had a few small questions/requests and I've just been too pulled under by other projects to address them. If you want to give it the last nudge into glory I'd be thrilled : ) Cheers Luke On Sun, Dec 28, 2014 at 2:33 AM, Erik de Castro Lopo wrote: > Hi Luke, > > I found your llvm git tree which contains a patch [0] implementing the > GHC calling convention for GHC. I also notice that: > > a) It has not been submitted upstream. > b) It can be cherry picked and applied on top of current llvm HEAD. > c) It can be applied to the llvm 3.5 tree > > and most importantly of all > > d) It actually works. > > With this patch applied to the llvm 3.5 tree, I was able to build an > x86_64-linux to aarch64-linux cross-compiler which was able to build > a simple "hello world" program that actually ran correctly. > > Are you in the process of trying to get this patch into LLVM? Do you need > any help? > > Cheers, > Erik > > [0] > https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1d01 > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukexipd at gmail.com Sun Dec 28 12:29:34 2014 From: lukexipd at gmail.com (Luke Iannini) Date: Sun, 28 Dec 2014 04:29:34 -0800 Subject: GHC ARM64 calling convention In-Reply-To: References: <20141228023321.07c60c02e62df50725224dbd@mega-nerd.com> Message-ID: (oh, and on the topic of Useful Work I've done but haven't had time to box up and ship, I backported the relevant ARM64 patches to GHC 7.8 here, in case it's useful to anyone: https://github.com/lukexi/ghc-7.8-arm64 ) On Sun, Dec 28, 2014 at 4:25 AM, Luke Iannini wrote: > Hi Erik! > > Really glad you found it. > > I did actually submit it to the LLVM team a couple months ago; the > relevant email from Tim Northover is here: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/243180.html > > He had a few small questions/requests and I've just been too pulled under > by other projects to address them. If you want to give it the last nudge > into glory I'd be thrilled : ) > > Cheers > Luke > > On Sun, Dec 28, 2014 at 2:33 AM, Erik de Castro Lopo > wrote: > >> Hi Luke, >> >> I found your llvm git tree which contains a patch [0] implementing the >> GHC calling convention for GHC. I also notice that: >> >> a) It has not been submitted upstream. >> b) It can be cherry picked and applied on top of current llvm HEAD. >> c) It can be applied to the llvm 3.5 tree >> >> and most importantly of all >> >> d) It actually works. >> >> With this patch applied to the llvm 3.5 tree, I was able to build an >> x86_64-linux to aarch64-linux cross-compiler which was able to build >> a simple "hello world" program that actually ran correctly. >> >> Are you in the process of trying to get this patch into LLVM? Do you need >> any help? >> >> Cheers, >> Erik >> >> [0] >> https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1d01 >> -- >> ---------------------------------------------------------------------- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 29 10:29:23 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 29 Dec 2014 10:29:23 +0000 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 In-Reply-To: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> References: <20141224.111200.2221307343344178430.kazu@iij.ad.jp> Message-ID: <618BE556AADD624C9C918AA5D5911BEF5628E269@DB3PRD3001MB020.064d.mgd.msft.net> | If I understand correctly, OverloadedRecordFields has not been merged | yet. Are there any chances to merge it into GHC 7.10.1? I'm afraid not. The situation is that Adam has a fairly complete patch for overloaded record fields, but neither he nor I are happy with it. It makes some fairly complicated and pervasive changes, and feels like a sledgehammer to crack a nut. We'd scheduled for Adam to spend a day at MSR for us to work on it together, but Adam had to cancel. We'll hopefully re-arrange. Meanwhile it'd be motivating to know who, if anyone, is actively keen on it. Kazu is presumably one. I expect there are others, but I couldn't list them. Simon | | --Kazu | | > We are pleased to announce the first release candidate for GHC 7.10.1: | > | > https://downloads.haskell.org/~ghc/7.10.1-rc1/ | > | > This includes the source tarball and bindists for 64bit/32bit Linux | > and Windows. Binary builds for other platforms will be available | > shortly. (CentOS 6.5 binaries are not available at this time like they | > were for 7.8.x). These binaries and tarballs have an accompanying | > SHA256SUMS file signed by my GPG key id (0x3B58D86F). | > | > We plan to make the 7.10.1 release sometime in February of 2015. We | > expect another RC to occur during January of 2015. | > | > Please test as much as possible; bugs are much cheaper if we find them | > before the release! | > | > -- | > Regards, | > | > Austin Seipp, Haskell Consultant | > Well-Typed LLP, http://www.well-typed.com/ | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Mon Dec 29 15:12:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 29 Dec 2014 10:12:58 -0500 Subject: Fwd: [Haskell-beginners] ghc prelude home In-Reply-To: <54A15CE3.2070501@dfki.de> References: <201412281449.sBSEnpbk007869@coolidge.cs.dartmouth.edu> <8761cvg17y.fsf@gmail.com> <1419792360.304034.207381885.45DCCAB6@webmail.messagingengine.com> <54A15CE3.2070501@dfki.de> Message-ID: seems we need to update the various ghc pages to point to 7.8.4? also maybe provide links to how folks can install cabal-install, though I guess the new haskell.org page will accomplish that too ---------- Forwarded message ---------- From: Christian Maeder Date: Mon, Dec 29, 2014 at 8:53 AM Subject: Re: [Haskell-beginners] ghc prelude home To: gale at sefer.org, The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell , Antoine Latter , GHC Users Mailing List < glasgow-haskell-users at haskell.org> Cc: Doug McIlroy 23 December 2014 GHC 7.8.4 Released! https://www.haskell.org/ghc/ So 7.8.4 is out! Only the download subpage https://www.haskell.org/ghc/download is not updated yet. Also http://downloads.haskell.org/~ghc/latest/ still refers to http://downloads.haskell.org/~ghc/7.8.3/ (and has a funny 7.8.4 subdirectory). I send this also to glasgow-haskell-users to reach someone who can fix this. Cheers Christian Am 28.12.2014 um 22:28 schrieb Yitzchak Gale: > Yes, sorry, neither 7.8.4 nor 7.10.1 is actually out yet. > They are both release candidates, and will be out soon. > > Thanks, > Yitz > > On Sun, Dec 28, 2014 at 9:50 PM, Antoine Latter > wrote: > >> I don't think GHC 7.10 is out yet: https://www.haskell.org/ghc/download >> >> Although that page doesn't have 7.8.4 on it. >> > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.dinapoli at gmail.com Mon Dec 29 17:53:02 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Mon, 29 Dec 2014 18:53:02 +0100 Subject: ANNOUNCE: GHC version 7.8.4 In-Reply-To: References: Message-ID: Hi Carter, I finally had the chance to test this on my personal laptop, where I was pretty much free on which version of Cabal/haddock to use. Installing a fresh haddock, and using Cabal-1.20.0.3 (but I suspect it doesn?t matter), ?cabal haddock? worked just fine on one of my libraries. A. On Wednesday, 24 December 2014, Carter Schonwald wrote: > or worse case, just cabal install haddock and that will work fine > On Wed, Dec 24, 2014 at 12:56 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > > try rm ~/.cabal/bin/haddock > and then type which haddock and you should be getting the /usr/local/bin/haddock or whatever, then stuff should work fine > On Wed, Dec 24, 2014 at 11:40 AM, Alfredo Di Napoli < alfredo.dinapoli at gmail.com> wrote: > > The installation succeedeed and GHC is working correctly. > But yes, "cabal haddock" seems to have some difficulty in the new version, but I can't judge if it's my sandboxed environment (we use "hub" at work) or the failure you mentioned. > > Calling "haddock" alone works (using the previously installed on my system), "cabal haddock" does not: > > ? mandrill [master] ? haddock src/Network/API/Mandrill.hs > Haddock coverage: > Warning: main:Network.API.Mandrill: Could not find documentation for exported module: M > Warning: Couldn't find .haddock for export Control.Monad.IO.Class.liftIO > 88% ( 7 / 8) in 'Network.API.Mandrill' > Warning: Network.API.Mandrill: could not find link destinations for: > Control.Monad.IO.Class.MonadIO Network.API.Mandrill.Types.MandrillMessage Network.API.Mandrill.Trans.MandrillT Network.API.Mandrill.Types.MandrillResponse Network.API.Mandrill.Messages.Types.MessagesResponse Text.Email.Parser.EmailAddress Data.Text.Internal.Text Text.Blaze.Html.Html GHC.Types.IO > > ? mandrill [master] ? cabal haddock > cabal-1.20.0.0: You need to re-run the 'configure' command. The version of > Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.20.0.0). > cabal haddock: /usr/hs/tools/cabal-1.20.0.0 failure (return code=1) > > On Wednesday, 24 December 2014, Carter Schonwald < carter.schonwald at gmail.com> wrote: >> sure, please verify first. (also make sure haddock etc works for you, i had to remove a haddock binary from ~/.cabal/bin before haddocks were building correctly for me) >> On Wed, Dec 24, 2014 at 10:52 AM, Alfredo Di Napoli < alfredo.dinapoli at gmail.com> wrote: >> >> Thanks Carter! >> >> I have just asked basically about it on Reddit, in the announce thread. >> I'll give it a spin, and if it works I will share the link (if you are ok with that!) on the >> same Reddit post. >> >> Alfredo >> >> On Tuesday, 23 December 2014, Carter Schonwald < carter.schonwald at gmail.com> wrote: >>> Heres a OS X build that should work with >= 10.7 >>> http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >>> >>> and the sha 512 >>> shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >>> c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd ghc-7.8.4-x86_64-apple-darwin.tar.bz2 >>> On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp wrote: >>> >>> ============================================================== >>> The (Interactive) Glasgow Haskell Compiler -- version 7.8.4 >>> ============================================================== >>> >>> The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4. >>> >>> This is an important bugfix release relative to 7.8.3 (with over 30 >>> defects fixed), so we highly recommend upgrading from the previous 7.8 >>> releases. >>> >>> The full release notes are here: >>> >>> https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_gui -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 29 18:30:51 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Dec 2014 19:30:51 +0100 Subject: master: Eliminate so-called "silent superclass parameters" (a6f0f5a) In-Reply-To: <1419874856.13967.7.camel@joachim-breitner.de> References: <20141223162932.A04A93A300@ghc.haskell.org> <1419874856.13967.7.camel@joachim-breitner.de> Message-ID: <1419877851.13967.11.camel@joachim-breitner.de> Hi Am Montag, den 29.12.2014, 18:40 +0100 schrieb Joachim Breitner: > Am Dienstag, den 23.12.2014, 16:29 +0000 schrieb git at git.haskell.org: > > commit a6f0f5ab45b2643b561e0a0a54a4f14745ab2152 > > Author: Simon Peyton Jones > > Date: Tue Dec 23 15:39:50 2014 +0000 > > > > Eliminate so-called "silent superclass parameters" > > you may or may not have noticed that ghcspeed stopped producing results > since this commits. > > The reason is that running nofib fails: reproduced locally, filed as: https://ghc.haskell.org/trac/ghc/ticket/9938 Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Dec 30 12:03:17 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Dec 2014 12:03:17 +0000 Subject: Compiling nofib-analyse Message-ID: <618BE556AADD624C9C918AA5D5911BEF5628F05C@DB3PRD3001MB020.064d.mgd.msft.net> When building nofib-analyse (in nofib), I get /home/simonpj/local/bin/ghc -O -cpp --make Main -o nofib-analyse Main.hs:14:18: Could not find module 'Text.Html' Use -v to see a list of the files searched for. There are rather a lot of HTML packages. Which one is needed? Does this meant that it's essential to install this package before running nofib, a manual step? I wonder if it'd be better to remove the HTML dependency, or make it optional? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Dec 30 13:50:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Dec 2014 13:50:00 +0000 Subject: Which of these commits to merge into ghc-7.10? In-Reply-To: <87iogxjpwu.fsf@gnu.org> References: <87iogxjpwu.fsf@gnu.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF56291207@DB3PRD3001MB020.064d.mgd.msft.net> | As I'm currently merging some commits into the ghc-7.10 branch, which | of the following commits do you deem suitable for 7.10? | | - | http://git.haskell.org/ghc.git/commitdiff/a6f0f5ab45b2643b561e0a0a54a4 | f14745ab2152 See https://ghc.haskell.org/trac/ghc/ticket/3064#comment:21 | http://git.haskell.org/ghc.git/commitdiff/3e96d89b1d37a989b92a11587de2 | 9e347ef19328 Yes, this can go in | http://git.haskell.org/ghc.git/commitdiff/679a661890c9e5a218d8328658ca | e2b71d367024 This is ok too; should be no change in functionality. | http://git.haskell.org/ghc.git/commitdiff/c3394e0d2cce4bbaa034dc77473a | dd151781ef93 Not so sure here... I may not have gotten the change in the test harness right. Simon From tuncer.ayaz at gmail.com Tue Dec 30 16:48:27 2014 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 30 Dec 2014 17:48:27 +0100 Subject: Right way to turn off dynamic linking in build.mk In-Reply-To: References: Message-ID: On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell wrote: > Some times when I play around with GHC I'd like to turn off dynamic > linking to make GHC compile faster. I'm not sure what the right way > to do this in build.mk. It's made confusing by the conditional > statements in that file: > > GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) > > This line make me worry that if I don't put > > DYNAMIC_GHC_PROGRAMS = NO > > in the right place in build.mk it wont "take". > > There's also this one: > > ifeq "$(PlatformSupportsSharedLibs)" "YES" > GhcLibWays += dyn > endif > > Seeing this makes me wonder if > > DYNAMIC_GHC_PROGRAMS = NO > DYNAMIC_BY_DEFAULT = NO > > is enough or if the build system still sniffs out the fact that my > platform supports dynamic linking. > > Could someone please give an authoritative answer to how to turn off > dynamic linking? Hi Johan, did you find the answer? From johan.tibell at gmail.com Tue Dec 30 16:59:41 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 30 Dec 2014 11:59:41 -0500 Subject: Right way to turn off dynamic linking in build.mk In-Reply-To: References: Message-ID: Not a good answer, I just set GhcLibWays = v DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO at the bottom of the file. This feels a bit hacky because we're overriding GhcLibWays (e.g. we could be dropping the prof way by accident). I think it should be possible to state our desire (i.e. I don't want dyn) somewhere in the file and have that just work. Trying to manually change things like GhcLibWays is error prone. On Tue, Dec 30, 2014 at 11:48 AM, Tuncer Ayaz wrote: > On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell > wrote: > > Some times when I play around with GHC I'd like to turn off dynamic > > linking to make GHC compile faster. I'm not sure what the right way > > to do this in build.mk. It's made confusing by the conditional > > statements in that file: > > > > GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) > > > > This line make me worry that if I don't put > > > > DYNAMIC_GHC_PROGRAMS = NO > > > > in the right place in build.mk it wont "take". > > > > There's also this one: > > > > ifeq "$(PlatformSupportsSharedLibs)" "YES" > > GhcLibWays += dyn > > endif > > > > Seeing this makes me wonder if > > > > DYNAMIC_GHC_PROGRAMS = NO > > DYNAMIC_BY_DEFAULT = NO > > > > is enough or if the build system still sniffs out the fact that my > > platform supports dynamic linking. > > > > Could someone please give an authoritative answer to how to turn off > > dynamic linking? > > Hi Johan, > > did you find the answer? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Dec 30 19:39:42 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 30 Dec 2014 14:39:42 -0500 Subject: Cabal 1.22 RC now available Message-ID: I've just uploaded the Cabal-1.22.0.0 RC: http://johantibell.com/files/Cabal-1.22.0.0-rc.tar.gz I know it's a bit late, but if you could update the GHC 7.10 branch to use it (Git tag: Cabal-v1.22.0.0-rc) that would be great. When do you need the actual release to happen, so it's out before GHC 7.10? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Dec 30 21:07:01 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 30 Dec 2014 21:07:01 +0000 Subject: Right way to turn off dynamic linking in build.mk References: Message-ID: I don't have an authoritative answer, but in the past I set DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT as Johan originally suggested and didn't have any issues with the resulting build. On Tue Dec 30 2014 at 9:00:07 AM Johan Tibell wrote: > Not a good answer, I just set > > GhcLibWays = v > DYNAMIC_GHC_PROGRAMS = NO > DYNAMIC_BY_DEFAULT = NO > > at the bottom of the file. This feels a bit hacky because we're overriding GhcLibWays > (e.g. we could be dropping the prof way by accident). I think it should be > possible to state our desire (i.e. I don't want dyn) somewhere in the file > and have that just work. Trying to manually change things like GhcLibWays > is error prone. > > On Tue, Dec 30, 2014 at 11:48 AM, Tuncer Ayaz > wrote: > >> On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell >> wrote: >> > Some times when I play around with GHC I'd like to turn off dynamic >> > linking to make GHC compile faster. I'm not sure what the right way >> > to do this in build.mk. It's made confusing by the conditional >> > statements in that file: >> > >> > GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) >> > >> > This line make me worry that if I don't put >> > >> > DYNAMIC_GHC_PROGRAMS = NO >> > >> > in the right place in build.mk it wont "take". >> > >> > There's also this one: >> > >> > ifeq "$(PlatformSupportsSharedLibs)" "YES" >> > GhcLibWays += dyn >> > endif >> > >> > Seeing this makes me wonder if >> > >> > DYNAMIC_GHC_PROGRAMS = NO >> > DYNAMIC_BY_DEFAULT = NO >> > >> > is enough or if the build system still sniffs out the fact that my >> > platform supports dynamic linking. >> > >> > Could someone please give an authoritative answer to how to turn off >> > dynamic linking? >> >> Hi Johan, >> >> did you find the answer? >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Dec 30 23:03:58 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 30 Dec 2014 18:03:58 -0500 Subject: Right way to turn off dynamic linking in build.mk In-Reply-To: References: Message-ID: I think that results in libs being built the dyn way as well, which probably doesn't hurt but takes quite a bit of time. On Tue, Dec 30, 2014 at 4:07 PM, John Lato wrote: > I don't have an authoritative answer, but in the past I set > DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT as Johan originally suggested > and didn't have any issues with the resulting build. > > On Tue Dec 30 2014 at 9:00:07 AM Johan Tibell > wrote: > >> Not a good answer, I just set >> >> GhcLibWays = v >> DYNAMIC_GHC_PROGRAMS = NO >> DYNAMIC_BY_DEFAULT = NO >> >> at the bottom of the file. This feels a bit hacky because we're >> overriding GhcLibWays (e.g. we could be dropping the prof way by >> accident). I think it should be possible to state our desire (i.e. I don't >> want dyn) somewhere in the file and have that just work. Trying to manually >> change things like GhcLibWays is error prone. >> >> On Tue, Dec 30, 2014 at 11:48 AM, Tuncer Ayaz >> wrote: >> >>> On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell >>> wrote: >>> > Some times when I play around with GHC I'd like to turn off dynamic >>> > linking to make GHC compile faster. I'm not sure what the right way >>> > to do this in build.mk. It's made confusing by the conditional >>> > statements in that file: >>> > >>> > GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) >>> > >>> > This line make me worry that if I don't put >>> > >>> > DYNAMIC_GHC_PROGRAMS = NO >>> > >>> > in the right place in build.mk it wont "take". >>> > >>> > There's also this one: >>> > >>> > ifeq "$(PlatformSupportsSharedLibs)" "YES" >>> > GhcLibWays += dyn >>> > endif >>> > >>> > Seeing this makes me wonder if >>> > >>> > DYNAMIC_GHC_PROGRAMS = NO >>> > DYNAMIC_BY_DEFAULT = NO >>> > >>> > is enough or if the build system still sniffs out the fact that my >>> > platform supports dynamic linking. >>> > >>> > Could someone please give an authoritative answer to how to turn off >>> > dynamic linking? >>> >>> Hi Johan, >>> >>> did you find the answer? >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Dec 31 00:10:56 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 30 Dec 2014 19:10:56 -0500 Subject: Compiling nofib-analyse In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF5628F05C@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF5628F05C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1419984556-sup-9043@sabre> Pretty sure it's the aptly named 'html'. https://hackage.haskell.org/package/html I can't remember the last time I used the HTML reporting capability, so I'd be happy about removing it. Edward Excerpts from Simon Peyton Jones's message of 2014-12-30 07:03:17 -0500: > When building nofib-analyse (in nofib), I get > > /home/simonpj/local/bin/ghc -O -cpp --make Main -o nofib-analyse > > Main.hs:14:18: > Could not find module 'Text.Html' > Use -v to see a list of the files searched for. > > There are rather a lot of HTML packages. Which one is needed? Does this meant that it's essential to install this package before running nofib, a manual step? > > I wonder if it'd be better to remove the HTML dependency, or make it optional? > > Simon From michael at snoyman.com Wed Dec 31 14:10:37 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 31 Dec 2014 14:10:37 +0000 Subject: Limiting size of global package database Message-ID: tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library), can we remove Cabal from the global package database installed with GHC? A problem that comes up quite a bit for users of GHC is conflicting package versions versus the version of a package that shipped with GHC. Some examples I've run into in the past include binary-0.7/GHC-7.6, and bytestring0-0.10/GHC-7.4. This is problematic for two reasons: 1. End users can be confused by having multiple versions of a package installed (one global, one user). I've seen at least a dozen questions on Stack Overflow, Reddit, and mailing lists about things like "ByteString is not bytestring-0.10.0.0-Data.ByteString.Internal.ByteString". 2. Any packages depended on by the ghc package can be very dangerous to upgrade, as then you're blocked from using the ghc package with the new version. This most often comes into play with doctest, though I've been affected by it on other projects as well. For both of these reasons, I think we should limit the number of packages included in the global package database. One seemingly small step we could do on that front is not include extraneous packages. In GHC 7.10rc1, that includes Cabal and xhtml: both packages are in the global package database, but could just as easily be removed from there and installed by users. The motivation for that would be to avoid problem (1) above. I realize that this change wouldn't affect point (2) above at all. Frankly, that's the issue that causes me quite a bit more trouble, and I'd love to see it resolved somehow, but it's unlikely to occur during the GHC 7.10 window. I'm writing this email now because I think there's a chance of resolving the smaller issue immediately, but I'd like to explore the wider issue of ghc-the-library dependencies for GHC 7.12. I've opened up an issue[1] on Stackage's issue tracker about this as well. [1] https://github.com/fpco/fpco/issues/3978 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Dec 31 14:25:08 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 31 Dec 2014 15:25:08 +0100 Subject: Limiting size of global package database In-Reply-To: (Michael Snoyman's message of "Wed, 31 Dec 2014 14:10:37 +0000") References: Message-ID: <87sifv522j.fsf@gmail.com> Hello Michael, On 2014-12-31 at 15:10:37 +0100, Michael Snoyman wrote: > tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library), > can we remove Cabal from the global package database installed with GHC? [...] > For both of these reasons, I think we should limit the number of packages > included in the global package database. One seemingly small step we could > do on that front is not include extraneous packages. In GHC 7.10rc1, that > includes Cabal and xhtml: btw, haskeline and terminfo should be considered as well, according to your argument. > both packages are in the global package database, but could just as > easily be removed from there and installed by users. The motivation > for that would be to avoid problem (1) above. However, as for xhtml, haskeline and terminfo, we had to register/expose them in the global pkg DB due to https://ghc.haskell.org/trac/ghc/ticket/8919 and as for Cabal, I have been told (maybe Duncan can weigh in...?) that Haskell implementations need to provide it (together with a `*hc-pkg` executable) in order to conform to the CABAL specification[1]. Cheers, hvr [1]: https://www.haskell.org/cabal/proposal/pkg-spec.pdf From michael at snoyman.com Wed Dec 31 14:32:00 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 31 Dec 2014 14:32:00 +0000 Subject: Limiting size of global package database References: <87sifv522j.fsf@gmail.com> Message-ID: On Wed Dec 31 2014 at 4:25:12 PM Herbert Valerio Riedel wrote: > Hello Michael, > > On 2014-12-31 at 15:10:37 +0100, Michael Snoyman wrote: > > tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library), > > can we remove Cabal from the global package database installed with GHC? > > [...] > > > For both of these reasons, I think we should limit the number of packages > > included in the global package database. One seemingly small step we > could > > do on that front is not include extraneous packages. In GHC 7.10rc1, that > > includes Cabal and xhtml: > > btw, haskeline and terminfo should be considered as well, according to > your argument. > > Yes, I didn't mean to imply that my list was exhaustive, those were just two examples that jumped out at me. > > both packages are in the global package database, but could just as > > easily be removed from there and installed by users. The motivation > > for that would be to avoid problem (1) above. > > However, as for xhtml, haskeline and terminfo, we had to register/expose > them in the global pkg DB due to > > https://ghc.haskell.org/trac/ghc/ticket/8919 > > IIUC, this comes down to the fact that distros want to install all packages into the global database, whereas the pain point I'm describing here is from users wanting to *avoid* having things in the global database. Perhaps there's a simple solution here: if end-users non-distro installations of GHC unregistered those packages, would it cause them any problems? Perhaps having those packages in the global database is something that *only* distros need. > and as for Cabal, I have been told (maybe Duncan can weigh in...?) that > Haskell implementations need to provide it (together with a `*hc-pkg` > executable) in order to conform to the CABAL specification[1]. > > > If that's the case, I would request that we modify the CABAL specification. I wouldn't want us to make a bad technical decision because a spec told us to do so. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboes at tweag.net Wed Dec 31 15:34:36 2014 From: mboes at tweag.net (Mathieu Boespflug) Date: Wed, 31 Dec 2014 16:34:36 +0100 Subject: Limiting size of global package database In-Reply-To: <87sifv522j.fsf@gmail.com> References: <87sifv522j.fsf@gmail.com> Message-ID: Hi Herbert, On 31 December 2014 at 15:25, Herbert Valerio Riedel wrote: > Hello Michael, > > On 2014-12-31 at 15:10:37 +0100, Michael Snoyman wrote: >> tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library), >> can we remove Cabal from the global package database installed with GHC? > > [...] > >> For both of these reasons, I think we should limit the number of packages >> included in the global package database. One seemingly small step we could >> do on that front is not include extraneous packages. In GHC 7.10rc1, that >> includes Cabal and xhtml: > > btw, haskeline and terminfo should be considered as well, according to > your argument. > >> both packages are in the global package database, but could just as >> easily be removed from there and installed by users. The motivation >> for that would be to avoid problem (1) above. > > However, as for xhtml, haskeline and terminfo, we had to register/expose > them in the global pkg DB due to > > https://ghc.haskell.org/trac/ghc/ticket/8919 Thanks for pointing to the root explanation. Though as noted in that ticket by Joachim, there was another solution to this problem: simply install DSO's in a location that wouldn't clash with where distros typically install packages themselves. The other solution is to simply statically link the GHC binaries that would otherwise require these DSO's. Is the reason why those solutions were not chosen in the end documented anywhere? As Michael points out, every additional package forcefully installed into the global db by GHC is yet another potential source of problems for users when installing libraries. Including when doing so in a sandbox! (because global packages leak inside sandboxes). Best, Mathieu