[TxMt] R daemon running 'inside' of TM + QUESTION on ram drive

[Charilaos Skiadas]

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