patch applied (testsuite): Accept -fmethod-sharing

2008-05-19 Thread Roman Leshchinskiy
Mon May 19 22:33:26 PDT 2008 Roman Leshchinskiy <[EMAIL PROTECTED]> * Accept -fmethod-sharing M ./tests/ghc-regress/ghci/scripts/ghci024.py +1 View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20080520053326-b2b0a-21f6b5b3a5f5b6f69ba45d47247cffe45b648619.gz

patch applied (ghc): Add -Odph

2008-05-19 Thread Roman Leshchinskiy
Mon May 19 20:19:13 PDT 2008 Roman Leshchinskiy <[EMAIL PROTECTED]> * Add -Odph This is the optimisation level recommended when compiling DPH programs. At the moment, it is equivalent to -O2 -fno-method-sharing -fdicts-cheap -fmax-simplifier-iterations20 -fno-spec-constr-threshold.

patch applied (ghc): Make -f[no-]method-sharing a dynamic flag

2008-05-19 Thread Roman Leshchinskiy
Mon May 19 19:59:56 PDT 2008 Roman Leshchinskiy <[EMAIL PROTECTED]> * Make -f[no-]method-sharing a dynamic flag We want -Odph to be a dynamic flag and that should imply -fno-method-sharing. This doesn't add a lot of complexity. M ./compiler/main/DynFlags.hs +4 M ./compiler/main/S

Validate fails

2008-05-19 Thread Roman Leshchinskiy
I get the following two failures: Unexpected failures: ghci024(ghci) num009(normal) Recently, I tend to get unexpected failures every time I pull in patches. What happened to the policy of running validate before pushing? I thought we agreed that was a good idea? In any case, I have n

patch applied (ghc): documentation for ZipDataflow

2008-05-19 Thread nr
Mon May 19 20:24:54 PDT 2008 Norman Ramsey <[EMAIL PROTECTED]> * documentation for ZipDataflow M ./compiler/cmm/ZipDataflow.hs -53 +237 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080520032454-39dff-472ad292ee0e176c1ca379c13e774774130b9457.gz _

[nightly] 19-May-2008 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

2008-05-19 Thread GHC Build Reports
Build description = HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/simonmar/nightly/HEAD Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Mon May 19 18:00:01 BST 2008. checking out

[nightly] 19-May-2008 build of STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

2008-05-19 Thread GHC Build Reports
Build description = STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/simonmar/nightly/STABLE Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx Nightly build started on cam-02-unx at Mon May 19 18:10:01 BST 2008. checki

RE: patch applied (ghc): Improve the treatment of 'seq' (Trac #2273)

2008-05-19 Thread Simon Peyton-Jones
| So would you say this affects our standard idiom for strictifying things. | The | | let !x = e in ... x ... | | form should be used now, for robustness reasons. Yes, this is better than let x = e in x `seq` ...x... precisely because the former is invulnerable to valid but leak-indu

Daily report for stable

2008-05-19 Thread BuildBot Collator
Build results: kahl G5 Gentoo Linux stable: fail (failed darcs) macgyver PPC OSX stable: pass x86 Windows stable: fail (failed bindisttest) x86 Windows stable fast: pass pass lost pass pass pass x86-64 Linux stable: pass Old unexpected test passes: cg057 1 x86-64 Li

Daily report for head

2008-05-19 Thread BuildBot Collator
Build results: x86-64 Linux head: fail (failed stage1) x86 Windows head: fail (failed bindisttest) x86 Windows head fast: pass pass pass kahl G5 Gentoo Linux head: pass tnaur PPC OSX head 2: fail (failed darcs) x86-64 Linux head unreg: pass Old unexpected test passes: