[Link] Development of Ruby VMs

[Robert Klemme]

Hi,

I had heard of most of the mentioned projects once but is impressive
to see them all in a single list: it's longer than I would have
guessed!

http://www.igvita.com/2009/11/20/state-of-ruby-vms-ruby-renaissance/

Cheers

robert

 

[Jörg W Mittag]

I had heard of most of the mentioned projects once but is impressive
to see them all in a single list: it's longer than I would have
guessed!

http://www.igvita.com/2009/11/20/state-of-ruby-vms-ruby-renaissance/

There's a couple ones missing, actually. Overall, there have been
around 30 Ruby implementations to date. Although only half of them are
still being developed (for generous definitions of "half" and
"developed") and only three of them (MRI, JRuby, YARV) have ever
produced a production release. (And one could argue about whether an
implementation which doesn't even *run* its *own* testsuite, let alone
*pass* it, or one which leaks memory, can be called "production
ready".)

Among the ones that *are* still being developed and that are missing
from the list are:

* YARV (Koichi Sasada's custom VM for Ruby 1.9)
* XRuby (Ruby compiler for the JVM)
* SmallRuby (Ruby on Smalltalk/X)
* tinyrb (Marc-André Cournoyer's tiny Ruby-subset VM)
* HotRuby (YARV bytecode interpreter on Flash or ECMAScript)
* Cardinal (Ruby on Parrot)

Especially YARV seems to be a pretty big omission from the list.

A couple of the ones that are no longer being developed but are
nonetheless interesting are:

* the original IronRuby (yes, there are two implementations called
IronRuby; this one had experimental support for continuations,
which is something that JRuby, XRuby, Ruby.NET and the other
IronRuby don't have)
* Carbone (Ruby VM automatically generated by vmgen)
* IoRuby (Ruby on Io)
* MetaRuby (Ruby 100% in Ruby, using Ruby2C)
* Red Sun (YARV bytecode interpreter in ActionScript)

And of course Rite, the mythical Ruby implementation that Matz once
wanted to write one day, but never did.

jwm

 

[Iñaki Baz Castillo]

El Mi=C3=A9rcoles, 2 de Diciembre de 2009, J=C3=B6rg W Mittag escribi=C3=B3:

Among the ones that *are* still being developed and that are missing
from the list are:
=20
* YARV (Koichi Sasada's custom VM for Ruby 1.9)
* XRuby (Ruby compiler for the JVM)
* SmallRuby (Ruby on Smalltalk/X)
* tinyrb (Marc-Andr=C3=A9 Cournoyer's tiny Ruby-subset VM)
* HotRuby (YARV bytecode interpreter on Flash or ECMAScript)
* Cardinal (Ruby on Parrot)
=20
Especially YARV seems to be a pretty big omission from the list.

What about Rubinius?



=2D-=20
I=C3=B1aki Baz Castillo <[email protected]>

 

[Iñaki Baz Castillo]

El Mi=C3=A9rcoles, 2 de Diciembre de 2009, J=C3=B6rg W Mittag escribi=C3=B3:

* HotRuby (YARV bytecode interpreter on Flash or ECMAScript)

=46rom the project web (http://hotruby.yukoba.jp):

=2D---------------
Most of the grammars are implemented. However, exceptions are not implement=
ed.=20
Most of the build-in functions and build-in classes are not implemented.
=2D---------------

The idea is good, but obviously it's not mantained, neither enoguh advanced.


=2D-=20
I=C3=B1aki Baz Castillo <[email protected]>

 

[Jörg W Mittag]

El Miércoles, 2 de Diciembre de 2009, Jörg W Mittag escribió:

What about Rubinius?

That's already on Ilya's list.

jwm

 

[Eleanor McHugh]

Among the ones that *are* still being developed and that are missing
from the list are:
=20
* tinyrb (Marc-Andr=E9 Cournoyer's tiny Ruby-subset VM)

Hopefully this list will soon be joined by RubyGoLightly, my project to =
port TinyRb from C to Go and then see where that leads. Anyone =
interested in helping (or chucking stones) can find work in progress at:

http://github.com/feyeleanor/RubyGoLightly


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Jörg W Mittag]

Hopefully this list will soon be joined by RubyGoLightly, my project
to port TinyRb from C to Go and then see where that leads. Anyone
interested in helping (or chucking stones) can find work in
progress at:

http://github.com/feyeleanor/RubyGoLightly

This looks very cool!

Now, if only tinyrb worked on Windows, Go worked on Windows and I
could overcome my deep-seated hatred against so-called "systems
programming languages"[1] and actually bring myself to learning the
damn thing.

Anyway, regarding your "see where that leads", I have a couple of
questions:

* Are you planning to use Go's garbage collector or provide your own?
Currently, tinyrb uses the Boehm-Demers-Weiser conservative
garbage collector (AFAIK anyway), which incidentally is also the
collector used by one of the two Go implementations. Marc-André
was considering switching to reference counting, which
incidentally is also what the *other* Go implementation is
planning on doing.

* Are you simply using Go as an implementation language, like, say,
tinyrb, MRI, YARV or Rubinius do or are you planning some sort of
interoperability between Go and Ruby as JRuby and IronRuby do or
even a very deep unification of the two languages like MacRuby and
MagLev?

* Are you planning on implementing Threads with Goroutines? What about
Fibers, Continuations?

* Are you planning on surfacing the CSP/Pi-calculus style concurrency
of the Go runtime somehow in Ruby?

* Are you planning anything at all, or just having fun? (-:

jwm

[1] This hatred is rooted in two things:

1.) "Systems programming language" is commonly used as a
euphemism for "crappy programming language" in the sense
that "we know it's crap but it's okay, because it's a
systems programming language!". Ex.: C, C++, Java

2.) I strongly believe that systems programming languages should
not exist. Writing operating systems, garbage collectors,
compilers, interpreters, real-time systems, interrupt
handlers, databases, etc. *in* Lisp, Smalltalk, Python,
Haskell has been done for decades, as has writing fast
implementations *for* them.

 

[Eleanor McHugh]

Hopefully this list will soon be joined by RubyGoLightly, my project
to port TinyRb from C to Go and then see where that leads. Anyone
interested in helping (or chucking stones) can find work in
progress at:
=20
http://github.com/feyeleanor/RubyGoLightly

=20
This looks very cool!
=20
Now, if only tinyrb worked on Windows, Go worked on Windows and I
could overcome my deep-seated hatred against so-called "systems
programming languages"[1] and actually bring myself to learning the
damn thing.

Well I'm not holding my breath on Go making it to Windows anytime soon, =
but I hope I'm wrong.
I also share many of your feelings about "systems programming =
languages", compounded by the fact I spend a lot of time working on C =
codebases. Part of what I find appealing about Go is that it reads like =
a high-level language, that and the fact that it provides a decent =
native concurrency model.

Anyway, regarding your "see where that leads", I have a couple of
questions:
=20
* Are you planning to use Go's garbage collector or provide your own?=20=

Currently, tinyrb uses the Boehm-Demers-Weiser conservative=20
garbage collector (AFAIK anyway), which incidentally is also the=20
collector used by one of the two Go implementations. Marc-Andr=E9=20=

was considering switching to reference counting, which=20
incidentally is also what the *other* Go implementation is=20
planning on doing.

I'd like to phrase everything to leverage Go's garbage collection, the =
same way that JRuby uses the JVM's collector.

* Are you simply using Go as an implementation language, like, say,=20
tinyrb, MRI, YARV or Rubinius do or are you planning some sort of=20=

interoperability between Go and Ruby as JRuby and IronRuby do or=20
even a very deep unification of the two languages like MacRuby and=20=

MagLev?

As Go's still a bit of a moving target I'm initially looking at it as an =
implementation language, although supporting NaCl and other elements of =
Google's emerging software platform would be interesting.

* Are you planning on implementing Threads with Goroutines? What about=20=

Fibers, Continuations?

It'll use Goroutines for both Threads and Fibers, and I'm interested in =
using the Go Iterator pattern to implement Ruby Enumerators.

Continuations should also be feasible, although a lot depends on how the =
VM's instruction set evolves and the=20

* Are you planning on surfacing the CSP/Pi-calculus style concurrency=20=

of the Go runtime somehow in Ruby?

Whilst it'd be nice to have it's a very low priority - at least until =
there's a stable interpreter capable of passing all of TinyRb's tests.

* Are you planning anything at all, or just having fun? (-:

Well fun is a big part of it

However there's also a plan. Initially I want to get a codebase that =
compiles, makes reasonable use of Go's idioms, and passes TinyRb's =
tests. Once that milestone is hit I plan to experiment with the VM's =
instruction set and to start fleshing out the runtime, possibly with the =
intention of becoming a full-blown Ruby implementation (if there's a =
demand).

A high priority at that stage will be getting Ruby-FFI support so I can =
continue my low-level coding adventures


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net