Didn't know this:
http://www.parrotcode.org/news/2006/Parrot-0.4.6.html
----------------------------------------------------------------------
Jim Hranicky, Senior SysAdmin UF/CISE Department |
E314D CSE Building Phone (352) 392-1499 |
jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
In article <200608111059.27179.jfh@cise.ufl.edu>,
Didn't know this:
Several years ago (was it '02?) when I first proposed Cardinal and opened
up a project, it became apparent that Parrot was very much a moving target
and thus it seemed like it could be a waste of time to put much effort
into Cardinal. A couple of years ago it was reborn for a time due to the
efforts of Mark Sparshatt. But even then Parrot still proved to be too
much of a moving target so not much happened (you can see the fruits of
that effort here: http://rubyforge.org/projects/cardinal/ ).
More recently the Parrot folks have come up with lots of nice tools to
help you write a front end and integrate it with Parrot. I hadn't kept up
with recent Parrot developments so I wasn't aware of these tools.
Kevin Tew contacted me and asked if he could use the 'Cardinal' name and
I told him that would be fine. So hopefully this time we'll actually
see Cardinal become something useful.
Phil
James F. Hranicky <jfh@cise.ufl.edu> wrote:
James F. Hranicky wrote:
Didn't know this:
It's not dead, it's just pining for the inodes.
Actually I'm more interested in Ruby on .NET
these days... but more power to anyone who wants
to put Ruby on a VM.
And I guess Parrot will be good for interop between
Perl, Python, and Ruby.
Hal
Interop between different dynamic languages was one thing that we
spent some time talking about at the recent Ruby + .NET summit (Wilco
Bauwer of IronRuby, myself, and John Gough of Ruby.NET) along with Jim
Hugunin of IronPython and Paul Vick of VB.
While there are lots of nasty corner cases in doing interop with a
statically typed VM like the CLR, I think there are even more nasty
corner cases in doing interop across dynamic languages. One thing that
we would really like to come up with is some kind of a spec along the
lines of the CLS (Common Language Specification) for statically typed
languages. That is, if you want interop across dynamic language
libraries (e.g. consuming Python code in Ruby) that there is a certain
minimum set of features that your libraries will use *and restrict
themselves to using* if they want to play nicely with others.
But one thing at a time - I think that it's important to get interop
with the static libraries working well to start with. And with
features like generics, it just makes my life a living hell 
-John
On 8/11/06, Hal Fulton <hal9000@hypermetrics.com> wrote:
Actually I'm more interested in Ruby on .NET
these days... but more power to anyone who wants
to put Ruby on a VM.And I guess Parrot will be good for interop between
Perl, Python, and Ruby.Hal
Hal Fulton wrote:
James F. Hranicky wrote:
Didn't know this:
It's not dead, it's just pining for the inodes.
Actually I'm more interested in Ruby on .NET
these days... but more power to anyone who wants
to put Ruby on a VM.And I guess Parrot will be good for interop between
Perl, Python, and Ruby.Hal
Wait a minute -- the whole *point* is that the parrot is dead, isn't it?