[nightly] 08-Feb-2011 build of HEAD on x86_64-unknown-linux (cam-04-unx)

Build description = HEAD on x86_64-unknown-linux (cam-04-unx) 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 Feb 8 18:00:01 GMT 2011. checking out new source t

[nightly] 08-Feb-2011 build of STABLE on x86_64-unknown-linux (cam-04-unx)

Build description = STABLE on x86_64-unknown-linux (cam-04-unx) Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx Nightly build started on cam-04-unx at Tue Feb 8 18:10:01 GMT 2011. checking out new so

RE: Simon's presentation

I won't second-guess Ben's responses, but remember that you are merely looking at a textual dump of the C-- data type. The best way is to look at the data type declarations. For the new code path, assuming you have the HEAD compiler, they are *compiler/cmm/CmmExpr defines expressions

Re: [Haskell.org Google Summer of Code] #1560: Efficient Maps using Generalised Tries

I'm not inclined to think so. (Also, http://hackage.haskell.org/package/TrieMap.) Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis On Tue, Feb 8, 2011 at 1:46 PM, Haskell.org Google Summer of Code < cvs-ghc@haskell.org> wrote: > #1560: Efficient Maps using G

patch applied (testsuite): Remove the haskell98 dependency from full-testsuite tests

Tue Feb 8 06:16:14 PST 2011 Ian Lynagh * Remove the haskell98 dependency from full-testsuite tests M ./tests/ghc-regress/concurrent/should_run/conc019.hs -1 M ./tests/ghc-regress/concurrent/should_run/conc022.hs -1 M ./tests/ghc-regress/concurrent/should_run/conc023.hs -1 +1 M

patch applied (testsuite): Remove concprog003's haskell98 dependency, and remove some unused imports

Tue Feb 8 06:04:44 PST 2011 Ian Lynagh * Remove concprog003's haskell98 dependency, and remove some unused imports M ./tests/ghc-regress/concurrent/prog003/CASList.hs -3 +1 M ./tests/ghc-regress/concurrent/prog003/ImmList.hs -1 M ./tests/ghc-regress/concurrent/prog003/MVarListLock

patch applied (testsuite): Remove the haskell98 dependency from the array tests

Tue Feb 8 05:47:46 PST 2011 Ian Lynagh * Remove the haskell98 dependency from the array tests M ./tests/ghc-regress/array/should_run/arr001.hs -1 +1 M ./tests/ghc-regress/array/should_run/arr002.hs -1 +1 M ./tests/ghc-regress/array/should_run/arr003.hs -1 +1 M ./tests/ghc-regr

patch applied (testsuite): #1333 is fixed now

Tue Feb 8 05:46:19 PST 2011 Ian Lynagh * #1333 is fixed now M ./tests/ghc-regress/arrows/should_run/all.T -7 +4 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20110208134619-3fd76-3718db308af73697e2d446ac08f057f2a2c6beb1.gz

patch applied (ghc): Call the final build system phase "final" rather than ""

Mon Feb 7 06:20:46 PST 2011 Ian Lynagh * Call the final build system phase "final" rather than "" M ./Makefile -1 +1 M ./docs/man/ghc.mk -1 +1 M ./ghc.mk -2 +6 M ./rules/build-package.mk -2 +2 M ./rules/build-prog.mk -2 +2 M ./rules/docbook.mk -3 +3 View patch online:

patch applied (ghc): Fix bug introduced in "Implement fuzzy matching for the Finder"

Tue Feb 8 01:01:21 PST 2011 Simon Marlow * Fix bug introduced in "Implement fuzzy matching for the Finder" The finder was reporting a hidden package when it meant a hidden module, and vice versa (looks like a typo). M ./compiler/main/Finder.lhs -1 +1 View patch online: http://darcs.h

Re: Directions for building GHC via LLVM backend?

On 08/02/2011 04:07, Skirmantas Kligys wrote: Hello, I think I remember reading that the LLVM backend can be used to rebuild GHC itself. Naively, I tried the following edit in GHC 7.0.1's mk/build.mk: # Fast build via LLVM backend: BuildFlavour = quickllvm ifeq "$(BuildFlavour)" "quickllvm" S

Re: test failures

On 07/02/2011 15:16, Simon Peyton-Jones wrote: Ian I’m getting this. I think I’ve pulled all stuff. Maybe a missing update to tests in stm/tests? I'm fixing this. Note that stm is an "extra" package, so Ian probably doesn't have it in his validate run. Cheers, Simon Simon =

RE: is shadowing allowed in CoreSyn?

| Is shadowing allowed in CoreSyn? For example: | |(Lam x (Lam x e)) Yes, that's fine. | If it is okay, I assume it creates a situation where you may shadow, but | only if the variables have the same type. In other words, you can't | represent this term without doing some \alpha-renam