[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Trouble with OSA and Excel

Robert Schaaf

4/27/2009 9:43:00 PM

[Note: parts of this message were removed to make it a legal post.]

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.
3 Answers

hengist podd

4/28/2009 12:00:00 PM

0

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/replacing-applescript-with...

Documentation generation and code translation tools are at:

http://appscript.sourc.../...

HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourc...
--
Posted via http://www.ruby-....

Robert Schaaf

4/28/2009 11:17:00 PM

0

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 Apr 28, 2009, at 8:00 AM, hengist podd wrote:

> 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/replacing-applescript-with...
>
> Documentation generation and code translation tools are at:
>
> http://appscript.sourc.../...
>
> HTH
>
> has
> --
> Control AppleScriptable applications from Python, Ruby and ObjC:
> http://appscript.sourc...
> --
> Posted via http://www.ruby-....
>

hengist podd

4/29/2009 6:31:00 PM

0

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
--
Posted via http://www.ruby-....