Ruby -> python

Ruby
1

I was thinking the other day…wouldn’t it be nice to be able to take
advantage of some python capabilities from within Ruby, like psyco, for
example?

i.e.
any “bottleneck” inner loops can be converted to Python, run by an
optimized psyco compiled Python, and come back out to a familiar Ruby
environment.

Does anyone know if such a project exists? Any feedback on the idea
itself?
I’d imagine that most Ruby constructs have their Python equivalent.

Thanks!
-=r

2

Roger P. wrote:

itself?
I’d imagine that most Ruby constructs have their Python equivalent.

Why introduce Python, when on many platforms, you have the ability to
use inline C, C++ or assembler? IIRC it works on Cygwin, all *Nix
platforms and probably MacOS X as well.

Thanks!
-=r

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§, WOM

I’ve never met a happy clam. In fact, most of them were pretty steamed.

3

On Dec 26, 11:11 pm, Roger P. [email protected] wrote:

shouldn’t be as hard to write as, say, a ruby to c JIT translator [psyco
is a Python->bytecode JIT translator, so the work has been done there].

Obviously a translator to C would be the best, I just think it would be
pretty hard, and if one could translate to Python, a lot of the
optimization exists. A fit of python envy, you could call it.
Thoughts?
-=r

What about _why experiments on Ruby to Python front (only YARV):

http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppEngine.html

I know, is silly, but is bytecode translated :wink:

Another option is look at ParseTree for the AST and generate C code
from it (ruby2c)

4

I’d imagine that most Ruby constructs have their Python equivalent.

Why introduce Python, when on many platforms, you have the ability to
use inline C, C++ or assembler? IIRC it works on Cygwin, all *Nix
platforms and probably MacOS X as well.

Because I don’t want to rewrite my bottlenecks to C–I want to leave
them as ruby and have them “automagically translated”

Main advantage: Python and Ruby are pretty similar, so a translator
shouldn’t be as hard to write as, say, a ruby to c JIT translator [psyco
is a Python->bytecode JIT translator, so the work has been done there].

Obviously a translator to C would be the best, I just think it would be
pretty hard, and if one could translate to Python, a lot of the
optimization exists. A fit of python envy, you could call it.
Thoughts?
-=r

5

Luis L. wrote:

On Dec 26, 11:11�pm, Roger P. [email protected] wrote:

shouldn’t be as hard to write as, say, a ruby to c JIT translator [psyco
is a Python->bytecode JIT translator, so the work has been done there].

Obviously a translator to C would be the best, I just think it would be
pretty �hard, and if one could translate to Python, a lot of the
optimization exists. A fit of python envy, you could call it.
Thoughts?
-=r

What about _why experiments on Ruby to Python front (only YARV):

http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppEngine.html

I know, is silly, but is bytecode translated :wink:

Unholy is definitely fascinating. I’m unsure of it’s ability to
transfer say a whole class directly into Python :slight_smile: [
Here’s a funny quote from _why:

“Instead of asking “can unholy run Rails?” try asking “can unholy run 4
plus 7?” And my answer to that is: no, no, no, no, it probably can’t!!”

Another option is look at ParseTree for the AST and generate C code
from it (ruby2c)

Yeah I would totally prefer a straight ruby2c conversion but unless you
create a run-time class analyzer and rewrite each method depending on
the parameters’ classes, it will end up being about the same speed as
ludicrous [which is fast, but not significantly faster than 1.9,
so…not screaming improvement]. So what you really need is a run-time
optimizer, and it seems to me that translating to Python and using psyco
is easier than (re)creating a psyco for Ruby. That sounds hard.
Thoughts?

-=r

6

On Sat, Dec 27, 2008 at 02:59:50PM +0900, Roger P. wrote:

Yeah I would totally prefer a straight ruby2c conversion but unless you
create a run-time class analyzer and rewrite each method depending on
the parameters’ classes, it will end up being about the same speed as
ludicrous [which is fast, but not significantly faster than 1.9,
so…not screaming improvement]. So what you really need is a run-time
optimizer, and it seems to me that translating to Python and using psyco
is easier than (re)creating a psyco for Ruby. That sounds hard.
Thoughts?

I think that, in the long run, it would be nice to have ruco (or
whatever
the Ruby equivalent of psyco would be called) anyway – so, if you’re
going to go to the effort of writing code intended to lead to runtime
optimization, you might want to consider just doing it “right” in the
first place.

On the other hand, I can see potential benefits of having a (preferably
two-way) translator between Ruby and Python for a lot of common-case
code, regardless of whether it ever gets used for Ruby psyco support.
As
such, again, if you’re intent on doing it that way I’d say get involved
in a Ruby-Python/Python-Ruby “compiler” and do that right, then
eventually use it as the basis for psyco runtime optimization of Ruby
code if nobody has gotten around to writing ruco-or-whatever by then.

Of course, I’m not really sold on the idea that automating translation
between Ruby and Python (especially the Ruby->Python part) would be
notably easier than compiling Ruby to C. Ruby has capabilities that the
Python core developers deliberately eschew, after all, because of the
whole “the way we do it is the right way” design aesthetic in Python
circles. If you start opening core classes, metaprogramming, or working
with complex callbacks (or, God forbid, actual lexical closures) in your
Ruby, I think your Ruby->Python translator is going to start puking
blood
all over your ultra-high thread count sheets and simultaneously soil its
britches.

I suppose I could be mistaken, though. I don’t actually know much about
Ruby and Python internals.

Note: My signature block is selected randomly by a script I wrote (in
Ruby, natch) many moons ago. I did not select it specifically to
illustrate any points about the subject at hand. My “random” signature
script, on the other hand, very well might have selected it to make a
point, for all I know.

7

On Tue, Dec 30, 2008 at 7:39 AM, Chad P. [email protected]
wrote:

Note: My signature block is selected randomly by a script I wrote (in
Ruby, natch) many moons ago. I did not select it specifically to
illustrate any points about the subject at hand. My “random” signature
script, on the other hand, very well might have selected it to make a
point, for all I know.
What amazes me most however is that it picked your name correctly :wink:
Was this one of the Ruby Q. solutions ?
Cheers
R.

–
Chad P. [ content licensed OWL: http://owl.apotheon.org ]
Common Reformulation of Greenspun’s Tenth Rule: Any sufficiently
complicated non-Lisp program contains an ad hoc informally-specified
bug-ridden slow implementation of half of Common Lisp.

–
Il computer non è una macchina intelligente che aiuta le persone
stupide, anzi, è una macchina stupida che funziona solo nelle mani
delle persone intelligenti.
Computers are not smart to help stupid people, rather they are stupid
and will work only if taken care of by smart people.

Umberto Eco

8

I think that, in the long run, it would be nice to have ruco (or
whatever
the Ruby equivalent of psyco would be called) anyway – so, if you’re
going to go to the effort of writing code intended to lead to runtime
optimization, you might want to consider just doing it “right” in the
first place.

Yeah–I’m looking for the easiest path here–like from the outside it
seems like a “ruco” project is two-fold: one get a working JIT
compilation working [arguably non-trivial] and then get it to work with
different parameters. Whereas “rupy” seems like one step.

Psyco itself has a large download from what appears to be “lots of lines
of code”[1], which made me think that “ruco” is hard and “rupy” might be
simpler. At least I can write rupy in Ruby theoretically, which seems
faster and easier than C.

On the other hand, I can see potential benefits of having a (preferably
two-way) translator between Ruby and Python for a lot of common-case
code, regardless of whether it ever gets used for Ruby psyco support.
What would the benefits be?

I suppose that being able to convert to Python might help with the
google app engine or what not.

As
such, again, if you’re intent on doing it that way I’d say get involved
in a Ruby-Python/Python-Ruby “compiler” and do that right, then
eventually use it as the basis for psyco runtime optimization of Ruby
code if nobody has gotten around to writing ruco-or-whatever by then.

By compiler you mean it translates a .rb file to a .py one? [or like
unholy bytecode → bytecode]?

Of course, I’m not really sold on the idea that automating translation
between Ruby and Python (especially the Ruby->Python part) would be
notably easier than compiling Ruby to C. Ruby has capabilities that the
Python core developers deliberately eschew, after all, because of the
whole “the way we do it is the right way” design aesthetic in Python
circles. If you start opening core classes, metaprogramming, or working

No joke. Just the thought of having to use len(instance) instead of
string_instance.length makes me cringe LOL.

My hope was that Python and Ruby would be similar enough to make it
easy. In which I’m probably sadly mistaken but…it might still be an
interesting project. I think I may well end up just living with 1.9’s
[slightly improved] speed :slight_smile:

Thoughts?

-=r
[1] http://codespeak.net/svn/psyco/dist/c/

Psyco v. 1.9 speeds:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=psyco&lang2=yarv