Porting Ruby: 1.8 or 1.9?

Ruby
1

I’ve got a consulting gig at the moment, working on Stratus
fault-tolerant
servers, and I don’t have much excuse to play with Ruby. So I thought
“Wouldn’t it be fun to try porting Ruby to Stratus?”

(Stratus servers - I can’t really call them “minicomputers” anymore -
run a
proprietary operating system called VOS. It’s written by some of the
same
people who wrote Multics, and shares many of its features. Two decades
ago, there wasn’t even a C compiler available. In recent years, they’ve
made some large strides toward portability, switching to a Xeon-based
platform, with POSIX.1 compliance built in, and gcc, perl5, SAMBA, and
other mainstays available.)

This would really be a just-for-fun project, for some strange values of
“fun”. The VOS community is tiny and shrinking, and the types of
businesses
still running VOS are not likely to adopt Ruby - last I heard, the
biggest
codebases were in COBOL and PL/I in that order. Even Stratus’s own
marketing materials talk about “staying on the VOS platform if you
choose
to do so” and migrating off it “as painlessly as possible”. It’s far
from
obsolete, but neither is it the future.

So, in all likelihood, the port wouldn’t be used. I just wanna see if I
can build it at all, and keep Ruby on my mind. Disabling wide swaths of
functionality isn’t a big deal (e.g. threads).

Can anbody recommend which tree - 1.8 or 1.9 - is easier to port to
oddball
systems? Anyone done that lately? I seem to remember hearing about
Ruby
running on a phone.

2

Jay L. wrote:

other mainstays available.)
can build it at all, and keep Ruby on my mind. Disabling wide swaths of
functionality isn’t a big deal (e.g. threads).

Can anbody recommend which tree - 1.8 or 1.9 - is easier to port to oddball
systems? Anyone done that lately? I seem to remember hearing about Ruby
running on a phone.

Well, if you’ve got GCC, either one should be “easily ported”. But 1.8
has threads and a scheduler built into the language, while 1.9 has to
have native OS threads available. So if you want threads, go with 1.8.

Then again, if it’s all about fun, why not write a Ruby 1.9 interpreter
from scratch in PL/I?

3

On Sun, 11 Nov 2007 19:45:02 -0500, M. Edward (Ed) Borasky wrote:

Well, if you’ve got GCC, either one should be “easily ported”. But 1.8
has threads and a scheduler built into the language, while 1.9 has to
have native OS threads available. So if you want threads, go with 1.8.

Ah, interesting. Does 1.9 have to have native threads just to run? Or
only if you want to use threads from the application?

Actually, threads were probably a bad example, since (unless there are
some
oddities in VOS’s POSIX pthread implementation) I imagine they’ll work
OK.

I was more wondering if, say, 1.9 used a more modern autoconf, or
anything
like that. One of the hardest things about porting apps to VOS is
apparently the autoconf scripts; they generally either (a) don’t have
the
notion of an “executable” suffix (a la .EXE), or (b) they do, but they
don’t use it consistently - e.g. it works for native Windows but not for
the whole POSIX build path.

When I tried to see if 1.8.6 would “just build”, that was the first
thing I
ran into; VOS executables end in .pm, but Ruby’s autoconf script ignores
that for all the various tests it runs once it finds gcc. (Worse, shell
scripts like autoconf are the single slowest thing you can run in VOS;
“fork” really creates a whole new login process, which takes about half
a
second, so just getting through a configure script can take an hour or
more.)

Also, if Ruby assumes that x86 = little-endian, I’ve got some work to
do.

Then again, if it’s all about fun, why not write a Ruby 1.9 interpreter
from scratch in PL/I?

My cardiologist tells me that I should try not to have too much fun at
one time.

4

On Sun, 11 Nov 2007 19:03:08 -0500, Jay L. wrote:

Can anbody recommend which tree - 1.8 or 1.9 - is easier to port to oddball
systems? Anyone done that lately? I seem to remember hearing about Ruby
running on a phone.

Answer my own question and give a tip to Googlers: For the moment,
anyway,
Ruby 1.9 requires Ruby to build itself. So that’d be a bad idea.