[nightly] 26-Apr-2007 build of of HEAD on i386-unknown-mingw32 (bling)

From: GHC Build Reports <[EMAIL PROTECTED]> To: cvs-ghc@haskell.org Subject: [nightly] 26-Apr-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/

[nightly] 26-Apr-2007 build of 6.6 branch on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

Build description = 6.6 branch on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/ghc/nightly/STABLE-cam-02-unx Build config file = /home/simonmar/nightly/site/msrc/conf-6.6-cam-02-unx Nightly build started on cam-02-unx at Thu Apr 26 19:00:00 BST 2007.

patch applied (ghc): restore the correct Unicode ellipsis character

Thu Apr 26 14:31:00 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * restore the correct Unicode ellipsis character It looks like this was accidentally replaced with '?' in the patch "HsSyn clean up for indexed types". (see bug #1294) M ./compiler/parser/Lexer.x -1 +1 _

[nightly] 26-Apr-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 Thu Apr 26 19:30:01 BST 2007. checki

Re: ticky

I've pushed a patch that fixes the segfault that (like I discussed before) was being caused by passing in -rstderr for the ticky file option. So with that patch, and the patch that Simon just pushed, I think ticky should be OK. As far as I can tell. One thing I noticed: the compiler option for t

patch applied (ghc): Avoid segfault when ticky file argument is stderr

Thu Apr 26 12:18:57 PDT 2007 Tim Chevalier <[EMAIL PROTECTED]> * Avoid segfault when ticky file argument is stderr If you compiled a program with -ticky and ran it with: ./foo +RTS -rstderr -RTS the result would be a segfault. This was because the RTS interprets stderr to mean "use de

patch applied (ghc): Dont tidy up tyvars after :print type reconstruction

Thu Apr 26 09:35:40 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Dont tidy up tyvars after :print type reconstruction I introduced a bug yesterday when I changed the way tidying up was performed. As a result of tidying, cvObtainTerm could be returning types with regular tyvars inside, w

patch applied (testsuite): modify test to reproduce a new bug

Thu Apr 26 08:37:44 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * modify test to reproduce a new bug M ./tests/ghc-regress/ghci.debugger/scripts/break005.script -4 +4 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listi

patch applied (testsuite): add another test, and accept some output

Thu Apr 26 08:26:39 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * add another test, and accept some output M ./tests/ghc-regress/ghci.debugger/scripts/all.T +1 M ./tests/ghc-regress/ghci.debugger/scripts/break001.stdout -5 +8 M ./tests/ghc-regress/ghci.debugger/scripts/break005.stdout

patch applied (ghc): fix scoping issues with mdo (test dynbrk004)

Thu Apr 26 08:16:15 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * fix scoping issues with mdo (test dynbrk004) M ./compiler/deSugar/Coverage.lhs -34 +23 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Re: patch applied (ghc): Tweak darcs-all script

i've just run into that 'sh darcs-all' updating darcs-all issue again!-( i think i've restored my local repo (made a copy, did 'darcs revert' in the copy, then 'diff ghc ghc2', then copied over the changes that were actually mine..). but even after './darcs-all pull -a', i still have one odd re

Re: patch applied (ghc): Tweak darcs-all script

i've just run into that 'sh darcs-all' updating darcs-all issue again!-( in addition to fixing that issue, perhaps darcs-all could run 'whatsnew' before each 'pull', and log the result somewhere? that way, if anything else goes wrong with darcs, one might at least safely do a 'darcs revert',

Re: patch applied (ghc): Tweak darcs-all script

i've just run into that 'sh darcs-all' updating darcs-all issue again!-( while i'm trying to reconstruct my repo once again, i was wondering whether we might do something to avoid this trouble with darcs-all updating itself, which is somewhat dubious anyway, and will fail on systems like windo

[nightly] 26-Apr-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] 26-Apr-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 (ghc-6.6/ghc): Set RELEASE back to NO

Thu Apr 26 04:14:06 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]> * Set RELEASE back to NO M ./configure.ac -1 +1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Formatting and minor changes in the ghci debugger section

Thu Apr 26 03:30:51 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Formatting and minor changes in the ghci debugger section M ./docs/users_guide/ghci.xml -4 +10 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs

patch applied (ghc): Update an example on the ghci debugger section

Thu Apr 26 03:30:14 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Update an example on the ghci debugger section M ./docs/users_guide/ghci.xml -38 +39 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): We don' t have -fdebugging anymore, and fine tuning is not really necessary now

Thu Apr 26 03:18:53 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * We don't have -fdebugging anymore, and fine tuning is not really necessary now M ./docs/users_guide/ghci.xml -19 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/m

patch applied (ghc): New section on debugging lambdas in the ghci user guide

Thu Apr 26 02:37:19 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * New section on debugging lambdas in the ghci user guide M ./docs/users_guide/ghci.xml -19 +105 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs

patch applied (ghc): Unbreak the users_guide

Thu Apr 26 02:23:42 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Unbreak the users_guide M ./docs/users_guide/ghci.xml -2 +2 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): :force is not unsupported anymore

Thu Apr 26 02:11:09 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * :force is not unsupported anymore M ./docs/users_guide/ghci.xml -1 +1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (testsuite): Fix the test I just added

Thu Apr 26 03:16:15 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Fix the test I just added :break qsort sets a breakpoint in the outer expression, before any variable has been bound. Once you :step the things are bound M ./tests/ghc-regress/ghci.debugger/scripts/break005.script +1

patch applied (ghc): Attach free variables rather than in-scope variables to breakpoints

Thu Apr 26 03:11:27 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * Attach free variables rather than in-scope variables to breakpoints This speeds up the debugger quite a bit, we're now only about 30% slower than ordinary GHCi, and still adding breakpoints to every sub-expression. Also we no

patch applied (ghc): getRdrNamesInScope: return interactively-bound names too

Thu Apr 26 01:39:02 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * getRdrNamesInScope: return interactively-bound names too so completion can now complete names of local bindings M ./compiler/main/GHC.hs -2 +9 ___ Cvs-ghc mailing list Cvs-ghc@hask

patch applied (ghc): unused import

Thu Apr 26 01:37:13 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * unused import M ./compiler/main/GHC.hs -1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Give a better error message when we try to print a value of unknown type

Thu Apr 26 01:36:57 PDT 2007 Simon Marlow <[EMAIL PROTECTED]> * Give a better error message when we try to print a value of unknown type Stopped at ../Test3.hs:(1,0)-(2,30) _result :: [a] [../Test3.hs:(1,0)-(2,30)] *Main> _result :1:0: Ambiguous type variable `a

patch applied (testsuite): Added a :break test

Thu Apr 26 01:55:38 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Added a :break test M ./tests/ghc-regress/ghci.debugger/scripts/all.T +1 A ./tests/ghc-regress/ghci.debugger/scripts/break005.script A ./tests/ghc-regress/ghci.debugger/scripts/break005.stdout __

patch applied (testsuite): Disable the monomorphism restriction warnings in all tests

Thu Apr 26 01:49:18 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Disable the monomorphism restriction warnings in all tests M ./tests/ghc-regress/ghci.debugger/scripts/all.T -26 +26 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.or

Daily report for head

New unexpected test failures: TH_bracket1 1 x86 Windows head fast TH_spliceE3 1 x86 Windows head fast ds006 1 x86 Windows head fast ds013 1 x86 Windows head fast dynbrk001 1 x86 Windows head fast dynbrk002 1 x86 Windows head fast dynbrk

Daily report for 6.6

New unexpected test failures: bytestring005 1 x86 Windows 6.6 stableptr004 1 x86 Windows 6.6 fast Fixed unexpected test failures: ThreadDelay001 conc049 ghcpkg01 ghcpkg03 Old unexpected test failures: barton-mangler-bug 2 x86-64 Linux 6.6 conc023