[nightly] 11-May-2007 build of of HEAD on i386-unknown-mingw32 (bling)

From: GHC Build Reports <[EMAIL PROTECTED]> To: cvs-ghc@haskell.org Subject: [nightly] 11-May-2007 build of of HEAD on i386-unknown-mingw32 (bling) Build description = of HEAD on i386-unknown-mingw32 (bling) Build location= /fptools/builds/HEAD Build config file = /fptools/builds/ghc-nightly/

patch applied (/haskell/ghc): Windows 6.6.1 updates

Fri May 11 20:24:09 EDT 2007 Ian Lynagh <[EMAIL PROTECTED]> * Windows 6.6.1 updates M ./download_ghc_661.html -8 +16 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

[nightly] 11-May-2007 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/ghc/nightly/HEAD-cam-02-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Fri May 11 19:30:01 BST 2007. checki

patch applied (ghc): Correct an egregious typo in LiberateCase that emasculated it

Fri May 11 08:55:07 PDT 2007 [EMAIL PROTECTED] * Correct an egregious typo in LiberateCase that emasculated it Somehow in the patch * Record-ise the liberate-case envt, in preparation for new stuff I managed to make lookupLevelEnv do entirely the wrong thing. I think it was just

Re: Mac OS X 10.4.8 fails to darcs get --verbose --partial http://darcs.haskell.org/ghc

Hello, Thanks a lot again for your help, support, and ideas to get me out of this mess. On Thursday 10 May 2007 10:29, Simon Marlow wrote: > ... Or something strange happening > at your ISP? > ... I have finally managed to get my ISP to look at it harder. It seems that it will extend into ne

patch applied (testsuite): add test for #1277

Fri May 11 07:57:20 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * add test for #1277 M ./tests/ghc-regress/parser/should_fail/all.T +1 A ./tests/ghc-regress/parser/should_fail/read033.hs A ./tests/ghc-regress/parser/should_fail/read033.stderr _

patch applied (ghc): don' t remove c++ files from Windows binary distribution

Fri May 11 07:53:52 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * don't remove c++ files from Windows binary distribution M ./distrib/prep-bin-dist-mingw -1 +1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs

patch applied (ghc): Support for adding custom commands to an individual breakpoint

Fri May 11 05:49:29 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * Support for adding custom commands to an individual breakpoint :set stop N runs when breakpoint N is hit. Note that the command to run might be a macro (defined with :def), and the macro can invoke :continue, so i

HEAD Buildable?

Is HEAD buildable? I see there are no nightly builds for 32 bit linux after April 4, and following the building instructions from Building/QuickStart on the developer wiki fails in the middle of the build, in a variety of ways (when trying again after make clean) Has anyone buil GHC from darcs rec

RE: patch applied (ghc): isDataTyCon should be False for all type families, even data type families

Excelelnt thanks! | -Original Message- | From: Manuel M T Chakravarty [mailto:[EMAIL PROTECTED] | Sent: 11 May 2007 12:51 | To: Simon Peyton-Jones | Cc: cvs-ghc@haskell.org | Subject: Re: patch applied (ghc): isDataTyCon should be False for all type families, even data type | families | |

Re: patch applied (ghc): isDataTyCon should be False for all type families, even data type families

Simon, I think we are agreed that you hold the token on this, and on http://hackage.haskell.org/trac/ghc/ticket/1331 Done. - add words to Section 4 of this same page, saying that it's a draft user-manual entry Done. I still have to update the wiki docs and modify the manual as agreed. Af

patch applied (testsuite): Adapt indexed type tests to removal of newtype families

Fri May 11 04:35:21 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]> * Adapt indexed type tests to removal of newtype families M ./tests/ghc-regress/indexed-types/should_compile/Deriving.hs -2 +2 M ./tests/ghc-regress/indexed-types/should_compile/Simple1.hs -3 +3 M ./tests/ghc-re

patch applied (testsuite): Various indexed types tests fail due to trac #1331

Sat May 5 08:56:05 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]> UNDO: Various indexed types tests fail due to trac #1331 M ./tests/ghc-regress/indexed-types/should_compile/all.T -11 +11 M ./tests/ghc-regress/indexed-types/should_fail/all.T -11 +11 M ./tests/ghc-regress/indexed-types/sho

patch applied (ghc): Remove the distinction between data and newtype families

Fri May 11 04:30:57 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]> * Remove the distinction between data and newtype families - This patch removes "newtype family" declarations. - "newtype instance" declarations can now be instances of data families - This also fixes bug #1331

FW: [GHC] #1333: core lint failures in arrow tests

Dear Andy, Ross It turns out that Trac #1333 is an interaction of the HPC and arrow syntax. Could you two fight it out and decide what to do? Currently I think that many programs involving arrow syntax won't compile with HPC and hence won't compile in GHCi. Which is a shame. Arrow syntax impo

patch applied (ghc): FIX BUILD: revert accidentally-committed patch

Fri May 11 00:29:44 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * FIX BUILD: revert accidentally-committed patch M ./rts/Linker.c -1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Store a SrcSpan instead of a SrcLoc inside a Name

Fri May 11 03:49:26 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * Store a SrcSpan instead of a SrcLoc inside a Name This has been a long-standing ToDo. M ./compiler/basicTypes/Id.lhs -2 +2 M ./compiler/basicTypes/Name.lhs -11 +15 M ./compiler/basicTypes/SrcLoc.lhs -11 +13 M ./co

patch applied (ghc): refactoring only

Fri May 11 00:55:05 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * refactoring only M ./compiler/ghci/InteractiveUI.hs -38 +19 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): improve :abandon, it wasn' t properly terminating the computation (see comments)

Fri May 11 02:07:19 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * improve :abandon, it wasn't properly terminating the computation (see comments) M ./compiler/main/InteractiveEval.hs -3 +19 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.h

[nightly] 11-May-2007 build of of 6.6 branch on i386-unknown-mingw32 (bling)

From: GHC Build Reports <[EMAIL PROTECTED]> To: cvs-ghc@haskell.org Subject: [nightly] 11-May-2007 build of of 6.6 branch on i386-unknown-mingw32 (bling) Build description = of 6.6 branch on i386-unknown-mingw32 (bling) Build location= /fptools/builds/STABLE Build config file = /fptools/buil

patch applied (testsuite): Add tests for -fwarn-implicit-prelude (and -fwarn-unused-imports along with it) (trac #1317)

Tue May 8 15:12:38 PDT 2007 Isaac Dupree <[EMAIL PROTECTED]> * Add tests for -fwarn-implicit-prelude (and -fwarn-unused-imports along with it) (trac #1317) M ./tests/ghc-regress/rename/should_compile/all.T +3 A ./tests/ghc-regress/rename/should_compile/rn055.hs A ./tests/ghc-regre

patch applied (ghc): Add a warning flag for when the Prelude is implicitly imported (trac #1317)

Fri May 11 01:45:25 PDT 2007 Isaac Dupree <[EMAIL PROTECTED]> * Add a warning flag for when the Prelude is implicitly imported (trac #1317) GHC already determines all the implicit (Prelude) imports, so we just need to check whether there are any of those, for each module being compiled.

patch applied (ghc): Comments only

Fri May 11 01:40:17 PDT 2007 [EMAIL PROTECTED] * Comments only M ./compiler/coreSyn/CoreSubst.lhs +2 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

RE: darcs patch: Add a warning flag for when the Prelude is implicitly ...

| > + -fno-implicit-prelude or a | > + LANGUAGE NoImplicitPrelude pragma). | > | > Have you actually altered the LANGUAGE pragma processing? | | No, it's an existing LANGUAGE pragma (in fact I use it in one of the | test cases). Ah yes, my mistake. I was confusing the existing >-

Daily report for head

Old unexpected test passes: tc224 2 x86 Windows head fast Old unexpected test failures: CPUTime001 1 tnaur PPC OSX head andre_monad 1 tnaur PPC OSX head andy_cherry 1 tnaur PPC OSX head arith0051 tnaur PPC OSX head