July 2016 - ghc-devs - Haskell.org

Parser changes for supporting top-level SCC annotations
by Ömer Sinan Ağacan 19 Jul '16

19 Jul '16

I'm trying to support SCCs at the top-level. The implementation should be trivial except the parsing part turned out to be tricky. Since expressions can appear at the top-level, after a {-# SCC ... #-} parser can't decide whether to reduce the token in `sigdecl` to generate a `(LHsDecl (Sig (SCCSig ...)))` or to keep shifting to parse an expression. As shifting is the default behavior when a shift/reduce conflict happens, it's always trying to parse an expression, which is always the wrong thing to do. Does anyone have any ideas on how to handle this? Motivation: Not having SCCs at the top level is becoming annoying real quick. For simplest cases, it's possible to do this transformation: f x y = ... => f = {-# SCC f #-} \x y -> ... However, it doesn't work when there's a `where` clause: f x y = <t is in scope> where t = ... => f = {-# SCC f #-} \x y -> <t is out of scope> where t = ... Or when we have a "equation style" definition: f (C1 ...) = ... f (C2 ...) = ... f (C3 ...) = ... ... (usual solution is to rename `f` to `f'` and define a new `f` with a `SCC`)

4 6

RE: [commit: ghc] wip/generics-flip: Flip around imports of GHC.Generics (cb12bdf)
by Simon Peyton Jones 18 Jul '16

18 Jul '16

I don’t object to this, but I suspect that it's just covering up some other bug. Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 18 July 2016 14:57 To: ghc-commits(a)haskell.org Subject: [commit: ghc] wip/generics-flip: Flip around imports of GHC.Generics (cb12bdf) Repository : ssh://git@git.haskell.org/ghc On branch : wip/generics-flip Link : https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell… >--------------------------------------------------------------- commit cb12bdf942df5e61771d69bbb6049f3b23ed580c Author: Ben Gamari <ben(a)smart-cactus.org> Date: Mon Jul 18 15:54:16 2016 +0200 Flip around imports of GHC.Generics Previously we had, GHC.Generics imports GHC.Ptr Data.Monoid imports GHC.Generics Data.Foldable imports GHC.Generics Data.Foldable imports Data.Monoid Prelude imports Data.Foldable Unfortunately this meant that any program importing Prelude (essentially all programs) would end up pulling in GHC.Generics and GHC.Ptr unnecessarily. Hopefully helps #12367. >--------------------------------------------------------------- cb12bdf942df5e61771d69bbb6049f3b23ed580c libraries/base/Data/Foldable.hs | 36 ---------------------- libraries/base/Data/Monoid.hs | 19 +++++------- libraries/base/GHC/Generics.hs | 67 +++++++++++++++++++++++++++++++++++++++-- 3 files changed, 72 insertions(+), 50 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 cb12bdf942df5e61771d69bbb6049f3b23ed580c _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…

2 1

Slow validate currently fails
by Ömer Sinan Ağacan 15 Jul '16

15 Jul '16

Hi all, Just wanted to say that HEAD (37aeff6) doesn't currently pass validate (in slow mode). See details below. ==== STAGE 2 TESTS ==== Unexpected results from: TEST="haddock.Cabal hpc_fork T4114c T4114d dynamic-paper" SUMMARY for test run started at Fri Jul 15 11:19:15 2016 UTC 0:43:36 spent to go through 5264 total tests, which gave rise to 21166 test cases, of which 3817 were skipped 197 had missing libraries 16928 expected passes 219 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures 1 unexpected stat failures Unexpected failures: /tmp/ghctest-7VEJbb/test spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) /tmp/ghctest-7VEJbb/test spaces/./driver/T4114c.run T4114c [bad exit code] (ghci) /tmp/ghctest-7VEJbb/test spaces/./driver/T4114d.run T4114d [bad exit code] (ghci) /tmp/ghctest-7VEJbb/test spaces/../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) Unexpected stat failures: /tmp/ghctest-7VEJbb/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) It validates in fast mode though (haven't tried the default mode).

1 0

Windows build
by Simon Peyton Jones 12 Jul '16

12 Jul '16

I've completed a successful build on my Surface Book! Thank you. One last glitch. I'm getting the validate failure bellow. No other test requires gcc in my path. GHC itself carefully navigates to its own private gcc. Do we really want this family of tests (half a dozen variants of T11223) to rely on some random gcc, which might or might not be the same as GHC is using? Shouldn't we use 'ghc foo.c'? Simon =====> T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s --no-print-directory t_11223_simple_unused_duplicate_lib Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: gcc: command not found make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127

3 3

Rethinking GHC's approach to managing proposals
by Ben Gamari 11 Jul '16

11 Jul '16

Hello everyone, Recently there has been a fair bit of discussion[1,2] around the mechanisms by which proposed changes to GHC are evaluated. While we have something of a formal proposal protocol [3], it is not clearly documented, inconsistently applied, and may be failing to serve a significant fraction of GHC's potential contributor pool. Over the last few weeks, I have been doing a fair amount of reading, thinking, and discussing to try to piece together a proposal scheme which better serves our community. The resulting proposal [4] is strongly inspired by the RFC process in place in the Rust community [5], the leaders of which have thought quite hard about fostering community growth and participation. While no process is perfect, I feel like the Rust process is a good starting point for discussion, offering enough structure to guide new contributors through the process while requiring only a modest investment of developer time. To get a sense for how well this will work in our community, I propose that we attempt to self-host the proposed process. To this end I have setup a ghc-proposals repository [6] and opened a pull request for discussion of the process proposal [4]. Let's see how this goes. Cheers, - Ben [1] https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/ [2] https://www.reddit.com/r/haskell/comments/4isua9/ghc_development_outsidein/ [3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures [4] https://github.com/ghc-proposals/ghc-proposals/pull/1/files?short_path=14d6… [5] https://github.com/rust-lang/rfcs [6] https://github.com/ghc-proposals/ghc-proposals

3 2

T11758 testcase help needed
by Alex Dzyoba 11 Jul '16

11 Jul '16

Hi, all! I was working on #11758, which is about dropping binutils<2.17 hack, and while it was relatively easy to remove the hack itself, I'm not sure how to add a test case for it. As I understand, after removing the aforementioned hack, native codegen now shouldn't generate sign extension. So my question is how to test it? Should it be Cmm file that will be tested with `compile_cmp_asm` like memcpy in "codeGen/should_gen_asm/memcpy.cmm"? Or should I stick to the Haskell test? Thanks, Alex Dzyoba

3 2

What fixed this?
by Ben Gamari 11 Jul '16

11 Jul '16

Does anyone know which commit fixed the testcase in #12381 on master? This testcase currently fails on 8.0.1 and it would be nice if we could merge the fix for 8.0.2. Cheers, - Ben

1 0

testsuite: Test named X but want to use Y.hs as source
by Ömer Sinan Ağacan 10 Jul '16

10 Jul '16

I have some number of test programs that I compile and run as usual. I also want to run them using GHCi, with -fobject-code. So I tried this: def just_ghci( name, opts ): opts.only_ways = ['ghci'] test('unboxedsums1.ghci', just_ghci, compile_and_run, ['-fobject-code']) Now, I don't have a file named `unboxedsums1.ghci.hs`, I want to use `unboxedsums1.hs` and I already have a test named `unboxedsums1`. Any ideas how to do this? Thanks

1 0

RE: [Diffusion] [Committed] rCABAL2863a628f857: Add two local type signatures
by Simon Peyton Jones 08 Jul '16

08 Jul '16

I don't believe I made this commit, or the ones around it. Mysterious; I hope I'm not being impersonated! Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 08 July 2016 20:43 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Committed] rCABAL2863a628f857: Add two local type signatures simonpj committed rCABAL2863a628f857: Add two local type signatures (authored by simonpj). Add two local type signatures I'm adding these type signatures to satisfy the "do not generalise local let/where" rule that GHC is taking on. The signatures are clearly correct, but I was surprised at the polymorphism needed. For example parseOptVersion :: ReadP r Version parseOptVersion = parseQuoted ver <++ ver where ver :: ReadP r Version ver = parse <++ return noVersion noVersion = Version{ versionBranch=[], versionTags=[] } Note that 'ver' really is called at two different types! That in turn is because of the type of (<++) (<++) :: ReadP a a -> ReadP r a -> ReadP r a (+++) :: ReadP r a -> ReadP r a -> ReadP r a Note the "a a" in the first arg, which is very unusual. For example, compare the type of (+++). Changing it to match the type of (+++) makes ReadP fail to compile, though, so I assume it's right as it stands. But surely this deserves a comment?! AFFECTED FILES /Distribution/ParseUtils.hs USERS simonpj (Author) COMMIT https://phabricator.haskell.org/rCABAL2863a628f857 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj

2 1

Msys2 64: progress
by Simon Peyton Jones 08 Jul '16

08 Jul '16

Friends I want to thank everyone who has responded - very helpful! Thanks to your help I am making progress * I re-installed msys64 from scratch, this time following the instructions on the GHC wiki rather than the msys2 page. By doing update-core; then pacman -Su; then pacman -Su again, I got a clean install. Very good! Getting a shell between each step is tricky. o The first shell is gotten with mingw64.bat o After update-core, that file is gone; you have to use msys2_shell.cmd I think o After pacman -Su we get mingw64.exe, which we can use thereafter. * My slow-start problem appears to have gone away. I adopted the fix from you may be hitting a long standing issue some computers have in which the domain controller is being hit for every invocation of commands, causing a slowdown https://github.com/Alexpux/MSYS2-packages/issues/138 , Solution 2 from https://gist.github.com/k-takata/9b8d143f0f3fef5abdab<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.githu…> seems to fix it for most people. I am not absolutely certain that was the problem, but things seem ok now. I also excluded c:/msys64 from my antivirus check. * Emacs too is now working normally. Hurrah So that's all good. Now I'm stuck on the windows tarballs download thing. I get configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... File not found - *.tar.xz I tried both the things described on the wiki<https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows>: Pacman -R mingw-w64-x86_64-curl error: target not found: mingw-w64-x86_64-curl For the other I did the two mkdir things, and tried ./configure again, but got the same error message as above. So I'm stuck again, but further forward. Can you advise me? Thanks! Simon

4 16