A true Ruby compiler (for Linux)

[Philip Rhoades]

People,

I have found RubyScript2Exe but that is not a real compiler. Ruby is
such an nice OO language to develop in - why isn't there a demand to
compile a finished script? - then you get the benefits of fast
development times as well as fast run times.

Thanks,

Phil.
--
Philip Rhoades

Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275)
GPO Box 3411
Sydney NSW 2001
Australia
Mobile: +610)411-185-652
Fax: +610)2-8221-9599
E-mail: (e-mail address removed)

 

[Devin Mullins]

Ruby is
such an nice OO language to develop in - why isn't there a demand to
compile a finished script?

I think you're confusing demand and supply.

Devin

 

[Jörg W Mittag]

I have found RubyScript2Exe but that is not a real compiler. Ruby is
such an nice OO language to develop in - why isn't there a demand to
compile a finished script? - then you get the benefits of fast
development times as well as fast run times.

XRuby is a Ruby compiler that compiles Ruby to Java Bytecode. You can
run Java Bytecode on Linux, so, technically speaking, XRuby is a Ruby
compiler for Linux. There are also various compilers out there that
compile Java Bytecode to native objectcode (e.g. GCJ), allowing you to
produce native objectode from Ruby sourcecode with an extra step.

Ruby.NET is a Ruby compiler that compiles Ruby to CIL Bytecode. You
can run CIL Bytecode on Linux, so, technically speaking, Ruby.NET is a
Ruby compiler for Linux. I think that there are also various
compilers out there that compile CIL Bytecode to native objectcode,
allowing you to produce native objectode from Ruby sourcecode with an
extra step.

jwm

 

[Wilson Bilkovich]

XRuby is a Ruby compiler that compiles Ruby to Java Bytecode. You can
run Java Bytecode on Linux, so, technically speaking, XRuby is a Ruby
compiler for Linux. There are also various compilers out there that
compile Java Bytecode to native objectcode (e.g. GCJ), allowing you to
produce native objectode from Ruby sourcecode with an extra step.

Ruby.NET is a Ruby compiler that compiles Ruby to CIL Bytecode. You
can run CIL Bytecode on Linux, so, technically speaking, Ruby.NET is a
Ruby compiler for Linux. I think that there are also various
compilers out there that compile CIL Bytecode to native objectcode,
allowing you to produce native objectode from Ruby sourcecode with an
extra step.

Rubinius also has this feature (saving portable, intermediate bytecode
for later execution). Not ready for production use yet, but it's
moving very quickly. Bignums, Regexp, and continuations went in this
week. Also, the development is validated with valgrind, which makes me
happy.

 

[Jörg W Mittag]

Rubinius also has this feature (saving portable, intermediate bytecode
for later execution). Not ready for production use yet, but it's
moving very quickly. Bignums, Regexp, and continuations went in this
week. Also, the development is validated with valgrind, which makes me
happy.

Great! I didn't know that.

IIRC, IronRuby, JRuby and YARV will eventually grow a compiler, too.

jwm

 

[pat eyler]

I wonder how much traction XRuby will ever be able to get now that JRuby = is
a Sun sponsored project. Maybe the XRuby guy should touch base with the
JRuby team about combining the two in some way or another.

The groups are talking about things, as are many of the other active ruby
implementation projects.

Though given the name XRuby, maybe the guy's overall goal is to build a
compiler that can compile Ruby into any number of bytecodes.

Either way, I like seeing this work. It means that we'll eventually be ab= le
to shut up those 'Ruby is too slow' naysayers.

Jason

--=20
thanks,
-pate

 

[David Vallner]

--------------enigD8A7F644580E46044AE20D27
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Either way, I like seeing this work. It means that we'll eventually be = able
to shut up those 'Ruby is too slow' naysayers.
=20

A significant part of the slowness comes from the computation model. So,
no, it probably won't, even the resulting bytecodes will have to go
through significant epicycles to preserve the runtime dynamism. It will
help, but won't bring it on par to a language with a more strict
computational model, at least not at first. (There's apparently some
deep voodoo implemented in some of the academic Smalltalk VMs and other
exploratory programming language runtimes that can be applied to narrow
the gap even more.)

David Vallner


--------------enigD8A7F644580E46044AE20D27
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFdd9ty6MhrS8astoRAiT2AJ91ruNvyt2cp92kBlGMqG+CR5t+yQCcDrqi
2NmJSA8vEJ4ECxDaNz5sV8w=
=ESIT
-----END PGP SIGNATURE-----

--------------enigD8A7F644580E46044AE20D27--