February 2011 - MacRuby-devel - lists.macosforge.org

is_a? method
by Robert Rice 04 Feb '11

04 Feb '11

Hi: I notice that the obj.is_a? method does not work on a class constant. It only works on an instance of the class. Is this the way it should work? Do I need to create a loop checking using the superclass method to check the inheritance of a class or is there an easier way? Thanks, Bob Rice

5 8

MacRuby Book discount
by Matt Aimonetti 04 Feb '11

04 Feb '11

O'Reilly is running a special today and my MacRuby: Definitive Guide - Early Release - ebook (PDF, mobi & ePub) is for sale for only $15.99 with the following code: DDMRD http://oreil.ly/eij2QS The book is also available in HTML format for free. If you've enjoyed the free version, please consider leaving a review on the page above to show your support to myself & to my publisher. Thanks, - Matt Sent from my iPhone

14 27

Strange behaviour when using a Proc for a callback
by Mark Rada 03 Feb '11

03 Feb '11

Hi, I was trying to setup an async callback using a proc instead of a method to register for app launching notifications. For some reason, when I use the proc method, I get the wrong object passed to the proc when it gets called. The version using a method callback: framework 'Cocoa' def callback notif puts notif.class puts notif.inspect puts notif.userInfo.inspect end def launch_mail workspace = NSWorkspace.sharedWorkspace workspace.notificationCenter.addObserver self, selector:'callback:', name:NSWorkspaceDidLaunchApplicationNotification, object:nil workspace.launchAppWithBundleIdentifier 'com.apple.mail', options:NSWorkspaceLaunchAsync, additionalEventParamDescriptor:nil, launchIdentifier:nil end launch_mail NSRunLoop.currentRunLoop.runUntilDate( Time.now + 5 ) That code will work the way that I expected it to, but if I try to use a proc: framework 'Cocoa' callback = Proc.new { |notif| puts notif.class puts notif.inspect puts notif.userInfo.inspect } workspace = NSWorkspace.sharedWorkspace workspace.notificationCenter.addObserver callback, selector:'call:', name:NSWorkspaceDidLaunchApplicationNotification, object:nil workspace.launchAppWithBundleIdentifier 'com.apple.mail', options:NSWorkspaceLaunchAsync, additionalEventParamDescriptor:nil, launchIdentifier:nil NSRunLoop.currentRunLoop.runUntilDate( Time.now + 5 ) It will crash because for some reason I am not getting the notification back as I should, instead I am getting a reference to the NSDictionary class. I don't think this is the intended behaviour in MacRuby, but I'm not sure if what I am trying to do is supported. Is the ability to use a proc as a callback a supported feature? It has worked for me in other cases. Mark Rada mrada(a)marketcircle.com

2 1

"incorrect checksum for freed object" with Nokogiri (w/simple test case)
by Andre Lewis 03 Feb '11

03 Feb '11

Hello, Nokogiri started working with MacRuby 0.8, which is awesome. However, I'm getting sporadic crashes: "incorrect checksum for freed object - object was probably modified after being freed." It doesn't crash every time I run the test, but if I run it 10 times, I get one or more failures. ***Self-contained script to reproduce:*** https://gist.github.com/797346. ***Example crash output:*** $ macruby nokogiri_test.rb starting Nokogiri parsed the html Run # 0: OK Run # 1: OK macruby(59860,0x100f81000) malloc: *** error for object 0x10944ce38: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap ***My Nokogiri info:*** $ nokogiri -v --- warnings: [] nokogiri: 1.4.4 ruby: version: 1.9.2 platform: universal-darwin10.0 engine: macruby libxml: binding: extension compiled: 2.7.3 loaded: 2.7.3 ***MacRuby Info*** $ macruby -v MacRuby 0.8 (ruby 1.9.2) [universal-darwin10.0, x86_64] I posted to the Nokogiri list ( https://github.com/tenderlove/nokogiri/issues/issue/406) The test case runs on all the other Ruby versions we've tried, so it seems Macruby-specific. Any insight appreciated! Andre

2 1

IDE and TextEditor
by Daniel Lopes 03 Feb '11

03 Feb '11

Hello everybody, I'm spending more and more time with macruby but I'm not very happy with XCode yet. The IDE is pretty good but I didn't found a good theme that colorizes Ruby syntax in the right way. I don't consider TextMate and Vim because for frameworks like Cocoa I think autocomplete and integration with docs is really important. What do you guys use for edit MacRuby code?

5 4

Strange NSDate behavior building 32 bit v 64 bit (Richard Sepulveda)
by Richard Sepulveda 02 Feb '11

02 Feb '11

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 into a Ruby Time object) MacRuby 0.8 with no changes MacRuby 0.9 with Vincent's NSDate changes. (He fixes the NSDate/Ruby Time object) The test code: NSLog( "In rb_main.rb") i = 1296445544 NSLog( "i = %d class = %s" % [i, i.class.to_s]) f = 1296445544.0 NSLog( "f = %f class = %@ DIG = %d" % [ f, f.class, Float::DIG.to_s]) if i == f NSLog( "Is equal") else NSLog( "Not equal") end time = Time.new NSLog( "time = %s" % [time.to_s]) NSLog( "time to_i = %d" % [time.to_i]) NSLog( "time to_f = %f" % [time.to_f]) nsdate = NSDate.date NSLog( "nsdate = %s" % [nsdate.description]) i = nsdate.timeIntervalSinceReferenceDate.to_i f = nsdate.timeIntervalSinceReferenceDate.to_f NSLog( "nsdate to_i = %d" % [i]) NSLog( "nsdate to_f = %f" % [f]) Summary (all tests were run in 32 bit mode): I can provide the output if you wish to see it. MacRuby 0.7 - NSDate is fixed, Can also do calculations with the date like adding 60 seconds,etc. - Ruby Time - date is correct, to_i is correct, to_f is incorrect - Bignum.to_i is correct, Bignum.to_f is wrong MacRuby 0.8 - NSDate is broken - wrong time, wrong to_i, wrong to_f - Ruby Time - date is correct, to_i is correct, to_f is incorrect - Bignum.to_i is correct, Bignum.to_f is wrong MacRuby 0.9 - NSDate is somewhat fixed. It returns the correct time, but fails when doing calculations with that date - Ruby Time - date is correct, to_i is correct, to_f is incorrect - Bignum.to_i is correct, Bignum.to_f is wrong 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 the problem nor a solution. * Late breaking news, I was running my real app with the modified 0.7 version and when i attempted to 'play' an NSSound, the application exited with a return code 45?? I am not sure what this means. I will try to create a test case for this later on.

3 2

Re: [MacRuby-devel] Subject: Re: Strange NSDate behavior building 32 bit v 64 bit
by Richard Sepulveda 01 Feb '11

01 Feb '11

Thanks for the rapid response to this problem. I will verify that it works with my project as soon as I can get MacRuby built. I also ran into some other strangeness in 32-bit mode but this may fix those issues as well. I will give an update soon. Another question, my project is currently using the default 0.7 MacRuby framework included in XCode. I assume that I should include this fix in the latest 0.7 or 0.8 build and run all of the test suites to verify that I didn't break anything in the build process? Thanks again, Richard 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 >>>

3 2

Re: [MacRuby-devel] Subject: Re: Strange NSDate behavior building 32 bit v 64 bit (Richard Sepulveda)
by Richard Sepulveda 01 Feb '11

01 Feb '11

Is trunk ready for primetime? I noticed some problem reports with 0.9 in the mailing list lately and wasn't sure if that was a good idea. And i haven't tested at all with 0.8 or 0.9. But I guess you guys are primarily fixing things for the 1.0 release and only changing things that are necessary. i am not knowledgable about MacRuby's build system. Do you guys primarily work off off top-of-trunk or do you tag specific intermediate versions that had better stability, more extensive testing, etc? Thanks, Richard > >> Another question, my project is currently using the default 0.7 MacRuby >> framework ?included in XCode. I assume >> that I should include this fix in the latest 0.7 or 0.8 build and run all of >> the test suites to verify that I didn't >> break anything in the build process? > > It looks like this part of the code did not change between 0.7 and my > change, so applying it to 0.7 should work fine. > > Unfortunately I don't think you will be able to run the specs in > 32-bit mode. I tried this morning on trunk at it crashed (and it's > probably nothing new).... > > If possible I would even recommend using trunk over 0.7/0.8 because > they have a bug (fixed in r5191 > http://www.macruby.org/trac/changeset/5191/ ) that could make MacRuby > crash randomly.

2 1

Ruby sort algorithm
by Robert Rice 01 Feb '11

01 Feb '11

Hi: Does the Ruby Array sort algorithm maintain the relative position for children returning the same value for the comparison? I had an instance where two children having the compare value were interchanged. Thanks, Bob Rice

3 9

Subject: Re: Strange NSDate behavior building 32 bit v 64 bit
by Richard Sepulveda 01 Feb '11

01 Feb '11

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(a)apple.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v > 64 bit > Message-ID: <D31EF44C-06F8-45B1-83B4-7977A32BD53F(a)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]

4 6