July 2015 - ghc-devs - Haskell.org

Re: GHC 7.10.2 plans
by Karel Gardas 10 Jul '15

10 Jul '15

Hi Ben, count with me. I always thought it may be a good idea to allow some time to builders to do their job. For me this means few hours for i386/amd64 solaris build and test and unfortunately about a day (~10 hours) of noisy run for sparc solaris build but I'll do it last time since I hope 7.12 will have fixed SPARC NCG which should cut the time to half or I'll buy faster sparc gear. :-) Generally speaking Monday morning is the best time for me. Then Wednesday. Cheers, Karel On 07/10/15 04:46 PM, Ben Gamari wrote: > Hi GHCers, > > So 7.10.2 is, believe it or not, slowly converging. After finding and > fixing a number of regressions since 7.10.1 (including, unfortunately, a > few only found this week), I think we finally have a source tree that > could possibly be called 7.10.2. > > I have been in communication with Herbert, who has built .debs from a > snapshot of the ghc-7.10 branch. They are currently available on his > PPA [1] (see the ghc-7.10.2-7.10.1.20150710-0 debs). Michael will be > using these to do a trial-build of Stackage. Hopefully by Monday we > will have a pretty good idea of whether the tree is fit for release. > > When all of this happens we will be ready to cut the release. As usual, > I will be doing binary builds for 32- and 64-bit Linux and Windows. As I > understand it, a subset of you have in the past offered binary builds > for other platforms, > > * Mark: Mac OS X, some Haskell Platform platforms > * Pali: FreeBSD > * Karel: Solaris > > Would you be willing to do this again? Ideally we would have these > packages available the day of the release. Assuming we can get a final, > Stackage-validated source tarball by Monday, when do you think we could > have all of these prepared? > > I'm willing to hold off announcing the release until late next week or > all of these releases are available, whichever happens first (unless > there is widespread agreement within this group that this is not enough > time). > > Cheers, > > - Ben > > > [1] https://launchpad.net/~hvr/+archive/ubuntu/ghc/ >

1 0

validate slow failures on os x 7.10 branch
by Carter Schonwald 10 Jul '15

10 Jul '15

hey all, I ran ./validate on 7.10 branch commit 51de9342b915688f1222760c74b9a63e44c533d3 earlier today heres the summary at the end, are these the expected test failures ? Unexpected results from: TEST="setnumcapabilities001 allocLimit4 conc012 conc034 joao-circular T7861 tcrun023 TH_StaticPointers sigcabal01 readRun004 CgStaticPointers StaticArraySize ghci024 mul2 quotRem2 add2 array001 retc001 dsrun014 DsStaticPointers GcStaticPointers linker_unload ListStaticPointers T7919 retc002 T3245 T2497 T10489 T2276_ghci topHandler03 haddock.Cabal" OVERALL SUMMARY for test run started at Fri Jul 10 12:04:03 2015 EDT 0:27:43 spent to go through 4451 total tests, which gave rise to 17100 test cases, of which 3620 were skipped 306 had missing libraries 12957 expected passes 165 expected failures 0 caused framework failures 0 unexpected passes 51 unexpected failures 1 unexpected stat failures Unexpected failures: ../../libraries/array/tests array001 [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad exit code] (ghci) codeGen/should_run StaticArraySize [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc034 [exit code non-0] (optasm,threaded2,dyn,optllvm) concurrent/should_run setnumcapabilities001 [bad stderr] (threaded2) deSugar/should_run DsStaticPointers [bad exit code] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) perf/should_run T3245 [bad stdout or stderr] (ghci) programs/joao-circular joao-circular [bad stdout or stderr] (ghci) rts GcStaticPointers [bad exit code] (ghci) rts ListStaticPointers [bad exit code] (ghci) rts T7919 [bad exit code] (optasm,threaded1,dyn,optllvm) rts linker_unload [bad exit code] (normal) th TH_StaticPointers [bad exit code] (ghci) typecheck/should_compile T10489 [exit code non-0] (normal,hpc,optasm,optllvm) typecheck/should_compile T2497 [exit code non-0] (optasm,optllvm) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) typecheck/should_run tcrun023 [bad stdout or stderr] (ghci) Unexpected stat failures: perf/haddock haddock.Cabal [stat not good enough] (normal) == Start post-testsuite package check Timestamp 2015-07-10 16:04:01 UTC for /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d/package.cache Timestamp 2015-07-10 16:04:01 UTC for /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d (same as cache) using cache: /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d/package.cache db stack: ["/Users/v645736/.ghc/x86_64-darwin-7.10.1.20150710/package.conf.d","/Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d"] modifying: Nothing flag db stack: ["/Users/v645736/.ghc/x86_64-darwin-7.10.1.20150710/package.conf.d","/Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d"] == End post-testsuite package check

1 0

Building a minimal/essential GHC
by Jakub Zalewski 08 Jul '15

08 Jul '15

Dear all, I am working on porting GHC to [native client]( https://developer.chrome.com/native-client) which has some degree of POSIX-compliance. I was thinking about building just the minimal/most essential parts of GHC that is enough to compile simple Haskell programs. I wanted to ask which parts of GHC are the most essential and sufficient enough to compile a simple Haskell program, for instance to compile `main = putStrLn "Hello, world!"`? I also wanted to ask how to force a GHC build without a particular package that comes by default, for instance how to build GHC without the `unix` package? Best wishes, Jakub

2 3

10527/5113
by Simon Peyton Jones 08 Jul '15

08 Jul '15

Ben I have pushed a new fix to the 7.10 branch, onto branch wip/T10572-2. (Don't apply this to HEAD.) Can you try it. I get validate failures as below, but I am hard pressed to see how they could be related. (The perf changes may be.) Simon Unexpected failures: codeGen/should_run T10414 [exit code non-0] (threaded2) driver T8959a [bad stderr] (normal) ghci/scripts T9878b [bad stderr] (ghci) simplCore/should_compile T4945 [bad stdout] (normal) th T10279 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T9961 [stat too good] (normal) perf/should_run T4830 [stat not good enough] (normal) perf/should_run T7436 [stat not good enough] (normal)

1 0

Windows broken -- again
by Simon Peyton Jones 08 Jul '15

08 Jul '15

I get this breakage on Windows. I have no idea who is responsible. Can someone fix? It looks as if throwIOIO really is always unused. Simon utils\ghc-pkg\Main.hs:1982:1: Warning: Defined but not used: 'throwIOIO'

1 0

Right way to turn off dynamic linking in build.mk
by Johan Tibell 07 Jul '15

07 Jul '15

Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) This line make me worry that if I don't put DYNAMIC_GHC_PROGRAMS = NO in the right place in build.mk it wont "take". There's also this one: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif Seeing this makes me wonder if DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO is enough or if the build system still sniffs out the fact that my platform supports dynamic linking. Could someone please give an authoritative answer to how to turn off dynamic linking? -- Johan

4 5

RE: [commit: ghc] master: Use -fno-warn-unused-imports instead of hiding `ord` (c875b08)
by Simon Peyton Jones 06 Jul '15

06 Jul '15

Add a comment, please, I beg you! In five years time no one will have a clue why that `-fno-warn-unused-imports` flag is there. It's a small thing I know, but the principle is: whenever adding a line of code whose purpose is not locally obvious, explain by adding a comment, or Note, or Trac reference, or all three. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 04 July 2015 23:44 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Use -fno-warn-unused-imports instead of | hiding `ord` (c875b08) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/c875b085d95377771a5b3cf0f44b | b2910dbfe966/ghc | | >--------------------------------------------------------------- | | commit c875b085d95377771a5b3cf0f44bb2910dbfe966 | Author: Thomas Miedema <thomasmiedema(a)gmail.com> | Date: Sat Jul 4 18:20:06 2015 +0200 | | Use -fno-warn-unused-imports instead of hiding `ord` | | This is more future proof. Maybe later versions of Alex won't | `import | Data.Char (ord)` anymore. | | | >--------------------------------------------------------------- | | c875b085d95377771a5b3cf0f44bb2910dbfe966 | compiler/cmm/CmmLex.x | 3 ++- | compiler/parser/Lexer.x | 3 ++- | 2 files changed, 4 insertions(+), 2 deletions(-) | | diff --git a/compiler/cmm/CmmLex.x b/compiler/cmm/CmmLex.x index | cb71c7d..fca5a1e 100644 | --- a/compiler/cmm/CmmLex.x | +++ b/compiler/cmm/CmmLex.x | @@ -13,6 +13,7 @@ | { | {-# OPTIONS_GHC -fno-warn-unused-matches #-} {-# OPTIONS_GHC -fno- | warn-unused-binds #-} | +{-# OPTIONS_GHC -fno-warn-unused-imports #-} | {-# OPTIONS_GHC -fno-warn-tabs #-} | {-# OPTIONS_GHC -fno-warn-missing-signatures #-} | -- The above warning suppression flags are a temporary kludge. | @@ -37,7 +38,7 @@ import Util | --import TRACE | | import Data.Word | -import Data.Char hiding (ord) | +import Data.Char | } | | $whitechar = [\ \t\n\r\f\v\xa0] -- \xa0 is Unicode no-break space | diff --git a/compiler/parser/Lexer.x b/compiler/parser/Lexer.x index | 8e6e67d..df7347e 100644 | --- a/compiler/parser/Lexer.x | +++ b/compiler/parser/Lexer.x | @@ -45,6 +45,7 @@ | {-# LANGUAGE BangPatterns #-} | {-# OPTIONS_GHC -fno-warn-unused-matches #-} {-# OPTIONS_GHC -fno- | warn-unused-binds #-} | +{-# OPTIONS_GHC -fno-warn-unused-imports #-} | {-# OPTIONS_GHC -fno-warn-tabs #-} | {-# OPTIONS_GHC -fno-warn-missing-signatures #-} {-# OPTIONS_GHC - | fno-warn-overlapping-patterns #-} @@ -84,7 +85,7 @@ import | Control.Applicative #endif import Control.Monad import Data.Bits - | import Data.Char hiding (ord) | +import Data.Char | import Data.List | import Data.Maybe | import Data.Word | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

1 0

Abstract FilePath Proposal
by Herbert Valerio Riedel 05 Jul '15

05 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello *, What? ===== We (see From: & CC: headers) propose, plain and simple, to turn the currently defined type-synonym type FilePath = String into an abstract/opaque data type instead. Why/How/When? ============= For details (including motivation and a suggested transition scheme) please consult https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath Suggested discussion period: 4 weeks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb HjIPRrJbVK9AABo4AZ/Y =lg0o -----END PGP SIGNATURE-----

20 33

Re: Abstract FilePath Proposal
by Sven Panne 04 Jul '15

04 Jul '15

2015-07-04 22:48 GMT+02:00 <amindfv(a)gmail.com>: > I'd argue that Haskell and GHC's history clearly shows we've answered that > question and that overalll we value frequent small breaking changes over > giant change roadblocks like Perl's or Python's. [...] > I'm not sure that "value" is the right word. My impression is more that this somehow happened accidentally and was not the result of careful planning or broad consensus. And even if in the past this might have been the right thing, I consider today's state of affairs as something totally different: In the past it was only GHC, small parts of the language or a handful of packages (or even just a few modules, in the pre-package times). Today every change resonates through thousands of packages on Hackage and elsewhere. IMHO some approach similar to e.g. C++03 => C++11 => C++14 makes more sense in world like this than a constantly fluctuating base, but others might see this differently. My fear is that this will inevitably lead to the necessity of having an autoconf-like feature detection machinery to compile a package, and looking at a few packages, we are already halfway there. :-/

1 0

ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Austin Seipp 04 Jul '15

04 Jul '15

We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so 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/

6 8