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
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Robert Klemme wrote:
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!
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
What about Rubinius?
El Miércoles, 2 de Diciembre de 2009, Jörg W Mittag escribió:
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.
--
Iñaki Baz Castillo <ibc@aliax.net>
From the project web (http://hotruby.yukoba.jp):
El Miércoles, 2 de Diciembre de 2009, Jörg W Mittag escribió:
* HotRuby (YARV bytecode interpreter on Flash or ECMAScript)
----------------
Most of the grammars are implemented. However, exceptions are not implemented.
Most of the build-in functions and build-in classes are not implemented.
----------------
The idea is good, but obviously it's not mantained, neither enoguh advanced.
--
Iñaki Baz Castillo <ibc@aliax.net>
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:
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
On 2 Dec 2009, at 15:40, Jörg W Mittag wrote:
Among the ones that *are* still being developed and that are missing
from the list are:* tinyrb (Marc-André Cournoyer's tiny Ruby-subset VM)
----
raise ArgumentError unless @reality.responds_to? :reason
Iñaki Baz Castillo wrote:
El Miércoles, 2 de Diciembre de 2009, Jörg W Mittag escribió:
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.
What about Rubinius?
That's already on Ilya's list.
jwm
Eleanor McHugh wrote:
Among the ones that *are* still being developed and that are missing
from the list are:* tinyrb (Marc-André 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:
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.
On 2 Dec 2009, at 15:40, Jörg W Mittag wrote:
Eleanor McHugh wrote:
Among the ones that *are* still being developed and that are missing
from the list are:* tinyrb (Marc-André 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: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.
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:* 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.
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,
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?
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
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
* Are you planning on surfacing the CSP/Pi-calculus style concurrency
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
On 3 Dec 2009, at 11:30, Jörg W Mittag wrote:
On 2 Dec 2009, at 15:40, Jörg W Mittag wrote:
----
raise ArgumentError unless @reality.responds_to? :reason