# I rock **URL:** \ **Category:** ruby-talk\ **Created:** [3 May 2005 17:23 UTC](https://rubytalk.org/t/i-rock/18091 "2005-05-03T17:23:14Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [3 May 2005 17:23 UTC](https://rubytalk.org/t/i-rock/18091/1 "2005-05-03T17:23:14Z")
Yup, rb\_intern needs to be cached. Yup, the \_\_self thing is wrong (it was late, and I forgot about NODE\_SELF). No, it doesn't let you directly call C code either (yet?). $ cat demo/factorial.rb class F    def factorial(n)      f = 1      n.downto(2) { |x| f \*= x }      return f    end    def main # horrid but funny hack      return factorial(5)    end end $ ./translate2.rb demo/factorial.rb \> f.c $ cc -dynamic -bundle -undefined suppress -flat\_namespace -g -O2 -pipe -fno-common -I /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0 f.c -o F.bundle $ ruby -I. -rF -e 'p F.new.factorial(5)' 120 $ time ruby -Idemo -rfactorial -e 'p F.new.factorial(9999)' \> /dev/null real 0m3.938s user 0m3.360s sys 0m0.080s $ time ruby -I. -rF -e 'p F.new.factorial(9999)' \> /dev/null real 0m3.751s user 0m3.340s sys 0m0.060s (but I don't expect a speed increase, the way it works) $ cat f.c // BEGIN METARUBY PREAMBLE #include \ #define case\_equal\_long(x, y) (rb\_funcall((x), rb\_intern("==="), 1, (y))) // END METARUBY PREAMBLE // class F \< Object static VALUE rrc\_cF\_factorial(VALUE \_\_self, VALUE n) { VALUE f; VALUE x; f = LONG2FIX(1); x = n; while (RTEST(rb\_funcall(x, rb\_intern("\>="), 1, LONG2FIX(2)))) { f = rb\_funcall(f, rb\_intern("\*"), 1, x); x = rb\_funcall(x, rb\_intern("-"), 1, LONG2FIX(1)); }; return f; } static VALUE rrc\_cF\_main(VALUE \_\_self) { return rb\_funcall(\_\_self, rb\_intern("factorial"), 1, LONG2FIX(5)); } void Init\_F() { VALUE rrc\_cF = rb\_define\_class("F", rb\_path2class("Object")); rb\_define\_method(rrc\_cF, "factorial", rrc\_cF\_factorial, 1); rb\_define\_method(rrc\_cF, "main", rrc\_cF\_main, 0); } > **···** > > -- > Eric Hodel - [drbrain@segment7.net](mailto:drbrain@segment7.net) - [http://segment7.net](http://segment7.net) > FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 ---
**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\ **Post date:** [3 May 2005 18:09 UTC](https://rubytalk.org/t/i-rock/18091/2 "2005-05-03T18:09:32Z")
In article \, > **···** > > Eric Hodel \ wrote: > > > Yup, rb\_intern needs to be cached. Yup, the \_\_self thing is wrong (it > > was late, and I forgot about NODE\_SELF). No, it doesn't let you > > directly call C code either (yet?). > > > > $ cat demo/factorial.rb > > class F > >   def factorial(n) > >     f = 1 > >     n.downto(2) { |x| f \*= x } > >     return f > >   end > > > >   def main # horrid but funny hack > >     return factorial(5) > >   end > > end > > $ ./translate2.rb demo/factorial.rb \> f.c > > $ cc -dynamic -bundle -undefined suppress -flat\_namespace -g -O2 -pipe > > -fno-common -I /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0 f.c -o > > F.bundle > > $ ruby -I. -rF -e 'p F.new.factorial(5)' > > 120 > > $ time ruby -Idemo -rfactorial -e 'p F.new.factorial(9999)' \> /dev/null > > > > real 0m3.938s > > user 0m3.360s > > sys 0m0.080s > > $ time ruby -I. -rF -e 'p F.new.factorial(9999)' \> /dev/null > > > > real 0m3.751s > > user 0m3.340s > > sys 0m0.060s > > > > (but I don't expect a speed increase, the way it works) > > > > $ cat f.c > > // BEGIN METARUBY PREAMBLE > > #include \ > > #define case\_equal\_long(x, y) (rb\_funcall((x), rb\_intern("==="), 1, > > (y))) > > // END METARUBY PREAMBLE > > // class F \< Object > > > > static VALUE > > rrc\_cF\_factorial(VALUE \_\_self, VALUE n) { > > VALUE f; > > VALUE x; > > f = LONG2FIX(1); > > x = n; > > while (RTEST(rb\_funcall(x, rb\_intern("\>="), 1, LONG2FIX(2)))) { > > f = rb\_funcall(f, rb\_intern("\*"), 1, x); > > x = rb\_funcall(x, rb\_intern("-"), 1, LONG2FIX(1)); > > }; > > return f; > > } > > > > static VALUE > > rrc\_cF\_main(VALUE \_\_self) { > > return rb\_funcall(\_\_self, rb\_intern("factorial"), 1, LONG2FIX(5)); > > } > > > > void > > Init\_F() { > > VALUE rrc\_cF = rb\_define\_class("F", rb\_path2class("Object")); > > > > rb\_define\_method(rrc\_cF, "factorial", rrc\_cF\_factorial, 1); > > rb\_define\_method(rrc\_cF, "main", rrc\_cF\_main, 0); > > > > } > > How does this differ from the current RubyToC stuff? > Is this newer version available for download yet? > > Phil ---
**Author:** ![Ryan\_Davis1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/ryan_davis1/32/1848_2.png) [@Ryan\_Davis1](https://rubytalk.org/u/Ryan_Davis1)\ **Post date:** [3 May 2005 22:19 UTC](https://rubytalk.org/t/i-rock/18091/3 "2005-05-03T22:19:16Z")
> Yup, rb\_intern needs to be cached. Yup, the \_\_self thing is wrong (it was late, and I forgot about NODE\_SELF). No, it doesn't let you directly call C code either (yet?). ... > $ cat f.c > ... > static VALUE > rrc\_cF\_factorial(VALUE \_\_self, VALUE n) { > VALUE f; > VALUE x; > f = LONG2FIX(1); > x = n; > while (RTEST(rb\_funcall(x, rb\_intern("\>="), 1, LONG2FIX(2)))) { > f = rb\_funcall(f, rb\_intern("\*"), 1, x); > x = rb\_funcall(x, rb\_intern("-"), 1, LONG2FIX(1)); > }; > return f; YAY! You do rock! And no, "\_\_self" doesn't suck, but most of the C impl I've seen just calls it "self" straight up. This is really cool and I can't wait to read the code. > **···** > > On May 3, 2005, at 10:23 AM, Eric Hodel wrote: ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [3 May 2005 18:27 UTC](https://rubytalk.org/t/i-rock/18091/4 "2005-05-03T18:27:27Z")
> In article \, > > > $ cat f.c > > // BEGIN METARUBY PREAMBLE > > #include \ > > #define case\_equal\_long(x, y) (rb\_funcall((x), rb\_intern("==="), 1, > > (y))) > > // END METARUBY PREAMBLE > > // class F \< Object > > > > static VALUE > > rrc\_cF\_factorial(VALUE \_\_self, VALUE n) { > > VALUE f; > > VALUE x; > > f = LONG2FIX(1); > > x = n; > > while (RTEST(rb\_funcall(x, rb\_intern("\>="), 1, LONG2FIX(2)))) { > > f = rb\_funcall(f, rb\_intern("\*"), 1, x); > > x = rb\_funcall(x, rb\_intern("-"), 1, LONG2FIX(1)); > > }; > > return f; > > } > > > > static VALUE > > rrc\_cF\_main(VALUE \_\_self) { > > return rb\_funcall(\_\_self, rb\_intern("factorial"), 1, LONG2FIX(5)); > > } > > > > void > > Init\_F() { > > VALUE rrc\_cF = rb\_define\_class("F", rb\_path2class("Object")); > > > > rb\_define\_method(rrc\_cF, "factorial", rrc\_cF\_factorial, 1); > > rb\_define\_method(rrc\_cF, "main", rrc\_cF\_main, 0); > > > > } > > How does this differ from the current RubyToC stuff? This one (Ruby2RubyC) generates a C extension, where the other tail generates raw, type inferenced C code. I think Ruby2RubyC can make optimizations for Fixnum math and other boolean logic, but I haven't explored that yet. Ruby2RubyC is also dynamic code safe. It automatically converts from Fixnum to Bignum, thanks to the Ruby C runtime. (I snipped the output of factorial(9999), but it outputs a handful of lines of numbers.) For example, the other tail could not handle factorial(9999) because C doesn't have Bignums. > Is this newer version available for download yet? No, not yet. Maybe after Thursday hacking. > **···** > > On 03 May 2005, at 11:09, Phil Tomson wrote: > > > Eric Hodel \ wrote: > > -- > Eric Hodel - drbrain@segment7.net - [http://segment7.net](http://segment7.net) > FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 ---
**Author:** ![Linus\_Sellberg1](https://avatars.discourse-cdn.com/v4/letter/l/e47c2d/32.png) [@Linus\_Sellberg1](https://rubytalk.org/u/Linus_Sellberg1)\ **Post date:** [3 May 2005 20:25 UTC](https://rubytalk.org/t/i-rock/18091/5 "2005-05-03T20:25:15Z")
> This one (Ruby2RubyC) generates a C extension, where the other tail > generates raw, type inferenced C code. Sounds like a nice way to obfuscate code a bit, for those that are inclined that way. ---
**Author:** ![Gyoung-Yoon\_Noh1](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@Gyoung-Yoon\_Noh1](https://rubytalk.org/u/Gyoung-Yoon_Noh1)\ **Post date:** [3 May 2005 20:32 UTC](https://rubytalk.org/t/i-rock/18091/6 "2005-05-03T20:32:11Z")
Python has PyRex which enables writing CPython extensions with python-like syntax. I guess Ruby2RubyC can do a foundation role for future great works such as writing extensions with ruby syntax, enhancing performance easily with type conversion, or can be used as intermediate format for translating Ruby to C. Cheers, > **···** > > On 5/4/05, Eric Hodel \ wrote: > > > On 03 May 2005, at 11:09, Phil Tomson wrote: > > > > \> In article \, > > \> Eric Hodel \ wrote: > > \>\> $ cat f.c > > \>\> // BEGIN METARUBY PREAMBLE > > \>\> #include \ > > \>\> #define case\_equal\_long(x, y) (rb\_funcall((x), rb\_intern("==="), 1, > > \>\> (y))) > > \>\> // END METARUBY PREAMBLE > > \>\> // class F \< Object > > \>\> > > \>\> static VALUE > > \>\> rrc\_cF\_factorial(VALUE \_\_self, VALUE n) { > > \>\> VALUE f; > > \>\> VALUE x; > > \>\> f = LONG2FIX(1); > > \>\> x = n; > > \>\> while (RTEST(rb\_funcall(x, rb\_intern("\>="), 1, LONG2FIX(2)))) { > > \>\> f = rb\_funcall(f, rb\_intern("\*"), 1, x); > > \>\> x = rb\_funcall(x, rb\_intern("-"), 1, LONG2FIX(1)); > > \>\> }; > > \>\> return f; > > \>\> } > > \>\> > > \>\> static VALUE > > \>\> rrc\_cF\_main(VALUE \_\_self) { > > \>\> return rb\_funcall(\_\_self, rb\_intern("factorial"), 1, LONG2FIX(5)); > > \>\> } > > \>\> > > \>\> void > > \>\> Init\_F() { > > \>\> VALUE rrc\_cF = rb\_define\_class("F", rb\_path2class("Object")); > > \>\> > > \>\> rb\_define\_method(rrc\_cF, "factorial", rrc\_cF\_factorial, 1); > > \>\> rb\_define\_method(rrc\_cF, "main", rrc\_cF\_main, 0); > > \>\> > > \>\> } > > \>\> > > \> > > \> > > \> How does this differ from the current RubyToC stuff? > > > > This one (Ruby2RubyC) generates a C extension, where the other tail > > generates raw, type inferenced C code. > > > > I think Ruby2RubyC can make optimizations for Fixnum math and other > > boolean logic, but I haven't explored that yet. > > > > Ruby2RubyC is also dynamic code safe. It automatically converts from > > Fixnum to Bignum, thanks to the Ruby C runtime. (I snipped the output > > of factorial(9999), but it outputs a handful of lines of numbers.) > > > > For example, the other tail could not handle factorial(9999) because C > > doesn't have Bignums. > > > > \> Is this newer version available for download yet? > > > > No, not yet. Maybe after Thursday hacking. > > > > -- > > Eric Hodel - drbrain@segment7.net - [http://segment7.net](http://segment7.net) > > FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 > > -- > [http://nohmad.sub-port.net](http://nohmad.sub-port.net) ---
**Author:** ![Ryan\_Davis1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/ryan_davis1/32/1848_2.png) [@Ryan\_Davis1](https://rubytalk.org/u/Ryan_Davis1)\ **Post date:** [3 May 2005 22:21 UTC](https://rubytalk.org/t/i-rock/18091/7 "2005-05-03T22:21:01Z")
Ruby2RubyC will probably not, for the first few months at least, improve performance with any sort of type conversion at all. In fact, I suspect that Eric's current version will start to get fairly severe penalties until we move away from using rb\_funcall for everything. If you want performance then you should either hand write (using RubyInline!) or take a peek at zenoptimizer when it gets released in my ZenHacks package (it uses a combination of ruby2c and rubyinline with a custom lightweight profiler I wrote last week). > **···** > > On May 3, 2005, at 1:32 PM, Gyoung-Yoon Noh wrote: > > > Python has PyRex which enables writing CPython extensions > > with python-like syntax. I guess Ruby2RubyC can do a foundation > > role for future great works such as writing extensions with ruby > > syntax, enhancing performance easily with type conversion, > > or can be used as intermediate format for translating Ruby to C. > > -- > ryand-ruby@zenspider.com - Seattle.rb - [Seattle.rb | Home](http://www.zenspider.com/seattle.rb) > [http://blog.zenspider.com/](http://blog.zenspider.com/) - [http://rubyforge.org/projects/ruby2c](http://rubyforge.org/projects/ruby2c) ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [3 May 2005 22:45 UTC](https://rubytalk.org/t/i-rock/18091/8 "2005-05-03T22:45:47Z")
> > Python has PyRex which enables writing CPython extensions > > with python-like syntax. I guess Ruby2RubyC can do a foundation > > role for future great works such as writing extensions with ruby > > syntax, enhancing performance easily with type conversion, > > or can be used as intermediate format for translating Ruby to C. > > Ruby2RubyC will probably not, for the first few months at least, improve performance with any sort of type conversion at all. In fact, I suspect that Eric's current version will start to get fairly severe penalties until we move away from using rb\_funcall for everything. Yup, it only bypasses the fast parts of eval.c (AST walking), and none of the slow parts (rb\_funcall) so you get almost zero speed benefit out of it currently. (See the "time factorial(9999)" output further up the thread). > If you want performance then you should either hand write (using RubyInline!) or take a peek at zenoptimizer when it gets released in my ZenHacks package (it uses a combination of ruby2c and rubyinline with a custom lightweight profiler I wrote last week). Yes. When you find a slow part, you could use this as your template. You'll have working Ruby/C code to refactor into faster C code in no time at all. I should be able to skip rb\_funcall for places where I know the types, and directly call the C implementation of a method. That will be more work though, because I'll have to fall back in case a TypeError is raised in addition to pulling the right bits from the VALUE. Or something. > **···** > > On 03 May 2005, at 15:21, Ryan Davis wrote: > > > On May 3, 2005, at 1:32 PM, Gyoung-Yoon Noh wrote: > > -- > Eric Hodel - drbrain@segment7.net - [http://segment7.net](http://segment7.net) > FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 ---
**Author:** ![Ryan\_Davis1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/ryan_davis1/32/1848_2.png) [@Ryan\_Davis1](https://rubytalk.org/u/Ryan_Davis1)\ **Post date:** [3 May 2005 23:43 UTC](https://rubytalk.org/t/i-rock/18091/9 "2005-05-03T23:43:59Z")
> > If you want performance then you should either hand write (using RubyInline!) or take a peek at zenoptimizer when it gets released in my ZenHacks package (it uses a combination of ruby2c and rubyinline with a custom lightweight profiler I wrote last week). > > Yes. When you find a slow part, you could use this as your template. You'll have working Ruby/C code to refactor into faster C code in no time at all. oooh. I didn't think of that. Not sure why. 😛 > I should be able to skip rb\_funcall for places where I know the types, and directly call the C implementation of a method. That will be more work though, because I'll have to fall back in case a TypeError is raised in addition to pulling the right bits from the VALUE. \*nod\* I expect that we'll do a version down the line that includes TypeChecker in the SexpProcessor pipeline and we'll have better sends in that version. Isn't it cool that we have these discussions out on a public list like ruby-talk??? It is almost like, oh I dunno, we want people to look at the software! 😉 > **···** > > On May 3, 2005, at 3:45 PM, Eric Hodel wrote: > > > On 03 May 2005, at 15:21, Ryan Davis wrote: > > -- > ryand-ruby@zenspider.com - Seattle.rb - [http://www.zenspider.com/seattle.rb](http://www.zenspider.com/seattle.rb) > [http://blog.zenspider.com/](http://blog.zenspider.com/) - [http://rubyforge.org/projects/ruby2c](http://rubyforge.org/projects/ruby2c) ---
**Author:** ![Gyoung-Yoon\_Noh1](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@Gyoung-Yoon\_Noh1](https://rubytalk.org/u/Gyoung-Yoon_Noh1)\ **Post date:** [4 May 2005 02:48 UTC](https://rubytalk.org/t/i-rock/18091/10 "2005-05-04T02:48:25Z")
Oops, by 'type conversion', I meant PyRex-style C types usage. PyRex enables feeding native C types, instead of PythonC types, easily within its python-like syntax anywhere. In case of ruby, I think it will be much greater if it's possible to use RubyDL's type wrapper against native C types. > **···** > > On 5/4/05, Eric Hodel \ wrote: > > > On 03 May 2005, at 15:21, Ryan Davis wrote: > > > > \> On May 3, 2005, at 1:32 PM, Gyoung-Yoon Noh wrote: > > \> > > \>\> Python has PyRex which enables writing CPython extensions > > \>\> with python-like syntax. I guess Ruby2RubyC can do a foundation > > \>\> role for future great works such as writing extensions with ruby > > \>\> syntax, enhancing performance easily with type conversion, > > \>\> or can be used as intermediate format for translating Ruby to C. > > \> > > \> Ruby2RubyC will probably not, for the first few months at least, > > \> improve performance with any sort of type conversion at all. In fact, > > \> I suspect that Eric's current version will start to get fairly severe > > \> penalties until we move away from using rb\_funcall for everything. > > > > Yup, it only bypasses the fast parts of eval.c (AST walking), and none > > of the slow parts (rb\_funcall) so you get almost zero speed benefit out > > of it currently. (See the "time factorial(9999)" output further up the > > thread). > > -- > [http://nohmad.sub-port.net](http://nohmad.sub-port.net) ---
**Author:** ![Bill\_Guindon1](https://avatars.discourse-cdn.com/v4/letter/b/4da419/32.png) [@Bill\_Guindon1](https://rubytalk.org/u/Bill_Guindon1)\ **Post date:** [4 May 2005 15:14 UTC](https://rubytalk.org/t/i-rock/18091/11 "2005-05-04T15:14:28Z")
Not being a c programmer, I've been watching this thread (and some others) mostly out of curiousity. But I'm beginning to get the impression that the two of you are on the verge of having a full Ruby to C converter. Is that an overestimate? If a full conversion is likely, any idea on a time line? What would be the likely limitations? Write it in Ruby, convert it to c, compile it, distribute it. That really would be something. Especially for the non c programmers like myself 🙂 > **···** > > On 5/3/05, Ryan Davis \ wrote: > > > On May 3, 2005, at 3:45 PM, Eric Hodel wrote: > > > > \> On 03 May 2005, at 15:21, Ryan Davis wrote: > > \> > > \>\> If you want performance then you should either hand write (using > > \>\> RubyInline!) or take a peek at zenoptimizer when it gets released in > > \>\> my ZenHacks package (it uses a combination of ruby2c and rubyinline > > \>\> with a custom lightweight profiler I wrote last week). > > \> > > \> Yes. When you find a slow part, you could use this as your template. > > \> You'll have working Ruby/C code to refactor into faster C code in no > > \> time at all. > > > > oooh. I didn't think of that. Not sure why. 😛 > > > > \> I should be able to skip rb\_funcall for places where I know the types, > > \> and directly call the C implementation of a method. That will be more > > \> work though, because I'll have to fall back in case a TypeError is > > \> raised in addition to pulling the right bits from the VALUE. > > > > \*nod\* > > > > I expect that we'll do a version down the line that includes > > TypeChecker in the SexpProcessor pipeline and we'll have better sends > > in that version. > > > > Isn't it cool that we have these discussions out on a public list like > > ruby-talk??? It is almost like, oh I dunno, we want people to look at > > the software! 😉 > > -- > Bill Guindon (aka aGorilla) ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [4 May 2005 18:43 UTC](https://rubytalk.org/t/i-rock/18091/12 "2005-05-04T18:43:11Z")
> > > > If you want performance then you should either hand write (using > > > > RubyInline!) or take a peek at zenoptimizer when it gets released in > > > > my ZenHacks package (it uses a combination of ruby2c and rubyinline > > > > with a custom lightweight profiler I wrote last week). > > > > > > Yes. When you find a slow part, you could use this as your template. > > > You'll have working Ruby/C code to refactor into faster C code in no > > > time at all. > > > > oooh. I didn't think of that. Not sure why. 😛 > > > > > I should be able to skip rb\_funcall for places where I know the types, > > > and directly call the C implementation of a method. That will be more > > > work though, because I'll have to fall back in case a TypeError is > > > raised in addition to pulling the right bits from the VALUE. > > > > \*nod\* > > > > I expect that we'll do a version down the line that includes > > TypeChecker in the SexpProcessor pipeline and we'll have better sends > > in that version. > > > > Isn't it cool that we have these discussions out on a public list like > > ruby-talk??? It is almost like, oh I dunno, we want people to look at > > the software! 😉 > > Not being a c programmer, I've been watching this thread (and some > others) mostly out of curiousity. But I'm beginning to get the > impression that the two of you are on the verge of having a full Ruby > to C converter. Is that an overestimate? I think that is on-target. > If a full conversion is likely, any idea on a time line? What would > be the likely limitations? For Ruby2RubyC, you trade safety for speed (but I may be able to do something about that), and you are limited in what is translatable. Code in a class or module, or at the top level can't be translated. The translator isn't fully done yet, I don't know if things like constant lookup actually works, and I didn't do anything to make global variables work. Those things can be fixed. It may do different things with scoping of variables too. > Write it in Ruby, convert it to c, compile it, distribute it. That > really would be something. Especially for the non c programmers like > myself 🙂 For a Ruby subset, yes, you can do that. Just for a larger subset than Ruby2C. > **···** > > On 04 May 2005, at 08:14, Bill Guindon wrote: > > > On 5/3/05, Ryan Davis \ wrote: > > > > > On May 3, 2005, at 3:45 PM, Eric Hodel wrote: > > > > > > > On 03 May 2005, at 15:21, Ryan Davis wrote: > > -- > Eric Hodel - drbrain@segment7.net - [http://segment7.net](http://segment7.net) > FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 ---
**Author:** ![Bill\_Guindon1](https://avatars.discourse-cdn.com/v4/letter/b/4da419/32.png) [@Bill\_Guindon1](https://rubytalk.org/u/Bill_Guindon1)\ **Post date:** [5 May 2005 02:39 UTC](https://rubytalk.org/t/i-rock/18091/13 "2005-05-05T02:39:24Z")
Eric, you and Ryan have impressed me before, but this takes the cake. I'll keep watching, and I hope others can do more than just watch. I expect that subset will be growing, and I look forward to it. I've used Erik Veenstra's RubyScript2Exe a couple times to share toys with non-ruby coders, and I think it's a great tool, but this would be much more impressive (losing size/speed issues). Keep up the great work. I imagine many others feel the same way. Consider this an 'advocacy bump' 😉 > **···** > > On 5/4/05, Eric Hodel \ wrote: > > > \> On 5/3/05, Ryan Davis \ wrote: > > \>\> Isn't it cool that we have these discussions out on a public list like > > \>\> ruby-talk??? It is almost like, oh I dunno, we want people to look at > > \>\> the software! 😉 > > \> > > \> Not being a c programmer, I've been watching this thread (and some > > \> others) mostly out of curiousity. But I'm beginning to get the > > \> impression that the two of you are on the verge of having a full Ruby > > \> to C converter. Is that an overestimate? > > > > I think that is on-target. > > > > \> If a full conversion is likely, any idea on a time line? What would > > \> be the likely limitations? > > > > For Ruby2RubyC, you trade safety for speed (but I may be able to do > > something about that), and you are limited in what is translatable. > > Code in a class or module, or at the top level can't be translated. > > > > The translator isn't fully done yet, I don't know if things like > > constant lookup actually works, and I didn't do anything to make global > > variables work. Those things can be fixed. > > > > It may do different things with scoping of variables too. > > > > \> Write it in Ruby, convert it to c, compile it, distribute it. That > > \> really would be something. Especially for the non c programmers like > > \> myself 🙂 > > > > For a Ruby subset, yes, you can do that. Just for a larger subset than > > Ruby2C. > > -- > Bill Guindon (aka aGorilla)