Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

[Ben Gamari-3]

Markus Trippelsdorf <[hidden email]> 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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[George Colpitts]

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

On Wed, May 17, 2017 at 1:44 PM George Colpitts <[hidden email]> wrote:

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

On Wed, May 17, 2017 at 10:26 AM Ben Gamari <[hidden email]> wrote:

George Colpitts <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users