- ghc-devs - Haskell.org

GHC nightly builds?
by Iavor Diatchki 02 May '16

02 May '16

Hello, do we have nightly builds for development versions of GHC somewhere? -Iavor

3 2

Re: GHC nightly builds?
by Ryan Scott 02 May '16

02 May '16

Herbert has an Ubuntu PPA with a ghc-head package that is built on a regular basis: https://launchpad.net/~hvr/+archive/ubuntu/ghc Best, Ryan S.

1 0

Reverted your commit
by Simon Peyton Jones 01 May '16

01 May '16

Simon I reverted your commit https://phabricator.haskell.org/rGHC546f24e4f8a7c086b1e5afcdda624176610cbcf8 because it made every single binary that GHC builds seg-fault on windows. Even main = return () seg-faults. You may want to review and re-commit it. Simon commit 24864ba5587c1a0447beabae90529e8bb4fa117a Author: Simon Marlow <marlowsd(a)gmail.com> Date: Sat Apr 23 22:14:43 2016 +0100 Use __builtin_clz() to implement log_2() A microoptimisation in the block allocator.

3 2

Testsuite change: CLEANUP=1 is now the default
by Thomas Miedema 30 Apr '16

30 Apr '16

Hello devs, by popular request (#9758), the testsuite will now clean up after itself after running the tests, removing generated files, saving you some 10G of diskspace in the worst case. If you want the old behavior back, you can do: ``` $ make test CLEANUP=0 ``` I updated https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running. The cleaning itself is not perfect at the moment; some temporary files are not deleted. I have a solution for this in https://ghc.haskell.org/trac/ghc/ticket/11980 and https://phabricator.haskell.org/D1187. More about that later. Cheers, Thomas

1 0

Re: Bikeshedding request for GHCi's :type
by Johannes Waldmann 29 Apr '16

29 Apr '16

> .. :type should report the real type What about defaulting? Is it real? https://ghc.haskell.org/trac/ghc/ticket/11994 - J.W.

3 3

[ANNOUNCE] GHC 8.0.1 release candidate 4 available
by Ben Gamari 29 Apr '16

29 Apr '16

Hello Haskellers, The GHC team is happy to announce the availability of fourth release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc4/ This is the last of four candidates leading up to the 8.0.1 release, addressing nearly all of the known issues of the previous candidates. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * A variety of other typechecker issues (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell can now produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has improved version checks for libdw (#11820) * Typeable and hs-boot files now interact nicely (#11824) * The build system now checks for the broken Apple `nm` utility (#11823, #11744) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). The build system will check for this condition and request that the tree is configured to use the `nm-classic` utility if found. OS X users running XCode 7.3 are encouraged to open a ticket with Apple so that this issue may be fixed in future XCode releases. If no major issues pop up we expect that this will be the last release candidate before the final release, which we hope to push out in the coming weeks. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers and happy testing, - Ben

3 2

Windows link failure
by Simon Peyton Jones 29 Apr '16

29 Apr '16

OK Windows is back. But all these fail with this error Stderr: /bin/sh: cc: command not found make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127 Simon rts/T11223 T11223_link_order_a_b_2_fail [bad exit code] (normal) rts/T11223 T11223_link_order_a_b_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_2_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_succeed [bad exit code] (normal) rts/T11223 T11223_simple_duplicate_lib [bad exit code] (normal) rts/T11223 T11223_simple_link [bad exit code] (normal) rts/T11223 T11223_simple_link_lib [bad exit code] (normal) rts/T11223 T11223_simple_unused_duplicate_lib [bad exit code] (normal)

2 4

better improvement for nm-classic message?
by Brandon Allbery 28 Apr '16

28 Apr '16

It's slower the first time it is run but should be fast afterward unless you switch active Xcode toolchains, as xcrun caches the result. --with-nm=$(xcrun --find nm-classic) -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

2 1

Every GHC-compiled program seg-fault (HEAD)
by Simon Peyton Jones 27 Apr '16

27 Apr '16

Does anyone feel able to look at https://ghc.haskell.org/trac/ghc/ticket/11988 The symptom is that every single GHC-compiled binary now seg-faults on Windows (with HEAD). That’s pretty serious. Can Travis pinpoint the offending commit? Simon

2 1

Custom Type Error not getting triggered in the nested Type function call
by Magesh B 27 Apr '16

27 Apr '16

Hello, I have partial type function which is invoked by another type function. When the inner type function fails with TypeError, outer type function is not been able to propagate that type error to its caller. As a result of it, I'm getting following error • No instance for (KnownSymbol (NestedPartialTF (TypeError ...))) instead of • Unexpected type @ NestedPartialTF: Char Is this a bug? This behavior seems bit counter-intuitive as to work around, I had to write another (duplicate) type function at the top level to get the desired type error I'm using GHC-8 RC 3 and have attached complete src for reference. Regards, Magesh B

2 1