Re: MinGW compilation on Windows and proposed improvements

Matthew Fluet wrote:
> Yes, we've not distributed the target-specific packaging code in
> source distributions.

Ok... I would think that it would be a good idea, though,
since the packaging mechanism could change over time with
differing versions. Thus, if it is not distributed along with
each source version, it may end up being hard to dig out
the relevant version of the packaging directory.

> I found the files in my backups of the old mlton.org site.  I've
> uploaded them to:
>   http://www.mlton.org/misc/mingw/

Thanks a lot for this! It worked perfectly! :-)
It requires updating the links in the
package/mingw/dl/ directory. Just replace the prefix

http://mlton.org/pages/Experimental/attachments/

with

http://www.mlton.org/misc/mingw/

in all files. I would recommend just committing
this to the repository, since there is surely no
reason to keep broken links around.

Wesley W. Terpstra wrote:
 > I put these files in the wiki because the upstream tends to remove
 > them. You need specific versions of these tools that are 'known good'.
 > I had lots of problems where mingw gcc bugs broke the build.

Yes, I would also expect this :-)

 > Yes, all you should need to build the MLton installer is a FULL
 > install from the previous MLton installer and the WiX package from
 > Microsoft. Unfortunately, you need a specific version of WiX as well,
 > since they break compatibility all the time. I probably documented
 > which version is needed either in the build script or commit logs.

I wrote earlier that I had used candle-0.13-beta-win.zip,
but later in the process, there is also a command called
light missing and I used WiX Toolset 3.8 instead; the
file wix38-binaries.zip that can be downloaded here:
http://wix.codeplex.com/releases/view/115492

It seems that this might be an open source alternative
to Microsoft's? Anyway, I think this file also ought
to be hosted on http://www.mlton.org/misc/mingw/
to avoid possible problems with later versions.

 > I know you plan to modify the process handling code in MLton.
 > Be careful.
 >
 > I spent quite some time to find a balance which was as compatible with
 > *nix as possible while. If you change these things, make sure you
 > don't do it in a way that will break working programs.
 >
 > Keep also in mind that all the permissions you are attempting to
 > implement do not exist in Windows. If I recall correctly, the basis
 > specification allows us to simply omit those things a platform does
 > not have.

By now I have tested that chmod, fchmod and waitpid_nh all
work fine and don't need to be patched. This is great!
For MLton.Process, however, I still recommend my changes
of removing the last line calling reap in the kill function
and to add the getPid function. This will surely break some
working programs, but hopefully only programs that may
sometimes fail to successfully kill a process (typically
computationally intensive processes), and it might
be a good thing to break such programs ;-)
As argued earlier, calling reap in the kill function
has a different blocking behaviour than POSIX and
SML's Posix module, so I wouldn't consider this very
*nix like.

I also stated earlier that it would be enough to
keep killing a process, until waitpid_nh raises
an exception (due to the POSIX call returning -1),
but that's not even good enough, since this won't
happen if the process dies by itself or is killed
by someone else. The solution is to also consider the
process dead if waitpid_nh once returns the pid waited
for. Here is my application's kill function
that is fairly well tested by now:

fun iterKill (p, pid) =
       let
         val () = (MLton.Process.kill
                     (p, Posix.Signal.term)
                  ) handle _ => ()
         val () = (MLton.Process.kill
                     (p, Posix.Signal.int)
                  ) handle _ => ()

         (* Wait a bit before re-iterating or
            testing the kill (I use SDL's delay function
            here to wait 10ms, but you could use another
            function) *)
         val () = SDL.Delay 0w10
       in
         (case Posix.Process.waitpid_nh
                 (Posix.Process.W_CHILD pid, nil) of
            SOME (terminatedPid, exitStatus) =>
              if terminatedPid = pid then
                (* The child has terminated somehow *)
                ()
              else
                (* The child still lives *)
                iterKill (p, pid)
          | NONE =>
              (* The child still lives *)
              iterKill (p, pid)
         ) handle _ =>
             (* This means that the child with
                the given pid no longer lives *)
             ()
       end

(* p is the process returned from MLton.Process.create *)
val pid = MLton.Process.getPid p
val () = iterKill (p, pid)


Feel free to use this or get inspired by it or
even put it on the Wiki as an example.

 > I am sorry I haven't gotten to building a new MLton installer (or
 > debian/ubuntu package)!
 > Where I work now, I simply haven't used SML in the last two years,
 > whereas when I maintained those packages I was using it every day.

No worries; you did an excellent job in automating the process! :-)
Thanks a lot for this! :-)

I have a working installer of the patched 20100608 version now
and I will put the patch and the installer online soon, but
I want to release my own software using it first, so hopefully
you will have it approx. tomorrow. I will also try to
make two installers (a patched and a non-patched one) for
the 20130715 release and put those online as well, now that
I have the setup to make this.


Cheers,
Johnny
-- 
http://www.cex3d.net/inverse/ - 3D models from images automatically
http://www.hardcoreprocessing.com
http://www.anoq.net/music/ - creative instrumental electronic music

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk