
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
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