- ghc-devs - Haskell.org

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

RE: [commit: ghc] master: Use deterministic maps for FamInstEnv (9858552)
by Simon Peyton Jones 07 Jul '16

07 Jul '16

| | -type FamInstEnv = UniqFM FamilyInstEnv -- Maps a family to its | instances | +type FamInstEnv = UniqDFM FamilyInstEnv -- Maps a family to its | +instances | -- See Note [FamInstEnv] Bartosz, could you add your comment from the commit (or variant thereof) as a comment to this type definition, so we know WHY you are using UniqDFM here? Thanks Simon We turn FamInstEnvs into lists in some places which don't directly affect the ABI. That happens in family consistency checks and when producing output for `:info`. Unfortunately that nondeterminism is nonlocal and it's hard to tell locally what it affects. Furthermore the envs should be relatively small, so it should be free to use deterministic maps here. Testing with nofib and ./validate detected no difference between UniqFM and UniqDFM. GHC Trac: #4012

1 0

Windows is still broken
by Simon Peyton Jones 05 Jul '16

05 Jul '16

Simon, Windows is still broken. Do you want me to revert both patches, or will you? Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_thr_debug\" -optc-DWINVER=0x06000100 -static -optc-DTHREADED_RTS -optc-DDEBUG -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -O0 -Wnoncanonical-monad-instances -c rts/Linker.c -o rts/dist/build/Linker.thr_debug_o In file included from rts\Linker.c:13:0: error: rts\Linker.c: In function 'ocTryLoad': rts\Linker.c:2566:55: error: error: pointer type mismatch in conditional expression [-Werror] oc->archiveMemberName : oc->fileName)); ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ rts\Linker.c:2564:33: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 2 has type 'void *' [-Werror=format=] IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n", ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' failed make[1]: *** [rts/dist/build/Linker.debug_o] Error 1 make[1]: *** Waiting for unfinished jobs.... In file included from rts\Linker.c:13:0: error: rts\Linker.c: In function 'ocTryLoad': rts\Linker.c:2566:55: error: error: pointer type mismatch in conditional expression [-Werror] oc->archiveMemberName : oc->fileName)); ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ rts\Linker.c:2564:33: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 2 has type 'void *' [-Werror=format=] IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n", ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.thr_debug_o' failed make[1]: *** [rts/dist/build/Linker.thr_debug_o] Error 1 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 /cygdrive/c/code/HEAD$ git log -2 rts/Linker.c commit 01f449f4ffd2c4f23bfe5698b9f1b98a86276900 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Mon Jul 4 10:56:04 2016 +0100 Fix 32-bit build failures commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Jun 29 21:50:18 2016 +0100 Linker: some extra debugging / logging

2 1

Heads up LLVM 3.8
by Erik de Castro Lopo 05 Jul '16

05 Jul '16

HI all, This is just a heads up that git HEAD will soon be switch to LLVM 3.8. The Phab patch is here: https://phabricator.haskell.org/D2382 I suspect the ghc-8.0 branch will continue to use LLVM 3.7 for all the 8.0 releases. I also suspect that LLVM 3.9 will be released (and that we will switch to it) before the first RC release of 8.2. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0