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
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
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
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
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.
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/wiki/MacRuby
MacRuby is still extremely experimental, but a first release is
expected very soon.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
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.
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/wiki/MacRuby
MacRuby is still extremely experimental, but a first release is
expected very soon.
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
On Thu, Feb 28, 2008 at 2:34 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
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
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?
> 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
endAnd 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
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:
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
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
Hi,
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.
matz.
In message "Re: [ANN] MacRuby" on Fri, 29 Feb 2008 05:56:41 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com> writes:
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.
On 2/28/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
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
On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
In message "Re: [ANN] MacRuby" > > on Fri, 29 Feb 2008 05:56:41 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com> writes:
>> 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.
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
--
Posted via http://www.ruby-forum.com/\.
Hi,
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
You can still map one-argument method to duck.foo(1) as it does now.
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.
That is very important design decision. Objective-C-ish calling or
Ruby-ish calling. The latter makes program consistent, but the former
makes program obvious. Hmm.
matz.
In message "Re: [ANN] MacRuby" on Fri, 29 Feb 2008 08:04:38 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com> writes:
Roger Pack wrote:
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
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