Hi Jorg,
I just started using this and it look pretty sweet so far (though admittedly I haven't gone far ;) ). The only problem I am seeing so far is with plots, the first time they are generated. If the plot window is closed, and I run something like "plot(1:10)", sometimes I get:
326:331: execution error: System Events got an error: NSReceiverEvaluationScriptError: 4 (1) or sometimes 331:336: execution error: System Events got an error: NSReceiverEvaluationScriptError: 4 (1)
Though actually I cannot reproduce this now ;).
Anyway, very nice work! I've been copying and pasting for way too long ;).
I'll let you know if I find any other problems, I tend to use R quite a lot these days.
The only thing that would worry me about the RAM drive idea is the question of handling large data sets. Probably I am misunderstanding how it works, but what happens if you load some data that would take more than 80M?
Best, Haris Skiadas Department of Mathematics and Computer Science Hanover College
On Dec 20, 2007, at 10:42 AM, Hans-Joerg Bibiko wrote:
On 20 Dec 2007, at 15:10, Jon Clayden wrote:
Thanks for the update. You're improving the daemon quite a lot faster than I can try things out, but I've found a few issues:
- You seem to be using ⌘⎋ for autocompletion, but that
conflicts with Front Row
OK. key bindings is the last issue
- Trying to access help by typing '?print' or 'help("print")', for
example, blocks TM waiting for a (very CPU-intensive) perl process that appears to run indefinitely - I know I should be using ⌃H but it would be good if 'help' at least failed cleanly
Is already fixed. As default ?topic shows the HTML page in the default browser, but you also can change this to man pages (which will be cleaned of course)
- browser() doesn't seem to work properly, so debug(function) is
unusable
I already changed the entire process handling. Thus browser(), debug () work but I will fine-tune it a bit because now the prompt will be like:
myf <- function(x) {for(i in 1:10){print(i);a <- i*2;browser()}} myf()
[1] 1 Called from: myf() Browse[1]> |
'|' = caret
If you want to enter something you have to press ENTER first then you can continue typing debug commands. But I believe I will get rid of it ;)
With regard to the RAM drive, my feeling is that it's best not to block out a chunk of memory like that, particularly since older systems on which autocomplete will be slower are also likely to be the ones that can least spare the RAM. Personally, I find it quick enough as it is.
Well, I believe I will manage this by using customisable start options. By doing so the user can choose whether Rdaemon should run on a ram drive or not, including the chance to set the ram size.
Please be a bit patient, but it is really amazing to see how fast Rdaemon is running on a ram drive. It makes really really fun and together with TM's functionality and flexibility it's almost unbeatable ;)
--Hans