November 2014 - ghc-devs

ANNOUNCE: GHC 7.8.4 Release Candidate 1
by Austin Seipp 14 Dec '14

14 Dec '14

We are pleased to announce the first release candidate for GHC 7.8.4: https://downloads.haskell.org/~ghc/7.8.4-rc1/ This includes the source tarball and bindists for 64bit Linux. Binary builds for other platforms will be available shortly. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.8.4 release sometime in the next few weeks. 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/

13 18

Fwd: Garbage collection
by Facundo Domínguez 13 Dec '14

13 Dec '14

Hello, 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 Desugars to: g :: String g = "hello" main = deRefStaticPtr (StaticPtr (StaticName "" "Main" "g")) >>= putStrLn In principle, there is nothing stopping the garbage collector from reclaiming the closure of `g` before it is dynamically looked up. 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 This solution could be temporal though, until we implement the so called static pointer table, which would keep the values alive. Would you have any comments about such a solution or maybe would you advice some other alternative? Thanks, Facundo [1] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers

5 6

Keeping the "Newcomers" wiki page alive
by Jan Stolarek 02 Dec '14

02 Dec '14

Last year Richard created a wiki page for newcomers: https://ghc.haskell.org/trac/ghc/wiki/Newcomers One of assumptions was to store a list of low hanging fruits that newcomers can tackle: https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug But that list is far from exhaustive. Here's where your help is needed. Please remember that this page exists and whenever you report or encounter a simple bug or feature request please add it to the list on Newcomers page. Thanks. Janek

8 14

Possible error with strict_mark in Parser.y
by Alan & Kim Zimmerman 02 Dec '14

02 Dec '14

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

3 2

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

02 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

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

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

01 Dec '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 29 Nov '14

29 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