2008-10-11 Hackage status with GHC 6.10
Daily update of the state of Hackage wrt. GHC 6.10 release candidates. Lots of packages were updated today, Cabal 1.6 and cabal-install 0.6 were also put out. Things are in a good shape. Note that you'll need a "soft dep" in your cabal index file, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 for best results. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 684 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 74 DependencyFailed 134 BuildFailed 455 InstallOk Compared to GHC 6.8.x's results, there are now *48* packages that produce different results, or *6%* (down 2% from yesterday). The most common issues are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages Packages that have broken wrt. the new core library APIs are, ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 PArrows-0.1 TypeCompose-0.5 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 hasim-0.1 hask-home-2007.12.6 heap-0.4.0 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 streamproc-1.1 stringtable-atom-0.0.4 typalyze-0.1.1 unicode-prelude-0.1 xmonad-utils-0.1 yhccore-0.9 GHC bugs are suspected for, xmonad-contrib, stream-fusion, harpy, OpenAFP Tickets are open for these. Build reports for these packages were posted yesterday, http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430 -- Don
On Sat, 11 Oct 2008, Don Stewart wrote:
Build reports for these packages were posted yesterday,
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430
For 'numeric-prelude' it is reported: numeric-prelude src/Number/Complex.hs:3:12: cannot parse LANGUAGE pragma: comma-separated list expected The offending pragma is: {-# LANGUAGE_HOW_CAN_WE_ENABLE Rules ? #-} Why is this interpreted as LANGUAGE pragma at all? ... and erm, how can I enable parsing of optimizer rules? With {-# OPTIONS_GHC -O #-} ?
On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
... and erm, how can I enable parsing of optimizer rules? With {-# OPTIONS_GHC -O #-} ?
Yes, although note that Cabal passes -O by default. I'd recommend not putting it in a pragma, as that will break ./Setup configure --disable-optimization Thanks Ian
On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
... and erm, how can I enable parsing of optimizer rules? With {-# OPTIONS_GHC -O #-} ?
Yes, although note that Cabal passes -O by default. I'd recommend not putting it in a pragma, as that will break ./Setup configure --disable-optimization
I think the question was how to get the RULES pragmas to be parsed. One does have to turn on a language extension to get the forall in rules to parse and it's not very clear at the moment which one we should be using. See http://hackage.haskell.org/trac/ghc/ticket/2497 Duncan
duncan.coutts:
On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
... and erm, how can I enable parsing of optimizer rules? With {-# OPTIONS_GHC -O #-} ?
Yes, although note that Cabal passes -O by default. I'd recommend not putting it in a pragma, as that will break ./Setup configure --disable-optimization
I think the question was how to get the RULES pragmas to be parsed. One does have to turn on a language extension to get the forall in rules to parse and it's not very clear at the moment which one we should be using.
I've been suggesting Rank2Types, which does the trick. -- Don
On Sun, 12 Oct 2008, Duncan Coutts wrote:
On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
... and erm, how can I enable parsing of optimizer rules? With {-# OPTIONS_GHC -O #-} ?
Yes, although note that Cabal passes -O by default. I'd recommend not putting it in a pragma, as that will break ./Setup configure --disable-optimization
I think the question was how to get the RULES pragmas to be parsed.
I wondered whether it is possible to let the compiler read and store the RULES pragmas without optimizing the code in the same module with respect to these RULES. When I want to compile the code without optimization - for whatever reason - I would still like to have the RULES checked. They could still be applied when imported to another module that is compiled with optimization.
| >> Yes, although note that Cabal passes -O by default. I'd recommend not | >> putting it in a pragma, as that will break | >> ./Setup configure --disable-optimization | > | > I think the question was how to get the RULES pragmas to be parsed. There's a bug I'm fixing (http://hackage.haskell.org/trac/ghc/ticket/2497). | I wondered whether it is possible to let the compiler read and store the | RULES pragmas without optimizing the code in the same module with respect | to these RULES. When I want to compile the code without optimization - for | whatever reason - I would still like to have the RULES checked. They could | still be applied when imported to another module that is compiled with | optimization. Indeed you can: use -fno-omit-interface-pragmas. This overrides the default, which is that with -O no non-essential info is put in the interface file. If you think it's worth improving the documentation (e.g. you didn't know about this), then I'd welcome a concrete suggestion. (eg Say "...this..." in the second bullet off ...".) Simon
On Mon, 13 Oct 2008, Simon Peyton-Jones wrote:
| I wondered whether it is possible to let the compiler read and store the | RULES pragmas without optimizing the code in the same module with respect | to these RULES. When I want to compile the code without optimization - for | whatever reason - I would still like to have the RULES checked. They could | still be applied when imported to another module that is compiled with | optimization.
Indeed you can: use -fno-omit-interface-pragmas. This overrides the default, which is that with -O no non-essential info is put in the interface file.
If you think it's worth improving the documentation (e.g. you didn't know about this), then I'd welcome a concrete suggestion. (eg Say "...this..." in the second bullet off ...".)
I found it just confusing to switch on two features (namely 'optimization including application of rules' and 'parsing, checking and storing new rules') with one option (namely -O). It remains confusing for me also if one of the two features can be enabled separately with -fno-omit-interface-pragmas, but the other feature cannot. Also the option sounds like it also applies not only to RULES. I also find the doubled negation in 'no omit' confusing. What about '-finclude-all-interface-pragmas'? What concerns documentation: The description of an option for enabling parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:
I found it just confusing to switch on two features (namely 'optimization including application of rules' and 'parsing, checking and storing new rules') with one option (namely -O). It remains confusing for me also if one of the two features can be enabled separately with -fno-omit-interface-pragmas, but the other feature cannot. Also the option sounds like it also applies not only to RULES. I also find the doubled negation in 'no omit' confusing. What about '-finclude-all-interface-pragmas'? What concerns documentation: The description of an option for enabling parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
While it used to be more complex, the situation now is quite simple: RULES are always parsed (no flags or language extensions needed). They also go into the .hi files (unless you use the obscure option to change that), so they are exported for all client modules. RULES get used/applied with -O. Again, there is an option to turn off the use of rules (without affecting other optimisations). This seems pretty sane and easy to explain. Duncan
| RULES are always parsed (no flags or language extensions needed). They | also go into the .hi files (unless you use the obscure option to change | that), so they are exported for all client modules. The latter isn't true, and I think that's what Henning is objecting to. Currently, without -O GHC puts the absolute minimum in interface files to get the clients to compile: just the exports and their types. For example, if you have f x = x GHC will not put that unfolding in the interface file, tiny though it is. Currently without -O GHC therefore does *not* put RULES in the interface file. I thought that was consistent, since they are to do with optimisation. If, however, there's a consensus that RULES should be persisted even without -O, that'd be easy to arrange. For example, I think that deprecations are persisted unconditionally. Simon | -----Original Message----- | From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk] | Sent: 16 October 2008 05:57 | To: Henning Thielemann | Cc: Simon Peyton-Jones; libraries@haskell.org | Subject: RE: 2008-10-11 Hackage status with GHC 6.10 | | On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote: | | > I found it just confusing to switch on two features (namely 'optimization | > including application of rules' and 'parsing, checking and storing new | > rules') with one option (namely -O). It remains confusing for me also if | > one of the two features can be enabled separately with | > -fno-omit-interface-pragmas, but the other feature cannot. Also the option | > sounds like it also applies not only to RULES. I also find the doubled | > negation in 'no omit' confusing. What about | > '-finclude-all-interface-pragmas'? | > What concerns documentation: The description of an option for enabling | > parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html. | | While it used to be more complex, the situation now is quite simple: | | RULES are always parsed (no flags or language extensions needed). They | also go into the .hi files (unless you use the obscure option to change | that), so they are exported for all client modules. | | RULES get used/applied with -O. Again, there is an option to turn off | the use of rules (without affecting other optimisations). | | This seems pretty sane and easy to explain. | | Duncan |
simonpj:
| RULES are always parsed (no flags or language extensions needed). They | also go into the .hi files (unless you use the obscure option to change | that), so they are exported for all client modules.
The latter isn't true, and I think that's what Henning is objecting to.
Currently, without -O GHC puts the absolute minimum in interface files to get the clients to compile: just the exports and their types. For example, if you have f x = x GHC will not put that unfolding in the interface file, tiny though it is.
Currently without -O GHC therefore does *not* put RULES in the interface file. I thought that was consistent, since they are to do with optimisation.
If, however, there's a consensus that RULES should be persisted even without -O, that'd be easy to arrange. For example, I think that deprecations are persisted unconditionally.
So the next build with GHC 6.10 branch we should no longer see 'forall' parse failures from hackage libraries that use RULES? -- Don
| So the next build with GHC 6.10 branch we should no longer see | 'forall' parse failures from hackage libraries that use RULES? Yes -- but not for the reasons below. It should work now because I fixed http://hackage.haskell.org/trac/ghc/ticket/2497 Simon | -----Original Message----- | From: Don Stewart [mailto:dons@galois.com] | Sent: 16 October 2008 19:40 | To: Simon Peyton-Jones | Cc: Duncan Coutts; Henning Thielemann; libraries@haskell.org | Subject: Re: 2008-10-11 Hackage status with GHC 6.10 | | simonpj: | > | RULES are always parsed (no flags or language extensions needed). They | > | also go into the .hi files (unless you use the obscure option to change | > | that), so they are exported for all client modules. | > | > The latter isn't true, and I think that's what Henning is objecting to. | > | > Currently, without -O GHC puts the absolute minimum in interface files | > to get the clients to compile: just the exports and their types. For | > example, if you have | > f x = x | > GHC will not put that unfolding in the interface file, tiny though it | > is. | > | > Currently without -O GHC therefore does *not* put RULES in the | > interface file. I thought that was consistent, since they are to do | > with optimisation. | > | > If, however, there's a consensus that RULES should be persisted even | > without -O, that'd be easy to arrange. For example, I think that | > deprecations are persisted unconditionally. | | So the next build with GHC 6.10 branch we should no longer see | 'forall' parse failures from hackage libraries that use RULES? | | -- Don
On Thu, 2008-10-16 at 11:12 +0100, Simon Peyton-Jones wrote:
| RULES are always parsed (no flags or language extensions needed). They | also go into the .hi files (unless you use the obscure option to change | that), so they are exported for all client modules.
The latter isn't true, and I think that's what Henning is objecting to.
Oops. As I read it Henning wants the RULES parsed with or without -O. That bit is now much simpler than it used to be. I didn't read his objection as wanting them always exported even if the defining module was not built without -O, just that they should always be parsed and checked.
Currently, without -O GHC puts the absolute minimum in interface files to get the clients to compile
Right. My mistake.
Currently without -O GHC therefore does *not* put RULES in the interface file. I thought that was consistent, since they are to do with optimisation.
Right.
If, however, there's a consensus that RULES should be persisted even without -O, that'd be easy to arrange. For example, I think that deprecations are persisted unconditionally.
I think the current behaviour is consistent and makes sense. We do want the minimum without -O because it gives more minimal rebuilds if the .hi files do not change so often. I've updated the wiki page on 6.10 upgrading: http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_RULES_parsing Duncan
On Wed, 15 Oct 2008, Duncan Coutts wrote:
On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:
I found it just confusing to switch on two features (namely 'optimization including application of rules' and 'parsing, checking and storing new rules') with one option (namely -O). It remains confusing for me also if one of the two features can be enabled separately with -fno-omit-interface-pragmas, but the other feature cannot. Also the option sounds like it also applies not only to RULES. I also find the doubled negation in 'no omit' confusing. What about '-finclude-all-interface-pragmas'? What concerns documentation: The description of an option for enabling parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
While it used to be more complex, the situation now is quite simple:
RULES are always parsed (no flags or language extensions needed). They also go into the .hi files (unless you use the obscure option to change that), so they are exported for all client modules.
So they are handled like all pragmas. That sounds fine to me.
RULES get used/applied with -O. Again, there is an option to turn off the use of rules (without affecting other optimisations).
This seems pretty sane and easy to explain.
yes, indeed
Right. I've finally fixed 2497; it was a typo, and while I thought I'd tested it, the test didn't tet that RULES compile without any flags. The story is that you should not need any funny RankN flags just to make RULES parse and typecheck. -XScopedTypeVariables gets set automatically inside a RULES pragma. This is what the discussion on #2497 claimed, but there was a bug in the impl. Ian pls merge: Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan | Coutts | Sent: 12 October 2008 17:53 | To: Ian Lynagh | Cc: Henning Thielemann; libraries@haskell.org | Subject: Re: 2008-10-11 Hackage status with GHC 6.10 | | On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote: | > On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote: | > > | > > ... and erm, how can I enable parsing of optimizer rules? | > > With {-# OPTIONS_GHC -O #-} ? | > | > Yes, although note that Cabal passes -O by default. I'd recommend not | > putting it in a pragma, as that will break | > ./Setup configure --disable-optimization | | I think the question was how to get the RULES pragmas to be parsed. One | does have to turn on a language extension to get the forall in rules to | parse and it's not very clear at the moment which one we should be | using. | | See http://hackage.haskell.org/trac/ghc/ticket/2497 | | Duncan | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries
On Wed, 2008-10-15 at 09:46 +0100, Simon Peyton-Jones wrote:
Right. I've finally fixed 2497; it was a typo, and while I thought I'd tested it, the test didn't tet that RULES compile without any flags.
That's great, thanks.
The story is that you should not need any funny RankN flags just to make RULES parse and typecheck. -XScopedTypeVariables gets set automatically inside a RULES pragma. This is what the discussion on #2497 claimed, but there was a bug in the impl.
And for people trying to make their code compatible with older ghc too, they can use this in their .cabal files: extensions: ScopedTypeVariables Which makes Cabal pass -XScopedTypeVariables for ghc-6.8 and for 6.6 and earlier is passes -fglasgow-exts. This is what the bytestring package is currently using (and no more ghc-options: -fglasgow-exts). Duncan
participants (5)
-
Don Stewart -
Duncan Coutts -
Henning Thielemann -
Ian Lynagh -
Simon Peyton-Jones