Are there any?
my dictionary does not know the word "transpile"
what do you what?
evaluating ruby code inside an C Program or porting c-structs or c++
classes into ruby objects?
both is possible
···
--
Posted via http://www.ruby-forum.com/.
translating an ruby program into an c program is not as simple possible
because of ducktyping and dynamic stuff like including and extending
objects ans classes
c or c++ chould not handle that as simple
···
--
Posted via http://www.ruby-forum.com/.
Thomas Sawyer wrote in post #1013086:
Are there any?
Translators I know of are ruby2c and ruby2cext:
https://rubyforge.org/projects/ruby2c/
https://rubyforge.org/projects/ruby2cext/
Never tried the later.
Hans Mackowiak wrote in post #1013095:
my dictionary does not know the word "transpile"
what do you what?
I wondered as well. To me it sounds like "read a Ruby program and
output a pile of C code" where "pile" doesn't necessarily need to be a
complete program. 
evaluating ruby code inside an C Program or porting c-structs or c++
classes into ruby objects?
Or translate a Ruby program into a C program?
Kind regards
robert
···
--
Posted via http://www.ruby-forum.com/\.
Hans Mackowiak wrote in post #1013101:
translating an ruby program into an c program is not as simple possible
because of ducktyping and dynamic stuff like including and extending
objects ans classes
Performance gains would probably be marginal - unless all the dynamic
features were omitted.
c or c++ chould not handle that as simple
Nobody talked about "simple" though.
Btw, this is exactly what was asked:
Cheers
robert
···
--
Posted via http://www.ruby-forum.com/\.
Hmm
It would seem to assume that the source is a subset to the target
language. Which would explain Pascal to C but the unlikeliness of C to
Pascal.
So perhaps Ruby to Scheme which could then be compiled with the Gambit
Scheme compiler.
Not sure what the upside would be other than the bragging rights 
Hans Mackowiak wrote in post #1013101:
translating an ruby program into an c program is not as simple possible
because of ducktyping and dynamic stuff like including and extending
objects ans classesPerformance gains would probably be marginal - unless all the dynamic
features were omitted.
For type-inferred code we saw ~12x improvements. For straight translations w/ fully dynamic ruby we saw marginal performance losses because we couldn't cheat the way the interpreter does (eg regexp match nodes dispatched directly where we had to use rb_funcall or we couldn't take advantage of COW string hacks).
I demonstrated this in my rubyconf 2005 talk. I don't think any video of it exists.
c or c++ chould not handle that as simple
Nobody talked about "simple" though.
Translating was a lot less tough than I thought it would be (compared to, say, the parsing of ruby).
···
On Jul 26, 2011, at 07:11 , Robert Klemme wrote:
Well, both Pascal and C are Turing complete - so conversion in either
direction is possible. Of course, if you look to the small details
needed for driver implementations such as direct memory access a
standard Pascal will have a hard time doing all C's tricks. But this
is basically just a question of the standard library provided.
Kind regards
robert
···
On Tue, Jul 26, 2011 at 5:37 PM, Peter Hickman <peterhickman386@googlemail.com> wrote:
It would seem to assume that the source is a subset to the target
language. Which would explain Pascal to C but the unlikeliness of C to
Pascal.
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/