Hello all, This week's agony is with rdoc-osa and Excel 2008. I'm trying to create the documentation files, but the program hangs. I suspect a faulty AE dictionary. Here's the setup: travelers-macbook-pro-17:~ traveler$ rdoc --version RDoc V1.0.1 - 20041108 travelers-macbook-pro-17:~ traveler$ ruby --version ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] Here's the output: Last login: Mon Apr 27 17:10:13 on ttys000 travelers-macbook-pro-17:~ traveler$ rdoc-osa --name 'Microsoft Excel' /Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:470: warning: Passing no parameters to XML::Parser.new is deprecated. Pass an instance of XML::Parser::Context instead. XML::Parser#string is deprecated. Use XML::Parser.string instead /Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:495: warning: already initialized constant TRENDLINE_ADD_EXPONENTIAL /Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:495: warning: already initialized constant FLOOR Microsoft Excel-0-440.rb: mmcmmmmmmmmmmmc........................mc.............m and there it hangs. Has anyone done this successfully? Any guidance/workaround would be humbly appreciated. Thanks, Bob Schaaf PS. I've tried this on two machines with the same result, but it could be my particular installation.
on 2009-04-27 23:44
on 2009-04-28 13:59
Robert Schaaf wrote: > Hello all, > > This week's agony is with rdoc-osa and Excel 2008. I'm trying to > create the documentation files, but the program hangs. I suspect a > faulty AE dictionary. Most application dictionaries are not 100% perfect. AppleScript only uses the keyword-AE code mappings and ignores everything else, so any imperfections in the parts that AppleScript doesn't use often go unnoticed by application developers since everything works fine when tested in AppleScript. Other bridges that do rely on parts of dictionaries that AppleScript ignores (e.g. RubyOSA, Scripting Bridge) are far more sensitive to such minor imperfections, and therefore much more likely to partly or completely break on them. Also note that RubyOSA ceased development about 18 months ago, so it may or may not work with more recent Ruby releases. Your best bet would be to use rb-appscript (see my sig), which works much more like AppleScript so is a lot less prone to compatibility problems than RubyOSA or SB. Matt Neuburg wrote a good article a couple years back on rb-appscript that includes an example of Excel scripting: http://www.macdevcenter.com/pub/a/mac/2007/02/27/r... Documentation generation and code translation tools are at: http://appscript.sourceforge.net/tools.html HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net
on 2009-04-29 01:18
Hengist, Thanks for the reply. I have been using appscript for the better part of a year, but thought to switch to RubyOSA with the idea that the whole dictionary would be pre-cached, and thus faster than resolving the terminology on invocation. But maybe appscript does some similar caching? I never found it slow, but wanted to optimize AppleEvents, which are high impedance to begin with. BTW, where in the application bundle is the dictionary (formerly the 'aete' resource) hidden? I can't find Excel's. Bob Schaaf
on 2009-04-29 20:31
Robert Schaaf wrote: > Hengist, > > Thanks for the reply. I have been using appscript for the better part > of a year, but thought to switch to RubyOSA with the idea that the > whole dictionary would be pre-cached, and thus faster than resolving > the terminology on invocation. But maybe appscript does some similar > caching? I never found it slow, but wanted to optimize AppleEvents, > which are high impedance to begin with. Both appscript and RubyOSA parse an application dictionary the first time you create an application object. Appscript is quicker at this as it just constructs simple lookup tables whereas RubyOSA generates classes, although as this is a one-off cost it's only be a factor in short-running scripts. Appscript caches the results over the process's lifetime, so creating additional application objects for the same application is much faster; not sure about RubyOSA but it may well do so too. RubyOSA might be fractionally faster than appscript at constructing references (it's ages since I've compared it so I can't really remember), partly as it doesn't rely on #method_missing (which adds a bit of overhead in appscript) and partly because it lacks a lot of the functionality found in appscript so there's somewhat less code involved. I'm pretty sure any difference between different bridges' performance won't be significant, however, as the biggest overhead in application scripting is the time it takes for the target application to resolve any object specifiers and perform the command. As a rule of thumb, rb-appscript is typically 30-90% as fast as AppleScript, which is about as fast at building and sending Apple events as you can get. (Commands that return large numbers of references aren't as fast as appscript isn't as fast at constructing those than AppleScript) You might get slightly faster performance from appscript by dropping down into the AEM APIs (which skip the #method_missing stuff and use raw AE codes), or by using RubyCocoa/MacRuby with objc-appscript and static glues (Jordan Breeding, who you can likely find over on macruby-discuss, has been doing this). But I doubt it will make a significant difference. The biggest improvement will come from reducing the number of application commands you use in the first place, e.g. by having commands work on more than one object at a time (there's a chapter on optimisation techniques in the appscript manual), though Excel's scripting interface provides little opportunity for this due to the way it's designed. > BTW, where in the application bundle is the dictionary (formerly the > 'aete' resource) hidden? I can't find Excel's. AETE resources are held in .rsrc files. Use DeRez to extract them, although I can't think of any reason you'd want or need to. HTH has