Re: patch applied (ghc): Fix Trac #3066: checking argument types in foreign calls

Did you validate this one? I get /Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -package-name base-4.0.0.0 -hide-all-packages -no-user-package-conf -i -idist/ build -i. -idist/build/autogen -Idist/build/autogen -Idist/build - Iinclude -optP-include -optPdist/build/autogen/cabal_macros.h -

patch applied (testsuite): Fix a framework failure

Tue Mar 3 13:53:47 PST 2009 Ian Lynagh * Fix a framework failure M ./tests/ghc-regress/rts/all.T -1 +1 View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20090303215347-3fd76-451ff5c03f16cedf1e70ebe5244d51da07d26334.gz ___ Cv

Re: Daily report for stable

On Mon, Mar 02, 2009 at 08:45:42PM +0100, Matthias Kilian wrote: > On Mon, Mar 02, 2009 at 12:30:02AM -0800, BuildBot Collator wrote: > > kili stable: fail (failed stage1) > > tnaur PPC OSX stable 2: fail (failed stage1) > > This happens when building from ghc-6.6: > > [...] > > Conf

patch applied (ghc-6.10/ghc): Fix #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types

Tue Mar 3 11:37:06 PST 2009 pepe iborra * Fix #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types The problem is that calls to boxyUnify would panic if the types involved contained type functions. It looks like one should wrap these calls with getLIE, altho

patch applied (ghc-6.10/ghc): Filter out carriage returns in doc strings

Sat Feb 28 06:53:51 PST 2009 David Waern * Filter out carriage returns in doc strings We want the internal format to contain LFs only. This makes it easier to work with the doc strings for clients of the GHC API. M ./compiler/parser/HaddockLex.x -3 +6 View patch online: http://darc

patch applied (ghc-6.10/ghc): Improve documentation of bang patterns

Fri Feb 27 02:15:03 PST 2009 simo...@microsoft.com * Improve documentation of bang patterns Ignore-this: fa7bf72db82a612d16d44a93f1537351 M ./docs/users_guide/glasgow_exts.xml -15 +45 View patch online: http://darcs.haskell.org/ghc-6.10/ghc/_darcs/patches/20090227101503-1287e-2f926d3c6e3

patch applied (ghc-6.10/ghc): Use 'nonIOok' instead of 'True'; cosmetics only

Mon Feb 23 02:16:59 PST 2009 simo...@microsoft.com * Use 'nonIOok' instead of 'True'; cosmetics only Ignore-this: 80200cf3aec5abb95c6b23ef37fb590a M ./compiler/typecheck/TcForeign.lhs -1 +1 View patch online: http://darcs.haskell.org/ghc-6.10/ghc/_darcs/patches/20090223101659-1287e-77851

patch applied (ghc): Fix #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types

Tue Mar 3 11:37:06 PST 2009 pepe iborra * Fix #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types The problem is that calls to boxyUnify would panic if the types involved contained type functions. It looks like one should wrap these calls with getLIE, altho

patch applied (testsuite): Add test for #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types

Tue Mar 3 11:34:46 PST 2009 pepe iborra * Add test for #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types M ./tests/ghc-regress/ghci.debugger/scripts/all.T +1 A ./tests/ghc-regress/ghci.debugger/scripts/break028.hs A ./tests/ghc-regress/ghci.debugger/sc

[nightly] 03-Mar-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 Tue Mar 3 19:00:01 GMT 2009. ***

[nightly] 03-Mar-2009 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 Tue Mar 3 18:00:01 GMT 2009. checking out

patch applied (ghc): Fix Trac #3066: checking argument types in foreign calls

Tue Mar 3 09:42:58 PST 2009 simo...@microsoft.com * Fix Trac #3066: checking argument types in foreign calls Ignore-this: c07b0df24b9965b190dc0e0797401c51 When checking argument types in a foreign call we were stupidly looking through foralls. The fix is easy. Merge to 6.10.2

patch applied (testsuite): Test Trac #3066

Tue Mar 3 09:41:37 PST 2009 simo...@microsoft.com * Test Trac #3066 Ignore-this: fc5b761872929259688c8f62b2c7e047 A ./tests/ghc-regress/ffi/should_fail/T3066.hs A ./tests/ghc-regress/ffi/should_fail/T3066.stderr M ./tests/ghc-regress/ffi/should_fail/all.T +1 View patch online: h

patch applied (testsuite): Test Trac #3057

Tue Mar 3 09:11:21 PST 2009 simo...@microsoft.com * Test Trac #3057 Ignore-this: 7749f80700d209505fdafa9f3e81f477 A ./tests/ghc-regress/deriving/should_compile/T3057.hs M ./tests/ghc-regress/deriving/should_compile/all.T +1 View patch online: http://darcs.haskell.org/testsuite/_darc

Git error

I got this message when pushing today Simon Syncing Git repo. Finished applying... Waiting for fcntl lock... 1 Counting objects: 11, done. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 2.32 KiB, done. Total 6 (delta 5), reused 0 (delta 0) To g...@github.com:ghc-hq/ghc.git

patch applied (ghc): Fix Trac #3057 in deriving Functor

Tue Mar 3 09:06:12 PST 2009 simo...@microsoft.com * Fix Trac #3057 in deriving Functor Ignore-this: 7d7783868e4684930f75c3b35c18c586 The universal type variables of a data constructor are not necessarily identical to those of its parent type constructor, especially if the data type

RE: Retrieving closure code during code generation

There's no mapping Id -> CmmProc in the CgMonad at the moment, but it'd be easy to add, at least for top-level procedures. However in the example you give, 'f' is a parameter of 'map', so there's no hope of finding what it's bound to, because that depends on the caller (which might not even hav

patch applied (nofib): no functional changes

Wed Feb 25 02:14:48 PST 2009 Simon Marlow * no functional changes Ignore-this: 8c0a6c3e90f7f4695c69c091affdd28 M ./parallel/ray/Main.lhs -10 +10 View patch online: http://darcs.haskell.org/nofib/_darcs/patches/20090225101448-12142-05c85613b53873dfa8e51f0ceb50ff83f60c51ee.gz ___

patch applied (nofib): add gray, mandel

Wed Feb 25 02:15:12 PST 2009 Simon Marlow * add gray, mandel Ignore-this: adc9f161030ef1914238c5bb550d6bd2 M ./parallel/Makefile -1 +1 View patch online: http://darcs.haskell.org/nofib/_darcs/patches/20090225101512-12142-1f12121e5cbda66ed46270d4e351fad42d26e2b5.gz _

patch applied (nofib): use parBuffer

Wed Feb 25 02:14:29 PST 2009 Simon Marlow * use parBuffer Ignore-this: 375c6cca6929c5c1ddd7a075e985f06b M ./parallel/prsa/Rsa.hs -2 +14 View patch online: http://darcs.haskell.org/nofib/_darcs/patches/20090225101429-12142-f7887635e9a23dfc92a3aecb2550d9be83d776e6.gz

patch applied (nofib): use parBuffer

Wed Feb 25 02:14:22 PST 2009 Simon Marlow * use parBuffer Ignore-this: f8ca6d13ffa34a78a5a1751a8495d741 M ./parallel/mandel/Mandel.lhs -1 +11 View patch online: http://darcs.haskell.org/nofib/_darcs/patches/20090225101422-12142-96b09d34f73e57984b194396d5e9211f77d14d5c.gz __

patch applied (testsuite): update output

Tue Mar 3 07:22:17 PST 2009 Simon Marlow * update output Ignore-this: f27ecbf1bb07d5485c25b83eed4f618e M ./tests/ghc-regress/lib/Generics/bits/bits.stdout -1 +1 View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20090303152217-12142-d098e299291fecaa3afa704800088a0deb9

patch applied (testsuite): Adapt test to use CharRep instead of StringRep

Thu Feb 12 04:52:09 PST 2009 j...@cs.uu.nl * Adapt test to use CharRep instead of StringRep M ./tests/ghc-regress/lib/Generics/genUpTo/Main.hs -1 +1 View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20090212125209-6c157-44625fe5a9d90a488cbe02561c8b841c4e75a711.gz __

patch applied (testsuite): skip testwsdeque if ghc < 6.11

Thu Feb 19 07:25:46 PST 2009 Simon Marlow * skip testwsdeque if ghc < 6.11 Ignore-this: 31158cdd206272aa0de759c576302976 M ./tests/ghc-regress/rts/all.T -1 +2 View patch online: http://darcs.haskell.org/testsuite/_darcs/patches/20090219152546-12142-f1e1420fe7fc9eb8abdd37fc36834e6fab646a

Re: patch applied (ghc): #2875: Correct SYB's representation of Char

José Pedro Magalhães wrote: bits is just pattern-matching on a constructor which no longer exists. Replacing it with the new constructor solves the problem. I meant genUpTo and not bits. I'm attaching a patch (genUpTo.patch) to update the test. The other 3 seem to be related

Re: Building ghc with DEBUG: ASSERTION FAILED: file Capability.h, line 297

Ian Lynagh wrote: On Sun, Jan 11, 2009 at 08:21:36PM +0100, Matthias Kilian wrote: [...] If you can get this just by compiling Haddock with -debug, then it could be a bug. In our nightly builds we do turn on -debug for the stage2 build and hence compile all of stage 3 with the debugging-enabl

patch applied (ghc): fix assertion failure with -debug non-threaded RTS (by deleting code!)

Tue Mar 3 06:39:42 PST 2009 Simon Marlow * fix assertion failure with -debug non-threaded RTS (by deleting code!) Ignore-this: 352f3c57979529f44ea92edbf1acbf07 M ./rts/Schedule.c -6 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090303143942-12142-275563d4ee80991eb43e

patch applied (ghc): improvements: generate LaTeX tables for more than one run

Tue Mar 3 06:13:46 PST 2009 Simon Marlow * improvements: generate LaTeX tables for more than one run Ignore-this: 47588f0c4d046f2b5ff0dc7be38777c0 M ./utils/nofib-analyse/CmdLine.hs -5 +5 M ./utils/nofib-analyse/Main.hs -44 +99 View patch online: http://darcs.haskell.org/ghc/_darcs

patch applied (ghc): A few bug fixes; some improvements spurred by paper writing

Tue Mar 3 07:02:28 PST 2009 d...@eecs.harvard.edu * A few bug fixes; some improvements spurred by paper writing Among others: - Fixed Stg->C-- translation of let-no-escapes -- it's important to use the right continuation... - Fixed infinite recursion in X86 backend (shortcutJump misha

Re: Retrieving closure code during code generation

William Jones wrote: I am currently working with GHC's code generator and am wondering if there is any way I can retrieve the Cmm for a function during the compilation of another? I have looked at the information passed using CgMonad and at the bindings in scope but these don't seem to be what

patch applied (ghc): Comments only

Tue Mar 3 03:15:13 PST 2009 simo...@microsoft.com * Comments only Ignore-this: 5c2a7c2a8116fb05e0e035baea9566fa M ./compiler/typecheck/TcSimplify.lhs +6 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090303111513-1287e-03d7e78933597eade78e9d2322c79ef1da468e44.gz _

Daily report for stable

Build results: tnaur x86 Linux stable: pass x86 Linux stable:lost x86 Windows stable: pass x86 Windows stable fast: pass pass pass pass pass pass x86-64 Linux stable: pass New unexpected test failures: conc034 1 x86-64 Linux stable conc038 1 tnaur x86 Linux stable Fixe

Daily report for head

Build results: x86-64 Linux head: pass x86 Windows head:pass x86 Windows head fast: fail (failed darcs) fail (failed darcs) fail (failed darcs) fail (failed darcs) fail (failed darcs) fail (failed darcs) kgardas head:pass tnaur x86 Linux head:pass tnaur x86 OS X he