Hi Rich,
On Dec 3, 2008, at 10:38 AM, Rich Morin wrote:
At 02:26 -0800 12/3/08, Laurent Sansonetti wrote:
I said I would start to run the RubySpec project and contribute
missing 1.9/MacRuby specs to it. Since RubySpec uses the rspec
syntax, I indeed need to adopt the same syntax for contributions.
I just had the following IRC (#rubinius) exchange with Brian Ford:
Rich_Morin:
brixen: From your talk at RC08, I get the impression that the
handling of 1.9 specs may be in flux (eg, folded into the main
tree). Can you give me a precis to report back to the MacRuby
list?
brixen:
Rich_Morin: http://rubyspec.org/wiki/rubyspec/Specs-19
Rich_Morin: just need some more folks working on it
This page lays out the general approach that any rearrangement
will follow. In brief, however, there's no need to wait...
Yeah Brian told me the same thing, this is a good news.
Right now I do not have the time to start this, and we do not even
pass all the test/unit tests that ship with 1.9 yet.
My guess is that there will eventually be lots of folks adding
specs for 1.9, but that most of the projects are still focused
on getting full 1.8 compatibility and/or waiting on MRI 1.9 to
be released. So, MacRuby could well be out in front.
Obviously, there will need to bs some specs dealing with MR's
handling of "keyed arguments":
http://www.macruby.org/trac/wiki/HowDoesMacRubyWork#KeyedArguments
Also, I suspect that some specs rely on:
* the ancestry of core Ruby classes (eg, String)
True, Brian told me some specs are assuming the MRI ancestors chain.
We would have to decide either we conform to these specs by not
exposing the Cocoa classes or if we add exceptions to bypass them.
* the methods available to core Ruby classes
Objective-C methods are not introspected by default, so I think this
point should be safe.
What other areas will need MR-specific specs?
MR-specific specs could include calling/defining Objective-C selectors
as you suggested, but also accessing C APIs through BridgeSupport. I
guess we should have to go through the code to identify more things
that we could also cover.
Laurent
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
