Ruby Portable Runtime?

Hi all, it’s been a long time since I last posted here, pleased to see so
many bright people still hanging out :slight_smile:

The Pragmatic Programmer installation recently dumped Cygwin and supported
native Windows instead.
Which is a good thing IMHO.

Meanwhile I’ve on and off seen various attempts to create generic portable
runtime layers in C.

The last one I noticed was Apache Portable Runtime APR.

http://apr.apache.org/

Also, Appache has finally decided to ship on Windows in a decent 2.0 version
with reservations such as bad performance compared to Windows. They did work
a lot with getting thread synchronization work the same on Linux on Windows.

This makes me wonder, given

a) Web is becoming more and more the target platform
b) APR seems to be carefully and thoroughly developed.
c) mod_ruby / eruby seems to be maturing.

Would it make sense to base the Ruby runtime on APR in future versions? To
some extend Posix seems to have failed in the sense that it doesn’t work
properly on Windows.

I’m sure there are problems with APR in various areas, but they must have
done something right or?

While persuing this thought I also bumped into someone wanting to port the
OCaml runtime to APR (OCaml being my other favorite language), so I guess
I’m not the only one thinking of APR as a potential future OS cross platform
layer.

Mikkel

Hi,

···

In message “Ruby Portable Runtime?” on 02/07/31, “MikkelFJ” mikkelfj-anti-spam@bigfoot.com writes:

Would it make sense to base the Ruby runtime on APR in future versions? To
some extend Posix seems to have failed in the sense that it doesn’t work
properly on Windows.

Probably. It can reduce my burden.

But I’m not sure if APR (or mozilla’s NSPR or whatever) is reliable
enough in long term. Projects come and go. Languages has far longer
life span than other programs. It is little bit dangerous to rely on
other projects, even they are opensource.

						matz.

In article 3d4718f0$0$1565$edfadb0f@dspool01.news.tele.dk,

Hi all, it’s been a long time since I last posted here, pleased to see so
many bright people still hanging out :slight_smile:

The Pragmatic Programmer installation recently dumped Cygwin and supported
native Windows instead.
Which is a good thing IMHO.

Meanwhile I’ve on and off seen various attempts to create generic portable
runtime layers in C.

The last one I noticed was Apache Portable Runtime APR.

http://apr.apache.org/

Also, Appache has finally decided to ship on Windows in a decent 2.0 version
with reservations such as bad performance compared to Windows. They did work
a lot with getting thread synchronization work the same on Linux on Windows.

This makes me wonder, given

a) Web is becoming more and more the target platform
b) APR seems to be carefully and thoroughly developed.
c) mod_ruby / eruby seems to be maturing.

Would it make sense to base the Ruby runtime on APR in future versions? To
some extend Posix seems to have failed in the sense that it doesn’t work
properly on Windows.

I’m sure there are problems with APR in various areas, but they must have
done something right or?

Why is this any better than Cygwin? A software layer is a
software layer is a software layer. Putting one between you
and the OS is always a measure of last resort. If there was one
that truly worked, then you’d see a lot less projects
developing their own. The fact that every major project seems
to be developing it’s own runtime layer leads me to conclude
that they all suck in various ways.

Personally, I think the sane way is to focus on Posix and
implement workarounds when they are needed. But, I am
admittedly windows-phobic.

    • Booker C. Bense
···

MikkelFJ mikkelfj-anti-spam@bigfoot.com wrote:

Why is this any better than Cygwin? A software layer is a
software layer is a software layer. Putting one between you

Cygwin doesn’t work. It’s practically impossible to have to Cygwin dependent
applications running at the same time.
Furthermore Cygwin creates an artificial filesystem, which is good Unix
applications, but not a requirement for more enlightened applicatoins - for
example, the stdlib in C works fine on many platforms, it’s just too limited
to cover all OS aspects. Cygwin isn’t really what we need either. We need a
good common API not an API that try be that of another with limited success.
For example - no reason to have fork. Fork simply doesn’t make sense on
Windows and there is no reason to create processes using fork on Unix except
for backward compatibility.

and the OS is always a measure of last resort. If there was one
that truly worked, then you’d see a lot less projects
developing their own. The fact that every major project seems
to be developing it’s own runtime layer leads me to conclude
that they all suck in various ways.

No single library has been big enough to provide a stable platform. I was
figuring perhaps Apache might change this. Also because, as mentioned, more
and more development is towards the Web rather than towards a specific OS.

Personally, I think the sane way is to focus on Posix and
implement workarounds when they are needed. But, I am
admittedly windows-phobic.

I’d agree if it wasn’t for the practical perspective. It don’t understand
why MS deliberately avoids being Posix compatible (even after having been
Posix certified…). All they have gained is that all innovation has moved
to Unix / Linux. However, fact is that MS is non-posix and that I haven’t
seen a good Posix layer for Windows.
Anyway, as long as MS consistently avoids to achieve compatibility
developers have to struggle. Look at QNX to see how a definitely non-Unix OS
works quite well with the Posix interface.

Mikkel

MikkelFJ wrote:

I’d agree if it wasn’t for the practical perspective. It don’t understand
why MS deliberately avoids being Posix compatible (even after having been

Mikkel

MS feels that any friction between programs working well on both the Win
and Linux environments is to their advantage, because it causes more
customers to believe themselves captive. So they work to increase it.

···


– Charles Hixson
Gnu software that is free,
The best is yet to be.