2008-10-12 Hackage status with GHC 6.10 release candidate
Hey all. The GHC 6.10 RCs are out, and we're preparing the release. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate. For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 73 DependencyFailed 132 BuildFailed 456 InstallOk Note that these builds are with "soft deps", provided on hackage, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 which train cabal-install to build a larger set of packages. The important result: *46 packages produce different results to ghc 6.8.2* These packages and their logs are listed below. If you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy. The most common issues for these differences 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 Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-12/ The following packages are producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. 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 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 xmonad-utils-0.1 yhccore-0.9 If you'd like to try your own build of all of hackage, grab a package list (such as this one), http://www.galois.com/~dons/tmp/pkgs-6.10 Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage), and cabal-install 0.6 (on hackage), and then simply, cabal install -v -O0 $(cat pkgs-6.10) --build-reports This will construct a clever plan to install all the packages in the right order, and write logs to ~/.cabal/logs and a full structured build report into ~/.cabal/packages/hackage.*/build-report.log -- Don
Don Stewart wrote:
Note that these builds are with "soft deps", provided on hackage,
base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2
which train cabal-install to build a larger set of packages.
Will this happen automatically somehow, or will users have to do this manually?
The important result:
*46 packages produce different results to ghc 6.8.2*
These packages and their logs are listed below.
If you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy.
The most common issues for these differences are,
* Changes to Arrow class definition * Changes to types of Map and Set functions
It would be feasible to provide a containers-0.1, if anyone thinks that's worthwhile.
* Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved,
Nobody should be importing GHC.Prim, use GHC.Exts instead.
* Changes to -fvia-C and headers
I wrote a more detailed entry for the release notes about this: http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-1.html ("FFI change" under "User-visible compiler changes") Cheers, Simon
marlowsd:
Don Stewart wrote:
Note that these builds are with "soft deps", provided on hackage,
base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2
which train cabal-install to build a larger set of packages.
Will this happen automatically somehow, or will users have to do this manually?
Yes, Duncan and Ross have modified the scripts on hackage, so that a "preferred-versions" file is included in the Hackage index. So there is one central point where these version suggestions to cabal-install are set. As long as you're using cabal-install 0.6, and do a 'cabal update' things should just work. -- Don
On Mon, 2008-10-13 at 10:54 -0700, Don Stewart wrote:
marlowsd:
Don Stewart wrote:
Note that these builds are with "soft deps", provided on hackage,
base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2
which train cabal-install to build a larger set of packages.
Will this happen automatically somehow, or will users have to do this manually?
Yes, Duncan and Ross have modified the scripts on hackage, so that a "preferred-versions" file is included in the Hackage index.
There was a day and a half or so when this change got accidentally reverted due to some mis-communication between myself and Ross (my fault). It's all fixed up now. Currently these preferred version are only taken into account by "cabal install" not "cabal configure" (though that's an obvious improvement to do). Duncan
Simon Marlow wrote:
Don Stewart wrote:
* GHC.Prim was moved,
Nobody should be importing GHC.Prim, use GHC.Exts instead.
This is oft declared, but as things stand I don't think it's a tenable position. If someone's bothering to dig as far as GHC.Exts then it's very likely they're trying to optimize numeric computations and for that there are a number of functions in GHC.Prim which are essential, in particular the fast conversion functions for numeric types[1]. If those were moved to GHC.Exts then I think many people would be more inclined to heed the advice. [1] Of the many, these four especially: int2Double#, int2Float#, double2Float#, float2Double#. Though I'm sure the folks who work with Words would like to add to this list. -- Live well, ~wren
wren ng thornton wrote:
Simon Marlow wrote:
Don Stewart wrote:
* GHC.Prim was moved,
Nobody should be importing GHC.Prim, use GHC.Exts instead.
This is oft declared, but as things stand I don't think it's a tenable position. If someone's bothering to dig as far as GHC.Exts then it's very likely they're trying to optimize numeric computations and for that there are a number of functions in GHC.Prim which are essential, in particular the fast conversion functions for numeric types[1]. If those were moved to GHC.Exts then I think many people would be more inclined to heed the advice.
GHC.Exts re-exports the whole of GHC.Prim. There's no reason to import GHC.Prim at all. Admittedly this isn't immediately obvious from the documentation, but it is there. Hopefully in the future we can improve Haddock so that it'll be able to paste in the whole of GHC.Prim into the GHC.Exts documentation, and we can then hide GHC.Prim. Cheers, Simon
Simon Marlow wrote:
wren ng thornton wrote:
Simon Marlow wrote:
Don Stewart wrote:
* GHC.Prim was moved,
Nobody should be importing GHC.Prim, use GHC.Exts instead.
This is oft declared, but as things stand I don't think it's a tenable position. If someone's bothering to dig as far as GHC.Exts then it's very likely they're trying to optimize numeric computations and for that there are a number of functions in GHC.Prim which are essential, in particular the fast conversion functions for numeric types[1]. If those were moved to GHC.Exts then I think many people would be more inclined to heed the advice.
GHC.Exts re-exports the whole of GHC.Prim. There's no reason to import GHC.Prim at all. Admittedly this isn't immediately obvious from the documentation, but it is there. Hopefully in the future we can improve Haddock so that it'll be able to paste in the whole of GHC.Prim into the GHC.Exts documentation, and we can then hide GHC.Prim.
On more recent checking that seems to be the case, however I do recall having issues with it in the past. Seems to work on 6.6 too so I'll switch my stuff over. FWIW, if you explicitly re-export the entities by name Haddock will paste them in (though that's a lot of copying in the export list). -- Live well, ~wren
wren:
Simon Marlow wrote:
wren ng thornton wrote:
Simon Marlow wrote:
Don Stewart wrote:
* GHC.Prim was moved,
Nobody should be importing GHC.Prim, use GHC.Exts instead.
This is oft declared, but as things stand I don't think it's a tenable position. If someone's bothering to dig as far as GHC.Exts then it's very likely they're trying to optimize numeric computations and for that there are a number of functions in GHC.Prim which are essential, in particular the fast conversion functions for numeric types[1]. If those were moved to GHC.Exts then I think many people would be more inclined to heed the advice.
GHC.Exts re-exports the whole of GHC.Prim. There's no reason to import GHC.Prim at all. Admittedly this isn't immediately obvious from the documentation, but it is there. Hopefully in the future we can improve Haddock so that it'll be able to paste in the whole of GHC.Prim into the GHC.Exts documentation, and we can then hide GHC.Prim.
On more recent checking that seems to be the case, however I do recall having issues with it in the past. Seems to work on 6.6 too so I'll switch my stuff over.
FWIW, if you explicitly re-export the entities by name Haddock will paste them in (though that's a lot of copying in the export list).
Topic added to the wiki, http://haskell.org/haskellwiki/Upgrading_packages#No_more_GHC.Prim I'm glad we know how to handle the majority of migration issues prior to the release. This is a first :) -- Don
Hey all.
The GHC 6.10 RCs are out, and we're preparing the release. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate.
For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries.
Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total,
1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 73 DependencyFailed 132 BuildFailed 456 InstallOk
Note that these builds are with "soft deps", provided on hackage,
base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2
which train cabal-install to build a larger set of packages. What's the status of Gtk2Hs with regard to Cabal? Is it correct that not one of the applications on Hackage, and there are some, uses or can use a GUI at this point in time? Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the
On Sun, 2008-10-12 at 14:46 -0700, Don Stewart wrote: past there have sometimes been problems with new GHC releases and Gtk2Hs. These have always been addressed, but it usually took a few months.. Cheers, Hans van Thiel [snip]
On Mon, 2008-10-13 at 16:15 +0200, Hans van Thiel wrote:
What's the status of Gtk2Hs with regard to Cabal? Is it correct that not one of the applications on Hackage, and there are some, uses or can use a GUI at this point in time?
Gtk2Hs still does not use Cabal as its build system. With the recent summer of code project on a dependency framework for Cabal we're now much closer to being able to convert Gtk2Hs to use Cabal. There are several packages on hackage that depend on gtk2hs or wxhaskell.
Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the past there have sometimes been problems with new GHC releases and Gtk2Hs. These have always been addressed, but it usually took a few months..
I think I've seen some patches going past on the gtk2hs-devel list for ghc-6.10 compatibility. Duncan
Hans van Thiel wrote:
Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the past there have sometimes been problems with new GHC releases and Gtk2Hs. These have always been addressed, but it usually took a few months..
I just built Gtk2Hs with the 6.10-rc on Windows, and it seems to work. The release version, 0.9.13, is a no-go though: I needed a patch (related to an "instance Binary Integer") before I got it to compile. And a lot of other messing about as well, but I've got used to that on Windows.
participants (6)
-
Don Stewart -
Duncan Coutts -
Hans van Thiel -
Matti Niemenmaa -
Simon Marlow -
wren ng thornton