Forget my previous mail, I found a better workaround: in objc.m replace:
VALUE arg = DBL2NUM(time + CF_REFERENCE_DATE);
by
VALUE arg = LONG2NUM(time + CF_REFERENCE_DATE);
With this, you will lose sub-second precision but it will still be
better than what you have currently.
I can add microseconds precision but that will have to wait for tomorrow :-)
On Mon, Jan 31, 2011 at 9:37 PM, Vincent Isambart
<vincent.isamb...@gmail.com> wrote:
> Hi,
>
>> That makes perfectly good sense but i unfortunately started selling a
>> MacRuby app on the App Store
>> for i386 and 64 bit machines. And a few people are experiencing this issue.
>> I was just hoping
>> for a quick workaround to make them happy. And I would discontinue selling
>> the 32 bit version
>> on the next release.
>>
>> But i can't see anything obvious other than rewriting all of my NSDate based
>> code in Objective-C or
>> waiting for a fix. i include the MacRuby framework in my Pkg so that is
>> possible.
>
> Looking at MacRuby's source code, there might be a work-around, but I have
> not tried it (well I just did a very short test) and it has some limitations.
> MacRuby automatically converts instances of NSDate in instances of Time and
> the loss of precision is at that conversion.
> You could disable that automatic conversion, but if you do that you would
> only have the Cocoa NSDate methods, not the one added by MacRuby.
> To disable that conversion, in objc.m just remove or comment out:
> else if (k == (Class)rb_cNSDate) {
> @try {
> CFAbsoluteTime time = CFDateGetAbsoluteTime((CFDateRef)obj);
> VALUE arg = DBL2NUM(time + CF_REFERENCE_DATE);
> return rb_vm_call(rb_cTime, sel_at, 1, &arg);
> }
> @catch (NSException *e) {
> // Some NSDates might return an exception (example:
> uninitialized objects).
> break;
> }
> }
>
>
>
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
