March 2008 - MacRuby-devel - lists.macosforge.org

Re: [MacRuby-devel] [ruby] #36: on trunk .methods.sort doesn't work
by ruby 21 Mar '08

21 Mar '08

#36: on trunk .methods.sort doesn't work -------------------------------------+-------------------------------------- Reporter: jordan.breeding(a)mac.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: blocker | Milestone: MacRuby 1.0 Component: MacRuby | Resolution: Keywords: | -------------------------------------+-------------------------------------- Comment (by artension(a)gmail.com) It reproduced here. {{{ $ macruby -ve '1.methods.sort' MacRuby version 0.2 (ruby 1.9.0 2008-03-01) [universal-darwin9.0] -e:1: [BUG] Segmentation fault MacRuby version 0.2 (ruby 1.9.0 2008-03-01) [universal-darwin9.0] -- control frame ---------- c:0005 p:---- s:0011 b:0011 l:000010 d:000010 CFUNC :uniq! c:0004 p:---- s:0009 b:0009 l:000008 d:000008 CFUNC :methods c:0003 p:0008 s:0006 b:0006 l:000005 d:000005 TOP -e:1 c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH :inherited c:0001 p:0000 s:0002 b:0002 l:000001 d:000001 TOP --------------------------- DBG> : "-e:1:in `methods'" DBG> : "-e:1:in `<main>'" -- backtrace of native function call (Use addr2line) -- 0x2b0ac6 0x1de3cc 0x1de40b 0x265701 0x9684d5eb 0xffffffff 0x1f6a86 0x1f9052 0x92607923 0x1fc0f2 0x92607b86 0x1fd995 0x1c78de 0x1c7902 0x2af6e8 0x1e5012 0x1e5219 0x1e5952 0x2b853a 0x1d4aa5 0x21a1c7 0x2a0f85 0x2aee20 0x2a88e4 0x2adfbc 0x2ae291 0x1e203a 0x1e790f 0x1fdf 0x1f46 0x3 ------------------------------------------------------- Abort trap }}} -- Ticket URL: <http://trac.macosforge.org/projects/ruby/ticket/36#comment:3> ruby <http://ruby.macosforge.org/>

1 0

Re: [MacRuby-devel] [ruby] #36: on trunk .methods.sort doesn't work
by ruby 21 Mar '08

21 Mar '08

#36: on trunk .methods.sort doesn't work -------------------------------------+-------------------------------------- Reporter: jordan.breeding(a)mac.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: blocker | Milestone: MacRuby 1.0 Component: MacRuby | Resolution: Keywords: | -------------------------------------+-------------------------------------- Changes (by lsansonetti(a)apple.com) * milestone: => MacRuby 1.0 Comment: It seems that this problem affects a few people, and also very randomly. -- Ticket URL: <http://trac.macosforge.org/projects/ruby/ticket/36#comment:2> ruby <http://ruby.macosforge.org/>

1 0

Commit e-mail
by Benjamin Stiglitz 20 Mar '08

20 Mar '08

Any chance we can get the 'forge to send out changelogs on a new mailing list? macruby-changes? -Ben

4 8

Re: [MacRuby-devel] [ruby] #39: Range#include?(nil) never returns
by ruby 20 Mar '08

20 Mar '08

#39: Range#include?(nil) never returns -----------------------------------------+---------------------------------- Reporter: rowland(a)rowlandresearch.com | Owner: lsansonetti(a)apple.com Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.2 Component: MacRuby | Resolution: fixed Keywords: | -----------------------------------------+---------------------------------- Changes (by lsansonetti(a)apple.com) * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.2 Comment: Fixed in r112/trunk. Thanks for the report. -- Ticket URL: <http://trac.macosforge.org/projects/ruby/ticket/39#comment:1> ruby <http://ruby.macosforge.org/>

1 0

new Hash class
by Laurent Sansonetti 19 Mar '08

19 Mar '08

Hi, If you have been following trunk very recently you probably know. The Hash class now has a new implementation. So far I'm happy with the changes that are in trunk, and here are the details. - The Hash class is still a subclass of NSMutableDictionary. - All the Hash methods are not defined on Hash anymore, but on NSDictionary instead. The methods have been re-implemented to use the CF APIs. It means that you can for example call #has_key? on all dictionaries, created by Ruby (via the Hash class) or by Objective-C (as a NSCFDictionary object). Trying to call a method that will change the dictionary on an immutable dictionary will raise an exception ("can't modify immutable hash"). - To implement the semantics of the previous Hash class (such as the possibility to freeze it, or specify an "if none" value/proc), MacRuby allocates at demand a data structure and uses a feature of the Objective-C GC to associate/attach it to the dictionary. Once the dictionary is collected, the data structure is also collected at the same time (w00t!). So far, with these changes, MacRuby builds (yeepee!) and most of the tests in test/ruby/test_hash.rb are passing. Things that are not working yet: - Tainting objects. We need to attach the taint flag in the attached structure (like we do with the frozen state). - Passing a false value. Qfalse is 0 in Ruby core, and apparently CFDictionary (via CFDictionaryGetValueIfPresent) has some problems to remove it (though lookups are working). This should anyway be addressed once "false" is something different than 0 in the core. - Hash#compare_by_identity. Supporting that wouldn't be hard by calling some private APIs in CFDictionary. We can now start replacing Array. I proposed on ruby-core to deprecate RARRAY_PTR for element access, which we won't be able to efficiently support. Nobu-san proposed RARRAY_AT() which should work for us. Also, Ben and I have been brainstorming on Monday about future changes, and here is what we decided: http://trac.macosforge.org/projects/ruby/wiki/MacRubyBrainstorming Laurent

3 3

integrating macruby into cocoa apps
by Niko Matsakis 18 Mar '08

18 Mar '08

I downloaded the early release of MacRuby hoping to integrate it into an existing cocoa application: I need to be able to run small amounts of user-supplied code to do custom string manipulations, and I thought MacRuby might be perfect for this. However, I don't see any obvious way to hand off an NSString with code and have it execute in some environment. Does such an API exist? The only entry point I saw was macruby_main(), which doesn't seem quite right, or ruby_exec_node() which looks pretty low-level. I realize that MacRuby is still in an early state, but I just wanted to be sure I wasn't overlooking something before I dug too much deeper. thanks, Niko

4 4

Re: [MacRuby-devel] next release
by Laurent Sansonetti 14 Mar '08

14 Mar '08

On Mar 13, 2008, at 4:49 PM, Ernest Prabhakar wrote: > Hi Laurent, > > On Mar 13, 2008, at 4:17 PM, Laurent Sansonetti wrote: > >>> As we’ve discussed offline, I’d still love to take a crack at this >>> one. I do wonder what we’ll do with NSStrings, though, since >>> they’re not actually mutable. So many issues. >> >> We could check for mutability and accordingly raise exceptions in ! >> methods. Every string created by Ruby would be mutable anyway, we >> are only talking about non-mutable NSStrings received from ObjC, >> which I don't think are a big deal. But if we want to be truly >> compatible on the other side too... we will have to find a solution. > > Could we add a category on NSString that auto-converts it to an > NSMutableString when necessary? Well there is already [-mutableCopy] which when called on an NSString returns an NSMutableString. But you have to call it, the process is not done automatically for you. Say that you receive a non-mutable string from Objective-C, and want to call the #upcase! method on it. AFAIK, MacRuby could 1) raise an exception 2) auto-convert the receiver as mutable (but a new object will likely have to be created). Laurent

4 7

next release
by Laurent Sansonetti 13 Mar '08

13 Mar '08

Hi, For the next release, my objective is to re-implement String, Array and Hash using CoreFoundation. The idea is to have only one implementation for every primitive class, and therefore be able to pass primitive objects from Ruby to Objective-C without having to pay any cost. Basically, String would disappear as a class, and would be an alias to NSString. The whole String interface would be re-implemented on top of NSString, using the CFString API. The same goes for Array and Hash. There are several problems that need to be investigated, such as the new 1.9 i18n strings that can have different encodings, or the fact that Cocoa collections do not accept nil as an element. The new implementation should be as realistic as possible. However I doubt we can keep the C API compatible. At least RSTRING_PTR / RARRAY_PTR will not accept inline array modifications. I will start with Hash first because it's the most simple one. This change will also be interesting performance-wise. We might see some surprises when benchmarking against the original implementation. I suspect the new Array will be faster. Laurent

2 2

[ANN] MacRuby 0.1
by Laurent Sansonetti 13 Mar '08

13 Mar '08

Hi, I am pleased to announce the first release of MacRuby, 0.1. 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. So far, since the project beginning was announced a few weeks ago, many bugs were fixed and features added. MacRuby is still at this point experimental, although if it's also usable. The purpose of this version is to release functional code, and also to let you test the new user experience. Please note that the project implementation will change deeply in the next releases. You can learn more about the project on its homepage: http://trac.macosforge.org/projects/ruby/wiki/MacRuby And download a binary installer: http://trac.macosforge.org/projects/ruby/wiki/InstallingMacRuby Enjoy! Laurent

1 0

new testing version available
by Laurent Sansonetti 13 Mar '08

13 Mar '08

Hi, I just merged all the changes of this week into the testing branch. Many bugs were fixed, including the following bugs that were registered in the tracker: #22 NSPredicate doesn't work #20 Extending an Objective-C class before referencing it replaces it #21 Cocoa primitive classes do not respond to the Ruby interfaces. #18 NSZeroSize Causes Abort #17 Sending 'super' inside an objc overriden method provokes an infinite loop #2 function 'WebInitForCarbon' return value defined more than once #15 Crash when setting an ivar to an alloc/init'ed object #8 getting NSSize from NSImage from artwork doesn't work #7 crash when doing [NSDecimalNumber -decimalValue] #6 add support for loading custom bridgesupport files #1 Object#methods crashes Also, 3 Xcode-based samples are available. Note that you may have to modify the sample xcode project build settings according to where you actually installed macruby, if it doesn't build by default (which is temporary, after I would like to ship macruby as/in a framework). I am now working on merging the latest changes from Ruby trunk, then I will work on the test suite, write a few more examples, and change the project build to install itself as/in a framework. Then, I think we can make a first release! Laurent

3 6