Posted by Ben Jackson
Thu, 13 Mar 2008 22:57:15 GMT
Laurent Sansonetti just released MacRuby 0.1 today.
MacRuby is another bridge from Ruby to Cocoa. You can think of it as an improved version of RubyCocoa, or as a Ruby 1.9 runtime implemented in Objective C.
Threading is now native, and objects fly between Objective C and Ruby seamlessly, since they're all implemented in the same base class hierarchy.
Check the source out from subversion and play around with it, it's a young project and needs your help.
Posted in Development | Tags cocoa, macruby, osx, ruby | 2 comments | no trackbacks
Posted by Ben Jackson
Thu, 14 Feb 2008 02:09:19 GMT
The short answer: don't use them. Ruby threads (at least before 1.9) are not OS native, and while there is a patch to the ruby interpreter included in Leopard's ruby to work around this issue, it's not 100%. It's all too easy for a thread to access memory after it's been garbage collected, and you, the developer, have to always remember to never call anything GUI-related from a separate thread, instead littering your code with calls to performSelectorOnMainThread:withObject:waitUntilDone anytime you need to update the user interface from a thread other than the main one.
So what's the best solution? Props to Eloy for tipping me off that it's better to rely on Cocoa's native asynchronous functions anytime you need to do something long-running like, say, detect a weblog's API. NSURLConnection and NSURLDownload are your best friends. They use native threads and are much more stable. Use them with respect and you'll be much further along on your way to a crash-free application.
One thing to note about NSURLConnection is that it encapsulates a single request only, and will not follow redirects, so make sure to check the response code in connection:didReceiveResponse.
Good luck and happy threading.
Posted in Development | Tags cocoa, gotchas, ruby, rubycocoa, threads | 2 comments | no trackbacks
