Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-29 Thread Jens Petersen 
On 26 February 2016 at 02:09, Ben Gamari  wrote:
>> Thank you for RC2.
> I'm happy to help.

I think you're doing a great job.

>> I finally built ghc-8.0.0 for Fedora Rawhide (quick build):
>> https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1
>> (perf build is still ongoing).

Fedora perf builds are done now btw.

>> One minor thing I noticed is that docdir seems have changed RC2 to be 
>> versioned.
>> ie the LICENSE files for the included libraries now get installed under
>> "/usr/share/doc/ghc-/html/libraries/*/" rather than
>> "/usr/share/doc/ghc/html/libraries/*/" before.
>> I managed to work around that by configuring with
>> --docdir=/usr/share/doc but it took me by surprise.
>>
> This was an intentional change; see #11354. I'll make sure it is
> mentioned in the next release candidate announcement. Thanks for
> mentioning this.
https://ghc.haskell.org/trac/ghc/ticket/11354

I see, thanks.  I added a comment, since 'configure --help' still says
the default is unversioned,
and I opened a new ticket
https://ghc.haskell.org/trac/ghc/ticket/11659 for this.

Thanks, Jens
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-25 Thread Ben Gamari 
Jens Petersen  writes:

> On 8 February 2016 at 03:13, Ben Gamari  wrote:
>> http://downloads.haskell.org/~ghc/8.0.1-rc2/
>
> Thank you for RC2.
>
I'm happy to help.

Sorry about the delayed response Jens; I'm still catching up after
some downtime due to sickness earlier this week.

> I finally built ghc-8.0.0 for Fedora Rawhide (quick build):
> https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1
> (perf build is still ongoing).
>
> One minor thing I noticed is that docdir seems have changed RC2 to be 
> versioned.
> ie the LICENSE files for the included libraries now get installed under
> "/usr/share/doc/ghc-/html/libraries/*/" rather than
> "/usr/share/doc/ghc/html/libraries/*/" before.
> I managed to work around that by configuring with
> --docdir=/usr/share/doc but it took me by surprise.
>
This was an intentional change; see #11354. I'll make sure it is
mentioned in the next release candidate announcement. Thanks for
mentioning this.

Cheers,

- Ben



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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-23 Thread Jens Petersen 
On 8 February 2016 at 03:13, Ben Gamari  wrote:
> http://downloads.haskell.org/~ghc/8.0.1-rc2/

Thank you for RC2.

I finally built ghc-8.0.0 for Fedora Rawhide (quick build):
https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1
(perf build is still ongoing).

One minor thing I noticed is that docdir seems have changed RC2 to be versioned.
ie the LICENSE files for the included libraries now get installed under
"/usr/share/doc/ghc-/html/libraries/*/" rather than
"/usr/share/doc/ghc/html/libraries/*/" before.
I managed to work around that by configuring with
--docdir=/usr/share/doc but it took me by surprise.

I should open a ticket I guess...

Jens
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 Thread Ben Gamari 
Sven Panne  writes:

> 2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel :
>
>> [...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't
>> introduce anything new.
>>
>
> I'm fine with "sigs", my point was only the fact that non-abbreviated words
> seem to be much more common in the flags names (and are easier to
> remember). IMHO it doesn't really matter if the flag names are long: One
> probably doesn't type them on the command line often, they typically live
> in .cabal files, .travis.yml and pragmas where you type them once.
>
> Well... the  -Wnoncanonical-*-instances flag family was the best I could
>> come up with which is reasonably self-descriptive... do you have any
>> better suggestions?
>>
>
> No, and I actually like the long names, see above. :-)

I don't have an opinion here. Especially with tab completion these names
are rarely typed anyways.

>> Fwiw, `ghc --show-options | grep binding` come ups empty
>>
>
> Then the docs are out-of-sync:
> http://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc-flag--Wlazy-unlifted-bindings
Indeed it appears that this warning was supposed to be removed in 7.10.

I've gone ahead and finished this in https://phabricator.haskell.org/D1922

Cheers,

- Ben


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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 Thread Sven Panne 
2016-02-16 10:49 GMT+01:00 Ben Gamari :

> [...] To this end I recommend the following,
>
>  * Someone propose a consistent vocabulary for warning flag names
>
>  * We keep -fwarn- flags as they are currently
>
>  * We keep the inconsistently named -W flags corresponding to these
>-fwarn- flags
>
>  * We add consistently named -W flags alongside these
>
>  * We set a timeline for deprecating the inconsistent flags
>

This plan looks perfect.


> Sven, perhaps you would like to pick up this task?
>

Alas, I don't have many spare development cycles at the moment, especially
given the relatively tight timeline for 8.0.1. I have just enough time to
grumble about some GHC details on this list. ;-) More seriously, after
Herbert's option survey my proposal is quite short:

   * Use "sigs" or "signatures" consistently (doesn't really matter which
one)

   * Use "pattern-synonyms", not "pat-syn"
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 Thread Sven Panne 
2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel :

> [...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't
> introduce anything new.
>

I'm fine with "sigs", my point was only the fact that non-abbreviated words
seem to be much more common in the flags names (and are easier to
remember). IMHO it doesn't really matter if the flag names are long: One
probably doesn't type them on the command line often, they typically live
in .cabal files, .travis.yml and pragmas where you type them once.

Well... the  -Wnoncanonical-*-instances flag family was the best I could
> come up with which is reasonably self-descriptive... do you have any
> better suggestions?
>

No, and I actually like the long names, see above. :-)


> Fwiw, `ghc --show-options | grep binding` come ups empty
>

Then the docs are out-of-sync:
http://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc-flag--Wlazy-unlifted-bindings
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 Thread Herbert Valerio Riedel 
On 2016-02-16 at 08:00:49 +0100, Sven Panne wrote:
>> I have renamed it to -Wmissing-pat-syn-signatures.
>>
>
> Hmmm, things are still wildly inconsistent:
>
>* "pat" is spelled "pattern" in other flags.
>
>* We still have both "sigs" and "signatures" as parts of the names.

I simple head-count in GHC HEAD:

-ddump-strsigs
-Wmissing-local-sigs
-Wmissing-exported-sigs

vs

-dsuppress-type-signatures
-Wmissing-signatures
-Wpartial-type-signatures


at this point I'd be fine with either

 -Wmissing-pattern-synonyms-signatures

or even

 -Wmissing-pattern-synonyms-sigs

as neither 'pattern' nor 'synonym` have any abbreviation precedent in
`ghc --show-options`, but `sig(nature)s` has a precedent, so
using `-sigs` wouldn't introduce anything new.


>* Why is "synonyms" too long, but OTOH we have monsters like
> "-Wnoncanonical-monadfail-instances"?

Well... the  -Wnoncanonical-*-instances flag family was the best I could
come up with which is reasonably self-descriptive... do you have any
better suggestions?

>* We have both "binds" and "bindings" as parts of the names.

Fwiw, `ghc --show-options | grep binding` come ups empty
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 Thread Ben Gamari 
Sven Panne  writes:

> 2016-02-16 0:35 GMT+01:00 Matthew Pickering :
>
>> I have renamed it to -Wmissing-pat-syn-signatures.
>>
>
> Hmmm, things are still wildly inconsistent:
>
>* "pat" is spelled "pattern" in other flags.
>
>* We still have both "sigs" and "signatures" as parts of the names.
>
>* Why is "synonyms" too long, but OTOH we have monsters like
> "-Wnoncanonical-monadfail-instances"?
>
>* We have both "binds" and "bindings" as parts of the names.
>
> My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix
> all those inconsistencies in one big sweep before 8.0.1 is out, it only
> gets harder later. At the moment you need #ifdef magic in the code and "If
> impl(foo)" in .cabal, anyway, but doing these changes later will only keep
> this sorry state for longer than necessary. I don't really care if we use
> abbreviations like "sigs" or not, but whatever we use, we should use it
> consistently (personally I would prefer the whole words, not the
> abbreviations).
>
Fair enough; since we are are breaking away from -fwarn- we could
consider taking this opportunity to fix these inconsistencies. However,
I do want to make sure that we don't make the transition any more
painful for users than necessary. For instance, the user should be able
to get useful feedback from the compiler on what warning flags have
changed with s/-fwarn-/-W/

To this end I recommend the following,

 * Someone propose a consistent vocabulary for warning flag names

 * We keep -fwarn- flags as they are currently

 * We keep the inconsistently named -W flags corresponding to these
   -fwarn- flags

 * We add consistently named -W flags alongside these
 
 * We set a timeline for deprecating the inconsistent flags

Sven, perhaps you would like to pick up this task?

Cheers,

- Ben


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

RE: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 Thread Simon Peyton Jones 
I’m all for it.   We could add the new spellings as synonyms of the old ones; 
and deprecate old ones.  Then drop the old ones after a release cycle or three

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Sven Panne
Sent: 16 February 2016 07:01
To: GHC developers <ghc-devs@haskell.org>
Subject: Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 0:35 GMT+01:00 Matthew Pickering 
<matthewtpicker...@gmail.com<mailto:matthewtpicker...@gmail.com>>:
I have renamed it to -Wmissing-pat-syn-signatures.

Hmmm, things are still wildly inconsistent:

   * "pat" is spelled "pattern" in other flags.

   * We still have both "sigs" and "signatures" as parts of the names.

   * Why is "synonyms" too long, but OTOH we have monsters like 
"-Wnoncanonical-monadfail-instances"?

   * We have both "binds" and "bindings" as parts of the names.

My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix all 
those inconsistencies in one big sweep before 8.0.1 is out, it only gets harder 
later. At the moment you need #ifdef magic in the code and "If impl(foo)" in 
.cabal, anyway, but doing these changes later will only keep this sorry state 
for longer than necessary. I don't really care if we use abbreviations like 
"sigs" or not, but whatever we use, we should use it consistently (personally I 
would prefer the whole words, not the abbreviations).

Cheers,
   S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Sven Panne 
2016-02-16 0:35 GMT+01:00 Matthew Pickering :

> I have renamed it to -Wmissing-pat-syn-signatures.
>

Hmmm, things are still wildly inconsistent:

   * "pat" is spelled "pattern" in other flags.

   * We still have both "sigs" and "signatures" as parts of the names.

   * Why is "synonyms" too long, but OTOH we have monsters like
"-Wnoncanonical-monadfail-instances"?

   * We have both "binds" and "bindings" as parts of the names.

My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix
all those inconsistencies in one big sweep before 8.0.1 is out, it only
gets harder later. At the moment you need #ifdef magic in the code and "If
impl(foo)" in .cabal, anyway, but doing these changes later will only keep
this sorry state for longer than necessary. I don't really care if we use
abbreviations like "sigs" or not, but whatever we use, we should use it
consistently (personally I would prefer the whole words, not the
abbreviations).

Cheers,
   S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Matthew Pickering 
Hello,

I have renamed it to -Wmissing-pat-syn-signatures.

Matt

On Mon, Feb 15, 2016 at 9:09 PM, Ben Gamari  wrote:
> Sven Panne  writes:
>
>> 2016-02-15 20:16 GMT+01:00 Ben Gamari :
>>
>>> Sven Panne  writes:
>>> The reason for this is that the things missing signatures are pattern
>>> synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs
>>> [1], which is enabled in -Wall by default.
>>>
>>
>> OK, I missed that in the release notes. Two points here:
>>
>>* The naming of the options is horrible, sometimes it's "sigs",
>> sometimes it's "signatures". I would prefer if we named them consistently
>> (probably "signatures", it's easier to search for).
>>
> Indeed, I noticed that this when looking this up for you. The
> inconsistency is quite unfortunate. Perhaps -Wmissing-pattern-signatures
> or -Wmissing-patsyn-signatures? -Wmissing-pattern-synonym-signatures is
> a bit of a mouthful.
>
>>* Given the myriad of warning-related options, It is *extremely* hard to
>> figure out which one caused the actual warning in question. The solution to
>> this is very easy and done this way in clang/gcc (don't remember which one,
>> I'm switching quite often): Just suffix all warnings consistently with the
>> option causing it, e.g.
>>
> Indeed, this is #10752, as hvr pointed out. I'm not sure whether David
> has done anything on this yet; feel free to take a stab at implementing
> it if you have some free time.
>
> - Ben
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Ben Gamari 
Sven Panne  writes:

> 2016-02-15 20:16 GMT+01:00 Ben Gamari :
>
>> Sven Panne  writes:
>> The reason for this is that the things missing signatures are pattern
>> synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs
>> [1], which is enabled in -Wall by default.
>>
>
> OK, I missed that in the release notes. Two points here:
>
>* The naming of the options is horrible, sometimes it's "sigs",
> sometimes it's "signatures". I would prefer if we named them consistently
> (probably "signatures", it's easier to search for).
>
Indeed, I noticed that this when looking this up for you. The
inconsistency is quite unfortunate. Perhaps -Wmissing-pattern-signatures
or -Wmissing-patsyn-signatures? -Wmissing-pattern-synonym-signatures is
a bit of a mouthful.

>* Given the myriad of warning-related options, It is *extremely* hard to
> figure out which one caused the actual warning in question. The solution to
> this is very easy and done this way in clang/gcc (don't remember which one,
> I'm switching quite often): Just suffix all warnings consistently with the
> option causing it, e.g.
>
Indeed, this is #10752, as hvr pointed out. I'm not sure whether David
has done anything on this yet; feel free to take a stab at implementing
it if you have some free time.

- Ben



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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Herbert Valerio Riedel 
On 2016-02-15 at 21:05:29 +0100, Sven Panne wrote:

[...]

>* Given the myriad of warning-related options, It is *extremely* hard to
> figure out which one caused the actual warning in question. The solution to
> this is very easy and done this way in clang/gcc (don't remember which one,
> I'm switching quite often): Just suffix all warnings consistently with the
> option causing it, e.g.
>
> Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]:
> 

Fyi, https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings

and specifically https://ghc.haskell.org/trac/ghc/ticket/10752

:-)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Sven Panne 
2016-02-15 20:16 GMT+01:00 Ben Gamari :

> Sven Panne  writes:
> The reason for this is that the things missing signatures are pattern
> synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs
> [1], which is enabled in -Wall by default.
>

OK, I missed that in the release notes. Two points here:

   * The naming of the options is horrible, sometimes it's "sigs",
sometimes it's "signatures". I would prefer if we named them consistently
(probably "signatures", it's easier to search for).

   * Given the myriad of warning-related options, It is *extremely* hard to
figure out which one caused the actual warning in question. The solution to
this is very easy and done this way in clang/gcc (don't remember which one,
I'm switching quite often): Just suffix all warnings consistently with the
option causing it, e.g.

Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]:


Cheers,
   S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Ben Gamari 
Sven Panne  writes:

> I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the
> current discussion about -Wcompat and friends I decided to take a detailed
> look at the warnings in my projects and hit a regression(?): Somehow I'm
> unable to suppress the "Top-level binding with no type signature" warnings
> from 8.0.1 onwards.
>
> The gory details: In my .cabal file I set -Wall (
> https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L618),
> and in my .travis.yml I set -Werror (
> https://github.com/haskell-opengl/OpenGLRaw/blob/master/.travis.yml#L76).
> But the -Wno-missing-signatures pragma (
> https://github.com/haskell-opengl/OpenGLRaw/blob/master/src/Graphics/GL/Tokens.hs#L2)
> doesn't work, see
> https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109400373. Using
> -fno-warn-missing-signatures didn't work, either, see
> https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109396738.
>
> Am I doing something wrong here or is this really a regression? I'm quite
> sure that suppressions via pragmas worked in the past... :-(
>
The reason for this is that the things missing signatures are pattern
synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs
[1], which is enabled in -Wall by default.

Cheers,

- Ben


[1] 
http://downloads.haskell.org/~ghc/master/users-guide//using-warnings.html#ghc-flag--Wmissing-pat-syn-sigs


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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 Thread Sven Panne 
I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the
current discussion about -Wcompat and friends I decided to take a detailed
look at the warnings in my projects and hit a regression(?): Somehow I'm
unable to suppress the "Top-level binding with no type signature" warnings
from 8.0.1 onwards.

The gory details: In my .cabal file I set -Wall (
https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L618),
and in my .travis.yml I set -Werror (
https://github.com/haskell-opengl/OpenGLRaw/blob/master/.travis.yml#L76).
But the -Wno-missing-signatures pragma (
https://github.com/haskell-opengl/OpenGLRaw/blob/master/src/Graphics/GL/Tokens.hs#L2)
doesn't work, see
https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109400373. Using
-fno-warn-missing-signatures didn't work, either, see
https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109396738.

Am I doing something wrong here or is this really a regression? I'm quite
sure that suppressions via pragmas worked in the past... :-(

Cheers,
   S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-09 Thread Ben Gamari 
Joachim Breitner  writes:

> Hi,
>
> Am Sonntag, den 07.02.2016, 19:13 +0100 schrieb Ben Gamari:
>> As always, we look forward to hearing about any issues that you
>> encounter with this candidate. Thanks to everyone who has contributed so
>> far!
>
> I cannot bootstrap 8.0.1-rc2 with 8.0.1-rc1
>
> unrecognised flag: -this-unit-id
>
> Usage: For basic information, try the `--help' option.
> https://buildd.debian.org/status/fetch.php?pkg=ghc=arm64=8.0.0.20160204-1=1454952602
>
>
> I didn’t quite follow the Cabal issues on the tickets list, so this
> might be known, but it certainly should not happen.
>
> Or is this a problem with 8.0.1-rc1 and I should just avoid that
> version somehow, and it will bootstrap with 8.0.1-rc2 just fine?
>
Yes, this should merely be a problem with -rc1. Edward Yang did
some cleanups of the package-system command-line flags in -rc2. The
original goal of this was to ensure that users with older Cabals aren't
surprised with the terrible errors that they are currently faced with [1].
Sadly this didn't quite get resolved in -rc2, however. See D1892 [2] for
one possible future direction for putting this issue to rest.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/ticket/11558
[2] https://phabricator.haskell.org/D1892


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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-09 Thread Joachim Breitner 
Hi,

Am Sonntag, den 07.02.2016, 19:13 +0100 schrieb Ben Gamari:
> As always, we look forward to hearing about any issues that you
> encounter with this candidate. Thanks to everyone who has contributed so
> far!

I cannot bootstrap 8.0.1-rc2 with 8.0.1-rc1

   Bootstrapping using   : /usr/bin/ghc
  which is version   : 8.0.0.20160111
[..]
"rm" -f compiler/stage1/build/.depend-v.haskell.tmp  
"/usr/bin/ghc" -M -static  -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold 
-Wall   -package-db libraries/bootstrapping.conf  -this-unit-id 
ghc-8.0.0.20160204 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm 
-icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci 
-icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main 
-icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling 
-icompiler/rename -icompiler/simplCore -icompiler/simplStg 
-icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck 
-icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build 
-icompiler/stage1/build/autogen -Icompiler/stage1/build 
-Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils 
-Icompiler/stage1-optP-include 
-optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0 
-package-id base-4.9.0.0 -package-id binary-0.8.2.0 -package-id 
bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id 
directory-1.2.5.0 -package-id filepath-1.4.1.0 -package-id 
ghc-boot-8.0.0.20160204 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 
-package-id process-1.4.1.0 -package-id template-haskell-2.11.0.0 -package-id 
time-1.6 -package-id transformers-0.5.1.0 -package-id unix-2.7.1.1 -Wall 
-fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -DNO_REGS -DNOSMP 
-optc-DNOSMP -DSTAGE=1 -Rghc-timing   -no-user-package-db -rtsopts   -odir 
compiler/stage1/build -hidir compiler/stage1/build -stubdir 
compiler/stage1/build -dep-makefile compiler/stage1/build/.depend-v.haskell.tmp 
-dep-suffix "" -include-pkg-deps  compiler/basicTypes/Avail.hs  
compiler/basicTypes/BasicTypes.hs  compiler/basicTypes/ConLike.hs  
compiler/basicTypes/DataCon.hs  compiler/basicTypes/PatSyn.hs  
compiler/basicTypes/Demand.hs  compiler/cmm/Debug.hs  
compiler/utils/Exception.hs  compiler/basicTypes/FieldLabel.hs  
compiler/main/GhcMonad.hs  compiler/main/Hooks.hs  compiler/basicTypes/Id.hs  
compiler/basicTypes/IdInfo.hs  compiler/basicTypes/Lexeme.hs  
compiler/basicTypes/Literal.hs  compiler/llvmGen/Llvm.hs  
compiler/llvmGen/Llvm/AbsSyn.hs  compiler/llvmGen/Llvm/MetaData.hs  
compiler/llvmGen/Llvm/PpLlvm.hs  compiler/llvmGen/Llvm/Types.hs  
compiler/llvmGen/LlvmCodeGen.hs  compiler/llvmGen/LlvmCodeGen/Base.hs  
compiler/llvmGen/LlvmCodeGen/CodeGen.hs  compiler/llvmGen/LlvmCodeGen/Data.hs  
compiler/llvmGen/LlvmCodeGen/Ppr.hs  compiler/llvmGen/LlvmCodeGen/Regs.hs  
compiler/llvmGen/LlvmMangler.hs  compiler/basicTypes/MkId.hs  
compiler/basicTypes/Module.hs  compiler/basicTypes/Name.hs  
compiler/basicTypes/NameEnv.hs  compiler/basicTypes/NameSet.hs  
compiler/basicTypes/OccName.hs  compiler/basicTypes/RdrName.hs  
compiler/basicTypes/SrcLoc.hs  compiler/basicTypes/UniqSupply.hs  
compiler/basicTypes/Unique.hs  compiler/basicTypes/Var.hs  
compiler/basicTypes/VarEnv.hs  compiler/basicTypes/VarSet.hs  
compiler/utils/UnVarGraph.hs  compiler/cmm/BlockId.hs  compiler/cmm/CLabel.hs  
compiler/cmm/Cmm.hs  compiler/cmm/CmmBuildInfoTables.hs  
compiler/cmm/CmmPipeline.hs  compiler/cmm/CmmCallConv.hs  
compiler/cmm/CmmCommonBlockElim.hs  compiler/cmm/CmmImplementSwitchPlans.hs  
compiler/cmm/CmmContFlowOpt.hs  compiler/cmm/CmmExpr.hs  
compiler/cmm/CmmInfo.hs  compiler/cmm/CmmLex.hs  compiler/cmm/CmmLint.hs  
compiler/cmm/CmmLive.hs  compiler/cmm/CmmMachOp.hs  compiler/cmm/CmmSwitch.hs  
compiler/cmm/CmmNode.hs  compiler/cmm/CmmOpt.hs  compiler/cmm/CmmParse.hs  
compiler/cmm/CmmProcPoint.hs  compiler/cmm/CmmSink.hs  compiler/cmm/CmmType.hs  
compiler/cmm/CmmUtils.hs  compiler/cmm/CmmLayoutStack.hs  
compiler/cmm/MkGraph.hs  compiler/nativeGen/PprBase.hs  compiler/cmm/PprC.hs  
compiler/cmm/PprCmm.hs  compiler/cmm/PprCmmDecl.hs  compiler/cmm/PprCmmExpr.hs  
compiler/cmm/Bitmap.hs  compiler/codeGen/CodeGen/Platform.hs  
compiler/codeGen/CodeGen/Platform/ARM.hs  
compiler/codeGen/CodeGen/Platform/ARM64.hs  
compiler/codeGen/CodeGen/Platform/NoRegs.hs  
compiler/codeGen/CodeGen/Platform/PPC.hs  
compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs  
compiler/codeGen/CodeGen/Platform/SPARC.hs  
compiler/codeGen/CodeGen/Platform/X86.hs  
compiler/codeGen/CodeGen/Platform/X86_64.hs  compiler/codeGen/CgUtils.hs  
compiler/codeGen/StgCmm.hs  compiler/codeGen/StgCmmBind.hs  
compiler/codeGen/StgCmmClosure.hs  compiler/codeGen/StgCmmCon.hs  
compiler/codeGen/StgCmmEnv.hs  compiler/codeGen/StgCmmExpr.hs  
compiler/codeGen/StgCmmForeign.hs  compiler/codeGen/StgCmmHeap.hs  
compiler/codeGen/StgCmmHpc.hs  

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-08 Thread Ben Gamari 
Ben Gamari  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


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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-08 Thread Ben Gamari 
Páli Gábor János  writes:

> Hello there,
>
> 2016-02-07 19:13 GMT+01:00 Ben Gamari :
>> 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



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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-07 Thread Ben Gamari 
George Colpitts  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



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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-07 Thread George Colpitts 
Good news! I assume there will be a Mac OS binary distribution soon?

On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari  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-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-07 Thread Ben Gamari 
Ben Gamari  writes:

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


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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-07 Thread Páli Gábor János 
Hello there,

2016-02-07 19:13 GMT+01:00 Ben Gamari :
> 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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs