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 <b...@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-d...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users