[ANNOUNCE] GHC 8.2.2 release candidate 2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] GHC 8.2.2 release candidate 2

Ben Gamari-3

Hello everyone,

The GHC team is very pleased to announce the second candidate of the
8.2.2 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

    https://downloads.haskell.org/~ghc/8.2.2-rc2/

This is the second and hopefully last of two release candidates leading
up the final 8.2.2 release. This release fixes approximately fifty bugs
present in 8.2.1. These most notably include,

 * A correctness issue resulting in segmentation faults in some
   FFI-users (#13707, #14346)

 * A correctness issue resulting in undefined behavior in some programs
   using STM (#14171)

 * A bug which may have manifested in segmentation faults in
   out-of-memory condition (#14329)

 * clearBit of Natural no longer bottoms (#13203)

 * A specialisation bug resulting in exponential blowup of compilation
   time in some specialisation-intensive programs (#14379)

 * ghc-pkg now works even in environments with misconfigured NFS mounts
   (#13945)

 * GHC again supports production of position-independent executables
   (#13702)

 * Better error messages around kind mismatches (#11198, #12373, #13530,
   #13610)

See [1] for the full list.

As always, please report any issues you encounter.

Happy testing,

- Ben


[1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority

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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2

Sven Panne-2
This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode due to some ad hoc changes like https://phabricator.haskell.org/D3651. Related GitHub issues:


It should be noted that the output of GHC(i) is actually part of GHC's interface, so in this light, there have been some breaking changes, probably unintended, but nevertheless. So my question is: Is there a chance to revert some of these ad hoc changes and/or add some flags to get the old behavior back? I guess that Emacs + haskell-mode is one of the most important IDEs, so it would be a pity to worsen the situation there.

I'm quite aware that it is very late in the release cycle, but it would be extremely nice if there was something which can be done. In the future it might make sense to co-operate with the haskell-mode team a bit more, perhaps adding some tests regarding the required output format etc. to GHC's test suite.

Cheers,
   S.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

Sven Panne-2
2017-11-05 15:37 GMT+01:00 <[hidden email]>:
A better approach might be to develop a "machine-readable" output format which then is kept stable, and can be enabled with a flag. Git has a similar solution.

Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable.
 
It would be a shame to avoid changes which make the user experience better simply because other projects cannot sync their development cycle,

Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse.
 
especially if those projects are not universally used or required.

This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs?

Cheers,
   S.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2

Evan Laforge
In reply to this post by Sven Panne-2
On Sun, Nov 5, 2017 at 4:56 AM, Sven Panne <[hidden email]> wrote:
> This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent
> discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode
> due to some ad hoc changes like https://phabricator.haskell.org/D3651.

I've long used ghci -v0 to achieve the same effect.  When you have a
couple hundred modules the "loaded X Y Z" is worse than useless.  But
it's better to just add -v0, and maybe add more flags for finer
control, than change the default and break tools.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

Ben Gamari-3
In reply to this post by Sven Panne-2

Next time something like this arises please do open a ticket.


Sven Panne <[hidden email]> writes:

> 2017-11-05 15:37 GMT+01:00 <[hidden email]>:
>
>> A better approach might be to develop a "machine-readable" output format
>> which then is kept stable, and can be enabled with a flag. Git has a
>> similar solution.
>>
>
> Without doubt, this is definitely the better approach, but this is hardly
> what can be achieved for 8.2.2. Adding some flag to get the old behavior
> back when wanted *is* achievable.
>
Yes, I have opened a differential adding such a flag. See D4164 [1].
Please bikeshed to taste.

In general I would really prefer that we *not* consider GHCi's REPL to be
a stable programmatic interface. If haskell-mode needs access to some
bit of information from GHC, then please let's discuss how to provide it
in a more robust manner. This shouldn't be hard; we just need to have
feedback on what the interfaces required should look like.

[1] https://phabricator.haskell.org/D4164

>
>> It would be a shame to avoid changes which make the user experience better
>> simply because other projects cannot sync their development cycle,
>>
>
> Don't get me wrong: I'm all for improving user experience, but making ad
> hoc changes without enough thought or even a chance to get the old behavior
> back is probably not the right way to proceed. All SW lives in some kind of
> ecosystem, so it should behave well in that. And for Emacs users, the user
> experience has been made much worse.
>
The trouble is that GHC has an extremely large surface area, any bit of
which might have mechanical consumers. Those who reviewed the patch
indeed considered making this change behind a flag (as Francesco's
original patch did) but we concluded that this would be pointless as it
didn't seem likely that anyone relied on this behavior. It seems that in
this case we were wrong

That being said, we cannot always preemptively add complexity to the
project out of fear that a given change might break a hypothetical
mechanical consumer. GHCi is first-and-foremost a REPL for users.
When evaluating a change, if we feel it is likely that we will break a
mechanical user then we will likely guard the change with a flag.
However, if not, we won't.

Cheers,

- Ben

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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

Sven Panne-2
2017-11-06 17:54 GMT+01:00 Ben Gamari <[hidden email]>:
Next time something like this arises please do open a ticket.

Yep, will do...
 
Yes, I have opened a differential adding such a flag. See D4164 [1].
Please bikeshed to taste.

Thanks for the quick fix!
 
In general I would really prefer that we *not* consider GHCi's REPL to be
a stable programmatic interface.

I fully understand that, and that's definitely the way to go. Nevertheless, parsing tool/compiler output is still one of the most used hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs). Not every project is as open to suggestions and changes as GHC is, so this is often the only way out.
 
That being said, we cannot always preemptively add complexity to the
project out of fear that a given change might break a hypothetical
mechanical consumer.

That's of course not what was proposed. :-)
 
GHCi is first-and-foremost a REPL for users.
When evaluating a change, if we feel it is likely that we will break a
mechanical user then we will likely guard the change with a flag.
However, if not, we won't.

I think the main problem here was communication. I can't speak for the haskell-mode maintainers, but for my part I didn't notice the problems because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This is definitely part of the whole problem.). I tried the 8.2 series only sparingly and only via the command line, so this is perhaps what others did, too, so the interaction bug went unnoticed for such a long time.

Cheers,
   Sven

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