From juhpetersen at gmail.com  Tue Feb  2 03:15:21 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Tue, 2 Feb 2016 12:15:21 +0900
Subject: Dropping bzip2 release tarballs?
In-Reply-To: <87r3hl5u60.fsf@smart-cactus.org>
References: <87r3hl5u60.fsf@smart-cactus.org>
Message-ID: <CAEDGBqJibm_6df6OyX9CrvbGf4FRRajxODN9ZciB5Ag6-CDZNw@mail.gmail.com>

On 14 January 2016 at 01:19, Ben Gamari <ben at well-typed.com> wrote:
> tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org?

I don't have a strong opinion about it and understand the desire to
standardize on one archive type.
I use the xz src tarballs myself, but how about continuing to do bz2
tarballs of the src tarballs only? (they are about the same size as
the xz tarballs anyway)
(A lot of small projects even still use tgz... :)

Jens

From david.feuer at gmail.com  Tue Feb  2 03:32:36 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 1 Feb 2016 22:32:36 -0500
Subject: Dropping bzip2 release tarballs?
In-Reply-To: <87r3hl5u60.fsf@smart-cactus.org>
References: <87r3hl5u60.fsf@smart-cactus.org>
Message-ID: <CAMgWh9tOZ52f5Uq7bVOcsF+aZupxB3vrVNSths0UBt3u2RjXOQ@mail.gmail.com>

Does this really strain storage infrastructure? There are only a few
blobs per release. If that's really a problem, sufficiently ancient
ones can presumably be pruned down to a single format without too many
complaints (e.g., if someone wants GHC 7.6, they may not be able to
have their choice of format). Bandwidth seems an entirely legitimate
concern, but thankfully a symmetric one?most users will want to
download the smallest available format, and those who are willing to
pay the extra time to download another likely have a good reason.

On Wed, Jan 13, 2016 at 11:19 AM, Ben Gamari <ben at well-typed.com> wrote:
> tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org?
>       If so, let us know!
>
>
> Hello everyone,
>
> As you may have noticed, a few releases ago we started producing
> xz-compressed binary distributions in addition to the usual bzip2
> tarballs.
>
> While preparing 8.0.1-rc1 it was suggested that we move to distributing
> xz tarballs exclusively. Not only would this move reduce storage and
> bandwidth demands on our infrastructure but it would also simplify the
> job of producing the distributions. Indeed there is plenty of precendent
> for projects who have moved exclusively to xz (the Linux kernel and git
> being two examples).
>
> Of course, these reasons alone aren't sufficient to abandon those who
> might rely on our bzip2 tarballs. If you feel strongly that we should
> continue to distribute bzip2 tarballs, please let us know.
>
> Thanks!
>
> - Your friendly GHC packaging gnomes
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

From ben at well-typed.com  Tue Feb  2 12:04:26 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 02 Feb 2016 13:04:26 +0100
Subject: Dropping bzip2 release tarballs?
In-Reply-To: <CAMgWh9tOZ52f5Uq7bVOcsF+aZupxB3vrVNSths0UBt3u2RjXOQ@mail.gmail.com>
References: <87r3hl5u60.fsf@smart-cactus.org>
 <CAMgWh9tOZ52f5Uq7bVOcsF+aZupxB3vrVNSths0UBt3u2RjXOQ@mail.gmail.com>
Message-ID: <87y4b3b9o5.fsf@smart-cactus.org>

David Feuer <david.feuer at gmail.com> writes:

> Does this really strain storage infrastructure? There are only a few
> blobs per release.
> 
To me the real motivation here is to simplify the distribution
preparation process. Currently I need to worry about producing, signing,
hashing, and uploading two of each tarball. To do this requires a dozen
or so lines of bash source that I'd prefer not to have to maintain.
It's not the end of the world 

While our release process is improving, it's unfortunately still a bit
finicky. Requirements like having to produce redundant tarballs don't
help.

I wouldn't say that our storage infrastructure is particularly
strained. However, it is a finite resource and if we can use less of it
per release at no cost then I think we should.

> If that's really a problem, sufficiently ancient ones can presumably
> be pruned down to a single format without too many complaints (e.g.,
> if someone wants GHC 7.6, they may not be able to have their choice of
> format).

I would not feel comfortable doing this for any release in 7.0 series.
Once we put up a distribution, users should be able to expect that it
will be there for the foreseeable future.

> Bandwidth seems an entirely legitimate concern, but thankfully a
> symmetric one?most users will want to download the smallest available
> format, and those who are willing to pay the extra time to download
> another likely have a good reason.
>
This is essentially the point I'm trying to make: it appears that
essentially everyone uses the xz distributions. If this really is the
case, then I would ask why are we spending the disk space, effort,
bandwidth, and complexity preparing the bzips.

I can't think of a reason why users would prefer bz2 over xz but that of
course does not mean that one does not exist. This was the reason for
this thread. So far I get the impression that the bzip tarballs will not
be missed.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160202/5b8cbb5a/attachment.sig>

From ben at well-typed.com  Sun Feb  7 18:13:04 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 07 Feb 2016 19:13:04 +0100
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
Message-ID: <8737t49yof.fsf@smart-cactus.org>


Hello everyone,

The GHC Team is very pleased to announce the second release candidate of
the Glasgow Haskell Compiler 8.0.1 release. Source and binary
distributions as well as the newly revised users guide and Haddock
documentation can be found at

    http://downloads.haskell.org/~ghc/8.0.1-rc2/

This is the second in a series of release candidates leading up to the 8.0.1
release and fixes many of the issues reported in -rc1. These fixes
include,

  * A re-rewrite of the pattern checker by George Karachalias. The new
    checker should have far more predictable performance characteristics
    while sacrificing minimal reasoning power. This should resolve a
    large number of the issues felt in -rc1.

  * Richard Eisenberg has been hammering out all manner of
    type-application- and TypeInType-related issues (#11335, #11416,
    #11405). There is still more work to do here, however (e.g. #11471).

  * Matthew Pickering has restored support for multi-clause pattern
    synonyms (#11367)

  * A latent bug in the constraint solver which popped up as a build
    failure in xmonad-contrib in -rc1 has been fixed (#11379)

  * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
    variety of older type-checker bugs at a furious rate (#11458,
    #11248, #11330, #11408)

  * Simon Peyton Jones has taught demand analysis to more precisely
    handle exceptions (#11222)

  * Tamar Christina has added support for remote GHCi on Windows
    and resolved a long-standing linking issue (#11223)

  * Loading of compiled modules needing shared library symbols now works
    in GHCi thanks to Peter Trommler (#10458)

  * A variety of limitations in our implementation of Typeable
    implementation have been fixed (#11120) although there is still more
    to be done (#11334).

  * A terrible failure of type inference due to visible type application has
    been fixed (#11458)

  * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies

  * Custom type errors are now more robust (#11391) although there is
    still more work to be done (#11541)

  * We now have a more conservative default warning set, as well as
    better mechanisms for managing warning changes in the future.
    (#11429, #11370)

  * Compatibility with earlier Cabal versions should be a bit more
    robust.

  * The user-facing interface of the (formerly "implicit") CallStack
    functionality has been reworked, hiding the implicit callstack
    parameter behind a constraint synonym.

  * Online haddock documentation has been restored (#11419)

  * We now offer xz archives exclusively

  * A variety of miscellaneous bug-fixes have also been merged.

All of these changes add up to nearly 200 commits in total. Given the
large amount of churn between this candidate and -rc1, as well as the
fact that there is at least one more significant patch pending (D1891,
to fix #11471 and others), we will be releasing a third release
candidate in a few weeks which should address more of the issues listed
on the release status page [1]. Assuming things go well, we should be
able to cut a final release by early March at the latest.

All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit
e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the
Windows builds*. Unfortunately, it was realized only too late that the
tagged commit is broken on Windows. Consequently, the Windows builds
were produced from the ghc-8.0.1-rc2 tag with two additional patches
(commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of
course be completely unacceptable for a proper release, time constraints
have meant that this was unfortunately the only viable option for this
release candidate. We apologize for any confusion this may cause.

At this point we are working very hard to nail the remaining bugs
labelled as "highest" priority on the 8.0.1 status page [1]. If you have
an issue which you'd like to see addressed in the release that does not
appear in this list, please bring it to our attention.

As always, we look forward to hearing about any issues that you
encounter with this candidate. Thanks to everyone who has contributed so
far!

Cheers,

 - Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160207/3ac2114a/attachment.sig>

From george.colpitts at gmail.com  Sun Feb  7 18:21:08 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 7 Feb 2016 14:21:08 -0400
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
In-Reply-To: <8737t49yof.fsf@smart-cactus.org>
References: <8737t49yof.fsf@smart-cactus.org>
Message-ID: <CAB-d4A6N2xzr8boR=uPZRYvuTeW94CGHqxyMD+X0xx18h91p6g@mail.gmail.com>

Good news! I assume there will be a Mac OS binary distribution soon?

On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari <ben at well-typed.com> wrote:

>
> Hello everyone,
>
> The GHC Team is very pleased to announce the second release candidate of
> the Glasgow Haskell Compiler 8.0.1 release. Source and binary
> distributions as well as the newly revised users guide and Haddock
> documentation can be found at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc2/
>
> This is the second in a series of release candidates leading up to the
> 8.0.1
> release and fixes many of the issues reported in -rc1. These fixes
> include,
>
>   * A re-rewrite of the pattern checker by George Karachalias. The new
>     checker should have far more predictable performance characteristics
>     while sacrificing minimal reasoning power. This should resolve a
>     large number of the issues felt in -rc1.
>
>   * Richard Eisenberg has been hammering out all manner of
>     type-application- and TypeInType-related issues (#11335, #11416,
>     #11405). There is still more work to do here, however (e.g. #11471).
>
>   * Matthew Pickering has restored support for multi-clause pattern
>     synonyms (#11367)
>
>   * A latent bug in the constraint solver which popped up as a build
>     failure in xmonad-contrib in -rc1 has been fixed (#11379)
>
>   * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
>     variety of older type-checker bugs at a furious rate (#11458,
>     #11248, #11330, #11408)
>
>   * Simon Peyton Jones has taught demand analysis to more precisely
>     handle exceptions (#11222)
>
>   * Tamar Christina has added support for remote GHCi on Windows
>     and resolved a long-standing linking issue (#11223)
>
>   * Loading of compiled modules needing shared library symbols now works
>     in GHCi thanks to Peter Trommler (#10458)
>
>   * A variety of limitations in our implementation of Typeable
>     implementation have been fixed (#11120) although there is still more
>     to be done (#11334).
>
>   * A terrible failure of type inference due to visible type application
> has
>     been fixed (#11458)
>
>   * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies
>
>   * Custom type errors are now more robust (#11391) although there is
>     still more work to be done (#11541)
>
>   * We now have a more conservative default warning set, as well as
>     better mechanisms for managing warning changes in the future.
>     (#11429, #11370)
>
>   * Compatibility with earlier Cabal versions should be a bit more
>     robust.
>
>   * The user-facing interface of the (formerly "implicit") CallStack
>     functionality has been reworked, hiding the implicit callstack
>     parameter behind a constraint synonym.
>
>   * Online haddock documentation has been restored (#11419)
>
>   * We now offer xz archives exclusively
>
>   * A variety of miscellaneous bug-fixes have also been merged.
>
> All of these changes add up to nearly 200 commits in total. Given the
> large amount of churn between this candidate and -rc1, as well as the
> fact that there is at least one more significant patch pending (D1891,
> to fix #11471 and others), we will be releasing a third release
> candidate in a few weeks which should address more of the issues listed
> on the release status page [1]. Assuming things go well, we should be
> able to cut a final release by early March at the latest.
>
> All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit
> e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the
> Windows builds*. Unfortunately, it was realized only too late that the
> tagged commit is broken on Windows. Consequently, the Windows builds
> were produced from the ghc-8.0.1-rc2 tag with two additional patches
> (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of
> course be completely unacceptable for a proper release, time constraints
> have meant that this was unfortunately the only viable option for this
> release candidate. We apologize for any confusion this may cause.
>
> At this point we are working very hard to nail the remaining bugs
> labelled as "highest" priority on the 8.0.1 status page [1]. If you have
> an issue which you'd like to see addressed in the release that does not
> appear in this list, please bring it to our attention.
>
> As always, we look forward to hearing about any issues that you
> encounter with this candidate. Thanks to everyone who has contributed so
> far!
>
> Cheers,
>
>  - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160207/7c5f2344/attachment.html>

From ben at well-typed.com  Sun Feb  7 18:39:49 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 07 Feb 2016 19:39:49 +0100
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
In-Reply-To: <CAB-d4A6N2xzr8boR=uPZRYvuTeW94CGHqxyMD+X0xx18h91p6g@mail.gmail.com>
References: <8737t49yof.fsf@smart-cactus.org>
 <CAB-d4A6N2xzr8boR=uPZRYvuTeW94CGHqxyMD+X0xx18h91p6g@mail.gmail.com>
Message-ID: <87zivc8ive.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Good news! I assume there will be a Mac OS binary distribution soon?
>
There is one currently; "Darwin" is the name of the Mac OS X kernel.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160207/929643cf/attachment.sig>

From ben at well-typed.com  Sun Feb  7 18:43:18 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 07 Feb 2016 19:43:18 +0100
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
In-Reply-To: <87zivc8ive.fsf@smart-cactus.org>
References: <8737t49yof.fsf@smart-cactus.org>
 <CAB-d4A6N2xzr8boR=uPZRYvuTeW94CGHqxyMD+X0xx18h91p6g@mail.gmail.com>
 <87zivc8ive.fsf@smart-cactus.org>
Message-ID: <87wpqg8ipl.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> George Colpitts <george.colpitts at gmail.com> writes:
>
>> Good news! I assume there will be a Mac OS binary distribution soon?
>>
> There is one currently; "Darwin" is the name of the Mac OS X kernel.
>
Hmm, I should have fact-checked that first: XNU is apparently the name
of the kernel whereas Darwin is the name of the operating system itself [1].

Regardless, the point is that OS X binaries are available for your
testing pleasure. Let us know how it goes!

Cheers,

 - Ben
 

[1] https://en.wikipedia.org/wiki/Darwin_%28operating_system%29
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160207/7b202262/attachment.sig>

From george.colpitts at gmail.com  Sun Feb  7 19:45:10 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 7 Feb 2016 15:45:10 -0400
Subject: problem compiling GHC 8.0.1 release candidate 2 src on Apple
Message-ID: <CAB-d4A6Y4BNniRCWO-6QyVdocfKFCYyPJD6e5yQ2JGPgNjGTEw@mail.gmail.com>

"/usr/local/bin/ghc" -M -static  -H32m -O -Wall   -package-db
libraries/bootstrapping.conf  -this-unit-id terminfo-0.4.0.2
-hide-all-packages -i -ilibraries/terminfo/.
-ilibraries/terminfo/dist-boot/build
-ilibraries/terminfo/dist-boot/build/autogen
-Ilibraries/terminfo/dist-boot/build
-Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/.
 -optP-include
-optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-id
base-4.9.0.0 -Wall -XHaskell2010   -no-user-package-db -rtsopts
-fno-warn-unused-imports -fno-warn-deprecated-flags      -odir
libraries/terminfo/dist-boot/build -hidir
libraries/terminfo/dist-boot/build -stubdir
libraries/terminfo/dist-boot/build -dep-makefile
libraries/terminfo/dist-boot/build/.depend-v.haskell.tmp -dep-suffix ""
-include-pkg-deps  libraries/terminfo/./System/Console/Terminfo.hs
 libraries/terminfo/./System/Console/Terminfo/Base.hs
 libraries/terminfo/./System/Console/Terminfo/Cursor.hs
 libraries/terminfo/./System/Console/Terminfo/Color.hs
 libraries/terminfo/./System/Console/Terminfo/Edit.hs
 libraries/terminfo/./System/Console/Terminfo/Effects.hs
 libraries/terminfo/./System/Console/Terminfo/Keys.hs
ghc: unrecognised flag: -this-unit-id

Usage: For basic information, try the `--help' option.
make[1]: *** [libraries/terminfo/dist-boot/build/.depend-v.haskell] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2


 ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv -fno-builtin")
 ,("C compiler command","/usr/local/bin/gcc")
 ,("C compiler flags"," -m64 -fno-stack-protector")
 ,("C compiler link flags"," -m64")
 ,("Haskell CPP command","/usr/local/bin/gcc")
 ,("Haskell CPP flags","-E -undef -traditional")
 ,("ld command","/usr/bin/ld")
 ,("ld flags"," -arch x86_64")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","YES")
 ,("ld is GNU ld","NO")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","clqs")
 ,("ar supports at file","NO")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("cross compiling","NO")
 ,("target os","OSDarwin")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","True")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","8.0.0.20160111")
 ,("Project Git commit id","497454fc6610d67a2b2cd7902390c6497bddb483")
 ,("Booter version","7.10.2")
 ,("Stage","2")
 ,("Build platform","x86_64-apple-darwin")
 ,("Host platform","x86_64-apple-darwin")
 ,("Target platform","x86_64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
thr_debug_dyn l_dyn thr_l_dyn")
 ,("RTS expects libdw","NO")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Requires unified installed package IDs","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("GHC Profiled","NO")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ,("LibDir","/usr/local/lib/ghc-8.0.0.20160111")
 ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160111/package.conf.d")
 ]


On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari <ben at well-typed.com> wrote:

>
> Hello everyone,
>
> The GHC Team is very pleased to announce the second release candidate of
> the Glasgow Haskell Compiler 8.0.1 release. Source and binary
> distributions as well as the newly revised users guide and Haddock
> documentation can be found at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc2/
>
> This is the second in a series of release candidates leading up to the
> 8.0.1
> release and fixes many of the issues reported in -rc1. These fixes
> include,
>
>   * A re-rewrite of the pattern checker by George Karachalias. The new
>     checker should have far more predictable performance characteristics
>     while sacrificing minimal reasoning power. This should resolve a
>     large number of the issues felt in -rc1.
>
>   * Richard Eisenberg has been hammering out all manner of
>     type-application- and TypeInType-related issues (#11335, #11416,
>     #11405). There is still more work to do here, however (e.g. #11471).
>
>   * Matthew Pickering has restored support for multi-clause pattern
>     synonyms (#11367)
>
>   * A latent bug in the constraint solver which popped up as a build
>     failure in xmonad-contrib in -rc1 has been fixed (#11379)
>
>   * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a
>     variety of older type-checker bugs at a furious rate (#11458,
>     #11248, #11330, #11408)
>
>   * Simon Peyton Jones has taught demand analysis to more precisely
>     handle exceptions (#11222)
>
>   * Tamar Christina has added support for remote GHCi on Windows
>     and resolved a long-standing linking issue (#11223)
>
>   * Loading of compiled modules needing shared library symbols now works
>     in GHCi thanks to Peter Trommler (#10458)
>
>   * A variety of limitations in our implementation of Typeable
>     implementation have been fixed (#11120) although there is still more
>     to be done (#11334).
>
>   * A terrible failure of type inference due to visible type application
> has
>     been fixed (#11458)
>
>   * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies
>
>   * Custom type errors are now more robust (#11391) although there is
>     still more work to be done (#11541)
>
>   * We now have a more conservative default warning set, as well as
>     better mechanisms for managing warning changes in the future.
>     (#11429, #11370)
>
>   * Compatibility with earlier Cabal versions should be a bit more
>     robust.
>
>   * The user-facing interface of the (formerly "implicit") CallStack
>     functionality has been reworked, hiding the implicit callstack
>     parameter behind a constraint synonym.
>
>   * Online haddock documentation has been restored (#11419)
>
>   * We now offer xz archives exclusively
>
>   * A variety of miscellaneous bug-fixes have also been merged.
>
> All of these changes add up to nearly 200 commits in total. Given the
> large amount of churn between this candidate and -rc1, as well as the
> fact that there is at least one more significant patch pending (D1891,
> to fix #11471 and others), we will be releasing a third release
> candidate in a few weeks which should address more of the issues listed
> on the release status page [1]. Assuming things go well, we should be
> able to cut a final release by early March at the latest.
>
> All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit
> e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the
> Windows builds*. Unfortunately, it was realized only too late that the
> tagged commit is broken on Windows. Consequently, the Windows builds
> were produced from the ghc-8.0.1-rc2 tag with two additional patches
> (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of
> course be completely unacceptable for a proper release, time constraints
> have meant that this was unfortunately the only viable option for this
> release candidate. We apologize for any confusion this may cause.
>
> At this point we are working very hard to nail the remaining bugs
> labelled as "highest" priority on the 8.0.1 status page [1]. If you have
> an issue which you'd like to see addressed in the release that does not
> appear in this list, please bring it to our attention.
>
> As always, we look forward to hearing about any issues that you
> encounter with this candidate. Thanks to everyone who has contributed so
> far!
>
> Cheers,
>
>  - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160207/9a618fd5/attachment-0001.html>

From ben at well-typed.com  Sun Feb  7 21:14:44 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 07 Feb 2016 22:14:44 +0100
Subject: problem compiling GHC 8.0.1 release candidate 2 src on Apple
In-Reply-To: <CAB-d4A6Y4BNniRCWO-6QyVdocfKFCYyPJD6e5yQ2JGPgNjGTEw@mail.gmail.com>
References: <CAB-d4A6Y4BNniRCWO-6QyVdocfKFCYyPJD6e5yQ2JGPgNjGTEw@mail.gmail.com>
Message-ID: <87twlk8bp7.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

snip
>  ,("target has GNU nonexec stack","False")
>  ,("target has .ident directive","True")
>  ,("target has subsections via symbols","True")
>  ,("Unregisterised","NO")
>  ,("LLVM llc command","llc")
>  ,("LLVM opt command","opt")
>  ,("Project version","8.0.0.20160111")

It looks like you are trying to use rc1 to bootstrap rc2 which is not a
supported configuration. Perhaps you could try bootstrapping with 7.10?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160207/6a8ef66b/attachment.sig>

From pali.gabor at gmail.com  Sun Feb  7 23:04:14 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Mon, 8 Feb 2016 00:04:14 +0100
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
In-Reply-To: <8737t49yof.fsf@smart-cactus.org>
References: <8737t49yof.fsf@smart-cactus.org>
Message-ID: <CAHnG2CyDRNkV-yt-pS33s8ecQqZ8uPZhVEmG8AtaK+fmLydBJA@mail.gmail.com>

Hello there,

2016-02-07 19:13 GMT+01:00 Ben Gamari <ben at well-typed.com>:
> The GHC Team is very pleased to announce the second release candidate of
> the Glasgow Haskell Compiler 8.0.1 release.

For the FreeBSD users, the vanilla binary distributions are available
here, along with a brief installation guide:

http://haskell.inf.elte.hu/ghc/8.0.0.20160204/

Cheers,
G?bor

From ben at well-typed.com  Mon Feb  8 10:38:19 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 08 Feb 2016 11:38:19 +0100
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
In-Reply-To: <CAHnG2CyDRNkV-yt-pS33s8ecQqZ8uPZhVEmG8AtaK+fmLydBJA@mail.gmail.com>
References: <8737t49yof.fsf@smart-cactus.org>
 <CAHnG2CyDRNkV-yt-pS33s8ecQqZ8uPZhVEmG8AtaK+fmLydBJA@mail.gmail.com>
Message-ID: <87r3gn8p2c.fsf@smart-cactus.org>

P?li G?bor J?nos <pali.gabor at gmail.com> writes:

> Hello there,
>
> 2016-02-07 19:13 GMT+01:00 Ben Gamari <ben at well-typed.com>:
>> The GHC Team is very pleased to announce the second release candidate of
>> the Glasgow Haskell Compiler 8.0.1 release.
>
> For the FreeBSD users, the vanilla binary distributions are available
> here, along with a brief installation guide:
>
Thanks P?li!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160208/dd0389b8/attachment.sig>

From ben at well-typed.com  Mon Feb  8 11:04:57 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 08 Feb 2016 12:04:57 +0100
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2
In-Reply-To: <8737t49yof.fsf@smart-cactus.org>
References: <8737t49yof.fsf@smart-cactus.org>
Message-ID: <87oabr8nty.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hello everyone,
>
snip
>
>   * Compatibility with earlier Cabal versions should be a bit more
>     robust.
>
Unfortunately this characterization was perhaps a bit optimistic. Sadly
the errors provided by GHC when used with an older Cabal aren't any
better in -rc2 than they were in -rc1. I've opened #11558 to track this
issue.

Users seeing unexpected missing interface file errors need to update
Cabal and cabal-install from git. This must be done using GHC 7.10 at
the moment as some of Cabal's build dependencies lack a build plan with
8.0.

    $ git clone git://github.com/haskell/cabal
    $ cd cabal
    $ cabal update
    $ cabal install Cabal/ cabal-install/

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160208/239bce68/attachment.sig>

From ben at well-typed.com  Sun Feb 14 16:12:50 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 14 Feb 2016 17:12:50 +0100
Subject: Reconsidering -Wall and -Wcompat
Message-ID: <87y4an6zjx.fsf@smart-cactus.org>

tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
       advance notice of coming library changes. We want to know whether
       you think this set should be included in -Wall. See the Wiki [4]
       and voice your opinion via the linked poll.


Hello everyone,

GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
the MonadFail proposal discussion [1] late last year. This warning set
is intended to provide a means of informing users of coming changes in
GHC's core libraries.

We would like to solicit the community's feedback on whether this new
flag set should be implied by -Wall.

This proposal is motivated by concern expressed by some that -Wcompat
would see little usage unless it is placed in one of the warning sets
typically used during development. One such set is -Wall, which enables
a generous fraction of GHC's warning collectionand is is intended [2]
for use during development.

Unfortunately, despite the (albeit only recently stated) intent of
flag, -Wall is widely used outside of development [3], often with the
expectation that the result be warning-clean across multiple GHC
versions. While we hope that -Wall will see less use in this context in
the future, given its current role we wouldn't want to add options to it
that would cause undue burden for users.

So, we are asking for your opinion: should -Wcompat be implied by -Wall?
You can find a more thorough description of the precise proposal on the
GHC Wiki [4]. It would be very much appreciated if you could take a few
minutes familiarize yourself with the options and provide your thoughts
via this quick poll,

    https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform

Feel free to discuss the issue further in this thread.

Thank you for sharing,

- Ben



[1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html

[2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html

[3] In a rather unscientific study, nearly half of packages on Hackage
    include it in ghc-options,

        $ tar -xf ~/.cabal/packages/00-INDEX.tar
        $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l
        4352
        $ ls | wc -l 
        9347
		
[4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160214/112436f9/attachment.sig>

From svenpanne at gmail.com  Sun Feb 14 18:51:19 2016
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 14 Feb 2016 19:51:19 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <87y4an6zjx.fsf@smart-cactus.org>
References: <87y4an6zjx.fsf@smart-cactus.org>
Message-ID: <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>

2016-02-14 17:12 GMT+01:00 Ben Gamari <ben at well-typed.com>:

> [...] This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
>

IMHO, the distinction between "during development" and "outside of it" is
purely hypothetical.  A typical workflow is: Develop your code locally
against one GHC/set of libraries, commit to GitHub and let Travis CI do the
real work of testing against a matrix of configurations. If things work
well and the changes are worth it, tag your current state and release it.
Where exactly in this scenario is the code leaving the "during development"
state? I definitely want to enable -Wall for the Travis CI builds, because
that's the place where they are most valuable. As stated on the Wiki, stuff
in -Wcompat will often be non-actionable, so the only option I see if
-Wcompat is included in -Wall will be -Wno-compat for all my projects.
-Wcompat would be restricted to a few manual local builds to see where
things are heading.


> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, [...]


Seeing -Wall this way is quite unusual, especially for people coming from
C/C++ (and the numbers quoted from Hackage seem to be a hint that others
think so, too). Normally, -Wall -Wextra -pedantic etc. are life-savers and
should be kept enabled all the time, unless you like endless debugging
hours, of course.

In a nutshell: I would consider -Wall implying -Wcompat an annoyance, but
as long as it can be disabled by 2 lines in .travis.yml, I don't really
care. ;-)

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160214/c4866825/attachment.html>

From mail at joachim-breitner.de  Sun Feb 14 22:45:14 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 14 Feb 2016 23:45:14 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
Message-ID: <1455489914.4672.15.camel@joachim-breitner.de>

[Deliberately restricting my reply to one mailing list. Cross-posting
is usually not required.]

Hi,

Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne:
> As stated on the Wiki, stuff in -Wcompat will often be non-
> actionable,

you omitted the important ?if backwards compatibility is desired;?. The
sometimes complicated hoops that you will have to jump through to gain
3-release-backward-compatibility are not something I expect every
developer to follow, and for most others, ?adjust early to API changes?
will more likely be the sensible thing to do. Those might want to leave
-Wcompat in their builds.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160214/8f2a9839/attachment.sig>

From chak at justtesting.org  Sun Feb 14 23:04:45 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Mon, 15 Feb 2016 10:04:45 +1100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <87y4an6zjx.fsf@smart-cactus.org>
References: <87y4an6zjx.fsf@smart-cactus.org>
Message-ID: <58D9ECFB-BBAC-4BA4-8FD5-185F593E1221@justtesting.org>

Just as one data point, the Swift compiler is by default showing warnings about upcoming changes. Just like deprecation warnings, I do find that helpful. Based on that experience, including -Wcompat in -Wall seems like a good plan to me.

Manuel

> Ben Gamari <ben at well-typed.com>:
> 
> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
>       advance notice of coming library changes. We want to know whether
>       you think this set should be included in -Wall. See the Wiki [4]
>       and voice your opinion via the linked poll.
> 
> 
> Hello everyone,
> 
> GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
> the MonadFail proposal discussion [1] late last year. This warning set
> is intended to provide a means of informing users of coming changes in
> GHC's core libraries.
> 
> We would like to solicit the community's feedback on whether this new
> flag set should be implied by -Wall.
> 
> This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
> 
> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, given its current role we wouldn't want to add options to it
> that would cause undue burden for users.
> 
> So, we are asking for your opinion: should -Wcompat be implied by -Wall?
> You can find a more thorough description of the precise proposal on the
> GHC Wiki [4]. It would be very much appreciated if you could take a few
> minutes familiarize yourself with the options and provide your thoughts
> via this quick poll,
> 
>    https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform
> 
> Feel free to discuss the issue further in this thread.
> 
> Thank you for sharing,
> 
> - Ben
> 
> 
> 
> [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html
> 
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html
> 
> [3] In a rather unscientific study, nearly half of packages on Hackage
>    include it in ghc-options,
> 
>        $ tar -xf ~/.cabal/packages/00-INDEX.tar
>        $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l
>        4352
>        $ ls | wc -l 
>        9347
> 		
> [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From qdunkan at gmail.com  Mon Feb 15 00:32:36 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 15 Feb 2016 09:32:36 +0900
Subject: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?
Message-ID: <CACbaDy5bP8_stB7jUmfrwvEO7ENpU8OKtTT4iv21F5afL28cug@mail.gmail.com>

I recently upgraded to ghc 8 and started using stacks via
ImplicitParams.  For that I wind up using 'type Stack = (?stack ::
CallStack)' and so ContraintKinds (I see that in the future GHC will
do this by default).

So now I can have a file like:

module T where
import qualified Log as Log

f :: Log.Stack => IO ()
f = Log.warn "blah blah"

I noticed that now haskell-src-exts refuses to parse this file, saying
'MultiParamTypeClasses language extension is not enabled.'.

I assume it's a bug with haskell-src-exts in that it should require
LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want
ConstraintKinds.  Instead, it wants FlexibleContexts.  From the docs,
FlexibleContexts seems to be about the contexts in instance heads.

Is this intentional?  I'll go ahead and make a bug for
haskell-src-exts, but the ghc behaviour here seems odd as well.  What
extension should haskell-src-exts require to parse this?

From eric at seidel.io  Mon Feb 15 01:16:24 2016
From: eric at seidel.io (Eric Seidel)
Date: Sun, 14 Feb 2016 17:16:24 -0800
Subject: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?
In-Reply-To: <CACbaDy5bP8_stB7jUmfrwvEO7ENpU8OKtTT4iv21F5afL28cug@mail.gmail.com>
References: <CACbaDy5bP8_stB7jUmfrwvEO7ENpU8OKtTT4iv21F5afL28cug@mail.gmail.com>
Message-ID: <1455498984.2152291.521114346.75827F5C@webmail.messagingengine.com>

IIRC ConstraintKinds is only required in the module that defines the
type synonym, so your module T does not need it. My guess is that
haskell-src-exts sees 'Log.Stack =>', in which we have nullary
constraint instead of a unary constraint, and assumes that's bogus
without MultiParamTypeClasses. But I'm not familiar with
haskell-src-exts' internals, so that's just a wild guess :)

FYI, as of RC2 we provide a type synonym

  type HasCallStack = (?callStack :: CallStack)

in GHC.Stack, which is the recommended way to request a CallStack. We're
hiding the implicit parameter from the docs and API, as the reliance on
using the same name is a bit of a misfeature. We might also reimplement
HasCallStack without implicit-params in the future, so in the interest
of forward-compatibility I'd suggest using HasCallStack instead of your
own implicit-parameters.

Eric
 

On Sun, Feb 14, 2016, at 16:32, Evan Laforge wrote:
> I recently upgraded to ghc 8 and started using stacks via
> ImplicitParams.  For that I wind up using 'type Stack = (?stack ::
> CallStack)' and so ContraintKinds (I see that in the future GHC will
> do this by default).
> 
> So now I can have a file like:
> 
> module T where
> import qualified Log as Log
> 
> f :: Log.Stack => IO ()
> f = Log.warn "blah blah"
> 
> I noticed that now haskell-src-exts refuses to parse this file, saying
> 'MultiParamTypeClasses language extension is not enabled.'.
> 
> I assume it's a bug with haskell-src-exts in that it should require
> LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want
> ConstraintKinds.  Instead, it wants FlexibleContexts.  From the docs,
> FlexibleContexts seems to be about the contexts in instance heads.
> 
> Is this intentional?  I'll go ahead and make a bug for
> haskell-src-exts, but the ghc behaviour here seems odd as well.  What
> extension should haskell-src-exts require to parse this?
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

From qdunkan at gmail.com  Mon Feb 15 02:15:21 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 15 Feb 2016 11:15:21 +0900
Subject: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?
In-Reply-To: <1455498984.2152291.521114346.75827F5C@webmail.messagingengine.com>
References: <CACbaDy5bP8_stB7jUmfrwvEO7ENpU8OKtTT4iv21F5afL28cug@mail.gmail.com>
 <1455498984.2152291.521114346.75827F5C@webmail.messagingengine.com>
Message-ID: <CACbaDy69Z05ChEiUktNCZfWMsRXizEMitp5kEp00gL1WEVwZ2g@mail.gmail.com>

Right, that sounds like a good idea to me, it's the same reason I
added the synonym myself.

WRT not needing an extension I guess this is part of a general pattern
where you don't need extensions to use code that uses extensions.  In
this case though it seems a bit odd in that using the code that uses
extensions also requires previously illegal syntax.  But as long as
it's intentional it's fine by me.

But is the bit where the calling module needs FlexibleConstraints also
intentional?

On Mon, Feb 15, 2016 at 10:16 AM, Eric Seidel <eric at seidel.io> wrote:
> IIRC ConstraintKinds is only required in the module that defines the
> type synonym, so your module T does not need it. My guess is that
> haskell-src-exts sees 'Log.Stack =>', in which we have nullary
> constraint instead of a unary constraint, and assumes that's bogus
> without MultiParamTypeClasses. But I'm not familiar with
> haskell-src-exts' internals, so that's just a wild guess :)
>
> FYI, as of RC2 we provide a type synonym
>
>   type HasCallStack = (?callStack :: CallStack)
>
> in GHC.Stack, which is the recommended way to request a CallStack. We're
> hiding the implicit parameter from the docs and API, as the reliance on
> using the same name is a bit of a misfeature. We might also reimplement
> HasCallStack without implicit-params in the future, so in the interest
> of forward-compatibility I'd suggest using HasCallStack instead of your
> own implicit-parameters.
>
> Eric
>
>
> On Sun, Feb 14, 2016, at 16:32, Evan Laforge wrote:
>> I recently upgraded to ghc 8 and started using stacks via
>> ImplicitParams.  For that I wind up using 'type Stack = (?stack ::
>> CallStack)' and so ContraintKinds (I see that in the future GHC will
>> do this by default).
>>
>> So now I can have a file like:
>>
>> module T where
>> import qualified Log as Log
>>
>> f :: Log.Stack => IO ()
>> f = Log.warn "blah blah"
>>
>> I noticed that now haskell-src-exts refuses to parse this file, saying
>> 'MultiParamTypeClasses language extension is not enabled.'.
>>
>> I assume it's a bug with haskell-src-exts in that it should require
>> LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want
>> ConstraintKinds.  Instead, it wants FlexibleContexts.  From the docs,
>> FlexibleContexts seems to be about the contexts in instance heads.
>>
>> Is this intentional?  I'll go ahead and make a bug for
>> haskell-src-exts, but the ghc behaviour here seems odd as well.  What
>> extension should haskell-src-exts require to parse this?
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

From eir at cis.upenn.edu  Mon Feb 15 03:47:56 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 14 Feb 2016 22:47:56 -0500
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
Message-ID: <7DD5333B-FEE5-40A6-94B8-79D7C1C01757@cis.upenn.edu>


On Feb 14, 2016, at 1:51 PM, Sven Panne <svenpanne at gmail.com> wrote:
> 
> IMHO, the distinction between "during development" and "outside of it" is purely hypothetical. 

I find this comment quite interesting, as I see quite a large difference between these.* For example, I use -Werror during development, but not outside it. For me, "during development" is when the author can see the output from the compiler. "Outside of it" is when the author is not looking at the output.

When I'm developing, I want to see lots and lots of warnings.

When I'm building something I downloaded from Hackage, I generally don't care.

So I wonder if there's a way for the tooling to distinguish between development builds and non-dev builds.

I know cabal better than stack, so I'll use that as my example. When I say `cabal configure --enable-tests; cabal build`, it means I want more information about how well this package works. Perhaps with --enable-tests, -Wall -Wcompat -Werror should be enabled by default. If I just say `cabal install`, I probably don't care so much about how well the package is working and can leave off the extra diagnostics.

The approach of integrating this with tooling like cabal or stack also has the advantage that it is very easy to tailor custom treatment for specific compiler versions. This custom treatment could disable newly-written warnings individually if GHC introduces a new warning that, it is decided, should not be enabled by default on projects that wish to have legacy support.

Would this address some of the problems that people have had in this space?

Richard

* By "interesting" here, I certainly don't mean "stupid". I mean "interesting", because I, like many people, tend to think that others think like I do. This is clearly not the case here, so I have to broaden my viewpoint.

From eric at seidel.io  Mon Feb 15 03:57:24 2016
From: eric at seidel.io (Eric Seidel)
Date: Sun, 14 Feb 2016 19:57:24 -0800
Subject: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?
In-Reply-To: <CACbaDy69Z05ChEiUktNCZfWMsRXizEMitp5kEp00gL1WEVwZ2g@mail.gmail.com>
References: <CACbaDy5bP8_stB7jUmfrwvEO7ENpU8OKtTT4iv21F5afL28cug@mail.gmail.com>
 <1455498984.2152291.521114346.75827F5C@webmail.messagingengine.com>
 <CACbaDy69Z05ChEiUktNCZfWMsRXizEMitp5kEp00gL1WEVwZ2g@mail.gmail.com>
Message-ID: <1455508644.2187667.521203506.3B301FDA@webmail.messagingengine.com>

On Sun, Feb 14, 2016, at 18:15, Evan Laforge wrote:
> Right, that sounds like a good idea to me, it's the same reason I
> added the synonym myself.
> 
> WRT not needing an extension I guess this is part of a general pattern
> where you don't need extensions to use code that uses extensions.  In
> this case though it seems a bit odd in that using the code that uses
> extensions also requires previously illegal syntax.  But as long as
> it's intentional it's fine by me.
> 
> But is the bit where the calling module needs FlexibleConstraints also
> intentional?

It looks like it is. According to [1], the context must have the form `C
a` unless FlexibleContexts is enabled.

[1]:
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-extensions.html#flexible-contexts

From qdunkan at gmail.com  Mon Feb 15 06:15:44 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 15 Feb 2016 15:15:44 +0900
Subject: LANGUAGE ConstraintKinds not needed to use ConstraintKinds?
In-Reply-To: <1455508644.2187667.521203506.3B301FDA@webmail.messagingengine.com>
References: <CACbaDy5bP8_stB7jUmfrwvEO7ENpU8OKtTT4iv21F5afL28cug@mail.gmail.com>
 <1455498984.2152291.521114346.75827F5C@webmail.messagingengine.com>
 <CACbaDy69Z05ChEiUktNCZfWMsRXizEMitp5kEp00gL1WEVwZ2g@mail.gmail.com>
 <1455508644.2187667.521203506.3B301FDA@webmail.messagingengine.com>
Message-ID: <CACbaDy5sDLjBE3Aq9DBaPyMWpFurrKgY0ONHTy0my16fLbG+aA@mail.gmail.com>

On Mon, Feb 15, 2016 at 12:57 PM, Eric Seidel <eric at seidel.io> wrote:
> It looks like it is. According to [1], the context must have the form `C
> a` unless FlexibleContexts is enabled.

Works for me, thanks!

From hvriedel at gmail.com  Mon Feb 15 09:50:55 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 15 Feb 2016 10:50:55 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <7DD5333B-FEE5-40A6-94B8-79D7C1C01757@cis.upenn.edu> (Richard
 Eisenberg's message of "Sun, 14 Feb 2016 22:47:56 -0500")
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
 <7DD5333B-FEE5-40A6-94B8-79D7C1C01757@cis.upenn.edu>
Message-ID: <8737su5mkg.fsf@gmail.com>

On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote:
> On Feb 14, 2016, at 1:51 PM, Sven Panne <svenpanne at gmail.com> wrote:
>> 
>> IMHO, the distinction between "during development" and "outside of it" is purely hypothetical. 
>
> I find this comment quite interesting, as I see quite a large
> difference between these.* For example, I use -Werror during
> development, but not outside it. For me, "during development" is when
> the author can see the output from the compiler. "Outside of it" is
> when the author is not looking at the output.
>
> When I'm developing, I want to see lots and lots of warnings.
>
> When I'm building something I downloaded from Hackage, I generally don't care.
>
> So I wonder if there's a way for the tooling to distinguish between
> development builds and non-dev builds.

You may be interested in the upcoming `cabal.project`-file feature which
besides allowing to specify which .cabal files your multi-package
project is made up of (and tells cabal where your project-root is),
allows to set additional `ghc-options`, specify whether tests/benchmarks
are to be enabled, or request specific cabal flag settings (basically
most things you can set via the CLI as well), or even which GHC compiler
executable to use (rather than picking up whatever's in PATH). This can
be specified for all packages in the project or on per-package
granularity.

`cabal.project` files have only an effect when you're triggering cabal
invocations from within a source-tree, i.e. when you're in the "during
development" mode.  So that would be a good place to specify your
development-mode GHC warning-flag configuration and other
development-centric configurations.

> I know cabal better than stack, so I'll use that as my example. When I
> say `cabal configure --enable-tests; cabal build`, it means I want
> more information about how well this package works. Perhaps with
> --enable-tests, -Wall -Wcompat -Werror should be enabled by
> default. If I just say `cabal install`, I probably don't care so much
> about how well the package is working and can leave off the extra
> diagnostics.

From m at tweag.io  Mon Feb 15 10:33:09 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 15 Feb 2016 11:33:09 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <87y4an6zjx.fsf@smart-cactus.org>
References: <87y4an6zjx.fsf@smart-cactus.org>
Message-ID: <CAJ0eudoRRS7O7ztg2iuyjF2ZTqg43GLU6A+eZbjjqMPzZ0O-1w@mail.gmail.com>

Hi Ben,

could we enlarge the options a bit? I feel that we're in a false
dichotomy currently. I think the issue isn't so much what warnings you
see from the compiler with common settings, so much as "what warnings
will cause my build to fail?". i.e. the issue isn't what's in -Wall,
it's what goes in -Werror...

If we don't include -Wcompat in -Wall, then I suspect Ben is quite
right that many will ignore / not be aware of -Wcompat hence rendering
the 3 release policy rather moot (it's much less useful if developers
don't /know/ they're incompatible until the last minute). If we do
include it then packages with -Wall -Werror will fail far too early:
i.e. way before the compat change actually happens, 3 compiler
releases down the line. So may I suggest the following:

* include -Wcompat and -Wall, but make it "magic" so that -Wcompat
never causes a build to fail even when users set -Wall -Werror.

This should address the concerns I've been hearing by folks at large
companies who say that at their company a warning is equivalent to an
error, because they always compile with -Wall -Werror. Otherwise
warnings just accumulate, hence no one pays attention to them, hence
warnings become useless.

As an aside: I believe -Wall should do what it says on the tin: enable
all warnings. When GHC comes up with new warnings, we should pretty
much never hesitate to add them to the -Wall set. At Tweag I/O we've
had one instance of a serious bug that shipped into production and
several days worth of wasted effort, because a constraint maintaining
a key invariant was mistakenly unused. -fwarn-redundant-constraints
would of caught this bug very early and saved us all the trouble (a
test would have worked too, but as it happens a test did exist but had
a bug too).

Best,
--
Mathieu Boespflug
Founder at http://tweag.io.


On 14 February 2016 at 17:12, Ben Gamari <ben at well-typed.com> wrote:
> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
>        advance notice of coming library changes. We want to know whether
>        you think this set should be included in -Wall. See the Wiki [4]
>        and voice your opinion via the linked poll.
>
>
> Hello everyone,
>
> GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
> the MonadFail proposal discussion [1] late last year. This warning set
> is intended to provide a means of informing users of coming changes in
> GHC's core libraries.
>
> We would like to solicit the community's feedback on whether this new
> flag set should be implied by -Wall.
>
> This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
>
> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, given its current role we wouldn't want to add options to it
> that would cause undue burden for users.
>
> So, we are asking for your opinion: should -Wcompat be implied by -Wall?
> You can find a more thorough description of the precise proposal on the
> GHC Wiki [4]. It would be very much appreciated if you could take a few
> minutes familiarize yourself with the options and provide your thoughts
> via this quick poll,
>
>     https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform
>
> Feel free to discuss the issue further in this thread.
>
> Thank you for sharing,
>
> - Ben
>
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html
>
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html
>
> [3] In a rather unscientific study, nearly half of packages on Hackage
>     include it in ghc-options,
>
>         $ tar -xf ~/.cabal/packages/00-INDEX.tar
>         $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l
>         4352
>         $ ls | wc -l
>         9347
>
> [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From hvriedel at gmail.com  Mon Feb 15 10:43:02 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 15 Feb 2016 11:43:02 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
 (Sven Panne's message of "Sun, 14 Feb 2016 19:51:19 +0100")
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
Message-ID: <87twla45l5.fsf@gmail.com>

On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote:

[...]

> As stated on the Wiki, stuff in -Wcompat will often be non-actionable,
> so the only option I see if -Wcompat is included in -Wall will be
> -Wno-compat for all my projects.

This depends on what we mean by "actionable". I'm not sure I'd consider
the current -Wcompat warnings to be "non-actionable".

For instance, `aeson-0.11` happens to be free of

  -Wall -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances

warnings, which didn't require any CPP, see e.g.

 - https://github.com/bos/aeson/pull/337/files
 - https://github.com/bos/aeson/pull/338/files


Also, as an example for a larger code-base, {Cabal,cabal-install} HEAD
in Git aspire to be warning-free as well[1]; so depending on your definition,
-Wcompat *is* actionable.

> -Wcompat would be restricted to a few manual local builds to see where
> things are heading.



 [1]: See  .e.g. https://github.com/haskell/cabal/blob/master/Cabal/Cabal.cabal#L191-L193

         if impl(ghc >= 8.0)
            ghc-options: -Wcompat -Wnoncanonical-monad-instances
                         -Wnoncanonical-monadfail-instances

      and the Travis job enables -Werror

From hvriedel at gmail.com  Mon Feb 15 10:48:22 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 15 Feb 2016 11:48:22 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <CAJ0eudoRRS7O7ztg2iuyjF2ZTqg43GLU6A+eZbjjqMPzZ0O-1w@mail.gmail.com>
 (Mathieu Boespflug's message of "Mon, 15 Feb 2016 11:33:09 +0100")
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CAJ0eudoRRS7O7ztg2iuyjF2ZTqg43GLU6A+eZbjjqMPzZ0O-1w@mail.gmail.com>
Message-ID: <87povy45c9.fsf@gmail.com>

On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote:

[...]

> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
> never causes a build to fail even when users set -Wall -Werror.

Tbh, I don't like the "magic" part at all. In fact, I currently rely on
`-Wcompat -Werror` triggering an error in my builds.

To address the concern more generally is what

  https://ghc.haskell.org/trac/ghc/ticket/11219

aims to, but without any magic. Then you'd say

  -Wall -Werror -Wno-error=compat

if -Wcompat implied by -Wall. But we ran out of time for GHC 8.0, so
#11219 will have to wait till GHC 8.2.

From ben at smart-cactus.org  Mon Feb 15 11:00:04 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 15 Feb 2016 12:00:04 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <1455489914.4672.15.camel@joachim-breitner.de>
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CANBN=msm1yhd=U6kiOgJx4UU2PJV7oMHJwJDuuZ7JSpR-U1j4w@mail.gmail.com>
 <1455489914.4672.15.camel@joachim-breitner.de>
Message-ID: <87mvr26xxn.fsf@smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

> [Deliberately restricting my reply to one mailing list. Cross-posting
> is usually not required.]
>
> Hi,
>
> Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne:
>> As stated on the Wiki, stuff in -Wcompat will often be non-
>> actionable,
>
> you omitted the important ?if backwards compatibility is desired;?. The
> sometimes complicated hoops that you will have to jump through to gain
> 3-release-backward-compatibility are not something I expect every
> developer to follow, and for most others, ?adjust early to API changes?
> will more likely be the sensible thing to do. Those might want to leave
> -Wcompat in their builds.
>
Couldn't have said it better myself. Ubiquitous usage of -Wall isn't a
problem; it's when users begin to assume that the behavior of -Wall
(which nominally includes *all* warnings supported by GHC) will remain
stable across releases that the trouble begins.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160215/d10d698c/attachment.sig>

From m at tweag.io  Mon Feb 15 11:04:43 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 15 Feb 2016 12:04:43 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <87povy45c9.fsf@gmail.com>
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CAJ0eudoRRS7O7ztg2iuyjF2ZTqg43GLU6A+eZbjjqMPzZ0O-1w@mail.gmail.com>
 <87povy45c9.fsf@gmail.com>
Message-ID: <CAJ0eudoBTTjrW=3b4nA_EwGqZV5HHKC1P2iJKUcyDU3Wp7+-=Q@mail.gmail.com>

>> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
>> never causes a build to fail even when users set -Wall -Werror.
>
> Tbh, I don't like the "magic" part at all. In fact, I currently rely on
> `-Wcompat -Werror` triggering an error in my builds.

Point is - if -Wall implies -Wcompat that's simply not an option for
many companies, who have a huge codebase, turn on -Wall -Werror as a
matter of policy yet need the time granted by the 3 release policy to
adapt their codebase.

> To address the concern more generally is what
>
>   https://ghc.haskell.org/trac/ghc/ticket/11219
>
> aims to, but without any magic. Then you'd say
>
>   -Wall -Werror -Wno-error=compat
>
> if -Wcompat implied by -Wall.

That sounds good. -Wno-error=compat should work fine.

> But we ran out of time for GHC 8.0, so #11219 will have to wait till GHC 8.2.

Then is it reasonable to prevent -Wall -Werror from failing builds
because of -Wcompat through some kind of special casing in GHC 8.0, to
be generalized via -Wno-error in GHC 8.2?

From ben at well-typed.com  Mon Feb 15 14:09:32 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 15 Feb 2016 15:09:32 +0100
Subject: Reconsidering -Wall and -Wcompat
In-Reply-To: <CAJ0eudoRRS7O7ztg2iuyjF2ZTqg43GLU6A+eZbjjqMPzZ0O-1w@mail.gmail.com>
References: <87y4an6zjx.fsf@smart-cactus.org>
 <CAJ0eudoRRS7O7ztg2iuyjF2ZTqg43GLU6A+eZbjjqMPzZ0O-1w@mail.gmail.com>
Message-ID: <87k2m66p5v.fsf@smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> Hi Ben,
>
> could we enlarge the options a bit? I feel that we're in a false
> dichotomy currently. I think the issue isn't so much what warnings you
> see from the compiler with common settings, so much as "what warnings
> will cause my build to fail?". i.e. the issue isn't what's in -Wall,
> it's what goes in -Werror...

I can certainly see this point. As pointed out by Herbert, this is best
provided by #11219 which unfortunately didn't make the 8.0 release.

> If we don't include -Wcompat in -Wall, then I suspect Ben is quite
> right that many will ignore / not be aware of -Wcompat hence rendering
> the 3 release policy rather moot (it's much less useful if developers
> don't /know/ they're incompatible until the last minute). If we do
> include it then packages with -Wall -Werror will fail far too early:
> i.e. way before the compat change actually happens, 3 compiler
> releases down the line. So may I suggest the following:
>
> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
> never causes a build to fail even when users set -Wall -Werror.
>
> This should address the concerns I've been hearing by folks at large
> companies who say that at their company a warning is equivalent to an
> error, because they always compile with -Wall -Werror. Otherwise
> warnings just accumulate, hence no one pays attention to them, hence
> warnings become useless.
>
> As an aside: I believe -Wall should do what it says on the tin: enable
> all warnings.

I am sympathetic to this argument. For better or for worse, however,
there seems to be precedent for excluding some warnings in -Wall. Clang,
for instance, uses -Weverything for "give me everything". Up until this
point we have followed this model (although don't have a -Weverything);
for instance, we disable -Wimplicit-prelude in -Wall since it is
inappropriate for most users.

I'm not sure whether we should break with this tradition as users are
quite used to invoking their compiler with `-Wall` during development.
Throwing warnings about implicit Prelude imports at them would be
surprising to say the least.

> When GHC comes up with new warnings, we should pretty
> much never hesitate to add them to the -Wall set.

I agree. This is why Simon wrote an explicit declaration that -Wall is
not stable to the list a few weeks ago. We really don't want to worry
about breaking builds of (potentially broken) user code when adding
warnings.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160215/0e0852e9/attachment.sig>

From syd.kerckhove at gmail.com  Tue Feb 16 17:12:45 2016
From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove)
Date: Tue, 16 Feb 2016 18:12:45 +0100
Subject: [Feedback requested]: -fhelpful-import-errors
Message-ID: <20160216171245.GA30511@quintus.v.cablecom.net>

Hi,

I raised a ticket to request a new feature: -fhelpful-import-errors.

This flag should enable helpful errors if there are typo's in the
internal imports of your projects.

As suggested by `thomie`, I created a design proposal at
https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
and am now looking for feedback.

Thank you for your time.

-- 
Tom Sydney Kerckhove

From svenpanne at gmail.com  Tue Feb 16 18:02:37 2016
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 16 Feb 2016 19:02:37 +0100
Subject: [Feedback requested]: -fhelpful-import-errors
In-Reply-To: <20160216171245.GA30511@quintus.v.cablecom.net>
References: <20160216171245.GA30511@quintus.v.cablecom.net>
Message-ID: <CANBN=mvxCBMho43=9aSvQ9z7UMH=01nyC9bk1hAAwuzOhB-dEA@mail.gmail.com>

2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove <syd.kerckhove at gmail.com>:

> [...] As suggested by `thomie`, I created a design proposal at
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
> and am now looking for feedback.


[ Not sure if the feedback should be submitted here on in the corresponding
ticket... ]

Just a few quick remarks:

   * Whatever you do, never walk the file system tree up or down in an
uncontrolled way, this will kill basically all benefits and is a
show-stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so
*horribly* slow when used that way that the walks will probably dominate
your compilation time. And even under Linux it's not uncommon to have a few
dozen directory levels and hundreds of thousands of files below our cwd:
Just check out a few repositories, have some leftovers from compilations,
tons of documentations in small HTML files etc., and this sums up quickly.
Git walks up the tree, but only looking for a specific directory and will
e.g. not cross mount points under normal circumstances. This is probably
the limit of what you can do.

   * Caching between runs will be tricky: How will you invalidate the
cache? People can (and will :-) do all kinds of evil things between runs,
so how can you (in-)validate the cache quicker than re-scanning the file
system again?

   * As a general rule to keep in mind during the design: Successful
compiler runs should not pay a price. It's OK if things are a little bit
slower when an error occurs, but the main use case is successful
compilation. This is a bit like exceptions in most programming language
implementations: They are more or less for free when you don't use them
(yes, they have a cost even then because they complicate/invalidate some
compiler optimizations, but let's forget that for now), and are often
costly when you actually raise them.

Just my 2c,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160216/dc679b74/attachment.html>

From simonpj at microsoft.com  Tue Feb 16 22:55:50 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 16 Feb 2016 22:55:50 +0000
Subject: [Feedback requested]: -fhelpful-import-errors
In-Reply-To: <CANBN=mvxCBMho43=9aSvQ9z7UMH=01nyC9bk1hAAwuzOhB-dEA@mail.gmail.com>
References: <20160216171245.GA30511@quintus.v.cablecom.net>
 <CANBN=mvxCBMho43=9aSvQ9z7UMH=01nyC9bk1hAAwuzOhB-dEA@mail.gmail.com>
Message-ID: <aceaa911c9d242ef8bcf3ee2aca54233@DB4PR30MB030.064d.mgd.msft.net>

Best in the ticket https://ghc.haskell.org/trac/ghc/ticket/11418#comment:27, I transferred your comment there

S

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Sven Panne
Sent: 16 February 2016 18:03
To: glasgow-haskell-users at haskell.org
Subject: Re: [Feedback requested]: -fhelpful-import-errors

2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove <syd.kerckhove at gmail.com<mailto:syd.kerckhove at gmail.com>>:
[...] As suggested by `thomie`, I created a design proposal at
https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
and am now looking for feedback.

[ Not sure if the feedback should be submitted here on in the corresponding ticket... ]

Just a few quick remarks:

   * Whatever you do, never walk the file system tree up or down in an uncontrolled way, this will kill basically all benefits and is a show-stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so *horribly* slow when used that way that the walks will probably dominate your compilation time. And even under Linux it's not uncommon to have a few dozen directory levels and hundreds of thousands of files below our cwd: Just check out a few repositories, have some leftovers from compilations, tons of documentations in small HTML files etc., and this sums up quickly. Git walks up the tree, but only looking for a specific directory and will e.g. not cross mount points under normal circumstances. This is probably the limit of what you can do.

   * Caching between runs will be tricky: How will you invalidate the cache? People can (and will :-) do all kinds of evil things between runs, so how can you (in-)validate the cache quicker than re-scanning the file system again?

   * As a general rule to keep in mind during the design: Successful compiler runs should not pay a price. It's OK if things are a little bit slower when an error occurs, but the main use case is successful compilation. This is a bit like exceptions in most programming language implementations: They are more or less for free when you don't use them (yes, they have a cost even then because they complicate/invalidate some compiler optimizations, but let's forget that for now), and are often costly when you actually raise them.

Just my 2c,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160216/091f01c4/attachment-0001.html>

From ben at well-typed.com  Sat Feb 27 13:57:14 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 27 Feb 2016 14:57:14 +0100
Subject: GHC 8.0.1 status
Message-ID: <87wppqz26d.fsf@smart-cactus.org>

tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated.
       The release schedule is being pushed back a bit.


Hello everyone,

As you likely know we are currently in the depths of the 8.0 release. In
fact, under more ideal circumstances I would probably be cutting another
release candidate right now instead of writing this email, in
preparation for a final release next week or so.

However, our world is far from ideal as evidenced by the number
[1] of significant bugs present on the 8.0 branch. This isn't altogether
unexpected; we knew we were taking a bit of a risk in merging so many
high-impact patches in one release. However, we thought that given a
longer-than-usual period between first-candidate and the final release,
we'd have enough time to smooth out the wrinkles. Sadly, this has taken
a bit longer than we anticipated.

Of course, the last thing we want is to push a known buggy release out
the door. Consequently, we won't be delivering the 8.0.1 release next
week as originally planned. Instead, we'll be pushing the release back
by about three weeks. This will give developers a bit more breathing
room in which to work out the remaining issues. Hopefully in a few weeks
the tree will be in such a state that we can push out yet another
candidate which, with luck, will be the last before the release.

If you'd like to expedite the process (and have fun in the process), you
could do worse than to having a look at Trac [1], choosing a bug of your
liking, and trying your hand at solving it.

Thanks to everyone who has contributed to this effort thusfar.
If you have any questions about the release process or how you can help,
don't hesistate to ask.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160227/3f6f3fd6/attachment.sig>

From christiaan.baaij at gmail.com  Sat Feb 27 22:04:40 2016
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Sat, 27 Feb 2016 23:04:40 +0100
Subject: GHC 8.0.1 status
In-Reply-To: <87wppqz26d.fsf@smart-cactus.org>
References: <87wppqz26d.fsf@smart-cactus.org>
Message-ID: <CABzw7bVpU1zVH3MzRVZZ6GreePvv4vpiZSCtrqy9S82Bsd8ZWw@mail.gmail.com>

Given that I was working on at least once package (
https://github.com/goldfirere/singletons/pull/142) which gave panics on
GHC8-rc2, couldn't we get at least an GHC8-rc3 before doing an 8.0.1
release in 3 weeks?

On 27 February 2016 at 14:57, Ben Gamari <ben at well-typed.com> wrote:

> tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated.
>        The release schedule is being pushed back a bit.
>
>
> Hello everyone,
>
> As you likely know we are currently in the depths of the 8.0 release. In
> fact, under more ideal circumstances I would probably be cutting another
> release candidate right now instead of writing this email, in
> preparation for a final release next week or so.
>
> However, our world is far from ideal as evidenced by the number
> [1] of significant bugs present on the 8.0 branch. This isn't altogether
> unexpected; we knew we were taking a bit of a risk in merging so many
> high-impact patches in one release. However, we thought that given a
> longer-than-usual period between first-candidate and the final release,
> we'd have enough time to smooth out the wrinkles. Sadly, this has taken
> a bit longer than we anticipated.
>
> Of course, the last thing we want is to push a known buggy release out
> the door. Consequently, we won't be delivering the 8.0.1 release next
> week as originally planned. Instead, we'll be pushing the release back
> by about three weeks. This will give developers a bit more breathing
> room in which to work out the remaining issues. Hopefully in a few weeks
> the tree will be in such a state that we can push out yet another
> candidate which, with luck, will be the last before the release.
>
> If you'd like to expedite the process (and have fun in the process), you
> could do worse than to having a look at Trac [1], choosing a bug of your
> liking, and trying your hand at solving it.
>
> Thanks to everyone who has contributed to this effort thusfar.
> If you have any questions about the release process or how you can help,
> don't hesistate to ask.
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160227/ac3ffaeb/attachment.html>

From ben at well-typed.com  Sat Feb 27 22:58:42 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 27 Feb 2016 23:58:42 +0100
Subject: GHC 8.0.1 status
In-Reply-To: <CABzw7bVpU1zVH3MzRVZZ6GreePvv4vpiZSCtrqy9S82Bsd8ZWw@mail.gmail.com>
References: <87wppqz26d.fsf@smart-cactus.org>
 <CABzw7bVpU1zVH3MzRVZZ6GreePvv4vpiZSCtrqy9S82Bsd8ZWw@mail.gmail.com>
Message-ID: <87si0dzrod.fsf@smart-cactus.org>

Christiaan Baaij <christiaan.baaij at gmail.com> writes:

> Given that I was working on at least once package (
> https://github.com/goldfirere/singletons/pull/142) which gave panics on
> GHC8-rc2, couldn't we get at least an GHC8-rc3 before doing an 8.0.1
> release in 3 weeks?

As I said in the original message (and several times prior),

> Hopefully in a few weeks the tree will be in such a state that we can
> push out yet another candidate which, with luck, will be the last
> before the release.

that is, there will be *at least* one more release candidate before the
final release.

Fear not; we will not be pushing out 8.0.1 until we are convinced it has been
sufficiently tested.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160227/5ddf4be8/attachment.sig>