[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[ANN] MacRuby

Laurent Sansonetti

2/28/2008 2:43:00 AM

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/wi...

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

Enjoy,
Laurent
12 Answers

Stéphane Wirtel

2/28/2008 2:59:00 AM

0

> 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/wi...
>
> 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

2/28/2008 10:34:00 AM

0

Laurent Sansonetti wrote:
> 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

2/28/2008 10:50:00 AM

0

Laurent Sansonetti wrote:
> 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

2/28/2008 2:33:00 PM

0

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:
> 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/wi...
>
> 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.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Laurent Sansonetti

2/28/2008 8:36:00 PM

0

On Thu, Feb 28, 2008 at 2:34 AM, Charles Oliver Nutter
<charles.nutter@sun.com> wrote:
> Laurent Sansonetti wrote:
> > 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?

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

2/28/2008 8:40:00 PM

0

On Thu, Feb 28, 2008 at 2:49 AM, Charles Oliver Nutter
<charles.nutter@sun.com> wrote:
> Laurent Sansonetti wrote:
> > 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?

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

2/28/2008 8:57:00 PM

0

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
>
> On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:
> > 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/wi...
> >
> > 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.

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

2/28/2008 9:14:00 PM

0


On Feb 28, 2008, at 3:40 PM, Laurent Sansonetti wrote:

> On Thu, Feb 28, 2008 at 2:49 AM, Charles Oliver Nutter
> <charles.nutter@sun.com> wrote:
>> Laurent Sansonetti wrote:
>>> 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?
>
> 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

2/28/2008 10:54:00 PM

0

On 2/28/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:


> 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.

> > 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.

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.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Aria Stewart

2/29/2008 9:13:00 PM

0


On Feb 27, 2008, at 7:42 PM, Laurent Sansonetti wrote:

> 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/wi...
>
> 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.