- Glasgow-haskell-users

GHC 6.10 confusion
by J. Garrett Morris 20 Oct '08

20 Oct '08

Hello everyone, I've been attempting to build darcs under ghc-6.10.0.20080920. Currently, I'm getting the following error: ghc failed with: D:\Programs32\GHC\ghc-6.10.0.20080920\bin/windres: CreateProcess (null): No error Does anyone recognize this? Any pointers for where I should be looking? This is on Vista 64-bit SP1. /g -- I am in here

3 3

What a mess....
by Magicloud 20 Oct '08

20 Oct '08

Hi, I want to install ghc 6.10. Well.... I installed ghc 6.6.1 (binary distribution), and cabal, happy, alex (all from darcs, the latest version). Then darcsed 6.10's source. And made. I got: "templates/GenericTemplate.hs:47:21: parse error on input `#'", when "make -C genprimopcode" Any idea what should I do? Thanks.

2 2

Strictness in data declaration not matched in assembler?
by Tyson Whitehead 20 Oct '08

20 Oct '08

Consider the following code data Data = Data { unData :: !Int } func :: Data -> Int func x = case unData x of 1 -> 2 _ -> 0 Compiling with GHC 6.8.2 gives the following stg code Main.func = \r [x_slg] case x_slg of tpl_slx { Main.Data ipv_slj -> case ipv_slj of wild_sly { GHC.Base.I# ds_slm -> case ds_slm of ds1_slz { __DEFAULT -> Main.lvl1; 1 -> Main.lvl; }; }; }; The native code generator turns it into the following x86_64 assembler Main_func_info: leaq -8(%rbp),%rax cmpq %r14,%rax jb .LcnU movq %rsi,%rbx movq $sni_info,-8(%rbp) addq $-8,%rbp testq $7,%rbx jne sni_info jmp *(%rbx) .LcnU: movl $Main_func_closure,%ebx jmp *-8(%r13) sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx) snj_info: cmpq $1,7(%rbx) jne .LcnE movl $Main_lvl_closure+1,%ebx addq $8,%rbp jmp *(%rbp) .LcnE: movl $Main_lvl1_closure+1,%ebx addq $8,%rbp jmp *(%rbp) It seems to me that the !Int member of the Data constructor is being treated like it might be a thunk in sni_info (i.e., the whole "testq $7,%rbx" thing). Isn't this unnecessary as the "!" strictness flag means the Int argument must be forced by the Data constructor before being captured? Thanks! -Tyson

8 14

base-3 vs base-4 (Was: Breakage with 6.10)
by Niklas Broberg 19 Oct '08

19 Oct '08

> > 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? > > By having it use base-3 rather than 4. Right, and that's how I quickly fixed it up for now. But this doesn't sound like a long-term solution to me, I would prefer to use the new base-4 when possible. The cabal file already includes a conditional "if flag(splitBase)" to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such? Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?) Cheers, /Niklas

6 10

ANNOUNCE: GHC 6.10.1 beta
by Ian Lynagh 17 Oct '08

17 Oct '08

We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a beta release of GHC 6.10.1. You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extrali… Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows, and a binary distribution for x86_64/Linux. More may appear later. There are a couple of known problems with the x86_64/Linux bindist: * It uses libedit.so.0 whereas some distributions (e.g. Debian) only provide libedit.so.2. * It installs utilities like unlit in the wrong place, so compiling literate code won't work. If you install from source then you won't hit either of those problems. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to have release candidates followed by a release in around 3 weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

10 31

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