Mac and Ruby (as of Tiger, OS X 10.4.10)

Trying to keep track of the pieces of Ruby on a Mac.

Version: Tiger has one version installed. Most people recommending upgrading (or installing) 1.8.6
Installation methods. Packages, manually (building, etc via UNIX); and by svn, gem, Fink, ports–these last four need to be installed before they can be used (not sure, maybe ports is part of the Tiger UNIX). Fink and port, both have Mac GUI programs for their use.
Add-ons: Many are part of the base Ruby installation, but need to be “required” and/or “included.” And both required and included, but using different names (e.g., require ‘fileutils’, include FileUtils)

Mac specific add-ons: rb-appscript, RubyOSA, RubyCocoa
RubyCocoa is a bridge between the Ruby and the Objective-C languages, allowing you to manipulate Objective-C objects from Ruby, and vice-versa. RubyCocoa Also allows Ruby scripts to be used in XCode projects. Sansonetti and 5 others

rb-appscript and RubyOSA allow Ruby to use AppleScript (or the underlying technology of AppleScript–OSA)
rb-appscript — Ruby appscript (rb-appscript) is a port of the robust, mature Python appscript (py-appscript) bridge; and seems mature and well supported by Hamish Sanderson (HAS). rb-appscript

RubyOSA — is a bridge from the Ruby language to the Apple Event Manager. The Apple Event Manger allows applications to send and receive messages, or Apple events as they are called, to and from applications that support scripting. (description copied, but I think it functions like rb-appscript). Is RubyOSA going to be installed with Leopard? Laurent Sansonetti is the lead, lsansonetti@apple.com but he’s in Paris LRZ with Mike Naberezny .

3 thoughts on “Mac and Ruby (as of Tiger, OS X 10.4.10)”

  1. “RubyOSA — is a bridge from the Ruby language to the Apple Event Manager. […] (description copied, but I think it functions like rb-appscript).”

    Both RubyOSA and appscript hook into the Apple Event Manager. The difference is in how they expose that functionality to users:

    – Appscript uses the same approach as AppleScript, dressing up the underlying RPC+query mechanism in a pretty syntax for ease of use while being careful to preserve all of its original functionality and behaviour. The resulting API feels a bit less ‘Ruby-like’, but that’s just how Apple events are.

    – RubyOSA tries to make it look and feel completely object-oriented a-la COM or CORBA. The resulting API feels a bit more ‘Ruby-like’, but at a significant cost: missing functionality, various application compatibility issues and several hidden gotchas just waiting to bite unsuspecting users.

    “Is RubyOSA going to be installed with Leopard?”

    Unlikely. See:

    http://www.apple.com/macosx/leopard/technology/unix.html

    Looks like Apple will be promoting their Cocoa-based Scripting Bridge to Python and Ruby users, presumably via PyObjC and RubyCocoa (which they are including).

    HTH

  2. I wondered about RubyOSA in Leopard because it appears Sansonetti is an Apple employed or has a close connection and because he also is part of the RubyCocoa team. I don’t understand how RubyCocoa’s inclusion in Leopard affects the inclusion of Appscript or RubyOSA. I think I understand why Apple is putting more emphasis on RubyCocoa.

    Can Appscript be made more Ruby-like without giving up functionality? Ruby seems happy having more than one way to do things. But of course more confusing.

    HAS: Thanks for the comments.

  3. “I don’t understand how RubyCocoa’s inclusion in Leopard affects the inclusion of Appscript or RubyOSA”

    While Apple’s original plan was to provide each language with its own dedicated Apple event bridge, they’ve since decided to standardise on a single Cocoa API (Scripting Bridge) which can be accessed by any language that has Cocoa bindings – ObjC, Python+PyObjC, Ruby+RubyCocoa, etc. As to how this approach will actually work, we’ll just have to wait till October to find out.

    “Can Appscript be made more Ruby-like without giving up functionality?”

    Not really. Ruby is object-oriented while Apple events are query-oriented, so there’s always going to be a degree of impedance mismatch between the two. The only question is how you deal with that mismatch. RubyOSA tries to hide it away and pretend it doesn’t exist, whereas appscript has found honesty to be the best policy so puts it on the surface and makes (or at least tries to make) users aware of it.

    The cost to users is a slightly greater learning curve, but I think that’s a much better trade-off than reduced functionality and reliability – and once you get used to it, it pretty much becomes a non-issue anyway.

    HTH

Leave a Reply