5 ms·

MacRuby 0.6 Official Release

64 points by sant0sk1 16y ago

rauljara 16y ago
"In this release, we believe that MacRuby is now stable enough to consider using it to develop Cocoa applications." "This release also passes about 85% of RubySpecs..." Those two things seemed a little contradictory to me at first. But then I noticed the part about macruby apps being able to compile to machine code, so I guess what they mean is that if your app is stable in macruby, it will be stable when you ship it, even macruby isn't fully compatible with ruby yet. Definitely looking forward to playing around with it.
- jdminhbg 16y ago
  Ruby the language is pretty gigantic, so there are a lot of hard-to-fix corner cases. IronRuby, IIRC, passes 85% or so and just hit 1.0 and can run Rails. So most Ruby you write will run on this, but it is possible to break it.
  - knowtheory 16y ago
    well... just because 85% of Ruby runs, doesn't mean that 85% of your usecases are covered. Unfortunately for me, a variety of rubygems that my apps and libs depend on break with 0.6, even things as lightweight as Addressable. Still lookin' forward to more macruby though :)
tlrobinson 16y ago
I'm still waiting for the MacRuby/GCD Rack-compatible webserver they mentioned awhile ago, supposedly called "ControlTower".
- mattetti 16y ago
  It's available in the svn repo.
  - jballanc 16y ago
    True, but you probably want to wait for the official announcement. There's a decent amount of churn at the moment...
  - tlrobinson 16y ago
    I'm having a hard time finding it, can you point me to it?
mark_l_watson 16y ago
Nice, I am curious how it will benchmark against Ruby 1.9.1 for some of my libraries. Anyone run any benchmarks yet on their code?
- acangiano 16y ago
  I'm going to publish a Ruby shootout on Mac very soon.
  - shimonamit 16y ago
    Great. Looking forward to that.
    - acangiano 16y ago
      Published: http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0-6/ http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0...
- mark_l_watson 16y ago
  I am dissapointed: tried running it on a utility I wrote for crunching Wikipedia text (lots of string operations, some file IO) and it is so much slower than Ruby 1.9.1. I stopped the benchmark after 5 minutes (same test took about 70 seconds with Ruby 1.9.1). Then I tried a simple string manipulation benchmark, and it ran about 3 times slower in MacRuby. Using Cocoa classes in MacRuby is great for Mac development but (apparently) really slows down string operations.
  - cscotta 16y ago
    As I understand it, the focus up 'til now has been correctness and compatibility rather than performance / efficiency. It seems a bit early to jump on them for that (though the speed hit you mention is surprising). That said, I'd expect things to pick up speed once the next-generation compiler Laurent mentions in the blog post is ready (and when the RubySpec needle moves closer to 100). Regardless, the team has made a ton of progress since the last release. Here's looking forward to the next.
deleted 16y ago
[deleted]
hackermom 16y ago
Does anyone know how this differs from the Ruby that is a native part of OS X 10.6? Is it just a newer version? MomBook:~ hackermom$ ruby -v ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]
- wrs 16y ago
  It uses the Objective-C runtime, including "native" objects (strings are NSStrings, hashes are NSDictionaries, etc.). It generates native code (using LLVM) rather than interpreting. It has a more sensible syntax for making Objective-C method calls. (And more.)
  - Zev 16y ago
    Also might be worth noting: MacRuby is an implementation of Ruby 1.9, not 1.8.x. Any benchmarks done should be compared against YARV, not what comes with OS X.
  - aaronblohowiak 16y ago
    yes. and hotcocoa is a wrapper for cocoa that is more rubyish for making native cocoa apps in ruby. Also: The “Compile” target in Xcode allows an application to be ahead-of-time compiled to machine code, allowing the developer to avoid including the Ruby source in a shipping application.
- frofro 16y ago
  No, it's an alternative implementation of Ruby 1.9 that allows you to interface directly with native OS X frameworks.
  - demallien 16y ago
    It's actually a bit more profound than that. macruby objects are Cocoa objects, so all of the funny edge cases that we used to have problems with in RubyCocoa have just gone away. For example, in RubyCocoa, if you try to serialise a proxy object representing a Cocoa object using YAML, and then read that object back in, the proxy is no longer created, and if you try to pass the object to a Cocoa API, the program crashes, because Cocoa was expecting a Cocoa object... The same operation in macruby works just fine (well, apart from the fact that YAML is evil, but at any rate, I have a macruby app that uses it, and it works fine)

64 points by sant0sk1 16y ago

"In this release, we believe that MacRuby is now stable enough to consider using it to develop Cocoa applications." "This release also passes about 85% of RubySpecs..." Those two things seemed a little contradictory to me at first. But then I noticed the part about macruby apps being able to compile to machine code, so I guess what they mean is that if your app is stable in macruby, it will be stable when you ship it, even macruby isn't fully compatible with ruby yet. Definitely looking forward to playing around with it.

jdminhbg 16y ago
Ruby the language is pretty gigantic, so there are a lot of hard-to-fix corner cases. IronRuby, IIRC, passes 85% or so and just hit 1.0 and can run Rails. So most Ruby you write will run on this, but it is possible to break it.
- knowtheory 16y ago
  well... just because 85% of Ruby runs, doesn't mean that 85% of your usecases are covered. Unfortunately for me, a variety of rubygems that my apps and libs depend on break with 0.6, even things as lightweight as Addressable. Still lookin' forward to more macruby though :)

tlrobinson 16y ago

I'm still waiting for the MacRuby/GCD Rack-compatible webserver they mentioned awhile ago, supposedly called "ControlTower".

mattetti 16y ago
It's available in the svn repo.
- jballanc 16y ago
  True, but you probably want to wait for the official announcement. There's a decent amount of churn at the moment...
- tlrobinson 16y ago
  I'm having a hard time finding it, can you point me to it?

mark_l_watson 16y ago

Nice, I am curious how it will benchmark against Ruby 1.9.1 for some of my libraries. Anyone run any benchmarks yet on their code?

acangiano 16y ago
I'm going to publish a Ruby shootout on Mac very soon.
- shimonamit 16y ago
  Great. Looking forward to that.
  - acangiano 16y ago
    Published: http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0-6/ http://antoniocangiano.com/2010/05/16/benchmarking-macruby-0...
mark_l_watson 16y ago
I am dissapointed: tried running it on a utility I wrote for crunching Wikipedia text (lots of string operations, some file IO) and it is so much slower than Ruby 1.9.1. I stopped the benchmark after 5 minutes (same test took about 70 seconds with Ruby 1.9.1). Then I tried a simple string manipulation benchmark, and it ran about 3 times slower in MacRuby. Using Cocoa classes in MacRuby is great for Mac development but (apparently) really slows down string operations.
- cscotta 16y ago
  As I understand it, the focus up 'til now has been correctness and compatibility rather than performance / efficiency. It seems a bit early to jump on them for that (though the speed hit you mention is surprising). That said, I'd expect things to pick up speed once the next-generation compiler Laurent mentions in the blog post is ready (and when the RubySpec needle moves closer to 100). Regardless, the team has made a ton of progress since the last release. Here's looking forward to the next.

deleted 16y ago

[deleted]

hackermom 16y ago

Does anyone know how this differs from the Ruby that is a native part of OS X 10.6? Is it just a newer version? MomBook:~ hackermom$ ruby -v ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]

wrs 16y ago
It uses the Objective-C runtime, including "native" objects (strings are NSStrings, hashes are NSDictionaries, etc.). It generates native code (using LLVM) rather than interpreting. It has a more sensible syntax for making Objective-C method calls. (And more.)
- Zev 16y ago
  Also might be worth noting: MacRuby is an implementation of Ruby 1.9, not 1.8.x. Any benchmarks done should be compared against YARV, not what comes with OS X.
- aaronblohowiak 16y ago
  yes. and hotcocoa is a wrapper for cocoa that is more rubyish for making native cocoa apps in ruby. Also: The “Compile” target in Xcode allows an application to be ahead-of-time compiled to machine code, allowing the developer to avoid including the Ruby source in a shipping application.
frofro 16y ago
No, it's an alternative implementation of Ruby 1.9 that allows you to interface directly with native OS X frameworks.
- demallien 16y ago
  It's actually a bit more profound than that. macruby objects are Cocoa objects, so all of the funny edge cases that we used to have problems with in RubyCocoa have just gone away. For example, in RubyCocoa, if you try to serialise a proxy object representing a Cocoa object using YAML, and then read that object back in, the proxy is no longer created, and if you try to pass the object to a Cocoa API, the program crashes, because Cocoa was expecting a Cocoa object... The same operation in macruby works just fine (well, apart from the fact that YAML is evil, but at any rate, I have a macruby app that uses it, and it works fine)