[MLton] Some issues with MLton on MinGW

[Matthew Fluet]

> I am trying to port a large application from SML/NJ to MLton.
> The final product needs to be a standalone application on Windows,
> which is why we need to use the MinGW (not Cygwin) port of MLton.
> Stephen Weeks had been working on porting this for some time and
> gotten quite far and I am picking up where he left and trying to
> complete the job.  All in all this is progressing quite well
> although there were some problems along the way which I would like
> to share so that they maybe can get fixed.

If you have additional changes that you've made for use under MinGW, it 
would be great if we could put them into the repository.  Then everyone 
is on the same page with regards to changes.

> - When trying to compile MLton on MinGW,  I ran into the following
>   error:
> 
>   Error: ..\lib\mlton\basic\vector.sml 10.29.
>    Variable type in structure disagrees with argument signature.
>      variable: unfoldi
>      structure: _ -> [ 'a t ]
>      signature: _ -> [ 'a t  * 'b ]
> 
>   I was able to work around this issue by Hand-propagating changes
>   to unfoldi in Vector and Array structures as suggested in
>   http://mlton.org/pipermail/mlton/2006-May/028744.html

I think, though, that this is a general problem with changes since the 
last release.  We should add an upgrade-basis check to handle old 
versions of MLton.Vector.unfoldi.

> - The program I am trying to compile is rather large.  During
>   compilation (on Linux nad MinGW) I ran into the following errors:
>   "numPeeks overflow" and "numLinks overflow".
>   I was able to work around these by commenting out the lines in
>   lib/mlton/basic/property-list.fun that increase the numPeeks and
>   numLinks values (a suggestion by Stephen Weeks)

Large indeed.  I think Vesa is correct that Overflow sometimes signals a 
compiler bug.  It would be useful to verify that such is not the case in 
this situation.

> - OS.FileSys.tmpName() returns a unix-style filename (e.g. /tmp/abcde)
>   which on Windows most likely is not a good temporary filename
>   (unless the user by chance has a \tmp directory on the current drive)
>   The return value really should be one in a native Windows temporary
>   folder

It seems like we can just implement tmpName with a case on the platform 
using C:\TEMP\* for windows systems.

> - INetSock.any() and INetSock.toAddr() produce a
>   "SysErr: Invalid argument [inval]" error when called.
>   After trying the modifications suggested in
>   http://mlton.org/pipermail/mlton/2006-December/029466.html
>   the conversion still does not work.  The htons function seems to
>   not be called correctly (as suggested in
>   http://mlton.org/cgi-bin/viewsvn.cgi?rev=4333&view=rev )

Yes, as those notes say, I'm not at all sure that the endian changes are 
being applied at the right time or to the right values.  It would be 
really useful for someone with more network programming experience to 
look through the implementation.

> - After working around the INetSock.toAddr() issue,  I found that
>   neither function Socket.acceptNB() (to check whether a connection
>   is requested without blocking) nor Socket.select() (to wait until
>   a connection request arrives or a timeout expires) appear to
>   be currently implemented.  Without either of the two I don't see
>   any way to accept a connection without blocking the whole
>   application for an indefinite amount of time.  Does anybody know
>   a workaround for this?

> - On the other end,  Socket.connect does not appear to work either.
>   Calling it results in an
>   "unhandled exception: SysErr: No error [<UNKNOWN>]"
>   Although this might just be a problem of trying to connect to the
>   wrong port due to the htons function problem.  Although the
>   server listening on the other end is just a SML program compiled
>   with the same MLton as the client,  so the port number mangling
>   should be the same in both cases.  Note that all of this is on
>   MinGW under Windows -- it might work fine on Unix/Linux.

I don't have any immediate suggestions.

It would be nice to know if things do work fine on Unix/Linux; if it 
does not, then we'd at least know that it is a pervasive problem with 
the Basis Library implementation, rather than just a platform 
compatability issue.

Also, since your application works under SML/NJ, it wouldn't be a bad 
idea to look at the SML/NJ sources to see how they implement these 
functions on Windows.  (Though, I believe that they avoid MinGW altogether.)