Re: New codegen failing test-cases
On 06/12/2010, at 1:19 PM, David Terei wrote: > I haven't looked at these branches for a fair few weeks, the problem > when they fail to build usually is because all the libraries are just > set to follow HEAD, they're not actually branched themselves, just the > ghc compiler. So there are probably some patches from ghc HEAD that > need to be pulled in to sync the compiler with the libs again. If you > want to do some work on the new codegen the first step is to try to > pull in all the patches from ghc HEAD, synchronise the branch. Its not > a fun job but GHC HQ wants to try to merge in all the new codegen > stuff to HEAD asap. >> >> libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs:1:14: >>Unsupported extension: ParallelArrays >> make[1]: *** [libraries/dph/dph-par/dist-install/build/.depend-v.haskell] >> Error 1 >> make: *** [all] Error 2 >> >> I can debug this further if you want me to. We renamed the -XPArr language flag to -XParallelArrays. There was a patch to ghc-head that you'll have to pull or port across. We're still actively working on DPH, and changes to the compiler often entail changes to the libraries. If you haven't branched the libraries then your build is going to break on a weekly basis. Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
I haven't looked at these branches for a fair few weeks, the problem when they fail to build usually is because all the libraries are just set to follow HEAD, they're not actually branched themselves, just the ghc compiler. So there are probably some patches from ghc HEAD that need to be pulled in to sync the compiler with the libs again. If you want to do some work on the new codegen the first step is to try to pull in all the patches from ghc HEAD, synchronise the branch. Its not a fun job but GHC HQ wants to try to merge in all the new codegen stuff to HEAD asap. On 4 December 2010 23:45, Edward Z. Yang wrote: > Excerpts from David Terei's message of Fri Dec 03 23:44:33 -0500 2010: >> http://darcs.haskell.org/ghc-cmm-03Sep10/ > > This branch fails to build for me: > > "inplace/bin/ghc-stage1" -M -dep-makefile > libraries/dph/dph-par/dist-install/build/.depend-v.haskell.tmp > -include-pkg-deps -H64m -O -fasm -package-name dph-par-0.5 -hide-all-packages > -i -ilibraries/dph/dph-par/../dph-common > -ilibraries/dph/dph-par/dist-install/build > -ilibraries/dph/dph-par/dist-install/build/autogen > -Ilibraries/dph/dph-par/dist-install/build > -Ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/. > -optP-include > -optPlibraries/dph/dph-par/dist-install/build/autogen/cabal_macros.h -package > array-0.3.0.2 -package base-4.3.0.0 -package dph-base-0.5 -package > dph-prim-par-0.5 -package ghc-7.1.20101126 -package ghc-prim-0.2.0.0 -package > random-1.0.0.3 -package template-haskell-2.5.0.0 -Odph -funbox-strict-fields > -fcpr-off -fdph-this -package-name dph-par -XTypeFamilies -XGADTs > -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators > -no-user-package-conf -rtsopts -O -dcore-lint -odir > libraries/dph/dph-par/dist-install/build -hidir > libraries/dph/dph-par/dist-install/build -stubdir > libraries/dph/dph-par/dist-install/build -hisuf hi -osuf o -hcsuf hc > libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Int.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Word8.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Float.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Double.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/PArray.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/PArray.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Unboxed.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Scalar.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/TH/Repr.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Repr.hs l! > ibraries > /dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Closure.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Instances.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Combinators.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Int.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Word8.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Float.hs > > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Double.hs > > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Bool.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/PArr.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Tuple.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base.hs > libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Bool.hs > > libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs:1:14: > Unsupported extension: ParallelArrays > make[1]: *** [libraries/dph/dph-par/dist-install/build/.depend-v.haskell] > Error 1 > make: *** [all] Error 2 > > I can debug this further if you want me to. > > Edward > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to develop on a (GHC) branch with darcs
Hello, I am doing some work on a GHC branch and I am having a lot of troubles (and spending a lot of time) trying to keep my branch up to date with HEAD, so I would be very grateful for any suggestions by fellow developers of how I might improve the process. Here is what I have tried so far: First Attempt ~ My branch, called 'ghc-tn', was an ordinary darcs repo. I recorded my changes as needed, and every now and then would pull from the HEAD repo. If conflicts occurred, I would resolve them and record a patch. Very quickly I run into what, apparently, is a well-known darcs problem where trying to pull from HEAD would not terminate in a reasonable amount of time. Second Attempt ~~ Avoid "conflict patches" by constantly changing my patches. This is how I've been doing this: Initial state: ghc: a repository with an up-to-date version of GHC head ghc-tn: my feature repo based on a slightly out-of-date GHC HEAD. Goal: Merge ghc-tn with ghc (i.e., integrate developments in GHC HEAD into my branch) Process: 1. Create a temporary repository for the merge: darcs clone --lazy ghc ghc-tn-merge 2. Create a backup of the feature branch (strictly speaking not necessary but past experience shows that it is a good idea to have one of those). darcs clone --lazy ghc-tn ghc-tn-backup 3. Pull features patches from 'ghc-tn' into 'ghc-tn-merge', one at a time. darcs pull ghc-tn y d 3.1. If a feature patch causes a conflict, then resolve the conflict and create a new patch, obliterating the old one: darcs amend-record (creates a new patch, not a conflict patch, I think) After repeating this for all branch patches, I have an updated branch in 'ghc-tn-merge' with two caveats: 1. The new repository does not contain my previous build so I have to re-build the entire GHC and libraries from scratch. This is a problem because GHC is a large project and rebuilding everything takes a while, even on a pretty fast machine. I work around this problem like this: 1.1 Obliterate all branch patches from 'ghc-tn'. This, essentially, rewinds the repository to the last point when I synchronised with HEAD. To do this properly I need to know which patches belong to my branch, and which ones are from GHC. (I've been a bit sloppy about this--- I just use the e-mails of the branch developers to identify these and then look at the patches. A better way would be to have some kind of naming convention which marks all branch patches). 1.2 Pull from 'ghc-tn-merge' into 'ghc-tn'. By construction we know that this will succeed and reintroduce the feature changes, together with any new updates to GHC into 'ghc-tn'. Now 'ghc-tn-merge' and 'ghc-tn-backup' can be deleted. 2. The new repository contains rewritten versions of the branch patches so---if I understand correctly---it is not compatible with the old one (i.e., I cannot just push from my newly updated branch to the public repo for my branch as there will be confusion between the old feature patches and the new ones). I can think of only one solution to this problem, and it is not great: 2.1 Delete the original public repo, and publish the new updated repo, preferably with a new name. In this way, other developers who have the old patches can either just clone the new repo, or go through steps 1.1--1.2 but will not accidentally get in a confused state by mixing up the new feature patches with the old ones. For background, my solution is essentially a manual implementation of what is done by git's "rebase" command---except that there "branch patches" and various "repository states" are automatically managed by the system so there is no need to follow various naming conventions which tend to be error prone. Apologies for the longish e-mail but this seems like an important problem and I am hoping that there's a better way to do things. -Iavor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
