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 Fri Jan 4 19:00:01 GMT 2008.
c
HsVersions.h, included in all source-files, already imports FastString
(except when COMPILING_FAST_STRING), to make its own SLIT and FSLIT
macros work. This generates a lot of "unused import" warnings in
modules that don't happen to use any of those macros (or "_unused"
definitions in the modu
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 Jan 4 19:30:01 GMT 2008.
checkin
On Fri, Jan 04, 2008 at 09:33:40AM +, Simon Peyton-Jones wrote:
> | > The trouble is that 'error' calls an I/O function to print its message,
> and the I/O functions in turn depend
> | on a *lot* of stuff. So 'error' can be defined only when a lot of other
> functions have been defined.
>
>
I just wanted to check that my documentation was correct and my ifdef
reasonable; it validates fine. Then I'll commit, if it's fine.
Fri Dec 28 11:02:55 EST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* document BreakArray better
Fri Dec 28 11:39:22 EST 2007 Isaac Dupree <[EMAIL PROTECTED]>
*
Ian Lynagh wrote:
On Thu, Jan 03, 2008 at 07:07:56AM -0500, Isaac Dupree wrote:
even have memory leaks. To partially remedy this, What if in data types
everywhere
data Foo = Foo FastInt
becomes
data Foo = Foo !FastInt
(the strictness annotation simply has no additional effect when FastInt
= I
Simon Marlow wrote:
Ian Lynagh wrote:
On Mon, Dec 31, 2007 at 09:14:04AM -0500, Isaac Dupree wrote:
I guess boxed types are too risky for efficiency reasons in some
parts of the code
Again, I'd hope that that isn't true for modern GHC, and I personally
would love to see less unboxed hackery i
Fri Jan 4 09:37:07 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* ghci can't run unboxed tuples currently
M ./tests/ghc-regress/parser/should_run/all.T -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-g
Ian Lynagh wrote:
On Mon, Dec 31, 2007 at 09:14:04AM -0500, Isaac Dupree wrote:
I guess boxed types are too risky for efficiency reasons in some parts
of the code
Again, I'd hope that that isn't true for modern GHC, and I personally
would love to see less unboxed hackery in GHC's sources; I th
On Thu, Jan 03, 2008 at 07:07:56AM -0500, Isaac Dupree wrote:
>
> even have memory leaks. To partially remedy this, What if in data types
> everywhere
> data Foo = Foo FastInt
> becomes
> data Foo = Foo !FastInt
> (the strictness annotation simply has no additional effect when FastInt
> = Int#
Isaac Dupree wrote:
Also my other test, parser/should_compile/read063, (and probably others)
seem to be getting a failure for optimization mode just because of a
NOTE in stderr? :
--- /dev/null 2007-12-30 14:48:00.0 -0500
+++ ./read063.comp.stderr.normalised2008-01-04 08:55:51.
On Mon, Dec 31, 2007 at 09:14:04AM -0500, Isaac Dupree wrote:
> I guess boxed types are too risky for efficiency reasons in some parts
> of the code
Again, I'd hope that that isn't true for modern GHC, and I personally
would love to see less unboxed hackery in GHC's sources; I think it
sends a ba
Hi Isaac,
On Fri, Jan 04, 2008 at 09:00:26AM -0500, Isaac Dupree wrote:
> okay I only realized one thing: this test of running unboxed tuples of
> course won't currently work with the `ghci` mode. Does the test need to
> be specially notated in any way because of that?
Yup:
test('read004', e
Fri Jan 4 05:48:43 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* add test for curried unboxed-tuple constructors
M ./tests/ghc-regress/parser/should_run/all.T +1
A ./tests/ghc-regress/parser/should_run/read004.hs
A ./tests/ghc-regress/parser/should_run/read004.stdout
___
Simon Peyton-Jones wrote:
Thanks Isaac, that's great. I've simplified your last two patches quite a bit,
> and pushed the lot.
Thanks! for the GenIface one, you understand what the data structure is
doing enough that you were able to change it;
and for DebugNodes, hmm. You may have reduced
okay I only realized one thing: this test of running unboxed tuples of
course won't currently work with the `ghci` mode. Does the test need to
be specially notated in any way because of that?
Also my other test, parser/should_compile/read063, (and probably others)
seem to be getting a failur
Fri Jan 4 02:54:50 PST 2008 [EMAIL PROTECTED]
* A little refactoring of GenIfaceEq to make the Outputable instance into H98
M ./compiler/iface/IfaceSyn.lhs -4 +5
M ./compiler/iface/MkIface.lhs -2 +2
___
Cvs-ghc mailing list
Cvs-ghc@haskell.o
Fri Jan 4 02:54:09 PST 2008 [EMAIL PROTECTED]
* Make the instance of DebugNodes more H98-like
M ./compiler/cmm/CmmSpillReload.hs -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Fri Jan 4 02:53:39 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* change CmmActual, CmmFormal to use a data CmmHinted rather than tuple
(#1405)
This allows the instance of UserOfLocalRegs to be within Haskell98, and IMHO
makes the code a little cleaner generally.
This is one small (though
Wed Dec 26 09:59:15 PST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* generalize instance Outputable GenCmm to H98 (#1405)
M ./compiler/cmm/PprCmm.hs -3 +3
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Dec 26 09:49:04 PST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* move and generalize another instance (#1405)
was instance Outputable CmmGraph
type CmmGraph = LGraph Middle Last
now instance (ctx) => Outputable (LGraph m l),
in module with LGraph where it belongs
This also let us reduce
Wed Dec 26 09:19:13 PST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* move and generalize an instance (#1405)
UserOfLocalRegs (ZLast Last) isn't Haskell98, but it was just as
good an instance to be UserOfLocalRegs a => UserOfLocalRegs (ZLast a)
M ./compiler/cmm/ZipCfg.hs +10
M ./compiler/
Thanks Isaac, that's great. I've simplified your last two patches quite a bit,
and pushed the lot.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isaac Dupree
| Sent: 03 January 2008 20:24
| To: BuildBot Collator
| Subject: darcs patch: make s
Isaac Dupree wrote:
oops, one of the four "Rank2Types" is actually "PolymorphicComponents"
(I hadn't realized there existed a separate name for it, and LANGUAGE
Rank2Types was sufficient to compile it -- is that latter a bug?)
Rank2Types was sufficient *for ghc-6.8.2* to compile it, I should h
Fri Jan 4 04:58:14 PST 2008 [EMAIL PROTECTED]
* Do not consult -XGADTs flag when pattern matching on GADTs
See Trac #2004, and Note [Flags and equational constraints] in TcPat.
M ./compiler/typecheck/TcPat.lhs -6 +14
___
Cvs-ghc mailing
Fri Jan 4 04:53:05 PST 2008 [EMAIL PROTECTED]
* Add a note about primop wrappers (cf Trac #1509)
M ./compiler/basicTypes/Id.lhs -1 +16
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
oops, one of the four "Rank2Types" is actually "PolymorphicComponents"
(I hadn't realized there existed a separate name for it, and LANGUAGE
Rank2Types was sufficient to compile it -- is that latter a bug?)
~Isaac
___
Cvs-ghc mailing list
Cvs-ghc@has
Fri Jan 4 04:19:39 PST 2008 [EMAIL PROTECTED]
* Document SOURCE pragma; clarify TH behavior for mutually-recurive modules
(Trac #1012)
M ./docs/users_guide/glasgow_exts.xml -4 +17
M ./docs/users_guide/separate_compilation.xml -1 +4
___
Cvs-
Fri Jan 4 02:22:36 PST 2008 [EMAIL PROTECTED]
* White space and comments only
M ./compiler/iface/MkIface.lhs -1 +1
M ./compiler/simplCore/CSE.lhs -4 +4
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-
Thu Jan 3 09:02:36 PST 2008 Simon Marlow <[EMAIL PROTECTED]>
* Optionally use libffi to implement 'foreign import "wrapper"' (#793)
To enable this, set UseLibFFI=YES in mk/build.mk.
The main advantage here is that this reduces the porting effort for
new platforms: libffi works on mor
Thu Jan 3 08:38:05 PST 2008 Simon Marlow <[EMAIL PROTECTED]>
* remove trace apparently left in by accident
M ./compiler/utils/Panic.lhs -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
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 Jan 3 19:30:04 GMT 2008.
checkin
| > You'll probably end up with a link error, because there is no curried
function (#,#). With a regular data
| type, we inject the (rather odd-looking) function
| > (,) = \a \b. (a,b)
| > and similarly for all data type declarations, just so that there is a
current (,) function defined
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 Thu Jan 3 19:00:00 GMT 2008.
c
Isaac Dupree wrote:
would implementing that make it harder or easier for ghci to support
unboxed tuples?
Slightly easier, in that construction (of unboxed tuples with lifted
components only) could be done by calling the curried construction
functions in PrimopWrappers.
Deconstruction could
Isaac Dupree <[EMAIL PROTECTED]> wrote:
... lots of questions about the nhc98 .hi file format.
I think the easiest way to answer is just "have a look at an example
file". There are plenty supplied with the source distribution of nhc98:
you don't even need to build it. Look in the include/ direc
| > The trouble is that 'error' calls an I/O function to print its message, and
the I/O functions in turn depend
| on a *lot* of stuff. So 'error' can be defined only when a lot of other
functions have been defined.
| Why is this necessary in post-exceptions Haskell? Can we not just have
| err
On Fri, Jan 04, 2008 at 09:12:20AM +, Simon Peyton-Jones wrote:
> The trouble is that 'error' calls an I/O function to print its message, and
> the I/O functions in turn depend on a *lot* of stuff. So 'error' can be
> defined only when a lot of other functions have been defined.
>
> But 'err
The trouble is that 'error' calls an I/O function to print its message, and the
I/O functions in turn depend on a *lot* of stuff. So 'error' can be defined
only when a lot of other functions have been defined.
But 'error' is *needed* very early; e.g. to define 'head'.
Hence the module loop.
Ho
Build results:
gabor stable: pass
kahl G5 Gentoo Linux stable:pass
mnemosyne x86-64 Gentoo stable: pass
tnaur PPC OSX stable 2: fail (failed stage2)
tnaur x86 Linux stable: fail (failed stage1)
x86 Windows stable fast:lost fail (failed darcs) fail (fail
Build results:
x86-64 Linux head: pass
x86 Windows head fast: pass pass pass pass pass
kahl G5 Gentoo Linux head: pass
macgyver PPC OSX head: pass
tnaur x86 Linux head: pass
x86-64 Linux head unreg: pass
Dropping unexpected test passes reports from builders not seen in 7 day
41 matches
Mail list logo
