Posted
over 6 years
ago
by
Ben Gamari
Looking back on GHC's past release schedule reveals a rather checkered past,
Release
Date
Time to next major release
6.12.1
mid December 2009
12 months
7.0.1
... [More]
mid November 2010
9.5 months
7.2.1
early August 2011
6 months
7.4.1
early February 2012
7 months
7.6.1
early September 2012
19 months
7.8.1
early April 2014
13 months
7.10.1
late March 2015
14 months
8.0.1
late May 2016
14 months
8.2.1
late July 2017
-
8.4.1
TDB and the topic of this post
There are a few things to notice here:
release cadence has swung rather wildly
the release cycle has stretched in the last several releases
time-between-releases generally tends to be on the order of a year
While GHC is far from the only compiler with such an extended release
schedule, others (namely LLVM, Go, and, on the extreme end, Rust) have shown
that shorter cycles are possible. I personally think that a more
stable, shorter release cycle would be better for developers and users
alike,
developers have a tighter feedback loop, inducing less pressure
to get new features and non-critical bugfixes into minor releases
release managers have fewer patches to cherry-pick
users see new features and bugfixes more quickly
With 8.2.1 at long last behind us, now is a good time to reflect
on why these cycles are so long, what release schedule we would like
to have, and what we can change to realize such a schedule. On the way we'll take some time to examine the circumstances that lead to the 8.2.1 release which, while not typical, remind us that there is a certain amount of unpredictability inherent in developing large systems like GHC; a fact that must be born in mind when considering release policy.
Let's dig in...
The release process today
Cutting a GHC release is a fairly lengthy process involving many
parties and a significant amount of planning. The typical process
for a major release looks something like this,
(a few months after the previous major release) A set
of release priorities are defined determining which major features
we want in the coming release
wait until all major features are merged to the master branch
when all features are merged, cut a stable branch
in parallel:
coordinate with core library authors to determine which library
versions the new release should ship
prepare release documentation
do preliminary testing against Hackage and Stackage to identify and
fix early bugs
backport significant fixes merged to master
when the tasks in (4) are sufficiently advanced, cut a source
release for a release candidate
produce tier-1 builds and send source tarballs to binary packagers,
wait a week to prepare binary builds; if anyone finds the tree is
unbuildable, go back to (5)
upload release artifacts, announce release candidate
wait a few weeks for testing
if there are significant issues: fix them and return to (5)
finalize release details (e.g. release notes, last check over core library versions)
cut source tarball, send to binary build contributors, wait a week for builds
announce final release, celebrate!
Typically the largest time-sinks in this process are waiting for
regression fixes and coordinating with core library authors. In
particular, the coordination involved in the latter isn't difficult, but
merely high latency.
In the case of 8.2.1, the timeline looked something like this,
Time
Event
Fall 2016
release priorities for 8.2 discussed
Early March 2017
stable branch cut
Early April 2017
most core library versions set
release candidate 1 cut
Mid May 2017
release candidate 2 cut
Early July 2017
release candidate 3 cut
Late July 2017
final release cut
Unexpected set-backs
This timeline was a bit more extended than desired for a few
reasons.
The first issues were #13426 and #13535, compile-time performance regressions which
came to light shortly after the branch and after the first release
candidate, respectively. In #13535 it was observed that the testsuite of
the vector package (already
known for its
propensity to reveal compiler regressions) increased by nearly a factor
of five in compile-time allocations over 8.0.2.
While a performance regression would rarely classify as a release
blocker, both the severity of the regressions combined with the fact that
8.2 was intended to be a performance-oriented release made releasing
before fixes were available quite unappealing. For this reason David
Feuer, Reid Barton, and I invested significant effort to try to track down the
culprits. Unfortunately, the timescale on which this sort of bug is
resolved span days, stretching to weeks when time is split with other
responsibilities. While Reid's valiant efforts lead to the resolution of
#13426, we were eventually forced to set #13535 aside as the release
cycle wore on.
The second setback came in the form of two quite grave correctness
issues (#13615, #13916) late in the cycle. GHC being a compiler, we take
correctness very seriously: Users' confidence that GHC will
compile their programs faithfully is crucial for language adoption, yet
also very easily shaken. Consequently, while neither of these issues
were regressions from 8.0, we deemed it important to hold the 8.2
release until these issues were resolved (which ended up being significant efforts in their own right; a blog post on this will be coming soon).
Finally, there was the realization (#13739) after release candidate 2
that some BFD linker releases suffered from very poor performance when
linking with split-sections enabled (the default behavior in 8.2.1).
This served as a forcing function to act on #13541, which we originally
planned for 8.4. As expected, it took quite some time to follow through
on this in a way that satisfied users and distribution packagers in a
portable manner.
Moving forward: Compressing the release schedule
Collectively the above issues set the release back by perhaps six or
eight weeks in total, including the additional release candidate
necessary to validate the raft of resulting patches. While set-backs due
to long-standing bugs are hard to avoid, there are a few areas where we
can do better,
automate the production of release artifacts
regularly test GHC against user packages in between releases
expand continuous integration of GHC to less common platforms to
ensure that compatibility problems are caught before the release
candidate stage
regularly synchronize with core library maintainers between releases
to reduce need for version bound bumps at release time
putting in place tools to ease bisection, which is frequently a
useful debugging strategy around release-time
As it turns out, nearly all of these are helped by our on-going effort
to move GHC's CI infrastructure to Jenkins (see #13716). As this is a
rather deep topic in its own right, I'll leave this more technical
discussion for a second post (blog:jenkins-ci).
With the above tooling and process improvements, I think it would be
feasible to get the GHC release cycle down to six months or shorter if
we so desired. Of course, shorter isn't necessarily better: we need to
be careful to balance the desire for a short release cycle against the
need for an adequate post-release "percolation" time. This time is crucial to allow the community
to adopt the new release, discover and fix its regressions. In fact, the
predictability that a short release schedule (hopefully) affords is
arguably more important than the high cadence itself.
Consequently, we are considering tightening up the release schedule for
future GHC releases in a slow and measured manner. Given that we are now
well into the summer, I think positioning the 8.4 release around
February 2018, around seven months from now, would be a sensible
timeline. However, we would like to hear your opinions.
Here are some things to think about,
Do you feel that it takes too long for GHC features to make it to users' hands?
How many times per year do you envision upgrading your compiler
before the process becomes too onerous? Would the current load of interface changes per release be acceptable under a faster release cadence?
Should we adjust the
three-release policy
to counteract a shorter GHC release cycle?
Would you feel more likely to contribute to GHC if your work were more quickly available in a release?
We would love to hear your thoughts. Be sure to mention whether you are a user, GHC contributor, or both.
[Less]
|
Posted
over 6 years
ago
by
Ben Gamari
Looking back on GHC's past release schedule reveals a rather checkered past,
Release
Date
Time to next major release
6.12.1
mid December 2009
12 months
7.0.1
... [More]
mid November 2010
9.5 months
7.2.1
early August 2011
6 months
7.4.1
early February 2012
7 months
7.6.1
early September 2012
19 months
7.8.1
early April 2014
13 months
7.10.1
late March 2015
14 months
8.0.1
late May 2016
14 months
8.2.1
late July 2017
-
8.4.1
TDB and the topic of this post
There are a few things to notice here:
release cadence has swung rather wildly
the release cycle has stretched in the last several releases
time-between-releases generally tends to be on the order of a year
While GHC is far from the only compiler with such an extended release
schedule, others (namely LLVM, Go, and, on the extreme end, Rust) have shown
that shorter cycles are possible. I personally think that a more
stable, shorter release cycle would be better for developers and users
alike,
developers have a tighter feedback loop, inducing less pressure
to get new features and non-critical bugfixes into minor releases
release managers have fewer patches to cherry-pick
users see new features and bugfixes more quickly
With 8.2.1 at long last behind us, now is a good time to reflect
on why these cycles are so long, what release schedule we would like
to have, and what we can change to realize such a schedule. On the way we'll take some time to examine the circumstances that lead to the 8.2.1 release which, while not typical, remind us that there is a certain amount of unpredictability inherent in developing large systems like GHC; a fact that must be born in mind when considering release policy.
Let's dig in...
The release process today
Cutting a GHC release is a fairly lengthy process involving many
parties and a significant amount of planning. The typical process
for a major release looks something like this,
(a few months after the previous major release) A set
of release priorities are defined determining which major features
we want in the coming release
wait until all major features are merged to the master branch
when all features are merged, cut a stable branch
in parallel:
coordinate with core library authors to determine which library
versions the new release should ship
prepare release documentation
do preliminary testing against Hackage and Stackage to identify and
fix early bugs
backport significant fixes merged to master
when the tasks in (4) are sufficiently advanced, cut a source
release for a release candidate
produce tier-1 builds and send source tarballs to binary packagers,
wait a week to prepare binary builds; if anyone finds the tree is
unbuildable, go back to (5)
upload release artifacts, announce release candidate
wait a few weeks for testing
if there are significant issues: fix them and return to (5)
finalize release details (e.g. release notes, last check over core library versions)
cut source tarball, send to binary build contributors, wait a week for builds
announce final release, celebrate!
Typically the largest time-sinks in this process are waiting for
regression fixes and coordinating with core library authors. In
particular, the coordination involved in the latter isn't difficult, but
merely high latency.
In the case of 8.2.1, the timeline looked something like this,
Time
Event
Fall 2016
release priorities for 8.2 discussed
Early March 2017
stable branch cut
Early April 2017
most core library versions set
release candidate 1 cut
Mid May 2017
release candidate 2 cut
Early July 2017
release candidate 3 cut
Late July 2017
final release cut
Unexpected set-backs
This timeline was a bit more extended than desired for a few
reasons.
The first issues were #13426 and #13535, compile-time performance regressions which
came to light shortly after the branch and after the first release
candidate, respectively. In #13535 it was observed that the testsuite of
the vector package (already
known for its
propensity to reveal compiler regressions) increased by nearly a factor
of five in compile-time allocations over 8.0.2.
While a performance regression would rarely classify as a release
blocker, both the severity of the regressions combined with the fact that
8.2 was intended to be a performance-oriented release made releasing
before fixes were available quite unappealing. For this reason David
Feuer, Reid Barton, and I invested significant effort to try to track down the
culprits. Unfortunately, the timescale on which this sort of bug is
resolved span days, stretching to weeks when time is split with other
responsibilities. While Reid's valiant efforts lead to the resolution of
#13426, we were eventually forced to set #13535 aside as the release
cycle wore on.
The second setback came in the form of two quite grave correctness
issues (#13615, #13916) late in the cycle. GHC being a compiler, we take
correctness very seriously: Users' confidence that GHC will
compile their programs faithfully is crucial for language adoption, yet
also very easily shaken. Consequently, while neither of these issues
were regressions from 8.0, we deemed it important to hold the 8.2
release until these issues were resolved (which ended up being significant efforts in their own right; a blog post on this will be coming soon).
Finally, there was the realization (#13739) after release candidate 2
that some BFD linker releases suffered from very poor performance when
linking with split-sections enabled (the default behavior in 8.2.1).
This served as a forcing function to act on #13541, which we originally
planned for 8.4. As expected, it took quite some time to follow through
on this in a way that satisfied users and distribution packagers in a
portable manner.
Moving forward: Compressing the release schedule
Collectively the above issues set the release back by perhaps six or
eight weeks in total, including the additional release candidate
necessary to validate the raft of resulting patches. While set-backs due
to long-standing bugs are hard to avoid, there are a few areas where we
can do better,
automate the production of release artifacts
regularly test GHC against user packages in between releases
expand continuous integration of GHC to less common platforms to
ensure that compatibility problems are caught before the release
candidate stage
regularly synchronize with core library maintainers between releases
to reduce need for version bound bumps at release time
putting in place tools to ease bisection, which is frequently a
useful debugging strategy around release-time
As it turns out, nearly all of these are helped by our on-going effort
to move GHC's CI infrastructure to Jenkins (see #13716). As this is a
rather deep topic in its own right, I'll leave this more technical
discussion for a second post (blog:jenkins-ci).
With the above tooling and process improvements, I think it would be
feasible to get the GHC release cycle down to six months or shorter if
we so desired. Of course, shorter isn't necessarily better: we need to
be careful to balance the desire for a short release cycle against the
need for an adequate post-release "percolation" time. This time is crucial to allow the community
to adopt the new release, discover and fix its regressions. In fact, the
predictability that a short release schedule (hopefully) affords is
arguably more important than the high cadence itself.
Consequently, we are considering tightening up the release schedule for
future GHC releases in a slow and measured manner. Given that we are now
well into the summer, I think positioning the 8.4 release around
February 2018, around seven months from now, would be a sensible
timeline. However, we would like to hear your opinions.
Here are some things to think about,
Do you feel that it takes too long for GHC features to make it to users' hands?
How many times per year do you envision upgrading your compiler
before the process becomes too onerous? Would the current load of interface changes per release be acceptable under a faster release cadence?
Should we adjust the
three-release policy
to counteract a shorter GHC release cycle?
Would you feel more likely to contribute to GHC if your work were more quickly available in a release?
We would love to hear your thoughts. Be sure to mention whether you are a user, GHC contributor, or both.
[Less]
|
Posted
almost 7 years
ago
by
Ben Gamari
The Glasgow Haskell Compiler -- version 8.2.1
The GHC developers are very happy to announce the long-awaited 8.2.1
release of Glasgow Haskell Compiler. Binary and source distributions can
be found at
... [More]
<https://downloads.haskell.org/~ghc/8.2.1/>.
This is the second release in the 8.0 series. As such, the focus of this
release is performance, stability, and consolidation. Consequently
numerous cleanups can be seen throughout the compiler including,
Significant improvements in compiler performance
More robust support for levity polymorphism
Reliable DWARF debugging information
Improved runtime system performance on NUMA systems
Retooling of the cost-center profiler, including support for live
streaming of profile data via the GHC event log
Interface file determinism
More robust treatment of join points, enabling significantly better
code generation in many cases
Numerous improvements in robustness on Windows
and the resolution of over 500 other tickets
In addition, there are a number of new features,
A new, more type-safe type reflection mechanism
The long-awaited Backpack module system
Deriving strategies to disambiguate between GHC's various instance
deriving mechanisms
Unboxed sum types, for efficient unpacked representation of sum data
types
Compact regions, allowing better control over garbage collection
in the presence of large heaps containing many long-lived objects.
Colorful messages and caret diagnostics for more legible errors
A more thorough list of the changes in this release can be found in the
[[https://haskell.org/ghc/docs/8.2.1/html/users_guide/8.2.1-notes.html
|release notes]].
There are a few changes in release-engineering that should be noted,
Binary distributions for 32-bit CentOS 6.7 have been dropped.
Moreover, there are no dedicated CentOS 7.0 distributions as CentOS 7
can use can use Debian 8 binaries. If you would like us to continue
to produce 32-bit CentOS 6.7 distributions please let us know.
GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this
comes after many years of these distributions being faithfully
provided by Karel Gardas and Pali Gabor Janos, who we should heartily
thank for their contributions.
GHC HQ building these distributions ourselves will allow us to more
quickly ship distributions to users by eliminating the need for a
long lag time between source release availability and having all
binary distributions available.
There is a technology-preview of an AArch64 Linux binary
distribution, as well as an ARM Linux build. AArch64 support is quite
preliminary but should be stable in 8.4 thanks to further linker
fixes by Moritz Angerman. ARM should be stable.
GHC now tries to use the gold and lld linkers by default. These
linkers are significantly faster than the BFD linker implementation
that most Linux distributions use by default. If gold or lld are not
available GHC will use the system's default linker. GHC can be forced
to use the default linker by passing --disable-ld-override to
configure.
This release has been the result of over a year of hard work by over 150
code contributors. Thanks to everyone who has helped in writing patches,
testing, reporting bugs, and offering feedback over the last year.
This release cycle was admittedly quite drawn out, significantly longer
than expected or desired. While we are confident that the result is
worth the wait, we have been steadily working on infrastructure which
should help shrink future release cycles and give us better testing
between releases. More details on this coming soon.
As always, let us know if you encounter trouble.
How to get it
Both the source tarball and binary distributions for a wide variety of platforms are available here.
Background
Haskell is a standard lazy functional programming language.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating efficient code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces. GHC is distributed under a BSD-style open source license.
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).
On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page
GHC developers' home page
Haskell home page
Supported Platforms
The list of platforms we support, and the people responsible for them,
is here
Ports to other platforms are possible with varying degrees of
difficulty. The Building Guide describes how to go about porting to a
new platform.
Developers
We welcome new contributors. Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac.
Community Resources
There are mailing lists for GHC users, developers, and monitoring bug tracker
activity; to subscribe, use the Mailman
web interface.
There are several other Haskell and GHC-related mailing lists on
haskell.org; for the full list, see the
lists page.
Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC
network, too. See the Haskell wiki for details.
Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here.
[Less]
|
Posted
almost 7 years
ago
by
Ben Gamari
The Glasgow Haskell Compiler -- version 8.2.1
The GHC developers are very happy to announce the long-awaited 8.2.1
release of Glasgow Haskell Compiler. Binary and source distributions can
be found at
... [More]
<https://downloads.haskell.org/~ghc/8.2.1/>.
This is the second release in the 8.0 series. As such, the focus of this
release is performance, stability, and consolidation. Consequently
numerous cleanups can be seen throughout the compiler including,
Significant improvements in compiler performance
More robust support for levity polymorphism
Reliable DWARF debugging information
Improved runtime system performance on NUMA systems
Retooling of the cost-center profiler, including support for live
streaming of profile data via the GHC event log
Interface file determinism
More robust treatment of join points, enabling significantly better
code generation in many cases
Numerous improvements in robustness on Windows
and the resolution of over 500 other tickets
In addition, there are a number of new features,
A new, more type-safe type reflection mechanism
The long-awaited Backpack module system
Deriving strategies to disambiguate between GHC's various instance
deriving mechanisms
Unboxed sum types, for efficient unpacked representation of sum data
types
Compact regions, allowing better control over garbage collection
in the presence of large heaps containing many long-lived objects.
Colorful messages and caret diagnostics for more legible errors
A more thorough list of the changes in this release can be found in the
[[https://haskell.org/ghc/docs/8.2.1/html/users_guide/8.2.1-notes.html
|release notes]].
There are a few changes in release-engineering that should be noted,
Binary distributions for 32-bit CentOS 6.7 have been dropped.
Moreover, there are no dedicated CentOS 7.0 distributions as CentOS 7
can use can use Debian 8 binaries. If you would like us to continue
to produce 32-bit CentOS 6.7 distributions please let us know.
GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this
comes after many years of these distributions being faithfully
provided by Karel Gardas and Pali Gabor Janos, who we should heartily
thank for their contributions.
GHC HQ building these distributions ourselves will allow us to more
quickly ship distributions to users by eliminating the need for a
long lag time between source release availability and having all
binary distributions available.
There is a technology-preview of an AArch64 Linux binary
distribution, as well as an ARM Linux build. AArch64 support is quite
preliminary but should be stable in 8.4 thanks to further linker
fixes by Moritz Angerman. ARM should be stable.
GHC now tries to use the gold and lld linkers by default. These
linkers are significantly faster than the BFD linker implementation
that most Linux distributions use by default. If gold or lld are not
available GHC will use the system's default linker. GHC can be forced
to use the default linker by passing --disable-ld-override to
configure.
This release has been the result of over a year of hard work by over 150
code contributors. Thanks to everyone who has helped in writing patches,
testing, reporting bugs, and offering feedback over the last year.
This release cycle was admittedly quite drawn out, significantly longer
than expected or desired. While we are confident that the result is
worth the wait, we have been steadily working on infrastructure which
should help shrink future release cycles and give us better testing
between releases. More details on this coming soon.
As always, let us know if you encounter trouble.
How to get it
Both the source tarball and binary distributions for a wide variety of platforms are available here.
Background
Haskell is a standard lazy functional programming language.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating efficient code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces. GHC is distributed under a BSD-style open source license.
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).
On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page
GHC developers' home page
Haskell home page
Supported Platforms
The list of platforms we support, and the people responsible for them,
is here:
http://ghc.haskell.org/trac/ghc/wiki/Contributors
Ports to other platforms are possible with varying degrees of
difficulty. The Building Guide describes how to go about porting to a
new platform:
http://ghc.haskell.org/trac/ghc/wiki/Building
Developers
We welcome new contributors. Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac.
Community Resources
There are mailing lists for GHC users, develpoers, and monitoring bug tracker
activity; to subscribe, use the Mailman
web interface.
There are several other Haskell and GHC-related mailing lists on
haskell.org; for the full list, see the
lists page.
Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC
network, too. See the Haskell wiki for details.
Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here.
[Less]
|
Posted
over 7 years
ago
by
bgamari
The GHC team is happy to at last announce the 8.0.2 release of the
Glasgow Haskell Compiler. Source and binary distributions are available
at
http://downloads.haskell.org/~ghc/8.0.2/
This is the second release of the 8.0 series and fixes
... [More]
nearly
two-hundred bugs. These include,
Interface file build determinism (#4012).
Compatibility with macOS Sierra and GCC compilers which compile
position-independent executables by default
Compatibility with systems which use the gold linker
Runtime linker fixes on Windows (see #12797)
A compiler bug which resulted in undefined reference errors while
compiling some packages (see #12076)
A number of memory consistency bugs in the runtime system
A number of efficiency issues in the threaded runtime which manifest
on larger core counts and large numbers of bound threads.
A typechecker bug which caused some programs using
-XDefaultSignatures to be incorrectly accepted.
More than two-hundred other bugs. See Trac for a complete
listing.
#12757, which lead to broken runtime behavior and even crashes in
the presence of primitive strings.
#12844, a type inference issue affecting partial type signatures.
A bump of the directory library, fixing buggy path
canonicalization behavior (#12894). Unfortunately this required a
major version bump in directory and minor bumps in several other
libraries.
#12912, where use of the select system call would lead to runtime
system failures with large numbers of open file handles.
#10635, wherein -Wredundant-constraints was included in the -Wall
warning set
A more detailed list of the changes included in this release can be
found in the release notes.
Please note that this release breaks with our usual tendency to avoid
major version bumps of core libraries in minor GHC releases by including
an upgrade of the directory library to 1.3.0.0.
Also note that, due to a rather serious bug (#13100) affecting Windows
noticed late in the release cycle, the Windows binary distributions were
produced using a slightly patched source tree. Users compiling from
source for Windows should be certain to include this patch in their
build.
This release is the result of six months of effort by the GHC
development community. We'd like to thank everyone who has contributed
code, bug reports, and feedback to this release. It's only due to
their efforts that GHC remains a vibrant and exciting project.
How to get it
Both the source tarball and binary distributions for a wide variety of platforms
are available here.
Background
Haskell is a standardized lazy functional programming language.
The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for
Haskell. Included is an optimising compiler generating efficient code for a
variety of platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling facilities, a
large collection of libraries, and support for various language extensions,
including concurrency, exceptions, and foreign language interfaces. GHC is
distributed under a BSD-style open source license.
Supported Platforms
The list of platforms we support, and the people responsible for them, can be
found on the GHC wiki
Ports to other platforms are possible with varying degrees of difficulty. The
Building Guide describes how to go about porting to a new platform.
Developers
We welcome new contributors. Instructions on getting started with hacking on GHC
are available from GHC's developer site.
Community Resources
There are mailing lists for GHC users, develpoers, and monitoring bug tracker
activity; to subscribe, use the Mailman
web interface.
There are several other Haskell and GHC-related mailing lists on
haskell.org; for the full list, see the
lists page.
Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC
network, too. See the Haskell wiki for details.
Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here.
[Less]
|
Posted
over 7 years
ago
by
bgamari
The GHC team is happy to at last announce the 8.0.2 release of the
Glasgow Haskell Compiler. Source and binary distributions are available
at
http://downloads.haskell.org/~ghc/8.0.2/
This is the second release of the 8.0 series and fixes
... [More]
nearly
two-hundred bugs. These include,
Interface file build determinism (#4012).
Compatibility with macOS Sierra and GCC compilers which compile
position-independent executables by default
Compatibility with systems which use the gold linker
Runtime linker fixes on Windows (see #12797)
A compiler bug which resulted in undefined reference errors while
compiling some packages (see #12076)
A number of memory consistency bugs in the runtime system
A number of efficiency issues in the threaded runtime which manifest
on larger core counts and large numbers of bound threads.
A typechecker bug which caused some programs using
-XDefaultSignatures to be incorrectly accepted.
More than two-hundred other bugs. See Trac for a complete
listing.
#12757, which lead to broken runtime behavior and even crashes in
the presence of primitive strings.
#12844, a type inference issue affecting partial type signatures.
A bump of the directory library, fixing buggy path
canonicalization behavior (#12894). Unfortunately this required a
major version bump in directory and minor bumps in several other
libraries.
#12912, where use of the select system call would lead to runtime
system failures with large numbers of open file handles.
#10635, wherein -Wredundant-constraints was included in the -Wall
warning set
A more detailed list of the changes included in this release can be
found in the release notes.
Please note that this release breaks with our usual tendency to avoid
major version bumps of core libraries in minor GHC releases by including
an upgrade of the directory library to 1.3.0.0.
Also note that, due to a rather serious bug (#13100) affecting Windows
noticed late in the release cycle, the Windows binary distributions were
produced using a slightly patched source tree. Users compiling from
source for Windows should be certain to include this patch in their
build.
This release is the result of six months of effort by the GHC
development community. We'd like to thank everyone who has contributed
code, bug reports, and feedback to this release. It's only due to
their efforts that GHC remains a vibrant and exciting project.
How to get it
Both the source tarball and binary distributions for a wide variety of platforms
are available here.
Background
Haskell is a standardized lazy functional programming language.
The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for
Haskell. Included is an optimising compiler generating efficient code for a
variety of platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling facilities, a
large collection of libraries, and support for various language extensions,
including concurrency, exceptions, and foreign language interfaces. GHC is
distributed under a BSD-style open source license.
Supported Platforms
The list of platforms we support, and the people responsible for them, can be
found on the GHC wiki
Ports to other platforms are possible with varying degrees of difficulty. The
Building Guide describes how to go about porting to a new platform.
Developers
We welcome new contributors. Instructions on getting started with hacking on GHC
are available from GHC's developer site.
Community Resources
There are mailing lists for GHC users, develpoers, and monitoring bug tracker
activity; to subscribe, use the Mailman
web interface.
There are several other Haskell and GHC-related mailing lists on
haskell.org; for the full list, see the
lists page.
Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC
network, too. See the Haskell wiki for details.
Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here.
[Less]
|
Posted
over 7 years
ago
by
bgamari
Hello everyone,
As you likely know, over the last few months we have been discussing
options for reforming the process for proposing language and
compiler changes to GHC. After much discussion, we have a process
which, while not perfect, is
... [More]
acceptable to a majority of our contributor
base and will be an improvement over the status quo. While we invite
suggestions for future improvements, we are at a point where we can move
ahead with implementation.
Consequently, we are seeking nominations for the initial GHC steering
committee. This body is responsible for overseeing the progression of
proposals through the process, working with authors on refining their
ideas, and evaluating proposals for acceptance. The committee will
consist of five to eight members of diverse backgrounds.
We would like to offer the following as a criteria for membership. Note
that a candidate is not expected to satisfy all or even most of these
criteria, but a good candidate should satisfy at least one:
A history of contributions to the design of new language features
Experience developing Haskell libraries and applications
A demonstrated track record of contributing code to GHC
A pedagogical background, with experience in either teaching or
authoring educational materials
Experience in compiler development
Knowledge of functional programming language theory
I would like to emphasize that committee membership is as much a duty as it
is a privilege. Membership is not intended to be a platform to be used
by members to drive their own ideas; rather it is a way of serving the
Haskell community by helping other community members refine and advance
their proposals. This, of course, requires an investment of
time and effort, which you should be willing and able to consistently
put forth.
If you would like to be considered for committee membership then please
write a statement describing why you feel you are well-qualified to
serve, in terms of the criteria above and any others that you would like
to offer. Please send your statements to ben at well-typed.com by September
30th. The initial committee selection will be made by the Simons soon
thereafter.
Thanks to everyone for their feedback and cooperation so far!
Cheers,
~ Ben
[Less]
|
Posted
almost 8 years
ago
by
bgamari
Recently there has been a fair bit of discussion around the
mechanisms by which proposed changes to GHC are evaluated. While we have
something of a formal proposal protocol, it is not clearly
documented, inconsistently applied, and may be failing
... [More]
to serve a
significant fraction of GHC's potential contributor pool.
Over the last few weeks, I have been doing a fair amount of reading,
thinking, and discussing to try to piece together a proposal scheme
which better serves our community.
The resulting proposal is strongly inspired by the RFC process in
place in the Rust community, the leaders of which have thought quite
hard about fostering community growth and participation. While no
process is perfect, I feel like the Rust process is a good starting
point for discussion, offering enough structure to guide new
contributors through the process while requiring only a modest
investment of developer time.
To get a sense for how well this will work in our community, I propose
that we attempt to self-host the proposed process. To this end I have
setup a ghc-proposals repository and opened a pull request for
discussion of the process proposal.
Let's see how this goes.
Cheers,
~ Ben
[Less]
|
Posted
almost 8 years
ago
by
bgamari
Recently there has been a fair bit of discussion around the
mechanisms by which proposed changes to GHC are evaluated. While we have
something of a formal proposal protocol, it is not clearly
documented, inconsistently applied, and may be failing
... [More]
to serve a
significant fraction of GHC's potential contributor pool.
Over the last few weeks, I have been doing a fair amount of reading,
thinking, and discussing to try to piece together a proposal scheme
which better serves our community.
The resulting proposal is strongly inspired by the RFC process in
place in the Rust community, the leaders of which have thought quite
hard about fostering community growth and participation. While no
process is perfect, I feel like the Rust process is a good starting
point for discussion, offering enough structure to guide new
contributors through the process while requiring only a modest
investment of developer time.
To get a sense for how well this will work in our community, I propose
that we attempt to self-host the proposed process. To this end I have
setup a ghc-proposals repository and opened a pull request for
discussion of the process proposal.
Let's see how this goes.
Cheers,
~ Ben
[Less]
|
Posted
almost 8 years
ago
by
bgamari
Recently there has been a fair bit of discussion around the
mechanisms by which proposed changes to GHC are evaluated. While we have
something of a formal proposal protocol, it is not clearly
documented, inconsistently applied, and may be failing
... [More]
to serve a
significant fraction of GHC's potential contributor pool.
Over the last few weeks, I have been doing a fair amount of reading,
thinking, and discussing to try to piece together a proposal scheme
which better serves our community.
The resulting proposal is strongly inspired by the RFC process in
place in the Rust community, the leaders of which have thought quite
hard about fostering community growth and participation. While no
process is perfect, I feel like the Rust process is a good starting
point for discussion, offering enough structure to guide new
contributors through the process while requiring only a modest
investment of developer time.
To get a sense for how well this will work in our community, I propose
that we attempt to self-host the proposed process. To this end I have
setup a ghc-proposals repository and opened a pull request for
discussion of the process proposal.
Let's see how this goes.
Cheers,
~ Ben
[Less]
|