[MLton] cygwoes
Matthew Fluet
fluet@cs.cornell.edu
Wed, 5 Oct 2005 10:07:12 -0400 (EDT)
>> Somehow, my path has been changed to lowercase (it should be
>> mlton.svn.HEAD, not mlton.svn.head). I renamed my path to the lowercase
>> version, hoping to avoid that issue.
>
> Uhm. Aren't windows filenames case insensitive?
> It is getting converted to lower-case because our implementation of
> OS.Path lower-cases everything in compliance with the standard....
>
> "
> In a Microsoft Windows implementation, canonical paths are entirely
> lowercase.
> "
>
> Or is it the case that *cygwin* somehow makes things case dependent?
Cygwin has an environment variable option that affects case-sensitivity.
When it is active, it does not allow you to "pun" and access a file along
a path that differs in case; though, it still prevents you from creating a
file with the same name, but different case.
I note that this Cygwin option has been deprecated since I added it to my
Cygwin startup; perhaps it's behavior has changed behind the scenes.
> Also, your path "/home\fluet\mlton\mlton.svn.head\build\lib/target-map"
> looks broken to me. The first "/" is ok; it is a cygwin specific hack to
> get access to the virtual (fake) filesystem root. However, the last '/'
> should be a '\'. Why isn't it?
The last separator is '/' and not '\' because mlton/main/main.fun:72
constructs the path via
concat [!Control.libDir, "/target-map"]
and the path is never canonicalized before being opened.
> From what (little) I understand of cygwin, I think this is due to the
> fork/exec code. However, do we know which code-path is being used?
> fork/exec or spawnp?
It should be spawnp, since fork/exec is disabled when we use
Virtual{Alloc,Free} instead of {mmap,free}.
> What was the original reason for avoiding mmap? Does it still apply?
We originally avoided mmap and fork because of Cygwin bugs.
http://mlton.org/RunningOnCygwin
Newer versions of Cygwin seem to have fixed that buggy interaction (hence,
the @MLton use-mmap -- runtime option seems to work now), but possibly
at the expense of bugging the Virtual{Alloc,Free} code.