Hi Ben I built from source and ran the tests on my Mac and found some problems. I'm not sure if the failing tests have been ran successfully by others on this platform. I did "make slowtest". Maybe the problem only happens on my machine. I'm new to running the testsuite and not sure how the sleep settings on my computer affect long running computations. - If I want to run a long running test such as "make slowtest" overnight will my computer go to sleep preventing the test from running? i.e. should I invoke it with something like "caffeinate -i make slowtest" ? I almost didn't run the tests assuming they had been run as part of the release process but then I guessed that maybe slowtest had not been run. It would be a pain but would it be worth documenting which tests had been run on which platforms? I assume I should file a bug for the following? make TEST=dynamic-paper WAY=profasm ... =====> dynamic-paper(profasm) 1 of 1 [0, 0, 0] cd "./dependent/should_compile/dynamic-paper.run" && "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 143842 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(profasm) Unexpected results from: TEST="dynamic-paper" SUMMARY for test run started at Wed May 17 08:19:59 2017 ADT 0:00:06 spent to go through 1 total tests, which gave rise to 5 test cases, of which 4 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) It fails with -fsimpl-tick-factor=1000 also: make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000' ... cd "./dependent/should_compile/dynamic-paper.run" && "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fsimpl-tick-factor=1000 -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1438402 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(profasm) Unexpected results from: TEST="dynamic-paper" SUMMARY for test run started at Wed May 17 08:29:43 2017 ADT 0:00:35 spent to go through 1 total tests, which gave rise to 5 test cases, of which 4 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) Cheers George On Mon, May 15, 2017 at 11:48 PM Ben Gamari wrote:

Hello everyone,

The GHC team is very pleased to announce the second candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at

https://downloads.haskell.org/~ghc/8.2.1-rc2/

This is the second of what will likely be either two or three release candidates leading up the final 8.2.1 release. This release will feature,

* A new type-indexed Typeable implementation

* The long awaited Backpack

* Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms

* Overloaded record fields

* Improved compiler performance

* Better code generation through more robust tracking of join points

* Compact regions for more efficient garbage collection and serialization

* Better support for machines with non-uniform memory architectures

* More robust support for levity (e.g. RuntimeRep) polymorphism

* A simple interface for streaming eventlog data from live processes

* Further refinement of DWARF support

This candidate fixes most of the issues present in release candidate one including,

* #13233: typePrimRep panic while compiling GHC with profiling enabled * #13509: type error involving unboxed tuples * #13426: compile-time memory-usage regression * #13560: Windows binary distributions carry absolute paths to toolchain * #13585: Control.Lens.Wrapped.ala causes compiler panic * #13623: Join points produce bad code for stream fusion

As always, please let us know if you have difficulty. Thanks to everyone who has contributed!

Happy testing,

- Ben _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hi, I'm trying to build an app with the new release candidate and I'm running into a couple of issues, some which I can fix or workaround, some are worrisome and others are blocking me. I'm using Nix, if that matters. The fixable --------------- - The expected too strict version bounds. Worked around using doJailbreak, will send PRs to the respective packages with relaxed bounds. - A weird kind error when using ConstraintKinds in a propietary package which didn't manifest itself with ghc < 8.2: src/Sigym4/Propag/Types.hs:1071:4: error: • Expected a type, but ‘(PropagIOConstraint l a, Missing (PropagIOVector l) (PropagIONullable l a), Elem (PropagIONullable l a) ~ a)’ has kind ‘Constraint’ • In the type ‘((PropagIOConstraint l a, Missing (PropagIOVector l) (PropagIONullable l a), Elem (PropagIONullable l a) ~ a))’ In the type declaration for ‘CanSerialize’ | 1071 | (( PropagIOConstraint l a | ^^^^^^^^^^^^^^^^^^^^^^^^... src/Sigym4/Propag/Types.hs:1077:4: error: • Expected a constraint, but ‘(CanSerialize l Double, CanSerialize l Int16)’ has kind ‘*’ • In the type ‘(CanSerialize l Double, CanSerialize l Int16)’ In the type declaration for ‘CanSerializePropagTypes’ | 1077 | ( CanSerialize l Double | ^^^^^^^^^^^^^^^^^^^^^^^... I cannot link to the source for this package since it belongs to my employer but I think that the interesting code is: type CanSerialize l a = ( PropagIOConstraint l a , Missing (PropagIOVector l) (PropagIONullable l a) , Elem (PropagIONullable l a) ~ a ) where PropagIOConstraint, PropagIONullable and PropagIOVector are "standalone" type families and Elem is an associated type family (not from IsList) Both errors disappear if I give an explicit kind signature like this: "type CanSerialize l a = (..... :: Constraint)". Is this expected behaviour? Should I try to isolate and open a ticket? The worrisome -------------------- - I had to disable the tests for two packages since they seem to "hang" (ie: they never finish running and don't seem to consume any CPU time). These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix environmental issue, I'm not sure. Can anyone reproduce this? The blockers ----------------- - I can't manage to install several packages which include executables (namely, update-nix-fetchgit and snap-server, for the moment) because Cabal says that it cannot find the source for the main module of the executables: "Setup: can't find source for Main in ." It seems that the "hs-source-dir" directive in the .cabal file is not being honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on how can I fix it? Thanks very much for GHC, btw :) Alberto On Tue, May 16, 2017 at 4:47 AM, Ben Gamari wrote:

Hello everyone,

The GHC team is very pleased to announce the second candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at

https://downloads.haskell.org/~ghc/8.2.1-rc2/

This is the second of what will likely be either two or three release candidates leading up the final 8.2.1 release. This release will feature,

* A new type-indexed Typeable implementation

* The long awaited Backpack

* Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms

* Overloaded record fields

* Improved compiler performance

* Better code generation through more robust tracking of join points

* Compact regions for more efficient garbage collection and serialization

* Better support for machines with non-uniform memory architectures

* More robust support for levity (e.g. RuntimeRep) polymorphism

* A simple interface for streaming eventlog data from live processes

* Further refinement of DWARF support

This candidate fixes most of the issues present in release candidate one including,

* #13233: typePrimRep panic while compiling GHC with profiling enabled * #13509: type error involving unboxed tuples * #13426: compile-time memory-usage regression * #13560: Windows binary distributions carry absolute paths to toolchain * #13585: Control.Lens.Wrapped.ala causes compiler panic * #13623: Join points produce bad code for stream fusion

As always, please let us know if you have difficulty. Thanks to everyone who has contributed!

Happy testing,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs