[MLton] Regressions (Mostly) Successful under Mingwin
Stephen Weeks
MLton@mlton.org
Sun, 11 Jul 2004 01:40:11 -0700
> I've got working regression tests (that execute under
> plain-vanilla Windows).
Cool! You're definitely getting close. Most of the failures are also
failures on Cygwin, so it's almost already as good.
> 1. Line endings:
...
> 2. File path differences:
Yes, these differences seem OK.
> 3. date test fails:
>
> 9c9
> < test4 OK
>
> ---
> > test4 WRONG
>
> I'm not sure where the text->date/time conversion is
> taking place. Is this parsed in an SML module
> somewhere?
Date.{fromString,scan} are defined in:
basis-library/system/date.sml
Date.toString is defined there as well, and calls the underlying
asctime function via Date_ascTime defined in runtime/basis/Date.c
I'd bet the error is in the behavior of ascTime, since
Date.{fromString,scan} are defined in pure SML.
> 4. Most socket stuff seems not to work:
> testing echo
> 1c1,2
> < server processed 1900 bytes
>
> ---
> > unhandled exception: Error
>
> > Nonzero exit status.
The Error exception is raised by echo.sml. You could change the uses
of Error to Fail to get a better message. My bet is the call to
listen is failing. The socket code is defined in
basis-library/net/socket.sml and runtime/basis/Net/Socket/*.
Here's a few general debugging techniques for the regressions.
* If there is some equivalent of strace for MinGW, that might help see
what's going on.
* Compile with -codegen c, to see if the results are the same as with
-codegen native. If so, you can often debug more effectively with
the C version by compiling with -keep g and using the debugger on
generated C code or inserting print statements.
* Use Primitive.Stdio.print at judicious places in the basis library
to see what's going on.
* Use print statements in the runtime C functions and/or compile
various runtime files setting DEBUG = TRUE at the start of the
file.
* Compile gc.c with various DEBUG_* variables set to TRUE.
> 5. A few filesystem tests fail:
> < test1b OK
> < test2 OK
> < test3a OK
> ---
> > test1b WRONG
> > test2 EXN
> > test3a WRONG
Finding these should be pretty easy by adding print statements to see
what's going on in C functions. For example, 1b is failing because of
mkdDir, which calls the C function Posix_FileSys_mkdir, defined in
runtime/Posix/FileSys/mkdir.c.
> 5. Signal-related stuff fails (signals test).
>
> 6. Suspend fails (Nonzero exit status).
>
> 8. timeout never times out (I kill it manually).
These are all signal related. DEBUG_SIGNALS in gc.c might help.
> 7. textio.2 fails (Unhandled Exception: Subscript).
This one's OK. It's due to different handling of newline on windows.
We see it with the Cygwin regressions too.
> 9. world1, world2, world3, world4 fail with several
> "Function not implemented [nosys]" errors.
> (I am the clone, 30, caught foo, between saves)
> repectively.
It should be easy to find which system call is not implemented by
using an strace equivalent, or by adding some print statements. Could
it be something as simple as failure to create temp files?
You could also compile gc.c with DEBUG_WORLD = TRUE to see what's
going on.
> 10. world5 fails with a Subscript exception.
This uses signals, so I wouldn't worry about it until signals work.
> 11. world6 fails with "No such file or directory".
Ditto.