[MLton] A few patches we had to apply to port
from version 20030716 to 20051202 and for the MinGW port
fluet at tti-c.org
Mon Apr 2 10:06:26 PDT 2007
>>>>> - 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.
>>>>> - 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
>>>>> - bug-fix-nethostdb-mingw.patch
>> There are different trade-offs.
>> In basis-library/net/net-host-db.sml, you could include code like the
>> structure Prim =
>> open Prim
>> val (getByAddress, getByName, getHostName) =
>> (if let open Primitive.MLton.OS in host = MinGW end
>> then Net.init ()
>> else ()
>> ; (getByAddress, getByName, getHostName))
>> 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
>>> because the backslash will be interpreted as an escape sequence if we
>>> pay attention to escape the string before. Usually, the ones who write
>>> or scripts for Cygwin are more familiar with Unix than Windows and do
>>> 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).
More information about the MLton