[nightly] 31-Dec-2009 build of HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com)

Build description = HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Thu Dec 31 19:00:01 GMT 2009. **

Re: rpath for shared libraries

On Fri, Jan 01, 2010 at 01:38:58AM +0100, Lars Viklund wrote: > On Wed, Dec 30, 2009 at 06:29:23PM +, Andrew Suffield wrote: > > I've been thinking about this. The only reason why rpath is needed is > > because the .so files are being stuck in lib/ghc-$version/ instead of > > going into lib/ di

Re: rpath for shared libraries

On Wed, Dec 30, 2009 at 06:29:23PM +, Andrew Suffield wrote: > On Wed, Dec 30, 2009 at 02:20:41PM +, Duncan Coutts wrote: > > On Wed, 2009-12-30 at 12:09 +0100, Maxime Henrion wrote: > > > > > - Is there a plan to deal with the ldconfig cache on UNIX systems? As > > > things are now, I had

patch applied (ghc): Rolling back: Make FastString thread-safe.

Thu Dec 31 08:46:51 PST 2009 Simon Marlow * Rolling back: Make FastString thread-safe. Ignore-this: 8f21b256b0c86d167f8f6984d2b27a87 This patch was the cause of the compile-time performance regression in #3796. My guess is that it is due to the use of unsafePerformIO which trave

patch applied (ghc): take newCAF() out from sm_mutex; use the capability-local mut list instead

Thu Dec 31 08:02:23 PST 2009 Simon Marlow * take newCAF() out from sm_mutex; use the capability-local mut list instead Ignore-this: 81a9a0a1e279dea805a4ffd9cf124c90 M ./compiler/codeGen/CgClosure.lhs -1 +4 M ./includes/rts/storage/GC.h -2 +2 M ./rts/sm/Storage.c -17 +17 View pat

patch applied (ghc): Use local mut lists in UPD_IND(), also clean up Updates.h

Thu Dec 31 03:34:35 PST 2009 Simon Marlow * Use local mut lists in UPD_IND(), also clean up Updates.h Ignore-this: a4659d4d24f8c6626fa8403314c6a2e4 M ./rts/Interpreter.c -1 +1 M ./rts/RaiseAsync.c -1 +1 M ./rts/Schedule.c -1 +2 M ./rts/ThreadPaused.c -3 +3 M ./rts/Updates

patch applied (ghc): use local mut lists rather than global mut lists in sequential GC

Thu Dec 31 03:31:18 PST 2009 Simon Marlow * use local mut lists rather than global mut lists in sequential GC Ignore-this: 782239ddca2a0ec5c928c310b1fad4e9 M ./rts/sm/Scav.c -1 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20091231113118-12142-7e5f96bd1ad37c0b1e9cdd

patch applied (ghc): Allow throwTo() to be called without a source thread

Fri Dec 18 08:32:00 PST 2009 Simon Marlow * Allow throwTo() to be called without a source thread Ignore-this: cb7265bc6c1c75f0dd49501c1bb74f64 Returns false if the exception could not be thrown becuase the tartget thread was running. Not used yet, but might come in handy later. M ./

patch applied (ghc): If ACTIVITY_INACTIVE is set, wait for GC before resetting it

Sun Dec 13 12:12:46 PST 2009 Simon Marlow * If ACTIVITY_INACTIVE is set, wait for GC before resetting it Ignore-this: a3cd1a3aacbd68789ccc191e3b8d7778 I don't think this fixes any real bugs, but there's a small possibility that when the RTS is woken up for an idle-time GC, the IO manage

Re: Validate fails on Mac OS X, again!

On Tue, Dec 22, 2009 at 09:08:54PM +0100, Matthias Kilian wrote: > On Tue, Dec 22, 2009 at 06:26:16AM +, Duncan Coutts wrote: > > > GNUisms, it's not Linux' fault, although I neither like Linux do I > > > know any Linux distribution not using the GNU tools. > > > > I don't think this was a GNU

Re: Validate failure

On Thu, Dec 31, 2009 at 02:34:33PM +, Ian Lynagh wrote: > * Why does HSdph-prim-par-0.4.0-ghc6.13.20091222 have filename > libHSdph-prim-seq-0.4.0-ghc6.13.20091222.so > (note par vs seq) Probably because -par-*.so is linked against -seq-*.so; the error message is from dlopen(), which

Re: Validate failure

On Thu, Dec 31, 2009 at 01:54:46PM +, Simon Marlow wrote: > The following validate failure has happened to me twice, and appears to > be a parallel make problem (a missing dependency somewhere). I'm using > -j3 on a dual-core. I'm posting it here in case anyone else has a clue > what's g

DPH libs are re-haddocked every time

If you have HADDOCK_DOCS enabled, then every 'make' will re-haddock the DPH libraries, which is rather annoying. I've done some investigation, here's what I've discovered: * When we run Haddock on DPH, Haddock must actually compile to object code, because they involve TH (actually annotatio

Validate failure

The following validate failure has happened to me twice, and appears to be a parallel make problem (a missing dependency somewhere). I'm using -j3 on a dual-core. I'm posting it here in case anyone else has a clue what's going on, otherwise I'll queue it for investigation. Cheers, Sim

Daily report for head

Build results: x86-64 Linux head: pass x86 Windows head fast: pass pass tnaur PPC OSX head 2:fail (failed compile) x86-64 Linux head unreg: pass Old unexpected test passes: 2410 2 x86-64 Linux head TH_spliceE5_prof 2 x86-64 Linux head newtype 2 x86-64

Daily report for stable

Build results: x86 Windows stable fast: pass pass x86-64 Linux stable: pass Old unexpected test passes: 2410 2 x86 Windows stable TH_spliceE5_prof 2 x86 Windows stable length0011 tnaur x86 OS X stable newtype 2 x86 Windows stable prof001