'ghc-options: -Werror' makes the package easy to break with future GHC versions
because new GHC versions often add new warnings.
"rm" -f libraries/dph/dph-par/dist-install/build/libHSdph-par-0.5.1.1.a
libraries/dph/dph-par/dist-install/build/libHSdph-par-0.5.1.1.a.contents
"/usr/bin/ld" -r -o
li
On Mon, Dec 14, 2009 at 09:56:20AM +, Simon Marlow wrote:
>
> On a related note, I timed the generation of the RTS .depend file, and
> it now takes 30s where it used to take 3s. This is mainly because we
> are now preprocessing each C file once per way, rather than just once.
> The new w
On Sat, Dec 12, 2009 at 07:19:17PM +1100, Manuel M T Chakravarty wrote:
> I think this is since the new c_asm.bit dependency stuff was introduced. The
> problem only seems to happen in a very parallel build, and my guess is that
> this happens on any box that doesn't have gmp.h globally installe
On 12/12/2009 08:19, Manuel M T Chakravarty wrote:
I think this is since the new c_asm.bit dependency stuff was introduced. The
problem only seems to happen in a very parallel build, and my guess is that
this happens on any box that doesn't have gmp.h globally installed.
I ran into it when us
BTW, windows buildbots fall over in the same way:
http://darcs.haskell.org/buildbot/all/builders/x86%20Windows%20head%20fast/builds/4977/steps/compile/logs/stdio
And it also happens with just one make thread, although it seems to succeed
sometime, I see more failure than successful builds.
Manu
Actually, it sometimes also happens with 4 cores (and maybe less?) and I also
sometimes get
> config.status: executing src commands
> # libffi.so needs to be built with the correct soname.
> # NOTE: this builds libffi_convience.so with the incorrect
> # soname, but we don't need that anyway!
> cd
I think this is since the new c_asm.bit dependency stuff was introduced. The
problem only seems to happen in a very parallel build, and my guess is that
this happens on any box that doesn't have gmp.h globally installed.
I ran into it when using 8 cores (with 'env CPUS=8 sh validate'):
> /usr/
On Tue, Oct 06, 2009 at 10:08:37AM +0100, Simon Marlow wrote:
> Apparently everyone's iconv is different. You'd think that "UTF32LE"
> would be a universal encoding name, but no.
Quoting the holy (and, in this case, not very helpful) open group
standard:
Settings of fromcode and tocode
On 06/10/2009 05:35, Manuel M T Chakravarty wrote:
"inplace/bin/ghc-stage2" -H32m -O -Wall -Werror -H64m -O0 -fasm
-DNEW_GHC_LAYOUT -hide-all-packages -i -iutils/haddock/src
-iutils/haddock/dist/build -iutils/haddock/dist/build/autogen
-Iutils/haddock/dist/build -Iutils/haddock/dist/build/autoge
"inplace/bin/ghc-stage2" -H32m -O -Wall -Werror -H64m -O0 -fasm -
DNEW_GHC_LAYOUT -hide-all-packages -i -iutils/haddock/src -iutils/
haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/
dist/build -Iutils/haddock/dist/build/autogen-optP-DIN_GHC_TREE -
optP-include -opt
Manuel M T Chakravarty wrote:
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-I../includes -optc-I. -optc-Iparallel -optc-Ism
-optc-DCOMPILING_RTS -optc-fomit-fram
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-Wstrict-
prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-
Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-
Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -
optc-I../gmp/gmp
oops. fixed.
-- Don
keller:
> validate breaks on the latest head with the following warning:
>
>
> ../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-Wstrict-
> prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-
> Winline -optc-Waggreg
validate breaks on the latest head with the following warning:
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-Wstrict-
prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-
Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-
Iparallel -optc-Ism
Claus Reinke wrote:
ThreadDelay is a perfectly reasonable test: it tests that threadDelay
doesn't wait for *less* time than was requested. Clearly something is
wrong on your machine with either threadDelay or the way time is
measured, but we haven't seen the same symptoms elsewhere so it's har
ThreadDelay is a perfectly reasonable test: it tests that threadDelay
doesn't wait for *less* time than was requested. Clearly something is
wrong on your machine with either threadDelay or the way time is measured,
but we haven't seen the same symptoms elsewhere so it's hard to diagnose.
Still
On 14/11/2007, at 20:43, Claus Reinke wrote:
Claus, is this expected to work with 6.8 ?
There is no ':show languages' option there, so the test fails.
i should have said STABLE branch, i guess.
The test passes in STABLE branch. I'll be pushing asap.
but this raises a question for those
Claus Reinke wrote:
btw, i've never seen a clean validate run on my system (win/xp), as
ThreadDelay001(normal) fails consistently.
Can you fix that or anybody else who uses that platform? (I am
making an effort to hunt down all Mac OS X breakages that I find.
For every platform, we need
ghci now has the ability to show dynamic flag settings
and language flags, and that is the test for it. as far as
i know, we've accounted for all platform issues, but as
there wasn't any other test of all flags before, only this one will
show up in validate runs after flag changes.
Ok, but tha
Claus, is this expected to work with 6.8 ?
There is no ':show languages' option there, so the test fails.
i should have said STABLE branch, i guess.
but this raises a question for those tests referring to
features and fixes that have been merged into STABLE
after release: should those tests b
Claus, is this expected to work with 6.8 ?
There is no ':show languages' option there, so the test fails.
It passes fine with HEAD here.
pepe
On 14/11/2007, at 14:48, Claus Reinke wrote:
I'm testing the fix now. Claus, I'm not very fluent with Python,
care if I send you the patch to ghci02
Oops, sorry everybody, I had some patches lying around from the
Hackathon which I had validated already back then. I naively assumed
they would still pass validation.
I'm testing the fix now. Claus, I'm not very fluent with Python, care
if I send you the patch to ghci024.py for revision?
| Unexpected failures:
| ghci024(ghci)
|
| This is probably related to the new debugger-related patches from
| yesterday. It'd be good to keep validate *break free* (or is this an
| OS issue)?
Yes, the protocol is: validate then commit. It's very easy to commit the test
patches but not the
Claus Reinke:
Validating the HEAD today on Mac OS X gives me
Unexpected failures:
ghci024(ghci)
This is probably related to the new debugger-related patches from
yesterday. It'd be good to keep validate *break free* (or is this
an OS issue)?
ghci now has the ability to show dynamic fla
Validating the HEAD today on Mac OS X gives me
Unexpected failures:
ghci024(ghci)
This is probably related to the new debugger-related patches from
yesterday. It'd be good to keep validate *break free* (or is this an
OS issue)?
ghci now has the ability to show dynamic flag settings
and
Validating the HEAD today on Mac OS X gives me
Unexpected failures:
ghci024(ghci)
This is probably related to the new debugger-related patches from
yesterday. It'd be good to keep validate *break free* (or is this an
OS issue)?
Manuel (aka "The Validator")
26 matches
Mail list logo
