[nightly] 31-Dec-2007 build of STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

2007-12-31 Thread GHC Build Reports
Build description = STABLE 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-STABLE-cam-02-unx Nightly build started on cam-02-unx at Mon Dec 31 19:00:01 GMT 2007.

[nightly] 31-Dec-2007 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

2007-12-31 Thread GHC Build Reports
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 Mon Dec 31 19:30:02 GMT 2007. checki

Re: Remove GHC.Err import from Data.Maybe

2007-12-31 Thread Judah Jacobson
On Dec 31, 2007 11:57 AM, Neil Mitchell <[EMAIL PROTECTED]> wrote: > > These imports of Err all include {-# SOURCE #-} pragmas, which GHC > warns me are unnecessary, but clear change the output. What do the > SOURCE pragma's do? I couldn't find them in the manual. > They break the circular depende

Re: Remove GHC.Err import from Data.Maybe

2007-12-31 Thread Neil Mitchell
Hi GHC.Arr and GHC.Base both also have this issue, but they could well be necessary. These imports of Err all include {-# SOURCE #-} pragmas, which GHC warns me are unnecessary, but clear change the output. What do the SOURCE pragma's do? I couldn't find them in the manual. Thanks Neil On 12/3

Remove GHC.Err import from Data.Maybe

2007-12-31 Thread Neil Mitchell
Hi, I noticed that Data.List uses "error" normally, but Data.Maybe explicitly imports it from GHC.Err. Is there a reason for this? Removing the import GHC.Err line still appears to work. This caused me issues with circular modules and recursive boot files, in various mixtures. It's not a fatal is

Re: unboxed types

2007-12-31 Thread Isaac Dupree
Neil Mitchell wrote: Hi Isaac, Or will I have to #define UTopen (# #defined UTclose #) and (UTopen x, y UTclose) Yuk! There is a ticket on adding a prefix form of (#,#), which is currently lacking. Perhaps adding that first, then moving to the unboxed thingy would be best. Also your use of #

Re: unboxed types

2007-12-31 Thread Neil Mitchell
Hi Isaac, > Or will I have to > #define UTopen (# > #defined UTclose #) > > and (UTopen x, y UTclose) Yuk! There is a ticket on adding a prefix form of (#,#), which is currently lacking. Perhaps adding that first, then moving to the unboxed thingy would be best. Also your use of # in a CPP macro

unboxed types

2007-12-31 Thread Isaac Dupree
I guess boxed types are too risky for efficiency reasons in some parts of the code (close examination of -ddump-simpl would be needed I guess), so I'll expand utils/FastTypes and put all the #ifdefs in there. Unboxed tuples that are used in little areas of GHC code solely for the efficiency of

Daily report for stable

2007-12-31 Thread BuildBot Collator
Build results: kahl G5 Gentoo Linux stable: pass x86 Windows stable: fail (failed darcs) x86 Windows stable fast: fail (failed darcs) fail (failed darcs) fail (failed darcs) fail (failed darcs) fail (failed darcs) fail (failed darcs) x86-64 Linux stable: pass New unexpected t