This build error is affecting me too. The problem appears to
be that libraries/process/dist-install/build/.depend-v-p-dyn.c_asm has
Windows style paths "C:", and make doesn't like the extra colon.
The sed magic in ./rules/build-dependencies.mk doesn't seem to
be working because it's backslashes no
Thu Sep 16 10:03:48 PDT 2010 simo...@microsoft.com
* Fix bad error in tyVarsOfType
We weren't gathering the type variables free in the kind
of a coercion binder!
M ./compiler/types/Type.lhs -6 +12
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitd
Thu Sep 16 10:04:52 PDT 2010 simo...@microsoft.com
* Fix a very subtle shadowing bug in optCoercion
See Note [Subtle shadowing in coercions]
This is what was going wrong in Trac 4160.
M ./compiler/types/OptCoercion.lhs -20 +67
View patch online:
http://darcs.haskell.org/cgi-bin/d
Thu Sep 16 10:02:29 PDT 2010 simo...@microsoft.com
* Add more location info in CoreLint
M ./compiler/coreSyn/CoreLint.lhs -10 +16
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100916170229-1287e-5a81b5108ca637ea8e2b35df423f67b864803a6f.gz
__
Thu Sep 16 10:03:10 PDT 2010 simo...@microsoft.com
* More assertions
M ./compiler/types/Coercion.lhs -3 +11
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100916170310-1287e-7446f2d9f1039de606edd3452ff266915ba06477.gz
Thu Sep 16 09:59:44 PDT 2010 simo...@microsoft.com
* Print coercion variables as such (debugging change only)
M ./compiler/basicTypes/Var.lhs -1 +2
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100916165944-1287e-763d2da271dd6b24fa8b954d3d72a
pgj2, build 143
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/143.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting | Success
configuring
Build description = HEAD on i386-unknown-linux (cam-02-unx)
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 Thu Sep 16 18:00:01 BST 2010.
checking out new source tree
pgj, build 146
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/146.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting | Success
configuring
Build description = STABLE on i386-unknown-linux (cam-02-unx)
Build location= /playpen/simonmar/nightly/STABLE
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx
Nightly build started on cam-02-unx at Thu Sep 16 18:10:01 BST 2010.
checking out new source tree
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 Thu Sep 16 18:00:01 BST 2010.
checking out new source
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 Thu Sep 16 18:10:01 BST 2010.
checking out new s
simonmar-win32-head, build 113
Build failed
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/113.html
darcs checkout | Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting
Ah, that worked perfectly! Thanks!
On Sep 16, 2010, at 11:45 AM, Simon Peyton-Jones wrote:
> For reasons explained in “Let should not be generalised” GHC isn’t going to
> generalise local let-bindings, at least not when you switch on GADTs , which
> you have.
>
> So unBM is monomorphic, hen
For reasons explained in "Let should not be generalised" GHC isn't going to
generalise local let-bindings, at least not when you switch on GADTs , which
you have.
So unBM is monomorphic, hence the error.
Give it a type signature, or make it top-level. Either works fine.
Simon
From: cvs-ghc-b
I'm now getting a type error when compiling with GHC HEAD that I wasn't getting
before (also GHC 6.10 and GHC 6.12 work fine). The code is part of a larger
program that I did not write and the type error is confusing to me. I cut it
down to the minimal I could, so hopefully it will be useful. Ca
I'm having a problem getting code with datatype contexts to build with GHC
HEAD. The code is from FGL, but even a simplified code like:
module Heap(
Heap(..)
) where
data Ord a => Heap a b = Empty | Node a b [Heap a b]
deriving Eq
does not work. I get the compile error:
Heap.hs:1:1:
On Tue, Sep 14, 2010 at 11:41:26AM +1000, Ben Lippmeier wrote:
>
> It looks like Simon's mega-patch pushed us over the limit:
I've just been looking at the module import graph, to see if we could
break the ghc package up into e.g. ncg, ghci, hsSyn, etc packages.
However, it looks like 364 of the
Simon Marlow:
> On 16/09/2010 12:56, Manuel M T Chakravarty wrote:
>> Simon Marlow:
>>> On 16/09/2010 04:09, Ben Lippmeier wrote:
The size of each section can only be 0xff (16 MiB). That
means we'd already used 92% of the available space in the text
section before the recent chan
On 16/09/2010 12:56, Manuel M T Chakravarty wrote:
Simon Marlow:
On 16/09/2010 04:09, Ben Lippmeier wrote:
The size of each section can only be 0xff (16 MiB). That
means we'd already used 92% of the available space in the text
section before the recent changes.
Really? Surely the size of
Simon Marlow:
> On 16/09/2010 04:09, Ben Lippmeier wrote:
>>
>> On 16/09/2010, at 9:56 AM, Manuel M T Chakravarty wrote:
>>
I don't know what the difference between "relocatable contents"
and "the whole .o file" is, or how many sections we're using. In
my build tree from Sept 9th t
On 16/09/2010 04:09, Ben Lippmeier wrote:
On 16/09/2010, at 9:56 AM, Manuel M T Chakravarty wrote:
I don't know what the difference between "relocatable contents"
and "the whole .o file" is, or how many sections we're using. In
my build tree from Sept 9th the resulting file is 44MB and it
made
Would it be worthwhile to try and turn off TNTC? I don't know which
section info tables live in without TNTC, but if it were to move info
tables into a separate section this might help.
On 16 September 2010 04:16, Ben Lippmeier wrote:
>
>>> I've been poking through the source of MacOS ld, and th
Thu Sep 16 01:06:22 PDT 2010 simo...@microsoft.com
* T3787 should pass
M ./tests/ghc-regress/indexed-types/should_compile/all.T -1 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20100916080622-1287e-9c1b3d7772552c147959910471541ca85da3f
24 matches
Mail list logo
