- ghc-devs - Haskell.org

Arrow notation and GHC 7.10 freeze
by Wolfgang Jeltsch 03 Dec '14

03 Dec '14

Hi, I would like to work on <https://ghc.haskell.org/trac/ghc/ticket/7081>. 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

3 4

New implementation draft for -XStaticPointers
by Facundo Domínguez 02 Dec '14

02 Dec '14

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

1 0

Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)
by Gabor Greif 02 Dec '14

02 Dec '14

Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too? Cheers, Gabor On 12/1/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715fb… > >>--------------------------------------------------------------- > > commit e6a2050ebb6da316aecec66a6795715fbab355ca > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > 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(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 3

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

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