Hi all,

On Saturday 23 May 2009 04:56:02 Trent W. Buck wrote:
> Eric Kow <[email protected]> writes:
> > On Tue, May 19, 2009 at 10:17:56 -0700, Jason Dagit wrote:
> >> I can't manage time for another review right now.  So please use your
> >> best judgment without my further input :)  Short answer: Sure if you
> >> think so.
> >
> > I'm afraid I'm going to have to just apply this without review.  Our
> > Review Team seems to be a bit stretched right now (and I personally have
> > to do a bit of catching up at work).  Need more reviewers!
>
> I did this:
>
>     ghc --make Setup
>     ./Setup configure -ftest\ tests
>     ./Setup build
>     dist/build/unit/unit -j4
>
> The output from unit is totally garbled, because multiple
> threads/processes are writing to stdout at the same time.

That's an unfortunate thing but there's little I can do about it. QuickCheck 
inherenly does console I/O and console I/O gets interleaved if done by 
multiple Haskell threads at the same time.

> AFAICT this makes it impossible to see which unit tests are failing AND
> it makes the unit tests run far more slowly -- perhaps because most of
> my CPU time is taken up trying to write the garble to stdout/stderr?

This is wrong. The test below does not actually use multiple CPU threads. To 
create multiple CPU threads you have to pass the -N flag to the Haskell 
runtime system, with the number of threads. The interesting thing to time is 
"dist/build/unit/unit -j4 +RTS -N4". I suppose the timing difference you see 
comes from the differences in the QuickCheck data and/or context switch 
overhead.

To tell what tests failed, look at the summary that you get after all tests 
have finished.

Regards,
Reinier

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users

Reply via email to