Re: package ghc depends on Cabal-1.5.5, which fails to load(ghchead, windows)

On Sat, 2008-12-06 at 11:50 +, Claus Reinke wrote: > >> > The way the solver works is that it does not commit to using the > >> > installed version until the last possible minute. It does this because > >> > the installed versions have much tighter constraints on dependencies. It > >> > does a

Re: HEADS UP: patches, package versions, and cabal-install

On Mon, 2008-12-08 at 18:06 +, Ian Lynagh wrote: > hunk ./array.cabal 18 > - if !impl(nhc98) > -build-depends: syb > > I don't know if the package dep removal could have contributed to > cabal-install reinstalling array, That's exactly it. > but I suspect it's more likely that the prob

Re: HEADS UP: patches, package versions, and cabal-install

On Mon, 2008-12-08 at 12:38 +, Simon Marlow wrote: > Claus Reinke wrote: > > If packages are patched without any change in version number, > > bad things can happen if one tries to cabal install additional packages > > onto such a patched ghc. > > > > At the moment, that seems to be the case f

Re: Panic when building head with profiling

Ok, rebuilding from scratch doesn't help. The message is almost the same, though the file may be obscured due to make -j3. With just make the actual failure is (unsurprisingly) in dist-stage2/build/BinIface.p_hi. Apparently there's a do_expr case missing for StgLam in stgMassageForProfiling, but

Re: Panic when building head with profiling

That seems to have fixed one problem, but I now get: <> /Users/nominolo/code/ghc/ng-api/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081205 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -ic

Re: HEADS UP: patches, package versions, and cabal-install

On Mon, Dec 08, 2008 at 04:28:31PM -, Claus Reinke wrote: > >>Could the array/containers version bumps be done soon, please, > > > >As far as I can see there are no code changes in the array package. I > >guess what we're really trying to do is work around cabal-install > >replacing libraries w

RE: Panic when building head with profiling

| | I guess it's quite possible that this is caused by one of Simon's | patches from Friday. Darn, you are almost certainly right. It's hard for me to build a profiled GHC right now on my laptop. But can you try adding these two lines to CoreUtils.eta_expand? Add the two lines highlighted with

patch applied (ghc): Inject implicit bindings after CoreTidy, not before Simplify

Mon Dec 8 09:35:25 PST 2008 [EMAIL PROTECTED] * Inject implicit bindings after CoreTidy, not before Simplify Originally I inject the "implicit bindings" (record selectors, class method selectors, data con wrappers...) after CoreTidy. However, in a misguided attempt to fix Trac #2070,

patch applied (ghc): Add assertion for arity match (checks Trac #2844)

Mon Dec 8 09:32:41 PST 2008 [EMAIL PROTECTED] * Add assertion for arity match (checks Trac #2844) The exported arity of a function must match the arity for the STG function. Trac #2844 was a pretty obscure manifestation of the failure of this invariant. This patch doesn't cure the bug

patch applied (ghc): Use CoreSubst.simpleOptExpr in place of the ad-hoc simpleSubst (reduces code too)

Mon Dec 8 09:30:18 PST 2008 [EMAIL PROTECTED] * Use CoreSubst.simpleOptExpr in place of the ad-hoc simpleSubst (reduces code too) M ./compiler/deSugar/DsBinds.lhs -50 +16 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20081208173018-1287e-4ed0a982ba1c0c0134dcf0a4bc168bcc8

patch applied (ghc): Move simpleOptExpr from CoreUnfold to CoreSubst

Mon Dec 8 04:48:40 PST 2008 [EMAIL PROTECTED] * Move simpleOptExpr from CoreUnfold to CoreSubst M ./compiler/coreSyn/CoreSubst.lhs -1 +87 M ./compiler/coreSyn/CoreUnfold.lhs -72 +1 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20081208124840-1287e-9c1fc5f6646bf52df10b

patch applied (ghc): White space only

Mon Dec 8 04:43:10 PST 2008 [EMAIL PROTECTED] * White space only M ./compiler/simplCore/Simplify.lhs -2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20081208124310-1287e-876f4ea93fbc100bbabff9990c89edb0554331f5.gz ___ Cvs-ghc

patch applied (ghc): Comments only

Mon Dec 8 04:41:55 PST 2008 [EMAIL PROTECTED] * Comments only M ./compiler/rename/RnEnv.lhs -1 +2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20081208124155-1287e-931e79e6948563b3f09855a37ea16aa07e686b2f.gz ___ Cvs-ghc mailin

Re: HEADS UP: patches, package versions, and cabal-install

Could the array/containers version bumps be done soon, please, As far as I can see there are no code changes in the array package. I guess what we're really trying to do is work around cabal-install replacing libraries with ABI-incompatible builds? array had dependency/import changes since the

Re: HEADS UP: patches, package versions, and cabal-install

Hi > You make it sound like "ghc gives you your linker error in raw form" is a > deliberate feature we implemented just to make your life more difficult! No, > obviously it's just the easiest thing to do, and we haven't implemented > anything more elaborate. I think most link errors are because t

Re: HEADS UP: patches, package versions, and cabal-install

On Mon, Dec 08, 2008 at 03:17:15PM -, Claus Reinke wrote: > > Could the array/containers version bumps be done soon, please, As far as I can see there are no code changes in the array package. I guess what we're really trying to do is work around cabal-install replacing libraries with ABI-inc

Re: HEADS UP: patches, package versions, and cabal-install

Claus Reinke wrote: All this "cabal install trying to be clever while packages lie about their versions" trouble, combined with "ghc gives you your linker error in raw form, completely untainted by high-level Haskell/Cabal concepts" makes me wonder what else is about to go wrong when lots of p

Re: Daily report for stable

On Mon, Dec 08, 2008 at 12:31:40PM +, Simon Marlow wrote: > > I think the tables in the HTML output are missing the elements - I > don't see any line breaks in Thunderbird, and viewing the HTML in firefox > shows the same thing. Yup; I fixed it yesterday, but forgot to recompile/reinstall.

Re: HEADS UP: patches, package versions, and cabal-install

If packages are patched without any change in version number, bad things can happen if one tries to cabal install additional packages onto such a patched ghc. At the moment, that seems to be the case for array and containers, which were adjusted following the syb split, without changes in version

Re: HEADS UP: patches, package versions, and cabal-install

Claus Reinke wrote: If packages are patched without any change in version number, bad things can happen if one tries to cabal install additional packages onto such a patched ghc. At the moment, that seems to be the case for array and containers, which were adjusted following the syb split, witho

Re: Daily report for stable

BuildBot Collator wrote: Build results: gabor stable:fail (failed darcs) kili stable:fail (failed stage2 runtestsuite) tnaur x86 OS X stable:pass

Daily report for head

Build results: x86-64 Linux head: fail (failed darcs) x86 Windows head: fail (failed stage2 bindist bindisttest runtestsuite) x86 Windows head fast: pass pass pass pass pass fail (failed stage2) tnaur PPC OSX head 2: pass tnaur x86 Linux head: pass x86-64 Linux head unreg:fail (f

Daily report for stable

Build results: gabor stable: fail (failed darcs) kili stable:fail (failed stage2 runtestsuite) tnaur x86 OS X stable: pass x86 Linux stable: pass x86 Windows stable: pass fail (failed stage1) x86 Windows stable fast:pass pass pass pass pass pass x86-64 Linux stab