Wed Oct 17 23:03:36 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]>
* Don't barf on error message with non-tc tyvars
MERGE TO STABLE
M ./compiler/typecheck/TcSimplify.lhs -2 +3
M ./compiler/typecheck/TcTyFuns.lhs -1 +1
___
Cvs-ghc ma
Wed Oct 17 21:43:52 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]>
* Fix deferring on tyvars in TcUnify.subFunTys
M ./compiler/typecheck/TcUnify.lhs -7 +8
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/c
Wed Oct 17 04:43:26 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]>
* TcUnify.subFunTys must take type families into account
* A bug reported by Andrew Appleyard revealed that subFunTys did take
neither type families nor equalities into account. In a fairly obscure
case there was
Wed Oct 17 21:57:46 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]>
* tcfail175: error message changed
* The error message has become less informative, but I don't see how to avoid
this easily.
* The error message is now also different to that of 6.8. I am not sure how
to handle
Wed Oct 17 21:42:34 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]>
* TypeFamilies: exercise deferring on tyvars in TcUnify.subFunTys
A ./tests/ghc-regress/indexed-types/should_compile/Simple23.hs
M ./tests/ghc-regress/indexed-types/should_compile/all.T +1
_
Wed Oct 17 04:40:35 PDT 2007 Manuel M T Chakravarty <[EMAIL PROTECTED]>
* TypeFamilies: should_compile/Simple22
* Demonstrates a bug in TcUnify.tcSubFun found by Andrew Appleyard
A ./tests/ghc-regress/indexed-types/should_compile/Simple22.hs
M ./tests/ghc-regress/indexed-types/should_
I get
Unexpected failures:
TH_exn1(normal)
This seems to be due to a changed error message. Can we accept the
new message?
Manuel
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Wed, Oct 17, 2007 at 06:48:57PM +0100, Duncan Coutts wrote:
>
> code.haskell.org/bytestring has a MOTD telling people to ignore it and
> use darcs.haskell.org/bytestring instead.
Why do you prefer d.h.o over c.h.o, out of interest?
c.h.o has the advantage that it's much easier to add accounts
duncan.coutts:
> On Wed, 2007-10-17 at 08:50 -0700, Don Stewart wrote:
>
> > > Don, what do you think? How about we keep bytestring on darcs.h.o and
> > > only move binary etc to code.h.o.
> >
> > As long as we have a head and stable branch. I don't want to validate
> > any time we make a change
On Wed, 2007-10-17 at 08:50 -0700, Don Stewart wrote:
> > Don, what do you think? How about we keep bytestring on darcs.h.o and
> > only move binary etc to code.h.o.
>
> As long as we have a head and stable branch. I don't want to validate
> any time we make a change to bytestring, only when merg
duncan.coutts:
> On Tue, 2007-10-16 at 14:14 +0100, Simon Marlow wrote:
>
> > > If we're doing this we should be consistent about it. ie where the head
> > > should
> > > go, where the other branches should go. Here's Cabal's layout at the
> > > moment:
> > >
> > > Cabal HEAD: d.h.o/cabal
> > >
ghci023,024,025 all fail, for various reasons. To be fair I can see why
024 fails and I can fix that. ghci023 seems to be caused by ^M - if I run
the script through dos2unix I get the right results. Does that help?
it is easier to fix problems that i can see than trying to guess. so it's
no
Claus Reinke wrote:
Hi Simon,
I've tested your patches - unfortunately they fail the tests for me.
Multi-line commands apparently work via readline, but not when piped
into stdin.
i don't know what you mean? the tests worked on my platform,
and piping from stdin seems to work fine for me. s
Wed Oct 17 06:41:45 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* Refactoring: extract platform-specific code from sm/MBlock.c
Also common-up some duplicate bits in the platform-specific code
M ./rts/posix/OSMem.c -1 +196
M ./rts/sm/MBlock.c -433 +15
M ./rts/sm/OSMem.h -1 +4
M .
Wed Oct 17 05:18:55 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* fix an error message (barf -> sysErrorBelch)
M ./rts/win32/OSMem.c -2 +3
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Oct 17 05:16:45 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* fix warning on Windows
M ./compiler/ghci/InteractiveUI.hs -1 +2
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Oct 17 03:09:08 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* Don't clean gmp when validating (speeds up validation on Windows)
M ./gmp/Makefile +5
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Tue Sep 25 05:11:39 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* document float2Int# and double2Int#
M ./compiler/prelude/primops.txt.pp +7
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
TH_exn1 is failing on the HEAD at the moment (see below).
=> TH_exn1(normal)
cd ./th && '/64playpen/simonmar/testing/compiler/stage2/ghc-inplace'
-no-recomp
-dcore-lint -dcmm-lint -Dx86_64_unknown_linux -c TH_exn1.hs -v0 -fth
-package
template-haskell >TH_exn1.comp.stderr 2>&1
Actual std
Wed Oct 17 05:02:12 PDT 2007 [EMAIL PROTECTED]
* Update HsExpr.hi-boot-6 for view pattern changes
M ./compiler/hsSyn/HsExpr.hi-boot-6 -2 +5
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Serge
I've just compiled docon-2.10 with the current 6.8 branch. It compiles fine.
Log is below
Simon
I'm in docon-2.10/docon/source
bash-2.05b$ make configure
runhaskell Setup.hs configure --ghc \
--with-compiler=/playpen/ghc/nightly/STABLE-cam-02-unx/i386-unknown-linux/compiler/s
On Tue, 2007-10-16 at 14:14 +0100, Simon Marlow wrote:
> > If we're doing this we should be consistent about it. ie where the head
> > should
> > go, where the other branches should go. Here's Cabal's layout at the moment:
> >
> > Cabal HEAD: d.h.o/cabal
> > ghc HEAD branch of Cabal: d.h.o/packa
Wed Oct 17 01:19:16 PDT 2007 [EMAIL PROTECTED]
* Add exotic functional-dependency test
A ./tests/ghc-regress/indexed-types/should_compile/Gentle.hs
M ./tests/ghc-regress/indexed-types/should_compile/all.T +2
___
Cvs-ghc mailing list
Cvs-ghc@h
Build results:
x86-64 Linux head: lost
kahl G5 Gentoo Linux head: pass
phil P4 SuSE Linux head: pass
tnaur x86 Linux head: fail (failed stage1)
x86-64 Linux head unreg: lost
New unexpected test passes:
arrowrun004 1 phil P4 SuSE Linux head
New unexpected test failures:
Build results:
kahl G5 Gentoo Linux stable: pass
tnaur PPC OSX stable:pass
x86 Windows stable: lost
x86 Windows stable fast: pass pass pass pass lost
x86-64 Linux stable: lost
Old unexpected test passes:
GMapAssoc 1 tnaur PPC OSX stable
GMapTop1 tnaur P
25 matches
Mail list logo