Ian Lynagh wrote:
Hi Roman,
On Mon, Aug 13, 2007 at 02:15:48PM +1000, Roman Leshchinskiy wrote:
when forking. With the current HEAD on OS X, I get a lot of testsuite
failures of the following form:
Compile failed (status 256) errors were:
i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual
Hi Roman,
On Mon, Aug 13, 2007 at 02:15:48PM +1000, Roman Leshchinskiy wrote:
> when forking. With the current HEAD on OS X, I get a lot of testsuite
> failures of the following form:
>
> Compile failed (status 256) errors were:
> i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expi
Hi all,
there seems to be something wrong with the way the RTS handles signals
when forking. With the current HEAD on OS X, I get a lot of testsuite
failures of the following form:
Compile failed (status 256) errors were:
i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expired
(p
The HEAD now has a 'validate' script at the top level, which you can use for
testing that patches in your tree pass minimal testing. It won't work on
Windows yet (no args are passed to configure), and parallelism is fixed at -j2.
'make fast' in the testsuite now runs with zero failures on x86-
i'm not a fan of cpp, but two things it was good for in other
projects was
..
I'm immediately suspicious of any plan involving more CPP use - the
existing CPP we have (for platform-specific code, mostly) is one of the
causes of build problems, as the compiler can't spot that modifying
import list
On Wed, Jul 04, 2007 at 01:10:05PM +0100, Claus Reinke wrote:
>
> i'm not a fan of cpp, but two things it was good for in other
> projects was
>
>- to have many branches evolving in one code base,
>with an easy way to switch between and test all
>
>- to let new code grow inside
obvious issues:
- cpp or similar is needed everywhere :-(
- should the TEST macro include a test identifier?
- how to generate the list of TEST(X)s? can this be automated?
the third issue (not hardcoding all available or anticipated variants/
platforms/buildbots) and the second issue can be addr
this would work better for new features than for modifications.
developers on OSX would -after testing- check in something like:
#if (OSX || TEST(WIN) || TEST(LINUX) ..)
.. new feature ..
#endif
..
depending on build/test outcome. TEST(X) would be false for
any non-X variant, true fo
i don't have the feeling that most of the recent breakage is due to
negligence, nor do i think that asking contributors to be more
responsible will solve the main issues. yes, there have been a few
cases where typos or incomplete commits caused breakage and,
yes, re-building, *after* pull, *bef
Manuel M T Chakravarty wrote:
Right now the fast testsuite doesn't have zero failures (it has about
20), we'll need to get that down to zero first. The fast testsuite
currently runs in about 8 minutes on a fast Linux machine; it was
about 5 minutes when I first did it, so we probably need som
Simon x 2,
I've just been chatting with Simon about this, and basically we're
willing to try a more rigorous testing regime for changes to the HEAD.
Yesterday Ian and I uncovered a problem with the "known buildable"
repositories idea: the build slave has a partial repository, so it can't
nec
Simon,
| I think its a matter of scalability. The "testing by pushing to head"
approach | that you seem to advocate worked well enough when few people were
hacking GHC. | However, it seems that the number of GHC developers has been
growing quite a bit | in recent times
I agree completely. It's
I've just been chatting with Simon about this, and basically we're willing to
try a more rigorous testing regime for changes to the HEAD.
Yesterday Ian and I uncovered a problem with the "known buildable" repositories
idea: the build slave has a partial repository, so it can't necessarily push
Manuel
| I think its a matter of scalability. The "testing by pushing to head"
approach
| that you seem to advocate worked well enough when few people were hacking GHC.
| However, it seems that the number of GHC developers has been growing quite a
bit
| in recent times
I agree completely. It's
chak:
> Simon Marlow wrote,
> >Personally, I think requiring a complete bootstrap/testsuite on two
> >platforms for every patch is still prohibitively expensive: up to 2
> >hours for each build plus the time and effort to set them up - that's if
> >you even have access to 2 different platforms.
Simon Marlow wrote,
Personally, I think requiring a complete bootstrap/testsuite on two
platforms for every patch is still prohibitively expensive: up to 2
hours for each build plus the time and effort to set them up - that's if
you even have access to 2 different platforms. If the developer d
Simon Marlow wrote:
As you know, so far we've been resistant to adding significant amounts
of "process" to modifying the HEAD, because it'll necessarily slow down
development. Instead, we've added lots of other measures:
Yes, but IMO this is only true if the number of developers is very
sm
Roman Leshchinskiy wrote:
To be entirely honest, I don't see why I can't have both most of the
time (I wouldn't mind too much if head was broken *occasionally*). I
think simply testing potentially destabilising patches on multiple
architectures before submitting/pushing them and clearly statin
Simon Peyton-Jones wrote:
Our current plan (were you in the loop when we discussed this?) is to have a
snapshot darcs repo, that is the last known clean build. (Question: do we need
one per architecture?)
Definitely one per architecture (and there doesn't seem to be a nightly
build for OS
Simon Peyton-Jones wrote:
| 4. Trying to maintain a branch is still frustrating. I've just spend 4
| hours (and had to rebuild ghc 6 or 7 times) trying to sync ghc-ndp with
| head. Even worse, in the last couple of months, we would have problems
| with building head itself more often than not. I
| 4. Trying to maintain a branch is still frustrating. I've just spend 4
| hours (and had to rebuild ghc 6 or 7 times) trying to sync ghc-ndp with
| head. Even worse, in the last couple of months, we would have problems
| with building head itself more often than not. I think we lost *weeks*
| tryi
Hi all,
today, I tried to sync the ghc-ndp branch with head. Again, I'll
describe the problems I've encountered in the hope that it will be helpful.
First, I tried
darcs pull http://darcs.haskell.org/ghc
./darcs-all pull
make distclean
This failed with
Registering filepath-1.0...
22 matches
Mail list logo
