Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[Alberto Valverde]

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

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[George Colpitts]

Done: https://ghc.haskell.org/trac/ghc/ticket/13715#ticket

On Wed, May 17, 2017 at 1:44 PM George Colpitts 
wrote:

> Yes, I agree, will file a bug this evening.
>
> On Wed, May 17, 2017 at 10:26 AM Ben Gamari  wrote:
>
>> George Colpitts  writes:
>>
>> > 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.
>> >
>> Currently Harbormaster only runs `make test`, not `make slowtest`.
>> Consequently, `slowtest` is generally rather broken, even on Linux.
>> Every once in a while I look at it and try to pare down the failures,
>> but it's an up-hill battle.
>>
>> > 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" ?
>> >
>> That sounds right to me.
>>
>> > 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 currently don't validate the binary distribution tarballs. Instead I
>> judge validation state from Harbormaster's testing of the ghc-8.2
>> branch.
>>
>> Over the summer we intend on revamping our CI infrastructure, which
>> should make it easier to do nightly runs of slowtest (and perhaps
>> provide nightly or even per-commit binary distributions).
>>
>> > I assume I should file a bug for the following?
>> >
>> That would be great. I had a quick look at this and it looks quite
>> likely that the simplifier is looping: even -fsimpl-tick-factor=1000
>> doesn't succeed. This looks like a real regression.
>>
>> Cheers,
>>
>> - Ben
>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[George Colpitts]

Yes, I agree, will file a bug this evening.

On Wed, May 17, 2017 at 10:26 AM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > 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.
> >
> Currently Harbormaster only runs `make test`, not `make slowtest`.
> Consequently, `slowtest` is generally rather broken, even on Linux.
> Every once in a while I look at it and try to pare down the failures,
> but it's an up-hill battle.
>
> > 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" ?
> >
> That sounds right to me.
>
> > 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 currently don't validate the binary distribution tarballs. Instead I
> judge validation state from Harbormaster's testing of the ghc-8.2
> branch.
>
> Over the summer we intend on revamping our CI infrastructure, which
> should make it easier to do nightly runs of slowtest (and perhaps
> provide nightly or even per-commit binary distributions).
>
> > I assume I should file a bug for the following?
> >
> That would be great. I had a quick look at this and it looks quite
> likely that the simplifier is looping: even -fsimpl-tick-factor=1000
> doesn't succeed. This looks like a real regression.
>
> Cheers,
>
> - Ben
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[Ben Gamari]

George Colpitts  writes:

> 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.
>
Currently Harbormaster only runs `make test`, not `make slowtest`.
Consequently, `slowtest` is generally rather broken, even on Linux.
Every once in a while I look at it and try to pare down the failures,
but it's an up-hill battle.

> 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" ?
>
That sounds right to me.

> 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 currently don't validate the binary distribution tarballs. Instead I
judge validation state from Harbormaster's testing of the ghc-8.2
branch.

Over the summer we intend on revamping our CI infrastructure, which
should make it easier to do nightly runs of slowtest (and perhaps
provide nightly or even per-commit binary distributions).

> I assume I should file a bug for the following?
>
That would be great. I had a quick look at this and it looks quite
likely that the simplifier is looping: even -fsimpl-tick-factor=1000
doesn't succeed. This looks like a real regression.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[George Colpitts]

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 

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[Ben Gamari]

Markus Trippelsdorf  writes:

> On 2017.05.15 at 22:47 -0400, Ben Gamari wrote:
>>
>>
>> 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,
>>
>> As always, please let us know if you have difficulty. Thanks to everyone
>> who has contributed!
>>
>> Happy testing,
>
> Unfortunately xmobar segfaults from time to time when build with
> 8.2.1-rc2, e.g.:
>
Thanks for your report! Segfaults are certainly no good. Do you know
whether these are also reproducible with rc1? What version of xmobar are
you using? What does your configuration look like?

I've started an xmobar built from upstream's master branch with an empty
configuration to see whether this is reproducible locally.

I've opened #13707 to track this.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[ANNOUNCE] GHC 8.2.1 release candidate 2

[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


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users