On Thu, Jul 28, 2005 at 08:25:05PM -0500, Brian Smith wrote:
I have attached a patch that allows "make check" run more or less successfully on Windows. The patch converts Windows-style newlines to Unix-style newlines from the output of the test, so that when the actual output is compared to the expected output, the newline differences don't set off false positives. It also fixes a couple obvious problems with the tests to make them work on MSYS.
Thanks! I don't know how to strip CRs portably, but I've applied the rest.
I have also attached the results of "make check." I went through all the failures and gave some notes below.
./../src/hugs +q -w -pHugs: static/mod154.hs < nul
This seems to be a known bug in Hugs since mod154.hs says "Hugs gets this wrong."
Yes
./../src/hugs +q -w -pHugs: rts/read.hs < rts/read.input
The exponents on floating point numbers include an extra leading "0": "-3.10862446895044e-015" instead of "-3.10862446895044e-15" and "2.384186e-007" instead of "2.384186e-07". GHCi strips all the leading zeros from the exponents in both cases. So, there is a bug in the tests (doesn't properly take leading zeros into account in exponents) and/or Hugs (if the Haskell spec. requires leading zeros to be stripped like GHCi does).
Another known bug. GHC follows Haskell 98, which specifies the output precisely. Hugs uses the system's C library, which is both noncomformant to H98 and differs between systems.
./../src/hugs +q -w -pHugs: rts/arith.hs < rts/arith.input
There is a difference "-0" vs. "0" that seems not totally unreasonable. The other difference "inf" vs. "1.#INF" seems like a bug in Hugs.
Another C library difference.
./../src/hugs +q -w -pHugs: ffi/Sin.hs < ffi/Sin.input
The unexpected signal is troubling, but I don't know what the problem is.
Probably using ccall where Windows uses stdcall.
./../src/hugs +q -w -pHugs: ffi/FileIO.hs < ffi/FileIO.input
The unexpected error seems to be caused by the fact that "/tmp/test_write" is being opened, when this file doesn't exist normally on Windows. This is a bug in the test.
Fixed that, but the test will fail because of CR/LFs in the data.
./../src/hugs +q -w -pHugs: ffi/Sparc.hs < ffi/Sparc.input
I have no idea what is wrong.
./../src/ffihugs +q -w -pHugs: ffi/Callback.hs ffi/callback.c < nul
However, after getting it to build successfully, it still fails with output "unexpected signal" and exit code 1, and I have no idea why.
More ccall/stdcall, I hope.