- Glasgow-haskell-users

breakage with Cabal-1.6
by Duncan Coutts 16 Oct '08

16 Oct '08

All, I'm trying to do a Cabal-1.6 release, in time for ghc-6.10. Here's an interim update. There are 7 packages on hackage where the latest version has a Setup.hs script that works with Cabal-1.4 but does not compile with Cabal-1.6. That's actually not too bad. It's been a lot worse in the past, and we have many more packages now. Here's the list and explanations: * ForSyDe-3.0 Uses the copyDest field from CopyFlags. These record types now use an equivalent of Maybe so they can be empty rather than always containing a default value. It's useful, but also kind of annoying in places. It's an easy fix. * MissingPy-0.10.0 * Takusen-0.8.3 * HDBC-postgresql-1.1.4.0 Imports writeHookedBuildInfo from Distribution.PackageDescription This one is a bit annoying. I tried to split up the Distribution.PackageDescription module a bit, because it was something like 1,700 lines long. I moved the parsing out into Distribution.PackageDescription.Parse. Some packages of course sill expect to get writeHookedBuildInfo from the previous location. I could make it still work by using recursive modules, but I worry what that would do to the process of bootstrapping Cabal (especially with hugs or nhc). Or I could re-merge the modules into one massive module again. Or I could say, it's only three packages broken, it's all ok. While the fix for these three packages' Setup scripts is trivial, there is not fix that will make them compile with old and new versions of the lib. Suggestions welcome. * alex-2.2 * happy-1.17 Imports buildVerbose from Distribution.Simple.Setup ( BuildFlags(..) ) however the flag has been renamed to buildVerbosity and with a different type. I would export a compat function but it would not help here since the Setup script expects it to be a record selector from BuildFlags. Cabal-1.4 contained a dodgy hack to make this continue to work, but I'm not doing that again. If I added a compat function then we could at least make it work with both ghc/cabal versions with a single implementation. So I might do that and do point releases of these packages, if Simon thinks that's ok. Really of course both packages should stop calling an external perl and other similar madness. * hsql-odbc-1.7 Imports Distribution.Setup which has been deprecated since at least Cabal-1.2. This package is unmaintained so it's not so surprising. Duncan

6 10

Re: [Haskell-cafe] 2008-10-13 Hackage status with GHC 6.10 release candidate
by Don Stewart 15 Oct '08

15 Oct '08

schlepptop: > Don Stewart schrieb: > > > numeric-prelude-0.0.4 > > Easy: Lanuage pragma > > My question was still not answered: I used the non-existing pragma > LANGUAGE_HOW_CAN_WE_ENABLE - I hoped it would be ignored, but it was > parsed and made GHC fail. Why? Bug or feature? > > Feature. {-# #-} language-y pragmas are parsed now. Check with GHC HQ for details. -- Don

1 0

2008-10-13 Hackage status with GHC 6.10 release candidate
by Don Stewart 15 Oct '08

15 Oct '08

Hey all. The GHC 6.10 RCs are out, and we're preparing the release of GHC proper. 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 from today, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 68 DependencyFailed 122 BuildFailed 469 InstallOk Since yesterday, * dependency failures have reduced by 5 * build failures have reduced by 10 * total successfully installed packages are **up by 14** These new packages now all build ok with the GHC 6.10 release candidate, Graphalyze-0.4 alsa-midi calc glome-hs harpy heap hmp3 ircbouncer mohws panda pandoc roguestar-engine type-level typeof unicode-prelude urlcheck Good work everyone! Some packages are still not ready though, 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 The following packages are still producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. I've marked the easy ones. ArrayRef-0.1.2 Easy: duplicate type signatures CLASE-2008.9.23.2 Hard: GADT changes EdisonCore-1.2.1.2 Easy: Monadic Map HPDF-1.4 Easy: Monadic Map HaLeX-1.1 Easy: Name clash with permutations Hashell-0.15 ? : GHC API Hipmunk-0.2 Easy: Monadic Map MemoTrie-0.0 Easy: 'forall' parsing NewBinary-0.1.1 Easy: Integer constructors moved PArrows-0.1 Easy: GHC.Prim moved (use GHC.Exts) TypeCompose-0.5 Easy: Arrow class changes YamlReference-0.9.2 Hard. Unknown Yampa-0.9.2.2 Arrow class changes arrows-0.4 Arrow class changes bytestring-show-0.2 Easy: Integer constructors moved cabal-setup-1.2.1 Hard: Cabal changes chp-1.1.0 Easy: Arrow class changes cmath-0.3 Hard: -fvia-C changes fixpoint-0.1 Easy: Uses -Werror unnecessarily hasim-0.1 Hard: GADT changes hask-home-2007.12.6 Easy: Cabal changes hetris-0.2 Easy: header macros/-fvia-C hexpat-0.2 Easy: 'forall' parsing in RULES hinstaller-2008.2.16 Easy: Cabal changes hint-0.2.4.1 Hard? GHC API hslackbuilder-0.0.1 Easy: Cabal changes hxt-8.1.0 Easy: Arrow class change iException-0.0.1 ? Exception changes libGenI-0.16.1 Easy: Monadic Map changes mage-1.1.0 Hard: -fvia-C changes numeric-prelude-0.0.4 Easy: Lanuage pragma plugins-1.3 Easy: Cabal changes quantum-arrow-0.0.4 Easy: Arrow class changes regex-tdfa-0.94 Easy: Map changes streamproc-1.1 Easy: Arrow class changes stringtable-atom-0.0.4 Easy: Monadic Map typalyze-0.1.1 ? GHC API xmonad-utils-0.1 ? GHC API yhccore-0.9 ? Pragma parsing Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-13/ How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages 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 I'll start mailing maintainers personally tomorrow. -- Don

3 2

Illegal type synonym family application in instance (Was: Breakage with 6.10)
by Niklas Broberg 15 Oct '08

15 Oct '08

dons: > A breakdown of the remaing causes for DependencyFailed, > [...] > 4 hsx-0.4.4 --------------- src/hsx$ runhaskell Setup build [snip warnings] src\HSX\XMLGenerator.hs:71:0 Illegal type synonym family application in instance: XML m In the instance declaration for `EmbedAsChild m (XML m)´ --------------- Could someone help me point out the problem here? The relevant code is: instance XMLGen m => EmbedAsChild m (XML m) where asChild = return . return . xmlToChild class XMLGen m => EmbedAsChild m c where asChild :: c -> GenChildList m class Monad m => XMLGen m where type XML m .... This works fine with 6.8.3, so what's new in 6.10, and what would I do to solve it? Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base? And how would I make the code work with both 6.8.3 and 6.10? Thanks, /Niklas

4 6

Re[2]: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.
by Bulat Ziganshin 14 Oct '08

14 Oct '08

Hello Thomas, Tuesday, October 14, 2008, 2:46:45 PM, you wrote: > The issue is binary compatibility. At the moment, GHC cannot make > sure that a library compiled with an older GHC can work with a newer > GHC. GHC does many cross-module optimisations, and its runtime system > changes occasionally, so it is very pessimistic in that regard. This > becomes an issue for packages that GHC has been build with itself > (like base, process, array), since these cannot be upgraded without > recompiling GHC (hence requiring recompiling every other package). is this correct? i was under impression that upgrading packages never require to recompile GHC itself. it just happen that we have only one version of base or array shipped with each GHC and at least with array this can be changed easily (and for base too - just noone plans to do it) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Re: Hackage and GUI (was Hackage status with GHC 6.10 release candidate)
by Matti Niemenmaa 13 Oct '08

13 Oct '08

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.

1 0

Re: [Haskell-cafe] Hackage and GUI (was Hackage status with GHC 6.10 release candidate)
by Duncan Coutts 13 Oct '08

13 Oct '08

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

1 0

2008-10-12 Hackage status with GHC 6.10 release candidate
by Don Stewart 13 Oct '08

13 Oct '08

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

3 3

Re: pandoc from cabal / MacPorts ?
by Christian Maeder 13 Oct '08

13 Oct '08

I'll CC this to glasgow-haskell-users(a)haskell.org in case someone else has the same problem. 1. Download http://hackage.haskell.org/packages/archive/pandoc/1.0.0.1/pandoc-1.0.0.1.t… http://hackage.haskell.org/packages/archive/zip-archive/0.1.1/zip-archive-0… http://hackage.haskell.org/packages/archive/utf8-string/0.3.1.1/utf8-string… http://hackage.haskell.org/packages/archive/zlib/0.4.0.4/zlib-0.4.0.4.tar.gz http://hackage.haskell.org/packages/archive/binary/0.4.3.1/binary-0.4.3.1.t… And install all this packages in reverse order (the last 3 packages are independent) 2. Alternatively you can first install http://hackage.haskell.org/packages/archive/cabal-install/0.5.2/cabal-insta… (versions 0.5.1 or 0.6 will work, too) after installing a further version of Cabal http://hackage.haskell.org/packages/archive/Cabal/1.4.0.2/Cabal-1.4.0.2.tar… and http://hackage.haskell.org/packages/archive/HTTP/3001.1.3/HTTP-3001.1.3.tar… http://hackage.haskell.org/packages/archive/zlib/0.4.0.4/zlib-0.4.0.4.tar.gz Once you have cabal, installing is much easier (just "cabal install pandoc"). Installing one of the above *.tar.gz packages works as follows: tar zxf <package-name>.tar.gz cd <package-name> ghc --make Setup.* ./Setup configure ./Setup build ./Setup install cd .. (This Setup.* is either Setup.hs or Setup.lhs) You may supply a "--prefix=/opt/local" to ./Setup configure. Cheers Christian denis wrote: > Greg, Christian, > still no luck here in macosx 10.4.11 ppc, > port install hs-ghc-paths => the errors in Friday's mail below > > I'm probably missing something basic -- > should I "port install hs-cabal" before hs-ghc-paths <- haddock <- > pandoc ? > It seems to have come in with ghc > cabal --version => > cabal-install version 0.5.1 > using version 1.4.0.2 of the Cabal library > > port list install | egrep => > ghc @6.8.3 lang/ghc > hs-HTTP @3001.0.4 devel/hs-HTTP > hs-libcabal @1.4.0.2 devel/hs-libcabal > hs-zlib @0.4.0.4 devel/hs-zlib > > > Trying to just configure hs-cabal -- maybe a wrong thing to do -- > sudo port clean --all hs-cabal > sudo port -v configure hs-cabal > # from: sudo port -v configure hs-cabal > # run: 13 Oct 2008 11:06 in /opt/local Denis.local mac 10.4.11 ppc > > ---> Verifying checksum(s) for hs-cabal > ---> Checksumming cabal-install-0.5.1.tar.gz > ---> Extracting hs-cabal > ---> Extracting cabal-install-0.5.1.tar.gz > ---> Configuring hs-cabal > Configuring cabal-install-0.5.1... > Setup: At least the following dependencies are missing: > Cabal >=1.4&&<1.5, HTTP >=3000&&<3002, zlib >=0.4 > Error: Target org.macports.configure returned: shell command "cd > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-cabal/work/cabal-install-0.5.1 > && runhaskell Setup configure --ghc --prefix=/opt/local" returned error 1 > Command output: Configuring cabal-install-0.5.1... > Setup: At least the following dependencies are missing: > Cabal >=1.4&&<1.5, HTTP >=3000&&<3002, zlib >=0.4 > > Warning: the following items did not execute (for hs-cabal): > org.macports.configure > Error: Status 1 encountered during processing. > > > Also, is there a way of listing dependency chains / trees like > ghc <- hs-ghc-paths <- haddock <- pandoc > (on all, not just installed, packages) > so that one can build them step by step ? > > > Christian, what's the simplest sequence to build haddock / pandoc from > the source > pandoc-1.0.0.1.tar.gz without MacPorts ? > I just want pandoc, don't care about haskel / ghc / ... at all. > The nice pandoc INSTALL says > Pandoc needs the `utf8-string` and `zip-archive` to compile. > ... On \*nix systems, the easiest way to do this is to install the > [cabal-install] tool ... > But how do I "cabal list installed-locally", "cabal list-tree-to pandoc" ? > > Thanks, > cheers > -- denis >

1 0

Breakage with 6.10
by Don Stewart 13 Oct '08

13 Oct '08

Quick summary of the latest hackage state, now hslogger has been amended. x86_64/linux/ghc-6.10/cabal-install 0.6/Cabal 1.6 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 71 DependencyFailed 138 BuildFailed 447 InstallOk So you can see that DependencyFailed is down 30, thanks to hslogger now working. InstallOk is up about 23. A breakdown of the remaing causes for DependencyFailed, 2 Win32-2.1.0.0 2 Yampa-0.9.2.2 2 hint-0.2.4.1 2 hsdns-1.3 2 plugins-1.3 3 pandoc-1.0.0.1 3 stringtable-atom-0.0.4 4 TypeCompose-0.5 4 hsql-1.7 4 hsx-0.4.4 5 hxt-8.1.0 6 HAppS-Data-0.9.2.1 6 arrows-0.4 6 wxcore-0.10.3 The main thing to fix there is 'arrows', an extra lib, we'll bump that. arrows fails due to: [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure' Even though cabal-install decided to use base-3.0.3.0 So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this? -- Don

4 3