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

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 Aug 18 18:02:05 BST 2008. checking out

patch applied (testsuite): add Makefile for haskell98 test

Mon Aug 18 09:29:47 PDT 2008 Ross Paterson <[EMAIL PROTECTED]> * add Makefile for haskell98 test A ./tests/ghc-regress/lib/haskell98/Makefile View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20080818162947-b47d3-c66543c3497df0d369ee811030e9aec54dd2d254.gz _

Re: darcs and ghc..

Simon Marlow wrote: Claus Reinke wrote: |Do you get this using darcs 2? We would appreciate a bug report! Well, okay, I'd like to switch to darcs 2 (forgot that Simon had already convinced me earlier..). But according to darcs.net: - the latest stable release is 2.0.2 - the latest win

RE: HEADS UP: big codegen patch

Hi Don, We have a couple of Wiki pages that outline the plan with the new code generator. The first page gives the short-term view: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGenPipeline and the following page gives the longer-term plans: http://hackage.haskell.org/trac/g

patch applied (testsuite): add test for #2330

Mon Aug 18 04:23:58 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * add test for #2330 M ./tests/ghc-regress/cabal/Makefile +11 M ./tests/ghc-regress/cabal/all.T +5 A ./tests/ghc-regress/cabal/ghcpkg06.stderr A ./tests/ghc-regress/cabal/ghcpkg06.stdout A ./tests/ghc-regress/caba

Re: haddock 2 and GHC

In fact it'll come with the Haskell Platform, and that's feasible because I don't think we're planning to make relocatable binary distributions of the HP. Not having relocatable binary distributions would be sad indeed, especially as a regression from what we used to have. Being able to use gh

patch applied (ghc): use System.FilePath's isSearchPathSeparator instead of our own

Mon Aug 18 04:35:55 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * use System.FilePath's isSearchPathSeparator instead of our own M ./compiler/utils/Util.lhs -12 +2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080818113555-12142-6b09c8447b2987023ed656449ff8a5bc116c879e.gz

patch applied (ghc): FIX #2521: trailing colon in GHC_PACKAGE_PATH

Mon Aug 18 04:33:45 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * FIX #2521: trailing colon in GHC_PACKAGE_PATH This was broken in the System.FilePath switchover, since filepath's splitSearchPath doesn't do what we want (it ignores empty components on Windows, and treats them as "." on Unix)

patch applied (ghc): Test for and reject duplicate dependencies (#2330)

Mon Aug 18 04:24:34 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * Test for and reject duplicate dependencies (#2330) M ./utils/ghc-pkg/Main.hs -7 +10 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080818112434-12142-03e21d480362ec9c38a2c106e55793bf1e7c3af2.gz _

Re: patch applied (testsuite): add test for leakage of Control.Monad.Instances into Haskell 98 modules

Ross Paterson wrote: Sat Aug 16 18:10:10 PDT 2008 Ross Paterson <[EMAIL PROTECTED]> * add test for leakage of Control.Monad.Instances into Haskell 98 modules A ./tests/ghc-regress/lib/haskell98/ A ./tests/ghc-regress/lib/haskell98/all.T A ./tests/ghc-regress/lib/haskell98/instance

Re: haddock 2 and GHC

Claus Reinke wrote: In fact it'll come with the Haskell Platform, and that's feasible because I don't think we're planning to make relocatable binary distributions of the HP. Not having relocatable binary distributions would be sad indeed, especially as a regression from what we used to have.

Re: haddock 2 and GHC

> As I've said before regarding (2), it's feasible to make the .hi > format stable across minor releases of GHC, but not major releases. Here is an idea that might help solve some of the "need exact version of ghc to build haddock" style of problem. Why not develop a _small_ stand-alone tool th

Re: haddock 2 and GHC

In fact it'll come with the Haskell Platform, and that's feasible because I don't think we're planning to make relocatable binary distributions of the HP. Not having relocatable binary distributions would be sad indeed, especially as a regression from what we used to have. Being able to use gh

Re: patch applied (testsuite): Skip num009 if fast, as it gives the wrong answer on some platforms

Max Bolingbroke wrote: 2008/8/18 Simon Marlow <[EMAIL PROTECTED]>: Ian Lynagh wrote: Sat Aug 16 12:02:22 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Skip num009 if fast, as it gives the wrong answer on some platforms Do we know why? No, but it appears to be an OS X specific bug. The associat

Re: patch applied (ghc): When doing :l, abandon all breakpoints before we unload everything

On Mon, Aug 18, 2008 at 09:19:36AM +0100, Simon Marlow wrote: > Ian Lynagh wrote: > >Sat Aug 16 08:21:35 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> > > * When doing :l, abandon all breakpoints before we unload everything > > I'm not 100% sure if this is the right fix, but it seems sensible and > >

Re: patch applied (testsuite): Skip num009 if fast, as it gives the wrong answer on some platforms

2008/8/18 Simon Marlow <[EMAIL PROTECTED]>: > Ian Lynagh wrote: >> >> Sat Aug 16 12:02:22 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> >> * Skip num009 if fast, as it gives the wrong answer on some platforms > > Do we know why? No, but it appears to be an OS X specific bug. The associated ticket is h

Re: haddock 2 and GHC

Claus Reinke wrote: Instead of working around them in each individual case, I'd really like to see general solutions to the two issues of 1 updating ghc-paths and notifying existing clients 2 making (some) ghc api clients less dependent on a single ghcversion Most suggestions about this h

Re: haddock 2 and GHC

Manuel M T Chakravarty wrote: I think the only sane choice is to install haddock with ghc. Some people may have multiple GHCs installed, some system-wide and some in their home directory. I think it is generally impossible to guess for an installer which version of which ghc to use. Sane bu

Re: patch applied (testsuite): Skip num009 if fast, as it gives the wrong answer on some platforms

Ian Lynagh wrote: Sat Aug 16 12:02:22 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Skip num009 if fast, as it gives the wrong answer on some platforms Do we know why? Cheers, Simon ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.hask

Re: [darcs-users] darcs and ghc..

Claus Reinke wrote: |Do you get this using darcs 2? We would appreciate a bug report! Well, okay, I'd like to switch to darcs 2 (forgot that Simon had already convinced me earlier..). But according to darcs.net: - the latest stable release is 2.0.2 - the latest windows binary bundles a

Re: patch applied (ghc): When doing :l, abandon all breakpoints before we unload everything

Ian Lynagh wrote: Sat Aug 16 08:21:35 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * When doing :l, abandon all breakpoints before we unload everything I'm not 100% sure if this is the right fix, but it seems sensible and stops break008 segfaulting for me on amd64/Linux. M ./compiler/ghci/

Re: Unboxed singleton tuples

Tim Chevalier wrote: On 8/14/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: IIUC, the practical difference is this. If you have f :: Int -> (# Int #) then case f m of (# n #) -> bar n will call f before calling bar but will not evaluate n. I fear I'm still not enlightened. I see

Daily report for head

Build results: x86-64 Linux head: lost x86 Windows head:fail (failed bindist bindisttest nofib.boot.0 nofib.boot.0_2 nofib.boot.0_3 nofib.boot.0_4 nofib.boot.0_5) x86 Windows head fast: pass lost pass pass fail (failed stage1) pass tnaur PPC OSX head 2:lost tnaur x86 Linux head

Daily report for stable

Build results: fast486 stable: fail (failed darcs) kgardas stable: fail (failed stage1) malcolm stable: fail (failed darcs) mnemosyne x86-64 Gentoo stable: pass x86 Windows stable: fail (failed stage1) x86 Windows stable fast:pass