Subject: Re: Strange NSDate behavior building 32 bit v 64 bit
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. Richard
Message: 2 Date: Sun, 30 Jan 2011 22:08:38 -0800 From: "Jordan K. Hubbard" <jkh@apple.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit Message-ID: <D31EF44C-06F8-45B1-83B4-7977A32BD53F@apple.com> Content-Type: text/plain; charset="us-ascii"
I suppose this begs the question: Does anyone really *require* 32 bit support for MacRuby at this point? SnowLeopard is already the minimum supported config, and the only Intel 32 bit-only platforms (very early MacBook and Mac Mini configurations) are several years old now. I don't want to sound like an unfeeling ogre to anyone who actually has such a configuration, mind you, but how big of an installed base does this really represent?
- Jordan
On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote:
1. Modified the Valid Archetectures to "i386 x86_64"
There's a simple way to run macruby (or any other program) on the command line in 32 bits: just add "arch -i386" before the name of the program to execute: $ macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ arch -i386 macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386]
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; } }
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.isambart@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; } }
Fair enough, I did not realize that you'd already deployed an app based on MacRuby and had already received bug reports (which suggests that the number of 32 bit users is clearly non-zero, at least!). Have you filed a ticket in trac with a reduction (e.g. the minimum code necessary to demonstrate the problem) yet? That will allow us to track and prioritize the work for possible inclusion in 0.9 (or later, depending on how things go). Thanks, - Jordan On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote:
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.
Richard
Message: 2 Date: Sun, 30 Jan 2011 22:08:38 -0800 From: "Jordan K. Hubbard" <jkh@apple.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit Message-ID: <D31EF44C-06F8-45B1-83B4-7977A32BD53F@apple.com> Content-Type: text/plain; charset="us-ascii"
I suppose this begs the question: Does anyone really *require* 32 bit support for MacRuby at this point? SnowLeopard is already the minimum supported config, and the only Intel 32 bit-only platforms (very early MacBook and Mac Mini configurations) are several years old now. I don't want to sound like an unfeeling ogre to anyone who actually has such a configuration, mind you, but how big of an installed base does this really represent?
- Jordan
On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote:
1. Modified the Valid Archetectures to "i386 x86_64"
There's a simple way to run macruby (or any other program) on the command line in 32 bits: just add "arch -i386" before the name of the program to execute: $ macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ arch -i386 macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386]
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Like Jordan said :) Please file a ticket and we will get this fixed in 0.9. Bugs breaking applications are considered as a priority. I think 0.9 should remain 32/64 bits, but the release after may drop 32-bit support (unless people really need it). I can add a note in the 0.9 release notes and then we can see if people complain. Laurent On Jan 31, 2011, at 12:07 PM, Jordan K. Hubbard wrote:
Fair enough, I did not realize that you'd already deployed an app based on MacRuby and had already received bug reports (which suggests that the number of 32 bit users is clearly non-zero, at least!). Have you filed a ticket in trac with a reduction (e.g. the minimum code necessary to demonstrate the problem) yet? That will allow us to track and prioritize the work for possible inclusion in 0.9 (or later, depending on how things go).
Thanks,
- Jordan
On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote:
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.
Richard
Message: 2 Date: Sun, 30 Jan 2011 22:08:38 -0800 From: "Jordan K. Hubbard" <jkh@apple.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit Message-ID: <D31EF44C-06F8-45B1-83B4-7977A32BD53F@apple.com> Content-Type: text/plain; charset="us-ascii"
I suppose this begs the question: Does anyone really *require* 32 bit support for MacRuby at this point? SnowLeopard is already the minimum supported config, and the only Intel 32 bit-only platforms (very early MacBook and Mac Mini configurations) are several years old now. I don't want to sound like an unfeeling ogre to anyone who actually has such a configuration, mind you, but how big of an installed base does this really represent?
- Jordan
On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote:
1. Modified the Valid Archetectures to "i386 x86_64"
There's a simple way to run macruby (or any other program) on the command line in 32 bits: just add "arch -i386" before the name of the program to execute: $ macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ arch -i386 macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386]
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Sorry, I'm not patient so I filed the ticket: http://www.macruby.org/trac/ticket/1143 And fixed it in r5215 :D http://www.macruby.org/trac/changeset/5215/ On Feb 1, 2011, at 8:07 AM, Laurent Sansonetti wrote:
Like Jordan said :)
Please file a ticket and we will get this fixed in 0.9. Bugs breaking applications are considered as a priority.
I think 0.9 should remain 32/64 bits, but the release after may drop 32-bit support (unless people really need it). I can add a note in the 0.9 release notes and then we can see if people complain.
Laurent
On Jan 31, 2011, at 12:07 PM, Jordan K. Hubbard wrote:
Fair enough, I did not realize that you'd already deployed an app based on MacRuby and had already received bug reports (which suggests that the number of 32 bit users is clearly non-zero, at least!). Have you filed a ticket in trac with a reduction (e.g. the minimum code necessary to demonstrate the problem) yet? That will allow us to track and prioritize the work for possible inclusion in 0.9 (or later, depending on how things go).
Thanks,
- Jordan
On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote:
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.
Richard
Message: 2 Date: Sun, 30 Jan 2011 22:08:38 -0800 From: "Jordan K. Hubbard" <jkh@apple.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit Message-ID: <D31EF44C-06F8-45B1-83B4-7977A32BD53F@apple.com> Content-Type: text/plain; charset="us-ascii"
I suppose this begs the question: Does anyone really *require* 32 bit support for MacRuby at this point? SnowLeopard is already the minimum supported config, and the only Intel 32 bit-only platforms (very early MacBook and Mac Mini configurations) are several years old now. I don't want to sound like an unfeeling ogre to anyone who actually has such a configuration, mind you, but how big of an installed base does this really represent?
- Jordan
On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote:
1. Modified the Valid Archetectures to "i386 x86_64"
There's a simple way to run macruby (or any other program) on the command line in 32 bits: just add "arch -i386" before the name of the program to execute: $ macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ arch -i386 macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386]
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Wow, now that's service! :-) Thanks, Vincent! - Jordan On Jan 31, 2011, at 3:22 PM, Vincent Isambart wrote:
Sorry, I'm not patient so I filed the ticket: http://www.macruby.org/trac/ticket/1143 And fixed it in r5215 :D http://www.macruby.org/trac/changeset/5215/
On Feb 1, 2011, at 8:07 AM, Laurent Sansonetti wrote:
Like Jordan said :)
Please file a ticket and we will get this fixed in 0.9. Bugs breaking applications are considered as a priority.
I think 0.9 should remain 32/64 bits, but the release after may drop 32-bit support (unless people really need it). I can add a note in the 0.9 release notes and then we can see if people complain.
Laurent
On Jan 31, 2011, at 12:07 PM, Jordan K. Hubbard wrote:
Fair enough, I did not realize that you'd already deployed an app based on MacRuby and had already received bug reports (which suggests that the number of 32 bit users is clearly non-zero, at least!). Have you filed a ticket in trac with a reduction (e.g. the minimum code necessary to demonstrate the problem) yet? That will allow us to track and prioritize the work for possible inclusion in 0.9 (or later, depending on how things go).
Thanks,
- Jordan
On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote:
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.
Richard
Message: 2 Date: Sun, 30 Jan 2011 22:08:38 -0800 From: "Jordan K. Hubbard" <jkh@apple.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit Message-ID: <D31EF44C-06F8-45B1-83B4-7977A32BD53F@apple.com> Content-Type: text/plain; charset="us-ascii"
I suppose this begs the question: Does anyone really *require* 32 bit support for MacRuby at this point? SnowLeopard is already the minimum supported config, and the only Intel 32 bit-only platforms (very early MacBook and Mac Mini configurations) are several years old now. I don't want to sound like an unfeeling ogre to anyone who actually has such a configuration, mind you, but how big of an installed base does this really represent?
- Jordan
On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote:
> 1. Modified the Valid Archetectures to "i386 x86_64"
There's a simple way to run macruby (or any other program) on the command line in 32 bits: just add "arch -i386" before the name of the program to execute: $ macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ arch -i386 macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386]
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (4)
-
Jordan K. Hubbard
-
Laurent Sansonetti
-
Richard Sepulveda
-
Vincent Isambart