GHC 7.8 release?

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

GHC 7.8 release?

Simon Peyton Jones
Dear GHC users,

Carter: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish?
Andreas: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8.

Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think.

At ICFP we speculated that we'd make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically:

?         major improvements in DPH (vectorisation avoidance, new vectoriser)

?         type holes

?         rebindable list syntax

?         major changes to the type inference engine

?         type level natural numbers

?         overlapping type families

?         the new code generator

?         support for vector (SSE/AVX) instructions

Whenever it comes it would definitely be great to include Andreas & friends' work:

?         Scheduler changes to the RTS to improve latency

The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild.  However, making a proper release imposes costs on everyone else.  Library authors have to scurry around to make their libraries work, etc.   Some of the new stuff hasn't been in HEAD for that long, and hence has not been very thoroughly tested.   (But of course making a release unleashes a huge wave of testing that doesn't happen otherwise.)

So another alternative is to leave it all as HEAD, and wait another few months before making a release.  You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution.  And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4.

There seem to be pros and cons each way.  I don't have a strong opinion.  If you have a view, let us know.

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/c3597a2a/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

José Pedro Magalhães
For the record, if we decide for a release soon, I'll make sure the
new-typeable branch gets merged asap.


Cheers,
Pedro

On Thu, Feb 7, 2013 at 8:25 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  Dear GHC users,  ****
>
> *
> *
>
> *Carter*: Will this RTS update make it into ghc 7.8 update thats coming
> up in the next monthish?****
>
> *Andreas*: We are almost there - we are now trying to sort out a problem
> on mac os x. It would be helpful to know if there is a cutoff date for
> getting things into 7.8. ****
>
> ** **
>
> Simon, Ian, and I have just been discussing 7.8, and would be interested
> in what you guys think.  ****
>
>
> At ICFP we speculated that we?d make a release of GHC soon after Christmas
> to embody tons of stuff that has been included since 7.6, specifically:***
> *
>
> **?         **major improvements in DPH (vectorisation avoidance, new
> vectoriser)****
>
> **?         **type holes****
>
> **?         **rebindable list syntax****
>
> **?         **major changes to the type inference engine****
>
> **?         **type level natural numbers****
>
> **?         **overlapping type families****
>
> **?         **the new code generator****
>
> **?         **support for vector (SSE/AVX) instructions****
>
> ** **
>
> Whenever it comes it would definitely be great to include Andreas &
> friends? work:****
>
> **?         **Scheduler changes to the RTS to improve latency****
>
> ** **
>
> The original major reason for proposing a post-Xmas release was to get DPH
> in a working state out into the wild.  However, making a proper release
> imposes costs on everyone else.  Library authors have to scurry around to
> make their libraries work, etc.   Some of the new stuff hasn?t been in HEAD
> for that long, and hence has not been very thoroughly tested.   (But of
> course making a release unleashes a huge wave of testing that doesn?t
> happen otherwise.)****
>
> ** **
>
> So another alternative is to leave it all as HEAD, and wait another few
> months before making a release.  You can still use all the new stuff by
> compiling HEAD, or grabbing a snapshot distribution.  And it makes it hard
> for the Haskell platform if GHC moves too fast. Many people are still on
> 7.4.****
>
> ** **
>
> There seem to be pros and cons each way.  I don?t have a strong opinion.
> If you have a view, let us know.****
>
> ** **
>
> Simon****
>
> ** **
>
> --
> You received this message because you are subscribed to the Google Groups
> "parallel-haskell" group.
>
> email to parallel-haskell+unsubscribe at googlegroups.com.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/3133c8a2/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Geoffrey Mainland
In reply to this post by Simon Peyton Jones
In practice the versions of GHC that are widely used are those that are
included in the platform. Maybe we should coordinate with their next
release? They are targeting a May 6 release, and the release process is
starting March 4, so it sounds like the original GHC release plan
(February release) would be a good fit for the platform as it would
allow library writers to catch up and ensure that STABLE was tested
enough for inclusion in the platform. It would be a shame to miss the
platform release.

Geoff

On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote:

> Dear GHC users,
>
> *                                                                                                                  
> *
>
> *Carter*: Will this RTS update make it into ghc 7.8 update thats coming
> up in the next monthish?
>
> *Andreas*: We are almost there - we are now trying to sort out a problem
> on mac os x. It would be helpful to know if there is a cutoff date for
> getting things into 7.8.
>
>  
>
> Simon, Ian, and I have just been discussing 7.8, and would be interested
> in what you guys think.
>
>
> At ICFP we speculated that we?d make a release of GHC soon after
> Christmas to embody tons of stuff that has been included since 7.6,
> specifically:
>
> ?         major improvements in DPH (vectorisation avoidance, new
> vectoriser)
>
> ?         type holes
>
> ?         rebindable list syntax
>
> ?         major changes to the type inference engine
>
> ?         type level natural numbers
>
> ?         overlapping type families
>
> ?         the new code generator
>
> ?         support for vector (SSE/AVX) instructions
>
>  
>
> Whenever it comes it would definitely be great to include Andreas &
> friends? work:
>
> ?         Scheduler changes to the RTS to improve latency
>
>  
>
> The original major reason for proposing a post-Xmas release was to get
> DPH in a working state out into the wild.  However, making a proper
> release imposes costs on everyone else.  Library authors have to scurry
> around to make their libraries work, etc.   Some of the new stuff hasn?t
> been in HEAD for that long, and hence has not been very thoroughly
> tested.   (But of course making a release unleashes a huge wave of
> testing that doesn?t happen otherwise.)
>
>  
>
> So another alternative is to leave it all as HEAD, and wait another few
> months before making a release.  You can still use all the new stuff by
> compiling HEAD, or grabbing a snapshot distribution.  And it makes it
> hard for the Haskell platform if GHC moves too fast. Many people are
> still on 7.4.
>
>  
>
> There seem to be pros and cons each way.  I don?t have a strong
> opinion.  If you have a view, let us know.
>
>  
>
> Simon




Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Richard Eisenberg-2
Geoff's reasoning seems quite sound.
+1 for February release.

On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland <mainland at apeiron.net> wrote:

> In practice the versions of GHC that are widely used are those that are
> included in the platform. Maybe we should coordinate with their next
> release? They are targeting a May 6 release, and the release process is
> starting March 4, so it sounds like the original GHC release plan
> (February release) would be a good fit for the platform as it would
> allow library writers to catch up and ensure that STABLE was tested
> enough for inclusion in the platform. It would be a shame to miss the
> platform release.
>
> Geoff
>
> On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote:
>> Dear GHC users,
>>
>> *                                                                                                                  
>> *
>>
>> *Carter*: Will this RTS update make it into ghc 7.8 update thats coming
>> up in the next monthish?
>>
>> *Andreas*: We are almost there - we are now trying to sort out a problem
>> on mac os x. It would be helpful to know if there is a cutoff date for
>> getting things into 7.8.
>>
>>
>>
>> Simon, Ian, and I have just been discussing 7.8, and would be interested
>> in what you guys think.
>>
>>
>> At ICFP we speculated that we?d make a release of GHC soon after
>> Christmas to embody tons of stuff that has been included since 7.6,
>> specifically:
>>
>> ?         major improvements in DPH (vectorisation avoidance, new
>> vectoriser)
>>
>> ?         type holes
>>
>> ?         rebindable list syntax
>>
>> ?         major changes to the type inference engine
>>
>> ?         type level natural numbers
>>
>> ?         overlapping type families
>>
>> ?         the new code generator
>>
>> ?         support for vector (SSE/AVX) instructions
>>
>>
>>
>> Whenever it comes it would definitely be great to include Andreas &
>> friends? work:
>>
>> ?         Scheduler changes to the RTS to improve latency
>>
>>
>>
>> The original major reason for proposing a post-Xmas release was to get
>> DPH in a working state out into the wild.  However, making a proper
>> release imposes costs on everyone else.  Library authors have to scurry
>> around to make their libraries work, etc.   Some of the new stuff hasn?t
>> been in HEAD for that long, and hence has not been very thoroughly
>> tested.   (But of course making a release unleashes a huge wave of
>> testing that doesn?t happen otherwise.)
>>
>>
>>
>> So another alternative is to leave it all as HEAD, and wait another few
>> months before making a release.  You can still use all the new stuff by
>> compiling HEAD, or grabbing a snapshot distribution.  And it makes it
>> hard for the Haskell platform if GHC moves too fast. Many people are
>> still on 7.4.
>>
>>
>>
>> There seem to be pros and cons each way.  I don?t have a strong
>> opinion.  If you have a view, let us know.
>>
>>
>>
>> Simon
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2

I'm not too optimistic we could actually get the final release out
during February, assuming we want to allow a couple of weeks for people
to test an RC.

Does the Haskell Platform actually want to commit to using a GHC release
with "tons of [new] stuff", that has had little testing, days or weeks
after its release? I thought the idea was that it would favour
known-good releases over the latest-and-greatest, but perhaps I
misunderstood or the philosophy has changed.


Thanks
Ian

On Thu, Feb 07, 2013 at 09:00:37AM -0500, Richard Eisenberg wrote:

> Geoff's reasoning seems quite sound.
> +1 for February release.
>
> On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland <mainland at apeiron.net> wrote:
>
> > In practice the versions of GHC that are widely used are those that are
> > included in the platform. Maybe we should coordinate with their next
> > release? They are targeting a May 6 release, and the release process is
> > starting March 4, so it sounds like the original GHC release plan
> > (February release) would be a good fit for the platform as it would
> > allow library writers to catch up and ensure that STABLE was tested
> > enough for inclusion in the platform. It would be a shame to miss the
> > platform release.
> >
> > Geoff
> >
> > On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote:
> >> Dear GHC users,
> >>
> >> *                                                                                                                  
> >> *
> >>
> >> *Carter*: Will this RTS update make it into ghc 7.8 update thats coming
> >> up in the next monthish?
> >>
> >> *Andreas*: We are almost there - we are now trying to sort out a problem
> >> on mac os x. It would be helpful to know if there is a cutoff date for
> >> getting things into 7.8.
> >>
> >>
> >>
> >> Simon, Ian, and I have just been discussing 7.8, and would be interested
> >> in what you guys think.
> >>
> >>
> >> At ICFP we speculated that we?d make a release of GHC soon after
> >> Christmas to embody tons of stuff that has been included since 7.6,
> >> specifically:
> >>
> >> ?         major improvements in DPH (vectorisation avoidance, new
> >> vectoriser)
> >>
> >> ?         type holes
> >>
> >> ?         rebindable list syntax
> >>
> >> ?         major changes to the type inference engine
> >>
> >> ?         type level natural numbers
> >>
> >> ?         overlapping type families
> >>
> >> ?         the new code generator
> >>
> >> ?         support for vector (SSE/AVX) instructions
> >>
> >>
> >>
> >> Whenever it comes it would definitely be great to include Andreas &
> >> friends? work:
> >>
> >> ?         Scheduler changes to the RTS to improve latency
> >>
> >>
> >>
> >> The original major reason for proposing a post-Xmas release was to get
> >> DPH in a working state out into the wild.  However, making a proper
> >> release imposes costs on everyone else.  Library authors have to scurry
> >> around to make their libraries work, etc.   Some of the new stuff hasn?t
> >> been in HEAD for that long, and hence has not been very thoroughly
> >> tested.   (But of course making a release unleashes a huge wave of
> >> testing that doesn?t happen otherwise.)
> >>
> >>
> >>
> >> So another alternative is to leave it all as HEAD, and wait another few
> >> months before making a release.  You can still use all the new stuff by
> >> compiling HEAD, or grabbing a snapshot distribution.  And it makes it
> >> hard for the Haskell platform if GHC moves too fast. Many people are
> >> still on 7.4.
> >>
> >>
> >>
> >> There seem to be pros and cons each way.  I don?t have a strong
> >> opinion.  If you have a view, let us know.
> >>
> >>
> >>
> >> Simon


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

John Lato-2
I agree with Ian.  Mid-February is very soon, and there's a lot of stuff
that seems to just be coming in now.  That doesn't leave much time for
testing to get 7.8 out in sync with the platform.

Although my perspective is a bit colored by the last release.  Testing the
7.6.1 RC took several weeks for us because of the number of upstream
packages that needed to be updated (not all trivially).  By the time we
were prepared to begin testing our own systems 7.6.1 was already released,
and we couldn't use it because of a number of bugs (
http://hackage.haskell.org/trac/ghc/ticket/7257 was a blocker, but there
were others also).  Most of the bugs were fixed very quickly (thanks Simon
M. and Simon PJ!), but by then they were already in the wild.  If there had
been a bit more time to test 7.6.1, maybe some of those fixes would have
made it into the release.


John L.


On Thu, Feb 7, 2013 at 10:23 PM, Ian Lynagh <ian at well-typed.com> wrote:

>
> I'm not too optimistic we could actually get the final release out
> during February, assuming we want to allow a couple of weeks for people
> to test an RC.
>
> Does the Haskell Platform actually want to commit to using a GHC release
> with "tons of [new] stuff", that has had little testing, days or weeks
> after its release? I thought the idea was that it would favour
> known-good releases over the latest-and-greatest, but perhaps I
> misunderstood or the philosophy has changed.
>
>
> Thanks
> Ian
>
> On Thu, Feb 07, 2013 at 09:00:37AM -0500, Richard Eisenberg wrote:
> > Geoff's reasoning seems quite sound.
> > +1 for February release.
> >
> > On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
> >
> > > In practice the versions of GHC that are widely used are those that are
> > > included in the platform. Maybe we should coordinate with their next
> > > release? They are targeting a May 6 release, and the release process is
> > > starting March 4, so it sounds like the original GHC release plan
> > > (February release) would be a good fit for the platform as it would
> > > allow library writers to catch up and ensure that STABLE was tested
> > > enough for inclusion in the platform. It would be a shame to miss the
> > > platform release.
> > >
> > > Geoff
> > >
> > > On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote:
> > >> Dear GHC users,
> > >>
> > >> *
> > >> *
> > >>
> > >> *Carter*: Will this RTS update make it into ghc 7.8 update thats
> coming
> > >> up in the next monthish?
> > >>
> > >> *Andreas*: We are almost there - we are now trying to sort out a
> problem
> > >> on mac os x. It would be helpful to know if there is a cutoff date for
> > >> getting things into 7.8.
> > >>
> > >>
> > >>
> > >> Simon, Ian, and I have just been discussing 7.8, and would be
> interested
> > >> in what you guys think.
> > >>
> > >>
> > >> At ICFP we speculated that we?d make a release of GHC soon after
> > >> Christmas to embody tons of stuff that has been included since 7.6,
> > >> specifically:
> > >>
> > >> ?         major improvements in DPH (vectorisation avoidance, new
> > >> vectoriser)
> > >>
> > >> ?         type holes
> > >>
> > >> ?         rebindable list syntax
> > >>
> > >> ?         major changes to the type inference engine
> > >>
> > >> ?         type level natural numbers
> > >>
> > >> ?         overlapping type families
> > >>
> > >> ?         the new code generator
> > >>
> > >> ?         support for vector (SSE/AVX) instructions
> > >>
> > >>
> > >>
> > >> Whenever it comes it would definitely be great to include Andreas &
> > >> friends? work:
> > >>
> > >> ?         Scheduler changes to the RTS to improve latency
> > >>
> > >>
> > >>
> > >> The original major reason for proposing a post-Xmas release was to get
> > >> DPH in a working state out into the wild.  However, making a proper
> > >> release imposes costs on everyone else.  Library authors have to
> scurry
> > >> around to make their libraries work, etc.   Some of the new stuff
> hasn?t
> > >> been in HEAD for that long, and hence has not been very thoroughly
> > >> tested.   (But of course making a release unleashes a huge wave of
> > >> testing that doesn?t happen otherwise.)
> > >>
> > >>
> > >>
> > >> So another alternative is to leave it all as HEAD, and wait another
> few
> > >> months before making a release.  You can still use all the new stuff
> by
> > >> compiling HEAD, or grabbing a snapshot distribution.  And it makes it
> > >> hard for the Haskell platform if GHC moves too fast. Many people are
> > >> still on 7.4.
> > >>
> > >>
> > >>
> > >> There seem to be pros and cons each way.  I don?t have a strong
> > >> opinion.  If you have a view, let us know.
> > >>
> > >>
> > >>
> > >> Simon
>
> _______________________________________________
> Haskell-platform mailing list
> Haskell-platform at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/4d81183b/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Mark Lentczner-2
In reply to this post by Simon Peyton Jones
I'd say the window for 7.8 in the platform is about closed. If 7.8 were to
be release in the next two weeks that would be just about the least amount
of time I'd want to see for libraries in the platform to get all stable
with the GHC version. And we'd also be counting on the GHC team to be
quickly responding to bugs so that there could be a point release of 7.8
mid-April. Historically, none of that seems likely.

So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2.

Since 7.8 will seems like it will be released before May, we will be faced
again with the bad public relations issue: Everyone will want the new shiny
and be confused as to why the platform is such a laggard. We'll see four
reactions:

   - New comers who are starting out and figure they should use the
   latest... Many will try to use 7.8, half the libraries on hackage won't
   work, things will be wonky, and they'll have a poor experience.
   - People doing production / project work will stay on 7.6 and ignore 7.8
   for a few months.
   - The small group of people exploring the frontiers will know how to get
   things set up and be happy.
   - Eventually library authors will get around to making sure their stuff
   will work with it.

I wish GHC would radically change it's release process. Things like 7.8
shouldn't be release as "7.8". That sounds major and stable. The web site
will have 7.8 at the top. The warning to use the platform will fall flat
because it makes the platform look out of date. Really, "7.8" should be in
a different release channel, not on the front page. It should bake in that
channel for six months - where only the third group of people will use it,
until it is getting close to merge into main, at which point the fourth
group will start to use it, so that the day it hits main, all the libraries
just work. Ideally, the first two groups of people will not pay the
slightest attention to it until it is further baked.

While we achievements of the GHC team are great, less than half of those
7.8 features seem interesting from the viewpoint of the aims of
the platform. I don't think adding syntactic or type-level features are
really all that important for Haskell at this juncture. And while I do like
to see improvements in generated code and run-time performance, I think
even those are less important than making crucial ecosystem improvements to
things like package management, cross-compilation, and libraries.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/aa8ee327/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Johan Tibell-2
In reply to this post by Simon Peyton Jones
Hi Simon,

Starting with the 7.8 release cycle, I will try to run all of nofib and
compare the results to the previous release (i.e. 7.6.2) to see if we have
any regressions. That way we can catch them before the release.

In the future I intend to set up a build bot that runs nightly and sends
out an email if there's a regression above some threshold. That way we
should catch regressions earlier, when they're easier to (fix i.e. when you
still have your recent changes fresh in your head).

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/118ce859/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Mark Lentczner-2
It?s fairly simple in my mind. There are two ?channels? (if I understand Mark?s terminology right):


?         Haskell Platform:

o   A stable development environment, lots of libraries known to work

o   Newcomers, and people who value stability, should use the Haskell Platform

o   HP comes with a particular version of GHC, probably not the hottest new one, but that doesn?t matter.  It works.



?         GHC home page downloads:

o   More features but not so stable

o   Libraries not guaranteed to work

o   Worth releasing, though, as a forcing function to fix bugs, and as a checkpoint for people to test, so that by the time the HP adopts a particular version it is reasonably solid.

So we already have the two channels Mark asks for, don?t we?  One is called the Haskell Platform and one is called the GHC home page.

That leaves a PR issue: we really don?t want newcomers or Joe Users wanting the ?new shiny?. They want the Haskell Platform, and as Mark says those users should not pay the slightest attention until it appears in the Haskell Platform.

So perhaps we principally need a way to point people away from GHC and towards HP?  eg We could prominently say at every download point ?Stop!  Are you sure you want this?  You might be better off with the Haskell Platform!  Here?s why...?.

Have I understood aright?  If so, how could we achieve the right social dynamics?

Our goal is to let people who value stability get stability, while the hot-shots race along in a different channel and pay the price of flat tires etc.

PS: absolutely right to use 7.6.2 for the next HP.  Don?t even think about 7.8.

Simon



From: Mark Lentczner [mailto:mark.lentczner at gmail.com]
Sent: 07 February 2013 17:43
To: Simon Peyton-Jones
Cc: andreas.voellmy at gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kostirya at gmail.com; Edsko de Vries; ghc-devs at haskell.org
Subject: Re: GHC 7.8 release?

I'd say the window for 7.8 in the platform is about closed. If 7.8 were to be release in the next two weeks that would be just about the least amount of time I'd want to see for libraries in the platform to get all stable with the GHC version. And we'd also be counting on the GHC team to be quickly responding to bugs so that there could be a point release of 7.8 mid-April. Historically, none of that seems likely.

So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2.

Since 7.8 will seems like it will be released before May, we will be faced again with the bad public relations issue: Everyone will want the new shiny and be confused as to why the platform is such a laggard. We'll see four reactions:

  *   New comers who are starting out and figure they should use the latest... Many will try to use 7.8, half the libraries on hackage won't work, things will be wonky, and they'll have a poor experience.
  *   People doing production / project work will stay on 7.6 and ignore 7.8 for a few months.
  *   The small group of people exploring the frontiers will know how to get things set up and be happy.
  *   Eventually library authors will get around to making sure their stuff will work with it.
I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as "7.8". That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, "7.8" should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked.

While we achievements of the GHC team are great, less than half of those 7.8 features seem interesting from the viewpoint of the aims of the platform. I don't think adding syntactic or type-level features are really all that important for Haskell at this juncture. And while I do like to see improvements in generated code and run-time performance, I think even those are less important than making crucial ecosystem improvements to things like package management, cross-compilation, and libraries.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/2dfb16f1/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Austin Seipp
In reply to this post by Simon Peyton Jones
This is a slight tangent but, I am always somewhat confused about the
release schedule. When reading this, the basic decision seems to come
down to when do we cut a release, taking into account factors like
reliability/bugs/support/community/other stuff like that.

So, IMO, perhaps one thing that's needed is a more formalized release
schedule, with something like a merge window for 'big changes'? For
example, many projects like LLVM and GCC have fairly fixed release
windows, with an accompanying merge window several months before an
official release. (The Linux kernel does this too, but they have a
much shorter cycle.) If a large feature misses the merge window, it
must go into the next release.

Personally, I am not too worried about necessarily getting every new
feature into a release, even if they're awesome (and they all are!)
And while giving HP users the latest and greatest is great, they want
stability more than anything, in my opinion. So I think they're fine
with that too. What I am worried about is there being a good length of
time where the features integrated have time to bake and see some
polish, without a lot of interference.

There are a lot of issues with this including how to deal with work
that goes on in the mean time, etc. GHC also has far less manpower and
a much different ratio of developer influence and 'spread' than any of
the above projects. And we have to define what qualifies as 'big
change.' But if the issue seems to be one of time, synchronization,
and quality, perhaps we should think about whether or not a change
like a more formalized schedule could help.

I think making releases so people can find bugs is important. But that
will always happen anyway, so I'd rather be a little cautious and wait
this one out, than try to cram it. The new vectoriser only came in
within the past ~48 hours, and SIMD was just pushed in the past week
(and DPH will need SIMD support merged, too!) I think Feburary or even
March is way, way too early for a solid release, and it's certainly
too late for the HP anyway. I see little pain in postponement,
personally.

On Thu, Feb 7, 2013 at 2:25 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:

> Dear GHC users,
>
>
>
> Carter: Will this RTS update make it into ghc 7.8 update thats coming up in
> the next monthish?
>
> Andreas: We are almost there - we are now trying to sort out a problem on
> mac os x. It would be helpful to know if there is a cutoff date for getting
> things into 7.8.
>
>
>
> Simon, Ian, and I have just been discussing 7.8, and would be interested in
> what you guys think.
>
>
> At ICFP we speculated that we?d make a release of GHC soon after Christmas
> to embody tons of stuff that has been included since 7.6, specifically:
>
> ?         major improvements in DPH (vectorisation avoidance, new
> vectoriser)
>
> ?         type holes
>
> ?         rebindable list syntax
>
> ?         major changes to the type inference engine
>
> ?         type level natural numbers
>
> ?         overlapping type families
>
> ?         the new code generator
>
> ?         support for vector (SSE/AVX) instructions
>
>
>
> Whenever it comes it would definitely be great to include Andreas & friends?
> work:
>
> ?         Scheduler changes to the RTS to improve latency
>
>
>
> The original major reason for proposing a post-Xmas release was to get DPH
> in a working state out into the wild.  However, making a proper release
> imposes costs on everyone else.  Library authors have to scurry around to
> make their libraries work, etc.   Some of the new stuff hasn?t been in HEAD
> for that long, and hence has not been very thoroughly tested.   (But of
> course making a release unleashes a huge wave of testing that doesn?t happen
> otherwise.)
>
>
>
> So another alternative is to leave it all as HEAD, and wait another few
> months before making a release.  You can still use all the new stuff by
> compiling HEAD, or grabbing a snapshot distribution.  And it makes it hard
> for the Haskell platform if GHC moves too fast. Many people are still on
> 7.4.
>
>
>
> There seem to be pros and cons each way.  I don?t have a strong opinion.  If
> you have a view, let us know.
>
>
>
> Simon
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,
Austin


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Johan Tibell-2
fantastic thanks

From: Johan Tibell [mailto:johan.tibell at gmail.com]
Sent: 07 February 2013 17:56
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org
Subject: Re: GHC 7.8 release?

Hi Simon,

Starting with the 7.8 release cycle, I will try to run all of nofib and compare the results to the previous release (i.e. 7.6.2) to see if we have any regressions. That way we can catch them before the release.

In the future I intend to set up a build bot that runs nightly and sends out an email if there's a regression above some threshold. That way we should catch regressions earlier, when they're easier to (fix i.e. when you still have your recent changes fresh in your head).

-- Johan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/0a4e22cd/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ben Lippmeier-2
In reply to this post by Simon Peyton Jones

On 08/02/2013, at 5:15 AM, Simon Peyton-Jones wrote:

> So perhaps we principally need a way to point people away from GHC and towards HP?  eg We could prominently say at every download point ?Stop!  Are you sure you want this?  You might be better off with the Haskell Platform!  Here?s why...?.

Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say "Built on ghc-7.6". By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the "real" GHC version is.

We'd have more chance of turning Joe User off the latest GHC release if Hackage was clearly split into stable/testing channels. Linux distros have been doing this for years.

Ben.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/4c291bc1/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Johan Tibell-2
On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier <benl at ouroborus.net> wrote:

> Right now, the latest packages uploaded to Hackage get built with ghc-7.6
> (only), and all the pages say "Built on ghc-7.6". By doing this we force
> *all* library developers to run GHC 7.6. I think this sends the clearest
> message about what the "real" GHC version is.
>

I don't know how closely users look at the "built on" line on the package
page. Perhaps they look there, perhaps they don't.

Between Bryan and me we build all of our own packages and all HP packages
on the latest 3 GHC versions:

http://ci.johantibell.com/
https://jenkins.serpentine.com/

That doesn't mean that it would be a bad idea to build all Hackage packages
on using more GHC versions, but that won't happen until the Hackage project
is unstuck (it has been stuck for years!).

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130207/4c02221f/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Carter Schonwald
johan, how do you and Bryan have those jenkin's nodes setup?

(I'm planning  to setup something similar  for my own use, and seeing how
thats setup would be awesome)

thanks
-Carter


On Thu, Feb 7, 2013 at 10:55 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
>
>> Right now, the latest packages uploaded to Hackage get built with ghc-7.6
>> (only), and all the pages say "Built on ghc-7.6". By doing this we force
>> *all* library developers to run GHC 7.6. I think this sends the clearest
>> message about what the "real" GHC version is.
>>
>
> I don't know how closely users look at the "built on" line on the package
> page. Perhaps they look there, perhaps they don't.
>
> Between Bryan and me we build all of our own packages and all HP packages
> on the latest 3 GHC versions:
>
> http://ci.johantibell.com/
> https://jenkins.serpentine.com/
>
> That doesn't mean that it would be a bad idea to build all Hackage
> packages on using more GHC versions, but that won't happen until the
> Hackage project is unstuck (it has been stuck for years!).
>
> -- Johan
>
>  --
> You received this message because you are subscribed to the Google Groups
> "parallel-haskell" group.
>
> email to parallel-haskell+unsubscribe at googlegroups.com.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/7b1ea0a0/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Carter Schonwald
In reply to this post by Johan Tibell-2
johan, how do you and Bryan have those jenkin's nodes setup?

(I'm planning  to setup something similar  for my own use, and seeing how
thats setup would be awesome)

thanks
-Carter


On Thu, Feb 7, 2013 at 10:55 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
>
>> Right now, the latest packages uploaded to Hackage get built with ghc-7.6
>> (only), and all the pages say "Built on ghc-7.6". By doing this we force
>> *all* library developers to run GHC 7.6. I think this sends the clearest
>> message about what the "real" GHC version is.
>>
>
> I don't know how closely users look at the "built on" line on the package
> page. Perhaps they look there, perhaps they don't.
>
> Between Bryan and me we build all of our own packages and all HP packages
> on the latest 3 GHC versions:
>
> http://ci.johantibell.com/
> https://jenkins.serpentine.com/
>
> That doesn't mean that it would be a bad idea to build all Hackage
> packages on using more GHC versions, but that won't happen until the
> Hackage project is unstuck (it has been stuck for years!).
>
> -- Johan
>
>  --
> You received this message because you are subscribed to the Google Groups
> "parallel-haskell" group.
>
> email to parallel-haskell+unsubscribe at googlegroups.com.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/67d4e8f9/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Tim Watson
On 8 Feb 2013, at 05:18, Carter Schonwald wrote:
> johan, how do you and Bryan have those jenkin's nodes setup?
>
> (I'm planning  to setup something similar  for my own use, and seeing how thats setup would be awesome)
>

Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud Haskell and would be very interested in seeing how you've dealt with multiple versions of GHC.

Cheers,
Tim

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Bryan O'Sullivan
On Fri, Feb 8, 2013 at 1:29 AM, Tim Watson <watson.timothy at gmail.com> wrote:

> Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud
> Haskell and would be very interested in seeing how you've dealt with
> multiple versions of GHC.
>

It's easy to parameterize builds in Jenkins based on different values of an
environment variable, so Johan and I just have different versions of GHC
installed side by side, and then set $GHC_VERSION to "7.6 7.4 7.2 7.0 6.12"
(or whatever), put /usr/local/$GHC_VERSION/bin at the front of $PATH, and
the right thing happens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/b161f26b/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Tim Watson
Hi Bryan,

On 8 Feb 2013, at 11:53, Bryan O'Sullivan wrote:

> On Fri, Feb 8, 2013 at 1:29 AM, Tim Watson <watson.timothy at gmail.com> wrote:
> Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud Haskell and would be very interested in seeing how you've dealt with multiple versions of GHC.
>
> It's easy to parameterize builds in Jenkins based on different values of an environment variable, so Johan and I just have different versions of GHC installed side by side, and then set $GHC_VERSION to "7.6 7.4 7.2 7.0 6.12" (or whatever), put /usr/local/$GHC_VERSION/bin at the front of $PATH, and the right thing happens.

Ok cool, that's pretty much what I had in mind but I wasn't sure about installing dependencies and using cabal-install. In my development environment I quickly found that installing multiple GHCs and haskell-platform releases got a bit messy, so I was wondering if there was a recognised 'best way' to do this. I'll probably replicate what I've done with other things (such as Erlang) and manage it with ${PREFIX}/ghc/versions/... and symlink ${PREFIX}/ghc/current/... to avoid the path switching. Hopefully telling cabal-install to use ${PREFIX}/ghc/current/lib will 'just work' when installing dependencies as I switch between ghc versions.

Cheers!
Tim

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
In reply to this post by Mark Lentczner-2
On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote:

>
> I wish GHC would radically change it's release process. Things like 7.8
> shouldn't be release as "7.8". That sounds major and stable. The web site
> will have 7.8 at the top. The warning to use the platform will fall flat
> because it makes the platform look out of date. Really, "7.8" should be in
> a different release channel, not on the front page. It should bake in that
> channel for six months - where only the third group of people will use it,
> until it is getting close to merge into main, at which point the fourth
> group will start to use it, so that the day it hits main, all the libraries
> just work. Ideally, the first two groups of people will not pay the
> slightest attention to it until it is further baked.

It's a catch-22: We don't want people to use a new release until all the
bugs have been found and fixed, and all the libraries have been updated.
But if people don't use it, then the bugs won't be found and the
libraries won't be updated.

I think you're saying that you'd like the uptake of new GHC versions to
be slower, which would mean fewer people would be using 7.6 now, but in
the last few days I've seen the Debian guys have had to send mails to
maintainers telling them that their packages don't work with 7.6:
    http://lists.debian.org/debian-haskell/2013/02/threads.html
despite 7.6 having been out for 5 months and about to enter the HP.

Perhaps more automatic Hackage building, with a group of people looking
at the logs of failing packages and acting appropriately, is the way
forward. Some cases (such as "installation failed due to dependencies
not being installable") you'd want to be handled automatically.


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Marlow-7
In reply to this post by Simon Peyton Jones
For a while we've been doing one major release per year, and 1-2 minor
releases.  We have a big sign at the top of the download page directing
people to the platform.  We arrived here after various discussions in
the past - there were always a group of people that wanted stability,
and a roughly equally vocal group of people who wanted the latest bits.  
So we settled on one API-breaking change per year as a compromise.

Since then, the number of packages has ballooned, and there's a new
factor in the equation: the cost to the ecosystem of an API-breaking
release of GHC.  All that updating of packages collectively costs the
community a lot of time, for little benefit.  Lots of package updates
contributes to Cabal Hell.  The package updates need to happen before
the platform picks up the GHC release, so that when it goes into the
platform, the packages are ready.

So I think, if anything, there's pressure to have fewer major releases
of GHC.  However, we're doing the opposite: 7.0 to 7.2 was 10 months,
7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too
efficient at making releases!

My feeling is that this pace is too fast.  You might argue that with
better tools and infrastructure the community wouldn't have so much work
to do for each release, and I wholeheartedly agree. Perhaps if we stop
releasing GHC so frequently they'll have time to work on it :)  
Releasing early and often is great, but at the moment it's having
negative effects on the ecosystem (arguably due to deficiencies in the
infrastructure).

Does this strike a chord with anyone, or have I got the wrong impression
and everyone is happy with the pace?

Cheers,
     Simon

On 07/02/13 18:15, Simon Peyton-Jones wrote:

>
> It?s fairly simple in my mind. There are two ?channels? (if I
> understand Mark?s terminology right):
>
> ?Haskell Platform:
>
> oA stable development environment, lots of libraries known to work
>
> oNewcomers, and people who value stability, should use the Haskell
> Platform
>
> oHP comes with a particular version of GHC, probably not the hottest
> new one, but that doesn?t matter.  It works.
>
> ?GHC home page downloads:
>
> oMore features but not so stable
>
> oLibraries not guaranteed to work
>
> oWorth releasing, though, as a forcing function to fix bugs, and as a
> checkpoint for people to test, so that by the time the HP adopts a
> particular version it is reasonably solid.
>
> So we already have the two channels Mark asks for, don?t we? One is
> called the Haskell Platform and one is called the GHC home page.
>
>
> That leaves a PR issue: we really /don?t/ want newcomers or Joe Users
> wanting the ?new shiny?. They want the Haskell Platform, and as Mark
> says those users should not pay the slightest attention until it
> appears in the Haskell Platform.
>
> So perhaps we principally need a way to point people away from GHC and
> towards HP?  eg We could prominently say at every download point
> ?Stop!  Are you sure you want this?  You might be better off with the
> Haskell Platform!  Here?s why...?.
>
> Have I understood aright?  If so, how could we achieve the right
> social dynamics?
>
> Our goal is to let people who value stability get stability, while the
> hot-shots race along in a different channel and pay the price of flat
> tires etc.
>
> PS: absolutely right to use 7.6.2 for the next HP.  Don?t even think
> about 7.8.
>
> Simon
>
> *From:*Mark Lentczner [mailto:mark.lentczner at gmail.com]
> *Sent:* 07 February 2013 17:43
> *To:* Simon Peyton-Jones
> *Cc:* andreas.voellmy at gmail.com; Carter Schonwald; GHC users; Simon
> Marlow; parallel-haskell; kostirya at gmail.com; Edsko de Vries;
> ghc-devs at haskell.org
> *Subject:* Re: GHC 7.8 release?
>
> I'd say the window for 7.8 in the platform is about closed. If 7.8
> were to be release in the next two weeks that would be just about the
> least amount of time I'd want to see for libraries in the platform to
> get all stable with the GHC version. And we'd also be counting on the
> GHC team to be quickly responding to bugs so that there could be a
> point release of 7.8 mid-April. Historically, none of that seems likely.
>
> So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2.
>
> Since 7.8 will seems like it will be released before May, we will be
> faced again with the bad public relations issue: Everyone will want
> the new shiny and be confused as to why the platform is such a
> laggard. We'll see four reactions:
>
>   * New comers who are starting out and figure they should use the
>     latest... Many will try to use 7.8, half the libraries on hackage
>     won't work, things will be wonky, and they'll have a poor experience.
>   * People doing production / project work will stay on 7.6 and ignore
>     7.8 for a few months.
>   * The small group of people exploring the frontiers will know how to
>     get things set up and be happy.
>   * Eventually library authors will get around to making sure their
>     stuff will work with it.
>
> I wish GHC would radically change it's release process. Things like
> 7.8 shouldn't be release as "7.8". That sounds major and stable. The
> web site will have 7.8 at the top. The warning to use
> the platform will fall flat because it makes the platform look out of
> date. Really, "7.8" should be in a different release channel, not on
> the front page. It should bake in that channel for six months - where
> only the third group of people will use it, until it is getting close
> to merge into main, at which point the fourth group will start to use
> it, so that the day it hits main, all the libraries just work.
> Ideally, the first two groups of people will not pay the slightest
> attention to it until it is further baked.
>
> While we achievements of the GHC team are great, less than half of
> those 7.8 features seem interesting from the viewpoint of the aims of
> the platform. I don't think adding syntactic or type-level features
> are really all that important for Haskell at this juncture. And while
> I do like to see improvements in generated code and run-time
> performance, I think even those are less important than making crucial
> ecosystem improvements to things like package management,
> cross-compilation, and libraries.
>
> - Mark
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/fd339cfa/attachment-0001.htm>

1234