Mitchell, Neil wrote:
Thanks Thorkil, more information:
=====> 2228(normal)
cd ./ghc-e/should_run && $MAKE --no-print-directory -s 2228
</dev/null >2228.run.stdout 2>2228.run.stderr
=====> 2636(normal)
cd ./ghc-e/should_run && $MAKE --no-print-directory -s 2636
</dev/null >2636.run.stdout 2>2636.run.stderr
Actual stdout output differs from expected:
--- ./ghc-e/should_run\2228.stdout.normalised 2008-10-17
16:03:32.386896400 +0100
+++ ./ghc-e/should_run\2228.run.stdout.normalised 2008-10-17
16:03:32.386896400 +0100
@@ -1,2 +1,2 @@
-BlockBuffering Nothing
+LineBuffering
BlockBuffering Nothing
*** unexpected failure for 2228(normal)
====> Running ./ghci/prog001/prog001.T
=====> prog001(ghci)
cd ./ghci/prog001 && HC='c:/ghc-build/ghc/ghc/stage2-inplace/ghc'
HC_OPTS='-dcore-lint -dcmm-lint -Di386_unknown_mingw32
-dno-debug-output ' 'c:/ghc-build/ghc/ghc/stage2-inplace/ghc'
--interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint
-Di386_unknown_mingw32 -dno-debug-output <prog001.script
prog001.run.stdout 2>prog001.run.stderr
====> Running ./ghci/prog002/prog002.T
Could it be that buffering has a different default on Windows?
2228 is now an expected failure on Windows. See #2628.
=====> break009(ghci)
cd ./ghci.debugger/scripts &&
HC='c:/ghc-build/ghc/ghc/stage2-inplace/ghc' HC_OPTS='-dcore-lint
-dcmm-lint -Di386_unknown_mingw32 -dno-debug-output '
'c:/ghc-build/ghc/ghc/stage2-inplace/ghc' --interactive -v0
-ignore-dot-ghci -dcore-lint -dcmm-lint -Di386_unknown_mingw32
-dno-debug-output -ignore-dot-ghci <break009.script
break009.run.stdout 2>break009.run.stderr
--- ./ghci.debugger/scripts\break008.stdout.normalised 2008-10-17
16:04:39.247127200 +0100
+++ ./ghci.debugger/scripts\break008.run.stdout.normalised
2008-10-17 16:04:39.247127200 +0100
@@ -1,3 +1,3 @@
-Breakpoint 0 activated at ../Test3.hs:1:13-14
-Stopped at ../Test3.hs:1:13-14
-_result :: [a] = _
+Cannot find default module for breakpoint.
+Perhaps no modules are loaded for debugging?
+[]
*** unexpected failure for break008(ghci)
And a GHCi debugger issue.
I haven't seen this, but I have noticed that one or two of the GHCi
debugger tests seem to be failing on Windows, I'll try to look into it shortly.
As a secondary issue, it appears that the failure reports are occuring
after the script has started to print out information about the next
test.
That's probably because the testsuite is running in parallel, which it does
automatically when validating if you have a new enough version of Python.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
