Skip to content

Applescript plans

7 messages · Erich Neuwirth, Simon Urbanek, Rob Goedman +3 more

#
Are there any plans to extend the Applescript facilities in R? If one  
could transfer R matrices  as nested lists to and from Applescript, I  
could build another version of RExcel on Macs.
Currently, Numbers from iWorks seems not to be scriptable (which seems  
strange for an app coming from Apple itself).
#
Hi Eric,
current support of applescript in R.app is very limited. You cannot  
pass objects & co, just run R commands.
It should be rewritten from scratch because the current one is based  
on old Carbon code.
No one has yet proposed himself to take over on that.
stefano
On 10/feb/08, at 20:26, Erich Neuwirth wrote:

            
#
On Feb 10, 2008, at 2:26 PM, Erich Neuwirth wrote:

            
Yes, we plan a new AS interface for the GUI 2.0. Right now we are in  
the process of collecting ideas as of what could be useful, so it's  
the perfect time to ask :).
What would you need exactly? It is not quite clear to me how to  
transport matrices - do you mean in textual or binary form? I'm not  
sure how much support we have on the AS side for such kind of a  
thing ... Please feel free to outline any ideas you have concerning  
the interface ...
Ah ,well, it's the first release, so I'm sure they'll be enhancing it  
a lot along the way ...

Cheers,
Simon
#
Hi,
On Feb 11, 2008, at 6:07 AM, Simon Urbanek wrote:

            
In private emails between Simon and myself I suggested to include the  
capability to send 'invisible commands' to R.app, e.g. to show  
function arguments in the R console.

A further improvement would allow access to 'GUI' functionality if  
that is not available through a simple 'cmd'.
The return path is more complicated. AS has limitations, the length of  
a single line comes to mind, I have been thinking more about using a  
file (e.g. R-script/coda-like and/or tab/csv based) based approach.

Byron also suggested some ideas on his blog ( http://statcomp.blogspot.com/ 
  ), also in relation to Numbers.

Nevertheless, a 'single line' return from R.app to an AS-ed  
application, as a string, might also be useful in some cases, e.g.  
package load/updates or R CMD build results.
On Feb 11, 2008, at 12:49 AM, stefano iacus wrote:
...
I committed to work on this once Simon's initial approach for the GUI  
2.0 is in place.

Rob
#
Apologizes Rob, I forgot about GUI 2.0. Surely the best place where to  
implement it.
stefano
On 11/feb/08, at 17:45, Rob Goedman wrote:

            
#
On Mon, 11 Feb 2008 09:07:05 -0500, Simon Urbanek wrote:
You might get some useful ideas and/or code from the py-appscript open-source 
project:
http://appscript.sourceforge.net

In the words of its author: "Py-appscript is a high-level, user-friendly Apple 
event bridge that allows you to control scriptable Mac OS X applications using 
ordinary Python scripts. Appscript makes Python a serious alternative to 
Apple's own AppleScript language for automating your Mac."

The author has also created an Apple event bridge for Ruby and seems to have 
very good grasp of how Applescript works under the hood.


Thomas Juntunen
#
Hmmm, I guess I really should post that code of mine. Well, no time
like the present. The code (which hasn't been touched in a while. It
actually predates the new graphics package and should be moved over to
the new API, especially in light of the improvements made by other
folks). In any case, it's the R-Multi project at
http://git.byronellis.name/ (just set it up today!).

I'll also see if I can find my osxtools package which includes a
clipboard and Spotlight R interface. It doesn't use the connections
API since, unless something has changed recently, packages can't
really implement new connections.

With respect to the Numbers (and Excel) stuff my approach was
primarily concerned with pasting "Excel" or "Numbers" into the Console
rather than scripting (although you could script those steps of
course). In both cases, using the Pasteboard Investigator or whatever
the tool is called, you find that the source makes several different
types available on the clipboard (either the primary clipboard or the
temporary drag-n-drop clipboard) at least one of which can be read by
R. Since only one object can really be on the clipboard at once the
presence of the other types suggests that one should use a particular
R-compatible type to get appropriate results. I haven't picked up a
copy of Office '08, but I imagine things will be more-or-less
unchanged with respect to Excel.
On Feb 11, 2008 8:45 AM, Rob Goedman <goedman at mac.com> wrote: