ghci now has the ability to show dynamic flag settings
and language flags, and that is the test for it. as far as
i know, we've accounted for all platform issues, but as
there wasn't any other test of all flags before, only this one will
show up in validate runs after flag changes.
Ok, but that just means the testsuite has to be changed in sync with
changes to the compiler - like with many other tests (ie, like those
including type error messages).
yes, i was just explaining for the benefit of those who might
be surprised that changing flags are now tested;-)
also, once the flag specifications are unified (#1880), one
might think of generating the expected test output, since that
test is supposed to test a ghci feature, not the flags themselves.
btw, i've never seen a clean validate run on my system (win/xp), as
ThreadDelay001(normal) fails consistently.
Can you fix that or anybody else who uses that platform? (I am making
an effort to hunt down all Mac OS X breakages that I find. For every
platform, we need somebody to do that.)
as far i can tell, assuming that this kind of test succeeds
assumes certain minimal timing differences, which will
always be fragile with evolving hardware. and since no
other test breaks, that assumption doesn't seem to be
neccessary, either.
my fix would be to ignore the output, as just something
to check when other test failures are suspected to be
timing-related. but i assume there is a reason for this test.
claus
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
