Thanks for looking into that Vincent.
My 2 cents, for what it is worth:
- NEVER use floating point for equality checks. Ever.
Not only is the precision misleading (Radix 2 - isms/ etc.), but 32 vs. 64
... etc. get in the way, quite often, in fact
- If NSDate in particular, "always use NSDate
> My conclusions,
> - 0.7 and 0.9 fix return the correct time now, 0.9 fix can't do necessary
> time arithmetic
> - Ruby Time.to_f is broken in all 3 versions
> - Bignum.to_f is broken in all 3 versions
> - I believe the to_f method is behind all of these problems but i haven't had
> time to find
Here is an update on what is going on with the NSDate issues.
i have been working with 3 version's of MacRuby.
MacRuby 0.7 with Vincent's first suggested modification (commenting out the
NSDate clause in objc.m (This
essentially makes MacRuby use a real NSDate object instead of converting it
i
Hi Richard,
0.7 is a bit old at this point, I recommend using the latest release, 0.8.
This said, nightly builds have been pretty stable so far, so you may want to
try one too. This is basically what will be released as 0.9 very soon (this
week maybe!).
Laurent
On Jan 31, 2011, at 7:59 PM, Ri
