[MLton] Regressions (Mostly) Successful under Mingwin

[Stephen Weeks]

> 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.