Can the in-progress ByteString proposals make it into GHC 7.4.1?
Hello GHC HQ, According to the GHC Status October 2011 Report[3], the GHC 7.4 branch is supposed to be in "feature freeze" by now. Does this affect/include the bytestring library (as it happens to be a GHC-boot library) as well? More specifically, if the ongoing proposals "Add {to,from}Strict conversion functions between strict and lazy ByteStrings"[1] and "Add NFData instances for strict and lazy ByteStrings"[2] succeed, what's the next stable GHC release they're gonna be included in? [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16444 [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16397 [3]: http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11 -- hvr
| According to the GHC Status October 2011 Report[3], the GHC 7.4 branch | is supposed to be in "feature freeze" by now. Does this affect/include | the bytestring library (as it happens to be a GHC-boot library) as well? Yes, we're supposed to be but we have two big additions nearly ready but not quite validate free so we have pushed it out a few days. | More specifically, if the ongoing proposals "Add {to,from}Strict | conversion functions between strict and lazy ByteStrings"[1] and "Add | NFData instances for strict and lazy ByteStrings"[2] succeed, what's the | next stable GHC release they're gonna be included in? I defer to the bytestring maintainers: Don Stewart and Duncan Coutts. Don, Duncan: were you wanting to get these changes into 7.4? Simon | | | [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16444 | | [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16397 | | [3]: http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11 | | | -- hvr | | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries
On Thu, 2011-11-03 at 12:40 +0000, Simon Peyton-Jones wrote:
| According to the GHC Status October 2011 Report[3], the GHC 7.4 branch | is supposed to be in "feature freeze" by now. Does this affect/include | the bytestring library (as it happens to be a GHC-boot library) as well?
Yes, we're supposed to be but we have two big additions nearly ready but not quite validate free so we have pushed it out a few days.
| More specifically, if the ongoing proposals "Add {to,from}Strict | conversion functions between strict and lazy ByteStrings"[1] and "Add | NFData instances for strict and lazy ByteStrings"[2] succeed, what's the | next stable GHC release they're gonna be included in?
I defer to the bytestring maintainers: Don Stewart and Duncan Coutts.
Don, Duncan: were you wanting to get these changes into 7.4?
Yes. They're now in the upstream repo for bytestring along with various other changes. So I hope that'll flow through into ghc's mirror. Duncan
On Mon, Nov 14, 2011 at 11:15:17AM +0000, Duncan Coutts wrote:
On Thu, 2011-11-03 at 12:40 +0000, Simon Peyton-Jones wrote:
Don, Duncan: were you wanting to get these changes into 7.4?
Yes. They're now in the upstream repo for bytestring along with various other changes. So I hope that'll flow through into ghc's mirror.
I tried pulling them a few days ago, but validate didn't go through. As we were well past the announced deadline I therefore wasn't planning on pulling them in for 7.4. Thanks Ian
On Tue, 2011-11-15 at 18:12 +0000, Ian Lynagh wrote:
On Mon, Nov 14, 2011 at 11:15:17AM +0000, Duncan Coutts wrote:
On Thu, 2011-11-03 at 12:40 +0000, Simon Peyton-Jones wrote:
Don, Duncan: were you wanting to get these changes into 7.4?
Yes. They're now in the upstream repo for bytestring along with various other changes. So I hope that'll flow through into ghc's mirror.
I tried pulling them a few days ago, but validate didn't go through.
Due to other libs requiring bytestring == 0.9.*, or any other more interesting reason? If you don't recall, nm.
As we were well past the announced deadline I therefore wasn't planning on pulling them in for 7.4.
Fair enough. I have other bigger things to include as well (new builder monoid) so it's fine to postpone the lot. Duncan
On Tue, Nov 15, 2011 at 11:07:31PM +0000, Duncan Coutts wrote:
On Tue, 2011-11-15 at 18:12 +0000, Ian Lynagh wrote:
On Mon, Nov 14, 2011 at 11:15:17AM +0000, Duncan Coutts wrote:
On Thu, 2011-11-03 at 12:40 +0000, Simon Peyton-Jones wrote:
Don, Duncan: were you wanting to get these changes into 7.4?
Yes. They're now in the upstream repo for bytestring along with various other changes. So I hope that'll flow through into ghc's mirror.
I tried pulling them a few days ago, but validate didn't go through.
Due to other libs requiring bytestring == 0.9.*, or any other more interesting reason? If you don't recall, nm.
I don't think I looked into the failure in detail.
Fair enough. I have other bigger things to include as well (new builder monoid) so it's fine to postpone the lot.
OK, ta. Thanks Ian
(had to resent this email as it got rejected the first time by the mailing list) On Wed, 2011-11-16 at 19:41 +0000, Ian Lynagh wrote:
On Tue, Nov 15, 2011 at 11:07:31PM +0000, Duncan Coutts wrote:
On Tue, 2011-11-15 at 18:12 +0000, Ian Lynagh wrote:
On Mon, Nov 14, 2011 at 11:15:17AM +0000, Duncan Coutts wrote:
On Thu, 2011-11-03 at 12:40 +0000, Simon Peyton-Jones wrote:
Don, Duncan: were you wanting to get these changes into 7.4?
Yes. They're now in the upstream repo for bytestring along with various other changes. So I hope that'll flow through into ghc's mirror.
I tried pulling them a few days ago, but validate didn't go through.
Due to other libs requiring bytestring == 0.9.*, or any other more interesting reason? If you don't recall, nm.
I don't think I looked into the failure in detail.
fyi, I've been trying to reproduce your validate observation, and I got quite a few -Werror caused errors in the process (which have been fixed in the upstream bytestring repo) This morning I ran a "validate" on a freshly checked out GHC source (which uses bytestring-0.9.2) tree, and got the following result: OVERALL SUMMARY for test run started at Thu Nov 17 12:30:14 CET 2011 3121 total tests, which gave rise to 10479 test cases, of which 0 caused framework failures 7673 were skipped 2733 expected passes 70 expected failures 0 unexpected passes 3 unexpected failures Unexpected failures: concurrent/should_run 5238 [exit code non-0] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) Then I applied the modifications (see the two patches attached) to the ghc source-tree and the haskeline library required to make ghc compile with bytestring-0.10 instead of bytestring-0.9.2, made sure the bytestring library was really updated to the 0.10 version, cleaned the source trees, and finally re-ran "validate" Now I'm pleased to report, that the overall summary reported the exact same numbers with bytestring-0.10 linked into GHC instead of bytestring-0.9.2 :-) hth, hvr
participants (4)
-
Duncan Coutts -
Herbert Valerio Riedel -
Ian Lynagh -
Simon Peyton-Jones