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 <ben@well-typed.com> 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