- ghc-devs - Haskell.org

help wrt semantics / primops for pure prefetches
by Carter Schonwald 01 Dec '14

01 Dec '14

Hey Everyone, in https://ghc.haskell.org/trac/ghc/ticket/9353 and https://phabricator.haskell.org/D350 is some preliminary work to fix up how the pure versions of the prefetch primops work is laid out and prototyped. However, while it nominally fixes up some of the problems with how the current pure prefetch apis are fundamentally borken, the simple design in D350 isn't quite ideal, and i sketch out some other ideas in the associated ticket #9353 I'd like to make sure pure prefetch in 7.10 is slightly less broken than in 7.8, but either way, its pretty clear that working out the right fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there WILL have to be breaking changes to fix those primops for 7.12 thanks and any feedback / thoughts appreciated -Carter

5 9

RE: Windows build broken again: urgent
by Simon Peyton Jones 01 Dec '14

01 Dec '14

| 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@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?

3 4

GHC Weekly News - 2014/12/01
by Austin Seipp 01 Dec '14

01 Dec '14

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/

1 0

Performance regression on typechecking type families?
by Dr. ERDI Gergo 01 Dec '14

01 Dec '14

Hi, Prompted by this question: http://stackoverflow.com/questions/26538595/more-efficient-type-level-compu… I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question. The two files are here: https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18 On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively! Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison? Bye, Gergo

4 3

Cross-compiling GHC for ARM (RPi)
by Xandaros 01 Dec '14

01 Dec '14

-----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-----

2 1

Windows build broken again: urgent
by Simon Peyton Jones 01 Dec '14

01 Dec '14

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

1 0

Re: [commit: ghc] master: compiler: fix trac issue #8815 (780b061)
by Joachim Breitner 30 Nov '14

30 Nov '14

Hi, just a quick note: This commit message is rather unhelpful. In this case it is not a big deal (the patch is quite self-explanatory), but I recommend you to manually clean up arc-generated commit messages before pushing. Also remember when creating a Phab DR that whatever you put in the summary will be part of the default commit message. Greetings, Joachim (who does more complaining than actual contributing these days...) Am Sonntag, den 30.11.2014, 19:17 +0000 schrieb git(a)git.haskell.org: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/780b061ce2aea4722d1a5d0e46fd4ed8e… > > >--------------------------------------------------------------- > > commit 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6 > Author: Sivaram Balakrishnan <sivaram1992(a)gmail.com> > Date: Sun Nov 30 13:05:56 2014 -0600 > > compiler: fix trac issue #8815 > > Summary: This patch changes the error message as suggested in trac issue #8815 comments. > > Reviewers: jstolarek, austin > > Reviewed By: jstolarek, austin > > Subscribers: jstolarek, thomie, carter > > Differential Revision: https://phabricator.haskell.org/D533 > > GHC Trac Issues: #8815 > > > >--------------------------------------------------------------- > > 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6 > compiler/typecheck/TcPat.lhs | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/compiler/typecheck/TcPat.lhs b/compiler/typecheck/TcPat.lhs > index 3b7b5df..58e8bae 100644 > --- a/compiler/typecheck/TcPat.lhs > +++ b/compiler/typecheck/TcPat.lhs > @@ -796,7 +796,8 @@ tcDataConPat penv (L con_span con_name) data_con pat_ty arg_pats thing_inside > ; gadts_on <- xoptM Opt_GADTs > ; families_on <- xoptM Opt_TypeFamilies > ; checkTc (no_equalities || gadts_on || families_on) > - (ptext (sLit "A pattern match on a GADT requires GADTs or TypeFamilies")) > + (text "A pattern match on a GADT requires the" <+> > + text "GADTs or TypeFamilies language extension") > -- Trac #2905 decided that a *pattern-match* of a GADT > -- should require the GADT language flag. > -- Re TypeFamilies see also #7156 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Partial type signatures validate failures
by Edward Z. Yang 29 Nov '14

29 Nov '14

I get these fails: TEST="overloadedlistsfail03 overloadedlistsfail05 sigof02dt sigof02dmt annfail07 FD3 T5689 T7696 T5978 FDsFromGivens tcfail178 tcfail014 T8603 tcfail143 tcfail200 T9612 tcfail159 T7368 T5570 T6069 T5691 T7368a T8262 T7851 T8392a T5246 tcfail123 tcfail122 tcfail090 mc24 mc25 mc22 mc23 T3950 tcfail165 T8142 T5462Yes1 T5462Yes2 T3169 SimpleFail5b T3330c T5439 T7729 T7354a T7354 T7729a T7786" Mostly stderr changes. Edward

1 0

Proposal: Improving the LLVM backend by packaging it
by Austin Seipp 28 Nov '14

28 Nov '14

Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. Needless to say, the situation right now isn't so hot: we have no commitment to version support, two major versions are busted, others are seriously buggy, and yet there are lots of things we could improve on. So I give you a proposal, from a few of us to you all, about improving it: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend I won't repeat what's on the wiki page too much, but the TL;DR version is: we should start packaging a version of LLVM, and shipping it with e.g. binary distributions of GHC. It's just a lot better for everyone. I know we're normally fairly hesitant about things like this (shipping external dependencies), but I think it's the only sane thing to do here, and the situation is fairly unique in that it's not actually very complicated to implement or support, I think. We'd like to do this for 7.12. I've also wrangled some people to help. Those people know who they are (because they're CC'd), and I will now badger them into submission until it is fixed for 7.12. Please let me know what you think. PS. Joachim, I would be particularly interested in upstream needs for Debian, as I know of their standard packaging policy to not duplicate things. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 20

let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
by Carter Schonwald 27 Nov '14

27 Nov '14

ok, i'm getting a let/app invariant failure when i build my test case with O1 or O2 but not without http://lpaste.net/114881 any help would be appreciated on how to address that On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > yup, i have that! > > wrapFetch prefetchValue0# (error "this shouldn't get evaluated") > > in the test suite! > > in contrast > wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated") > does explode > > shall I add a "should fail" test with the latter? (it doesn't seem > worthwhile) > > On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > >> Maybe test for laziness in the argument by just putting something in that >> goes boom when forced, e.g. 'undefined'? >> >> >> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald < >> carter.schonwald(a)gmail.com> wrote: >> >>> Hey All, >>> as part of trying to get some fixups for how prefetch works into 7.10, >>> i'm adding a "prefetchValue" primop that prefetchs the memory location >>> of a lifted heap value >>> >>> namely >>> >>> several operations of the following form >>> >>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp >>> a -> State# s -> State# s >>> with strictness = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] >>> topRes } >>> >>> I'd like some feedback on the strictness information design by someone >>> who's familiar with how that piece of GHC. the idea being that >>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it >>> just does a prefetch on the heap location, which may or may not be >>> evaluated). >>> >>> https://phabricator.haskell.org/D350 >>> >>> is the code in question. And i *believe* i'm testing for being lazy in >>> that argument correctly. >>> >>> thoughts? >>> >>> many thanks! >>> -Carter >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >

2 9