From: Eli Green <eli.green@...>
Date: 2001-10-03T08:06:13+09:00
Subject: [ruby-talk:21959] Flogging a live Window

Ok, I wanted to get away from the theory and conjecture thread of the
make-ruby-better-under-Windows topic and see if I can't try and make some
sense out of the problem. I have at my disposal a fair number of Windows
environments, with a good selection of compilers (Visual C++, Watcom, LCC,
mingw, cygwin, the weird version of gcc that comes with WebObjects).

Given that (and let's be honest, I'm a Windows ignoramus), I'd like to lend a
hand with the whole affair. But I have yet to see any specific problems or
limitations of ruby under win32. Sooo, the question remains: what needs
fixing? I know I have a couple of goals in mind... like being able to run
through rubicon flawlessly, but .. baby steps, baby steps. :)

So:

1. What parts are slow?
2. What parts are unreliable? (I think networking is the big ticket item here)
3. What parts require Cygwin? (popen?, fork?)

You may have noticed that I was singing the APR tune a few messages back
there. While I still think it'd be a great idea, it seems like Matz wants to
go smaller and smaller, not bigger. APR certainly wouldn't help shrink the
interpreter any.

The point has been made that this stuff works in Perl, Python, PHP, etc... so
there's no reason we can't pull inspiration from those camps, even if we do
seem to be lacking in a certain amount of Windows expertise.

As an aside, does anybody have any idea what ruby's chances are of surviving
being multi-threaded? I mean native threads. If the interpreter itself is
thread-safe (which it likely won't be, unless that was a design goal all
along), we should be able to write external native thread modules. No?