@laurentsansonetti: "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:
<url>
MacRuby is still extremely experimental, but a first release is
expected very soon.
Enjoy,
Laurent"
    @charlesnutter: "<quote>
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"
    @charlesnutter: "<quote>
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"
    @rickdenatale: "<quote>
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
<url>"
    @laurentsansonetti: "On Thu, Feb 28, 2008 at 2:34 AM, Charles Oliver Nutter
<quote>
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.)
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"
    @laurentsansonetti: "On Thu, Feb 28, 2008 at 2:49 AM, Charles Oliver Nutter
<quote>
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"
    @laurentsansonetti: "<quote>
True.
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 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"
    @rich: "<quote>
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"
    @matz: "Hi,
In message "Re: [ANN] MacRuby"
    on Fri, 29 Feb 2008 05:56:41 +0900, "Laurent Sansonetti" <email_address> 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.
							matz."
    @rickdenatale: "<quote>
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.
Rick DeNatale
My blog on Ruby
<url>"
    @laurentsansonetti: "<quote>
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"
    @matz: "Hi,
In message "Re: [ANN] MacRuby"
    on Fri, 29 Feb 2008 08:04:38 +0900, "Laurent Sansonetti" <email_address> writes:
|>  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."
    @aredridel: "<quote>
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."
{'source': 'USENET', 'other_information': '{"reply_count": 12, "forum_name": "comp.lang.ruby.20141210.mbox"}', 'file': 'data/output/usenet-comp.lang.parquet'}