[MLton] Cygwin->Mingw32: patch + future

[Wesley W. Terpstra]

On Tue, Nov 23, 2004 at 11:26:11AM -0800, Stephen Weeks wrote:
> > that's never going to be possible to achieve portably. 
> 
> I'm not sure what problem you're referring to.  We haven't had any
> problems getting a contiguous chunk on our various platforms (except
> that Cygwin's mmap doesn't give as much as it could).

Not all machines have the ability to do virtual addressing.
Many embedded devices don't for example.

However, I personally am not interested in cygwin or embedded devices, 
so I defer fixing these things to people who care. =)

> > What sort of problems does this cause? [cygwin+mmap]

I still would like to know the answer to this.
It seemed to work as reliably as linux for me.

The platform where I used cygwin+mmap+fork was:
    AMD Athlon64 + 512MB RAM
    Windows XP German SP1
    cygwin-1.5.12-1
    w32api-3.1-1

Does it just run out of memory and die, or what?

I would think fork() is more important than the ability to address huge
amounts of memory. Which do more programs use?

> > I see random segfaults of the mlton compiler under cygwin, but I had those
> > with the VirtualAlloc version too. I haven't spent time tracking it yet.
> 
> I haven't seen those and would be interested to track them down too,
> at least until we find it's YACB (yet another Cygwin bug).

It happened to me today under linux as well.

I believe it is my machine. I tried rebuilding repeatedly on another
computer and had no problems. It is sporadic, so I suspect RAM.
memtest86 doesn't complain though. hrm.

> > It might make sense to want to open a pipe as WideTextIO, BinIO, and
> > TextIO all at once and read things from one then the other. If the
> > buffering is shared like we discussed earlier, this is well-defined.
> 
> I had this thought as well.  I agree that we're not clear on what
> properties we would like of the extracted streams and that Unix.*
> doesn't do it very well. 
>
> Given that, why don't we drop the streams entirely, and go to a pure
> file-descriptor approach?

That seems a bit overkill to me.

There's certainly no harm in providing the ability to access the streams and
file descriptors at once. The constraint on only opening it one way is
probably at the very least a good stylistic guideline. Since you can get the
file descriptor (possibly with a future loss in portability) you could still
open it multiple ways yourself.

> I have somewhere on my todo list to hack mailman to put our header and
> search box at the top of each page. In general, it is preferable to have a
> single integrated search for a whole site than to have a scoped search
> that restricts only to a portion of the site.

That's a good point.
However, your solution still won't address the other short-comings of that
archiver: no attachments, poor threading, ...

> Anyways, I'm not opposed to a more powerful mail archiver/searcher,
> I'm just not convinced of its benefits. Lurker looks nice. If you're
> willing to set it up, I'd be happy to make available all our old mail
> and subscribe lurker to the lists, so people can try it out.

I don't have a non-{work,debian} server to host MLton lists on.
I would happy to set it up if you have such a machine.

-- 
Wesley W. Terpstra