Hi,
I open the first round for discussions ;)
The attached bundle 'R experimental' is REALLY experimentally!!! So, if you want to try it out, save everything in beforehand!
I tried to write a kind of a daemon which is able to use any TM window as R terminal directly (without applescript, paste©, restart R, etc.).
I was inspired of the ruby testpipe script. I implemented this in Perl, and improved it a bit. I used a named pipe '/tmp/r_in' to communicate with R which runs in --slave mode. Furthermore I have two additional temp files /tmp/r_out and /tmp/r_out.r. It was a bit tricky to get the right access rights and to avoid to parse much text.
Usage: -install this bundle -open a new empty window -set the scope to 'R' -run the bundle command 'Start TM's R session' (crtl+shiftR) ( The terminal opens and executes 'perl $TM_BUNDLE_SUPPORT/bin/runR.pl &'. Leave this terminal window open! Up to now I didn't find a way to invoke such a script from a TM command directly. ) -type in this new empty window
2*3
and press ctrl+enter
in the window now you should see
2*3
[1] 6
and so forth
-now you can declare variables as usual -you can write a function like:
a <- function(x)
{x^4}
and press ctrl+enter
-ctrl+enter or 'execute last command' will look for the last piece of code which begins with '\n> '; everything after that will piped to R (meaning also more than one line)
-ctrl+enter will invoke a macro which tries to set the caret to end of the window (for inserting) and starts 'execute last command' ; I know this solution is terrible but I had no other idea
-'> ?print' or '> ?log2' or '> ?ps' are working (rudimentary but faster than the normal Show R Help)
-to quit write as usual '> q()' and press ctrl+enter and close the Terminal window
-each piped call to R is written as 'try("2*3")'. By using 'try()' I avoid that the pipe will be cancelled after an error. (e.g.: If I write '> a*2' and "a" is not defined you get the error message and the daemon will be cancelled; if you write 'try(a*2)' you get the error message and the pipe is still open)
-stdout and sterr are redirected to stdout
This is the first approach.
I tested it, and the basics are working. If you want to draw something like '> plot(c(1:3))' you have to call '> quartz()' in beforehand to start a graphic device. But this leads to some weird things, so please be careful. In principal it works but it occurs some stack errors. Must be checked!
Keyboard input while running a function e.g. a demo(mathplot) doesn't work. Must be checked how to implement this!?
Questions:
1) Does this also work for others? 2) How to invoke a R session from TM directly? 3) How to set up this R session with a init script (for plot etc.) 4) How can I also kill the perl process after typing '> q()'? 5) How to start several TM R sessions? 6) R's readline function? 7) How to set the caret of my current window at the end of it within a command? 8) ......
Any comment is welcomed as usual
While testing I can see TM advantages as R GUI ;) but there is much to do.
Have a nice day or night
-Hans
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi,
after a period of testing this kind of daemon (perl/ruby) I must say it's hard to catch all eventualities. I solved the problems of synchronisation between TM and R, even if R does not output something, I caught the statement readline(), and and ... but still there are lot of problems. The biggest one is to catch ANY error while typing. I could solve it for normal typos, but, for instance, if I write "qu it" the daemon halted immediately and this could be very crucial (And I have no idea to fix it). An other problem is the statement "source()". That would mean that the source code must also piped through this daemon. Not mentioning R's statement completion if I type "4+" press enter, ... the daemon will give an error, and and and. Now I have a version which works very fast but only with a lot of exceptions.
So, by my opinion, it will cost too much effort to write such a daemon, and finally it ends up with something that R.app does. So why to invent the wheel twice?
Then I went back to communicate with R via AppleScript. I tried out whether a R terminal running in a shell (iTerm) would be fast than R.app, but it seems to me that is not the case.
So my summary is to improve the commands within the default R-bundle is up to now the best choice, but this will be an other thread.
Bye
-Hans