On 05/08/2008, at 14:15, Judah Jacobson wrote:
It seems that the old, pre-Cabal build system did not clean some or
all of the preprocessed files (such as Parser.hs). This was not much
of a problem in practice, because the Makefiles used the relative
timestamps to tell whether to regenerate Par
On Mon, Aug 4, 2008 at 12:07 PM, Claus Reinke <[EMAIL PROTECTED]> wrote:
> make distclean; ./darcs-all pull -a; sh boot; ./configure ..; make
>
> first complained about
>
> parser/Parser.hs:14:36:
>
> Module `HscTypes' does not export `DeprecTxt'
>
> Since Parser.hs and Parser.y looked diff
On 05/08/2008, at 01:30, Judah Jacobson wrote:
On Mon, Aug 4, 2008 at 1:07 AM, Roman Leshchinskiy
<[EMAIL PROTECTED]> wrote:
Configuring filepath fails without any diagnostics.
Strange; I haven't seen anything like that.
It seems to be caused by the exception handling changes and my rat
On Mon, Aug 04, 2008 at 10:40:58PM +0100, Duncan Coutts wrote:
> On Mon, 2008-08-04 at 16:33 +0100, Simon Peyton-Jones wrote:
> >
> > John discovered (we think) that a new feature of the build system is
> > that all GHC's source modules must be listed by the developer in
> > ghc.cabal.
>
> Yes.
On Mon, 2008-08-04 at 16:33 +0100, Simon Peyton-Jones wrote:
> Ian
>
> John discovered (we think) that a new feature of the build system is
> that all GHC's source modules must be listed by the developer in
> ghc.cabal.
Yes.
> Actually gets a long way without this, but there's a confusing link
>
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
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 Mon Aug 4 18:02:08 BST 2008.
checking out
Another 'make distclean' removes Parser.hs, but leaves lots of other
.hs files that have .x or .y files:
$ ls compiler/parser/
Ctype.lhs HaddockLex.x HaddockUtils.hs Lexer.xParserCore.y
cutils.c
HaddockLex.hs HaddockParse.hs LexCore.hs Parser.y.pp
make distclean; ./darcs-all pull -a; sh boot; ./configure ..; make
first complained about
parser/Parser.hs:14:36:
Module `HscTypes' does not export `DeprecTxt'
Since Parser.hs and Parser.y looked different, I removed the former
and tried again. But now, I get
dist-stage1/build/Parse
Mon Aug 4 09:09:46 PDT 2008 [EMAIL PROTECTED]
* Test for Trac #1930
M ./tests/ghc-regress/ghci/scripts/all.T +1
A ./tests/ghc-regress/ghci/scripts/ghci033.hs
A ./tests/ghc-regress/ghci/scripts/ghci033.script
A ./tests/ghc-regress/ghci/scripts/ghci033.stdout
View patch online:
Mon Aug 4 07:14:40 PDT 2008 [EMAIL PROTECTED]
* Test Trac 2433
A ./tests/ghc-regress/typecheck/should_compile/T2433.hs
A ./tests/ghc-regress/typecheck/should_compile/T2433_Help.hs
M ./tests/ghc-regress/typecheck/should_compile/all.T +3
View patch online:
http://darcs.haskell.org/t
Fri Aug 1 08:15:04 PDT 2008 [EMAIL PROTECTED]
* Test for Trac #2478
A ./tests/ghc-regress/typecheck/should_compile/T2478.hs
M ./tests/ghc-regress/typecheck/should_compile/all.T +1
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080801151504-1287e-88eca687c49ae88
Mon Aug 4 09:21:29 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #2467: decent warnings for orphan instances
This patch makes
* Orphan instances and rules obey -Werror
* They look nicer when printed
M ./compiler/iface/MkIface.lhs -21 +37
M ./compiler/main/ErrUtils.lhs -1 +1
Vi
Mon Aug 4 09:10:39 PDT 2008 [EMAIL PROTECTED]
* Fix the bug part of Trac #1930
M ./compiler/basicTypes/Name.lhs -1 +8
M ./compiler/hsSyn/HsDecls.lhs -2 +1
M ./compiler/hsSyn/HsExpr.lhs -11 +4
M ./compiler/hsSyn/HsImpExp.lhs -22
M ./compiler/main/PprTyThing.hs -2 +2
M ./
Mon Aug 4 07:15:03 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #2433 (deriving Typeable)
M ./compiler/typecheck/TcDeriv.lhs -2 +6
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080804141503-1287e-f6f07fcc2a83f18fafff6a0507f6eba2d5a79c64.gz
Fri Aug 1 05:22:23 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #2478
A minor glitch that shows up only when a data constructor has *both* a
"stupid theta" in the data type decl, *and* an existential type variable.
M ./compiler/typecheck/TcPat.lhs -1 +3
View patch online:
http://darcs.
Tue Jul 29 07:53:13 PDT 2008 [EMAIL PROTECTED]
* Improve docs for GADTs
M ./docs/users_guide/glasgow_exts.xml -1 +20
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080729145313-1287e-1febb0b3d3242a3ca6b0d246e18e3ff7eec9ad43.gz
Tue Jul 29 07:52:47 PDT 2008 [EMAIL PROTECTED]
* Document -dsuppress-uniques
M ./docs/users_guide/debugging.xml +14
M ./docs/users_guide/flags.xml +6
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080729145247-1287e-ff3e9971993ba218410550eafd850bfbc7b35433.gz
___
Ian
John discovered (we think) that a new feature of the build system is that all
GHC's source modules must be listed by the developer in ghc.cabal.
Actually gets a long way without this, but there's a confusing link error later.
(The old make system would just use whatever .hs files were aroun
On Mon, Aug 4, 2008 at 1:07 AM, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
>
> On 04/08/2008, at 17:45, Judah Jacobson wrote:
>
>> On Mon, Aug 4, 2008 at 12:15 AM, Roman Leshchinskiy <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On 04/08/2008, at 16:55, Judah Jacobson wrote:
>>>
For what it's worth
2. BuildBot can't cope with dropped connections in the middle of a build.
Again I have a ticket open against BuildBot but fixing it apparently
requires large amounts of infrastructure refactoring, so it's currently
scheduled for the next-but-one major release of BuildBot, which could be
months
Claus Reinke wrote:
going back from the use of darcs-specific 'pull --intersection' (but
still relying on selective pull in some form), and addressing Roman's
point about avoiding conflicts:
0. for each platform, have a list of successfully tested patches
1. humans (GHC users, needing a workin
going back from the use of darcs-specific 'pull --intersection' (but
still relying on selective pull in some form), and addressing Roman's
point about avoiding conflicts:
0. for each platform, have a list of successfully tested patches
1. humans (GHC users, needing a working build of HEAD):
Roman Leshchinskiy wrote:
On 04/08/2008, at 20:50, Claus Reinke wrote:
0. for each platform, have a list of successfully tested patches
1. push patches as now
2. humans pull the lists of tested patches, then only pull
the patches on the list for their platform (unless they
are trying to de
On 04/08/2008, at 20:50, Claus Reinke wrote:
0. for each platform, have a list of successfully tested patches
1. push patches as now
2. humans pull the lists of tested patches, then only pull
the patches on the list for their platform (unless they
are trying to debug the failed patches) - t
Actually there are some more orphan instances. I do not know which are
important and which are not, but it'd be better to eliminate them. Would
someone be willing to take a look?
Thanks
Simon
Data/Array.hs:90:9:
Warning: orphan instance: instance (Ix i) => Foldable (Array i)
Data/Array.
Ian Lynagh wrote:
Hi Claus,
On Sat, Aug 02, 2008 at 07:10:31PM +0100, Claus Reinke wrote:
But there seems to be no "Latest Successful Build" for each builder,
but of course we have other priorities in the build-up to release.
That confuses me everytime: how can you build up for a release
with
| Any idea when things will have settled down? Being sick of build
| failures, I have actually pretty much given up on pulling from the
| head and will keep my type family patches to myself until things have
| settled down. (Well, I am happy to push them, but I can't validate
| them against the c
Mon Aug 4 04:18:01 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* UNDO: FIX #2375: remove oc->lochash completely, it apparently isn't used
M ./rts/Linker.c +35
M ./rts/LinkerInternals.h +3
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080804111801-12142-bd93a8fb85b32d
Having imagined things that far, one might tune this further, to
simply assume that every patch is for buildbot only at first, and
to have lists of successfully built/tested patches per platform:
actually, it seems that darcs does have a feature I didn't know
about that might make this fairly s
Don Stewart wrote:
igloo:
Sun Aug 3 07:11:46 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Follow the move of assertError from Control.Exception to GHC.IOBase
M ./compiler/prelude/PrelNames.lhs -1 +1
Do we have good assurances end-user behaviour isn't changing with these
patches? Control
Simon's mail explains why we changed the build system, but to answer
your specific build problem:
On Sun, Aug 03, 2008 at 11:50:08PM -0500, Austin Seipp wrote:
>
> > Preprocessing executables for ghc-pkg-6.9...
> > Building ghc-pkg-6.9...
[...]
> > Main.hs:1143:14: Not in scope: `Exception.onExc
I've done a little searching, and I found at least one continuous
integration tool that will do this (for Git though, not Darcs)
"continuous integration" would seem to be a useful thing support
for which to have nice would be (even if it might permute patches
in unexpected ways, depending on whe
Roman Leshchinskiy wrote:
Does anyone actually pay attention to the bots? Yesterday:
x86-64 Linux head:lost
x86 Windows head: lost
x86 Windows head fast:fail (failed stage1) fail (failed
stage1) lost fail (failed stage1) lost lost
fast486 head:
We *do* think that stability is important (which is why we're using
validate now), and all the changes that have been made recently have been
made in good faith for good reasons. That's not to say I don't think
people have valid concerns - but let's deal with the motivation first.
Here's some
2008/8/4 Judah Jacobson <[EMAIL PROTECTED]>:
> It seems like most of the recent build breakages have been with
> patches not being validated on a complete set of OSes (OS X and
> Windows, in particular). In last week's IRC meeting, Neil Mitchell
> mentioned:
>
>> i've always wondered why there isn
Hi Austin,
> Essentially everything is coming down to the build system it looks
> like. The basic idea is to go from autoconf -> Cabal as I see it.
> What is this new system buying us? Because currently, it seems to have
> cost us:
>
> 1. Parallel builds (i.e. make -j, brought up by ChilliX)
> 2.
2008/8/4 Simon Peyton-Jones <[EMAIL PROTECTED]>:
> Max
>
> The perf impact is zero if you have no error messages, I assume? I'm not too
> stressed out about extra time taken to compile failing modules.
Right: the performance degradation only occurs for modules
experiencing unbound name errors, a
On 04/08/2008, at 17:45, Judah Jacobson wrote:
On Mon, Aug 4, 2008 at 12:15 AM, Roman Leshchinskiy <[EMAIL PROTECTED]
> wrote:
On 04/08/2008, at 16:55, Judah Jacobson wrote:
On Sun, Aug 3, 2008 at 9:50 PM, Austin Seipp <[EMAIL PROTECTED]>
wrote:
For the past two weeks or so I have been u
Max
The perf impact is zero if you have no error messages, I assume? I'm not too
stressed out about extra time taken to compile failing modules.
Mind you, doubling time for such modules sounds quite substantial, but I think
you're saying that's very much a worst case.
Personally I'm open to a
On Mon, Aug 4, 2008 at 12:15 AM, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
>
> On 04/08/2008, at 16:55, Judah Jacobson wrote:
>
>> On Sun, Aug 3, 2008 at 9:50 PM, Austin Seipp <[EMAIL PROTECTED]> wrote:
>>>
>>> For the past two weeks or so I have been unable to build the latest
>>> GHC HEAD fro
Yes, it's just a compile time thing. There's no runtime penalty
Simon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Leather
Sent: 01 August 2008 18:31
To: Simon Peyton-Jones
Cc: Ian Lynagh; Simon Marlow; cvs-ghc@haskell.org
Subject: Re: Orphans
Hi,
I'm fixing http://hackag
Build results:
x86-64 Linux head: lost
x86 Windows head:fail (failed stage1)
x86 Windows head fast: fail (failed stage1) lost lost fail (failed stage1)
fail (failed stage2) lost
x86-64 Linux head unreg: lost
Old unexpected test passes:
countReaders001 1 x86 Windows head fas
On 04/08/2008, at 16:55, Judah Jacobson wrote:
On Sun, Aug 3, 2008 at 9:50 PM, Austin Seipp <[EMAIL PROTECTED]>
wrote:
For the past two weeks or so I have been unable to build the latest
GHC HEAD from the main darcs development branch (I believe the last
one I managed to build here on OS X 1
43 matches
Mail list logo
