[MLton] A few patches we had to apply to port from version 20030716 to 20051202 and for the MinGW port

[Matthew Fluet]

>>>>> - bug-fix-cygwin-1_3_17.patch :
>> I think it would be fine to include portion of the patch that includes
>> work-arounds for fpclassify and nanosleep.  This would allow a program
>> compiled by MLton to be run on older Cygwin releases, without
>> necessarily condoning development on that older Cygwin release.
> 
> If you build a binary for a given version of Cygwin, it will only run on
> newer versions of Cygwin and will fail to run (you get a popup windows when
> you try to execute it) on older versions.
> 
> So, it does not really make sense to include the workarounds only.

O.k.

>>>>> - bug-fix-solaris7.patch
>> I figured you had tested it.  It just seems that 0 is a safer value for
>> a flag, as OR-ing it in obviously has no effect.  (I could imagine that
>> some system calls raise an error if they are passed an unknown flag, but
>> obviously mmap on Solaris 7 is not such a function.)
> 
> I think there is a reason why the compiler uses anonymous mapping (maybe it
> is more efficient on platforms which support it) and this is why I decided
> to use the real value. Then, if the binary runs on a platform which knows
> the flag, it will use it. If we set it to 0, it will never be used, even on
> platforms which handle it.
> 
> Another solution would be to detect the version at execution time ... but it
> may be a bit complex and costly.

Ahh.  You thinking of the situation where you build MLton (in 
particular, libmlton.a) and a mlton compiled executable on Solaris 7 and 
  then move the executable over to a Solaris 8 (9, 10) machine.  In 
which case, yes, it would be nice to take advantage of MAP_ANON on the 
newer version.

>>>>>  - bug-fix-nethostdb-mingw.patch
>> There are different trade-offs.
>>
>> In basis-library/net/net-host-db.sml, you could include code like the
>> following:
>>
>> structure Prim =
>> struct
>>    open Prim
>>    val (getByAddress, getByName, getHostName) =
>>      (if let open Primitive.MLton.OS in host = MinGW end
>>          then Net.init ()
>>          else ()
>>       ; (getByAddress, getByName, getHostName))
>> end
>>
>> This would have the effect that if any of 'getByAddress', 'getByName',
>> or 'getHostName' were used in the user program, then, at program
>> startup, Net.init would be called just once.  (One could pull the same
>> trick with the Socket.* functions.)  And you don't pay the cost of
>> checking whether networking has been initialized at each use of a
>> networking function.
>>
>> On the other hand, this means that one will load WinSock2 DLL regardless
>> of whether or not the program dynamically uses networking functions.
> 
> I'm not sure this very little performance optimization is really important
> here. It's all about networking and network resources are usually much
> slower than local ones.

I'm a little confused by your comments.  I thought you were in favor of 
reducing the overhead of the MLton_initSockets() function being called 
multiple times.  But here you seem to be saying that you don't think the 
optimization is important.

>>>>> - evol-dash-in-pathes-cygwin.patch
>> It is certainly the case that the semantics of OS.Path.* functions (on
>> Cygwin and MinGW) have changed since 20030716, but they have not changed
>> 20051202.  Looking at the SVN log, I see that a few of those changes
>> were committed on behalf of Wesley.
>>
>>> Then, if we use the resulting path in a shell command, the command may
>> fail
>>> because the backslash will be interpreted as an escape sequence if we
>> don't
>>> pay attention to escape the string before. Usually, the ones who write
>> code
>>> or scripts for Cygwin are more familiar with Unix than Windows and do
>> not
>>> think they have to pay attention to such things and may be disappointed.
>> I appreciate the difference between Windows and Unix paths.  I'm just
>> not sure whether your example above (/usr/local -> /usr\local) is an
>> example of a desired conversion or is an example of a conversion you
>> believe is wrong.
>>
> 
> It is a conversion I believe is wrong (I don't like getting backslashes in
> paths when I use Cygwin). 

Ok.