[ANN] MacRuby

[Laurent Sansonetti]

Hi,

I am honored to announce the beginning of the MacRuby project!

MacRuby is a version of Ruby that runs on top of Objective-C. More
precisely, MacRuby is currently a port of the Ruby 1.9 implementation
for the Objective-C runtime and garbage collector.

You can learn more about the project on its homepage:

http://trac.macosforge.org/projects/ruby/wiki/MacRuby

MacRuby is still extremely experimental, but a first release is
expected very soon.

Enjoy,
Laurent

 

[Stéphane Wirtel]

MacRuby is a version of Ruby that runs on top of Objective-C. More

precisely, MacRuby is currently a port of the Ruby 1.9 implementation
for the Objective-C runtime and garbage collector.

http://trac.macosforge.org/projects/ruby/wiki/MacRuby

MacRuby is still extremely experimental, but a first release is
expected very soon.

Thanks for this job

I am very excited to test it with my new MBP.

Best Regards,

Stephane

 

[Charles Oliver Nutter]

Hi,

I am honored to announce the beginning of the MacRuby project!

MacRuby is a version of Ruby that runs on top of Objective-C. More
precisely, MacRuby is currently a port of the Ruby 1.9 implementation
for the Objective-C runtime and garbage collector.

How are you able to implement ObjectSpace without any impact at runtime?
Do you disable the GC while ObjectSpace is walking? If not, how do you
avoid the possibility that objects may be collected while you are
walking the heap?

- Charlie

 

[Charles Oliver Nutter]

Hi,

I am honored to announce the beginning of the MacRuby project!

Can you talk about about expected performance? I imagine it's still
early days for the project, but being based on 1.9 I'd expect
performance to be somewhat similar. However on a few quick benchmarks
I've run it seems there's some degradation in MacRuby over Ruby 1.9.
Have you started to look at execution performance much yet?

- Charlie

 

[Rick DeNatale]

Hi,

I am honored to announce the beginning of the MacRuby project!

MacRuby is a version of Ruby that runs on top of Objective-C. More
precisely, MacRuby is currently a port of the Ruby 1.9 implementation
for the Objective-C runtime and garbage collector.

You can learn more about the project on its homepage:

http://trac.macosforge.org/projects/ruby/wiki/MacRuby

MacRuby is still extremely experimental, but a first release is
expected very soon.

Interesting stuff.

After reading some of the material on the macosforge wiki, I'm curious
about the keyed arguments design.

It sounds like if I invoke a method like this:

x.foo(1, bar: 2)

Then what happens is that this gets turned into an
Objective-C/Smalltalk syntax message selector of foo:bar:, but if I
use
x.foo(1, 2, bar: 3)

then it effectively uses a different selector and uses Ruby parameter
semantics with bar: 3 getting mapped into {:bar => 3} the way Ruby 1.9
does it.

So what happens if I write a ruby class like this:

class C
def foo(*a)
keywords = a.pop if Hash === a.last
...
end
end

And then, possibly in a separate file, write

def quack(duck) # duck might be an instance of C, but is it?
duck.foo(1, 2, bar: 3) # I guess this would work in any case.
duck.foo(1, bar: 2) # mapped to foo:bar: what does an
instance of C do with this?
end

This also seems to be treading on some of the territory which Matz has
indicated he plans to be defining in Ruby 2.0. I'm worried that
there's a fork down the road here.

 

[Laurent Sansonetti]

How are you able to implement ObjectSpace without any impact at runtime?

Because all objects are being allocated from the same memory zone, so
I just have to walk through the zone.

(See /usr/include/malloc/malloc.h for more details.)

Do you disable the GC while ObjectSpace is walking? If not, how do you
avoid the possibility that objects may be collected while you are
walking the heap?

I have been thinking of this too, it appears that the current code
path works well even if a collection occurs right in the middle.

I could nevertheless lock the GC during #each_object if there is a
problem. It doesn't change the fact that there is no runtime penalty
by default (you can use ObjectSpace if you want). Obviously, MacRuby's
#each_object is slower, definitely because it returns all objects from
the zone, including Objective-C objects too.

$ ruby -ve "p ObjectSpace.each_object {}"
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
310
$ /usr/local/bin/ruby -ve "p ObjectSpace.each_object {}"
MacRuby version 0.1 (ruby 1.9.0 2008-02-18 revision 0) [i686-darwin9.2.0]
8759
$ /usr/local/bin/ruby -ve "framework 'cocoa'; p ObjectSpace.each_object {}"
MacRuby version 0.1 (ruby 1.9.0 2008-02-18 revision 0) [i686-darwin9.2.0]
48425

Laurent

 

[Laurent Sansonetti]

Can you talk about about expected performance? I imagine it's still
early days for the project, but being based on 1.9 I'd expect
performance to be somewhat similar. However on a few quick benchmarks
I've run it seems there's some degradation in MacRuby over Ruby 1.9.
Have you started to look at execution performance much yet?

Yes I have been looking at some benchmarks, a few weeks ago. In
benchmarks measuring object creation, MacRuby is slower because
allocating an object in vanilla Ruby is cheap. On the other side, GC
cycles seem to be faster.

But it's definitely early to compare performances yet. And there are a
few things we can do in MacRuby to improve allocations, and more.

Laurent

 

[Laurent Sansonetti]

Interesting stuff.

After reading some of the material on the macosforge wiki, I'm curious
about the keyed arguments design.

It sounds like if I invoke a method like this:

x.foo(1, bar: 2)

Then what happens is that this gets turned into an
Objective-C/Smalltalk syntax message selector of foo:bar:, but if I
use
x.foo(1, 2, bar: 3)

then it effectively uses a different selector and uses Ruby parameter
semantics with bar: 3 getting mapped into {:bar => 3} the way Ruby 1.9
does it.

So what happens if I write a ruby class like this:

class C
def foo(*a)
keywords = a.pop if Hash === a.last
...
end
end

And then, possibly in a separate file, write

def quack(duck) # duck might be an instance of C, but is it?
duck.foo(1, 2, bar: 3) # I guess this would work in any case.
True.

duck.foo(1, bar: 2) # mapped to foo:bar: what does an
instance of C do with this?

Here, MacRuby will check if duck responds to foo:bar:. If true, this
message is sent with 1 and 2 as arguments. If not true, the foo
message is sent instead with 1 and {:bar => 2} as arguments.

If you're working with pure Ruby objects, the second code path should
always be taken. Unless you define foo:bar: in your Ruby class.

Note that the key:value syntax to describe a hash pair is available in
vanilla 1.9.

This also seems to be treading on some of the territory which Matz has
indicated he plans to be defining in Ruby 2.0. I'm worried that
there's a fork down the road here.

I don't really see this as a fork, but more as a port. Most of MacRuby
is based on 1.9, because we want to use all the upstream code base. We
just use Objective-C when it's necessary to provide a tighter
integration with Mac OS X APIs. Because we want people to use Ruby to
write complete full Mac OS X applications, without paying the bridging
cost.

Laurent

 

[Richard Kilmer]

Yes I have been looking at some benchmarks, a few weeks ago. In
benchmarks measuring object creation, MacRuby is slower because
allocating an object in vanilla Ruby is cheap. On the other side, GC
cycles seem to be faster.

But it's definitely early to compare performances yet. And there are a
few things we can do in MacRuby to improve allocations, and more.

Laurent

The most important thing for me re: performance in MacRuby is how
well the Ruby code performs for OS X applications, and since MacRuby
has no bridging costs the performance is exceedingly better than the
performance of bridged runtimes (like RubyCocoa).

What's nice is you can still drop into C or Objective-C trivially with
MacRuby if performance is critical but for most application logic
MacRuby will be quick enough I think.

For server based applications that are mostly pure Ruby (like
Rails) the raw Ruby performance numbers are important, but it is early
and I think performance will pick up.

One cool thing Apple did with the MacRuby GC was have it execute
in a background native thread so garbage collection does not lock
up the program execution flow.

Rich

 

[Rick DeNatale]

Note that the key:value syntax to describe a hash pair is available in
vanilla 1.9.

Yes I know, and that's my concern about the possibility of a fork.

In 1.9 Matz has basically set the caller side of keyword parameters.
What's left for 2.0 is how to write methods that take them as a
substitute for manipulating hash parameters in the input. My concern
is that MacRuby might be going down a road which is incompatible with
the way Matz eventually goes on the receiving side.

 

[Laurent Sansonetti]

Hi,

In message "Re: [ANN] MacRuby"


|> duck.foo(1, bar: 2) # mapped to foo:bar: what does an
|> instance of C do with this?
|
|Here, MacRuby will check if duck responds to foo:bar:. If true, this
|message is sent with 1 and 2 as arguments. If not true, the foo
|message is sent instead with 1 and {:bar => 2} as arguments.
|
|If you're working with pure Ruby objects, the second code path should
|always be taken. Unless you define foo:bar: in your Ruby class.
|
|Note that the key:value syntax to describe a hash pair is available in
|vanilla 1.9.

I still think having dedicated syntax for Objective-C call is better
than overriding normal call.


duck.foo: 1 bar: 2

or


duck.foo: 1, bar: 2

maybe? I am not sure if the parser allows this or not yet.

I have been thinking about this too, but I personally believe that it
doesn't reveal very pretty when messaging Objective-C methods with
only one argument.

duck.foo: 1

But maybe we will switch to it soon, because it's more consistent with
Objective-C (no potential ambiguities). But it doesn't feel very Ruby.

Laurent

 

[Aria Stewart]

Hi,

I am honored to announce the beginning of the MacRuby project!

MacRuby is a version of Ruby that runs on top of Objective-C. More
precisely, MacRuby is currently a port of the Ruby 1.9 implementation
for the Objective-C runtime and garbage collector.

You can learn more about the project on its homepage:

http://trac.macosforge.org/projects/ruby/wiki/MacRuby

MacRuby is still extremely experimental, but a first release is
expected very soon.

This. Is. Sweet.

I've been working on a hackish interpreter-on-ObjC (though GNUstep)
for a while, as an experiment. This sounds like exactly what I had in
mind.

 

[Roger Pack]

One cool thing Apple did with the MacRuby GC was have it execute
in a background native thread so garbage collection does not lock
up the program execution flow.

Rich

Is this possible with MRI? If so I'd be willing to give a $100 bounty
if someone made a thread safe version for 1.9
-R

 

[Charles Oliver Nutter]

Is this possible with MRI? If so I'd be willing to give a $100 bounty
if someone made a thread safe version for 1.9

Not easily, or at least not without changing the memory model. Most JVM
GCs work this way though, so you can certainly use JRuby.

- Charlie