Hi Jonathan, On Nov 28, 2008, at 7:08 PM, Jonathan deWerd wrote:
Hi! I was tracking down a bug in my app that caused a crash, and I finally narrowed it down to the conversion between NSNumber and the Numeric types. I don't think that was the direct cause of the crash (the immediate cause was a longjmp to a nonexistant "thread"), but manually converting it via to_i made it work just fine. In the spirit of "if it's worth doing once, it's worth automating" I wrote some code that patches NSNumber itself to act more like a a Numeric. You can now mix it in just about anywhere, with bignums and floats and ints and it should all Just Work.
This patch doesn't replace any ruby Numeric machinery, it just adds a bit of sugar to the bridge. <numeric.c.patch>
I didn't write any formal test cases for it since I was hoping a greater ruby mind than I could figure out an easy way to subvert the Numeric test cases to my purposes :) I would love for anyone experienced with boundary conditions to take a look at it. I think I got just about everything, but an awful lot of hackery goes on with ruby's numeric types, so a second opinion would be most welcome.
This is very interesting! In fact, I was planning to implement something very similar in order to fix http://www.macruby.org/trac/ticket/112 My idea is to move the Numeric methods to NSNumber directly (very similarly to what we currently do for NSString, NSArray and NSDictionary), so that pure NSNumber objects can respond to #+, #- etc... So your patch seems to already implement parts of this idea. The next step would be to make sure these methods are created on NSNumber and that this still works with Fixnums, which are as you might know special types in the core. They are not real objects but masked pointers, unless they got converted to a RFixnum structure in order to be passed to Objective-C. (Eventually I would like to get rid of the masked pointers and use RFixnum structures for every Fixnum, which shouldn't turn that bad performance wise once we will JIT compile the arithmetic code paths. I would investigate that later.) Would you be willing to adapt your patch to implement this idea?
Thanks to everyone here working on macruby, you've done an amazing job. It's a very worthy successor to rubycocoa :)
I'm very glad you like it, and thanks for taking the time to hack on a patch :-)
PS While you're applying patches, I've got another quick one in a ticket that deals with macruby_main and absolute paths: http://www.macruby.org/trac/ticket/163
I will look at this one, thanks for reminding me! Laurent