lack of reaction to latest ruby implementations

[James F. Hranicky]

so just to check, people are actually interested
in a faster ruby right? interested in a ruby 2.0
which would not only be faster in the general case!,
but due to the those speed improvements, would also
have some of the features that in the past were
cast off due to possible speed problems?. a ruby
implementation in which RCR's can be implemented
at a whim and extra extensions added in an easy
to use ruby subset?

Yes! Keep going, and thanks!

 

[Alexander Kellett]

After a quick look at the PyGgy site,
http://www.lava.net/~newsham/pyggy/, it seems to be a parser generator
written in Python. In which case it might be better to use either Racc
or Rockit.

racc doesn't support glr therefore making the creation
of the parser much harder. rockit is well. nowhere to be found.
pyggy is very well designed. author responded quick to an email.
and i started a ruby grammar in it without really needing
to actually know *anything* about the process of creating a
grammar so it officially gets my thumbs up (compared to yacc)
anyways. the generated .rb files could be stored in cvs, or
pyggy/python made a dep. the most important part is that creation
of the grammar is trivial and thusly while getting to pure ruby
will take a while. it can be done incrementally rather than
going with a self developed thing and wasting yourselves several
weeks.

Though I'll look more closely to see if I'm missing something.

its easy to port

Well the problem was interfacing Parrot with the core lib. The first
solution we tried was using Parrot's native call interface to directly
acces rubylib, but that didn't work.

The next best solution seemed to be to produce a converter which could
translate the c code in to Parrot InterMediate Code. This project
didn't really get past the planning stage so I don't know how much
work it would be or if it would be a feasible goal.

seems *very* ambitious. possibly too ambitious...

Like Phil Thomson I haven't had time to focus on Cardinal for a while
now.

thats a shame to hear
wish ruby had more funding possibilities.

AFAIK the perl6 implementation is still in the early stages. They have
a working parser engine and are working on the perl 6 grammar.

I don't know how far along the the python implementation has gotten.

okay. so all in all slow progress. (parrot)
so. quick question. why parrot? why not ironruby for example?
mono is a hell of a lot more mature than parrot.
net 2.0 will be getting all the highly used
and needed language impl features that ruby has.

Alex

 

[Alexander Kellett]

we need the ruby core libs implemented in ruby (or in Parrot's
IMCC, we wanted to make it so that you could taraget either IMCC or
Ruby, for Cardinal we would first target IMCC).
Perhaps now the aim should be to support the subset of Ruby that Ruby2C
supports so we can go full circle (C -> Ruby -> (Ruby2C) -> C).

Being able to automate the C-> Ruby (or C->IMCC) process would be a big
boon for both Cardinal and metaruby (the ability to keep class
libraries up-to-date when changes/additions occur would a great help).
But again, it's a big task, perhaps a bit too ambitious.

personally if i were u and had made the outright
irreversible decision to use parrot, then i'd go
now for modding ruby2c to make a ruby2imcc. and
begin writing the stdlib. which is the major part
of cardinal i guess.

Alex

 

[gabriele renzi]

mark ha scritto:

AFAIK the perl6 implementation is still in the early stages. They have a
working parser engine and are working on the perl 6 grammar.

I don't know how far along the the python implementation has gotten.

the python frontend has had quite a lot of work lately, mostly since Sam
Ruby started hard hacking it, IIRC. Btw Ruby writing a python frontend
for a perl VM sounds too much funny

It even caused quite a bit of discussion related to language interop and
parrot support for python's features.

 

[Phil Tomson]

seems *very* ambitious. possibly too ambitious...
Possibly...


thats a shame to hear
wish ruby had more funding possibilities.

I'd love to get paid to work on Cardinal. But nobody's lining up
to pay me :-( (and I'm not holding my breath)

okay. so all in all slow progress. (parrot)
so. quick question. why parrot? why not ironruby for example?
mono is a hell of a lot more mature than parrot.
net 2.0 will be getting all the highly used
and needed language impl features that ruby has.

Well, I guess I can answer since I was the original instigator of Cardinal
about 2 years ago...

At that point Perl was still very ubiquitous... now it actually seems less
so... so we thought that everyone would have Parrot installed eventually.
also, Parrot would allow us to use the existing Perl libraries (CPAN)
which are quite extensive. And the Parrot VM promises to be quite a good
performer... Now with two years in the rearview mirror, perhaps some of
those reasons don't stand up as well:
* Perl seems to have lost a lot of popularity to PHP (and some to Ruby and
Python as well)
* We've built a lot of libraries in the RAA since then (though I'm told it
still isn't as extensive as the CPAN
* Perl 6 seems to still be elusive...

However, the Parrot VM still seems like a good target because of it's
performance.

As far as .net goes (or mono), well I guess I'm just not as interested in
that platform (or in supporting it).

Phil

 

[Phil Tomson]

mark ha scritto:


the python frontend has had quite a lot of work lately, mostly since Sam
Ruby started hard hacking it, IIRC. Btw Ruby writing a python frontend
for a perl VM sounds too much funny

You couldn't make that up...

Why hasn't that Sam Ruby guy converted to Ruby yet? I mean here we've
got a language with his same name tailor made for him ;-)


Phil

 

[Garance A Drosehn]

working on alternatives for the ruby runtime has
to be about the most difficult tasks one could take
on, and on top of that, the community interest doesn't
really help.

maybe its just me but i expected *many* more emails in
reply to the yarv and ruby2c releases!!!!!

I am fairly interested in ruby2c, but I haven't had time to look
into it. It doesn't help if you hide references to it under a
subject of 'lack of reaction to ruby implementations'. I'm on
enough busy mailing lists that I receive an average of 1000 emails
per day. If your subject is meaningless to me, then I never read
the discussion.

That said, I did see some other reference to ruby2c. I think that
might make ruby more attractive to use in the "base system" of some
operating system. But I'm wondering if it really turns the script
into plain C -- with no dependencies on a ruby interpretter. Or if
it is like some other "scripting-language to executable" things
which I have seen, which merely combine the entire interpretter,
support libraries, and the source-script into one extremely large
and ungainly mess which happens to be a single executable program.

 

[Ryan Davis]

That said, I did see some other reference to ruby2c. I think that
might make ruby more attractive to use in the "base system" of some
operating system. But I'm wondering if it really turns the script
into plain C -- with no dependencies on a ruby interpretter. Or if
it is like some other "scripting-language to executable" things
which I have seen, which merely combine the entire interpretter,
support libraries, and the source-script into one extremely large
and ungainly mess which happens to be a single executable program.

It turns a method (or bunch of methods) into "plain" C, for some
definition of plain. Currently it doesn't generate any C code that is
dependent on the interpreter, but that may change (or branch to do
both) in the future.

 

[Neil Stevens]

working on alternatives for the ruby runtime has
to be about the most difficult tasks one could take
on, and on top of that, the community interest doesn't
really help.

maybe its just me but i expected *many* more emails in
reply to the yarv and ruby2c releases!!!!!

Well, people with existing ruby code usually can't afford to drop to a
subset of the language, so that rules out ruby2c a lot of the time.

I hadn't heard of YARV before, and would love to try it, but having to run
a patched version of a development version of ruby rules that out, too.
The version of ruby linked to from the YARV page won't even build and
install correctly here: the ruby binary keeps ending up with the version
number of the ruby I already had installed, then the install rule
complains about the version-number mismatch.

So, I think it's too soon to look for feedback on these projects from
people interested in development with ruby, instead of development of ruby.

 

[gabriele renzi]

Neil Stevens ha scritto:

I hadn't heard of YARV before, and would love to try it, but having to run
a patched version of a development version of ruby rules that out, too.
The version of ruby linked to from the YARV page won't even build and
install correctly here: the ruby binary keeps ending up with the version
number of the ruby I already had installed, then the install rule
complains about the version-number mismatch.

I think you have some environment problem, it does build correctly for
me on both my win32 and linux boxes.
Or maybe, since that is just a cvs snapshot, you were unlucky by getting
a temporarily broken version

 

[Neil Stevens]

Neil Stevens ha scritto:


I think you have some environment problem, it does build correctly for
me on both my win32 and linux boxes.
Or maybe, since that is just a cvs snapshot, you were unlucky by getting
a temporarily broken version

Yeah, and that's why you can't expect users to mess with it yet!

 

[Ryan Davis]

Well, people with existing ruby code usually can't afford to drop to a
subset of the language, so that rules out ruby2c a lot of the time.

NOT TRUE!

There is zero reason for most people to compile their entire apps.
Bottlenecks are usually a 90/10 thing (or 99/01 really) and are often
very structured and algorithmic. There is usually very little reason
why those small snippets can't be rewritten to use a nice clean static
subset of ruby that can be translated to C.

As a trivial-but-real example, I point you to the second from the last
slide in http://www.zenspider.com/~ryand/Ruby2C.pdf

 

[Neil Stevens]

There is zero reason for most people to compile their entire apps.
Bottlenecks are usually a 90/10 thing (or 99/01 really) and are often
very structured and algorithmic. There is usually very little reason
why those small snippets can't be rewritten to use a nice clean static
subset of ruby that can be translated to C.

As a trivial-but-real example, I point you to the second from the last
slide in http://www.zenspider.com/~ryand/Ruby2C.pdf

OK, that's interesting, and it's NOT how I've seen ruby2c described and
presented before. Show me an incomplete ruby compiler, and I won't give
it a second thought. Show me a tool to optimize bottlenecks, and I'll be
very interested.

Put this way, ruby2c really shouldn't be lumped together with YARV. That
doesn't do justice to ruby2c's power.

 

[Eric Hodel]

--Apple-Mail-53-473485141
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

OK, that's interesting, and it's NOT how I've seen ruby2c described and
presented before. Show me an incomplete ruby compiler, and I won't
give
it a second thought. Show me a tool to optimize bottlenecks, and I'll
be
very interested.

The former is the reason we made the tool, but the latter is a
side-benefit everybody gets from our work.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-53-473485141
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCBRaIMypVHHlsnwQRAoAlAJ9JuBSaHGso+chOP+KYxV+7Q7fUuQCdEJka
NX2vr3Ot1vIKiSvnePDg26A=
=kDZG
-----END PGP SIGNATURE-----

--Apple-Mail-53-473485141--

 

[Navindra Umanee]

As a trivial-but-real example, I point you to the second from the last
slide in http://www.zenspider.com/~ryand/Ruby2C.pdf

This is actually very interesting. I understand that the code is
being translated to C with RubyToC.translate, but where/when is the
compilation happening?

I notice that you do "c src" in your optimize method. Does this
invoke GCC or something? It's building a C module? Does this happen
at load time?

Cheers,
Navin.

 

[Alexander Kellett]

The former is the reason we made the tool, but the latter is a
side-benefit everybody gets from our work.

which i'll (as a "competitor") am also hoping to reuse.

ruby2c rocks

Alex