Hi Hans,
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 - 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 - browser() doesn't seem to work properly, so debug(function) is unusable
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.
HTH, Jon
On 20/12/2007, Hans-Joerg Bibiko bibiko@eva.mpg.de wrote:
Hi. I believe, now it works perfectly in some sense. I fixed the synchronisation by using the expect approach, meaning R must return something after doing the task, such as '> ', '+ ' or ': '. For that reason I had to merge stdout and stderr. Thus the error/warning messages appear in the document, but one can press 'undo' easily. This means further that EACH prompt for a readline command MUST be end of ': '! Otherwise TM blocks (press APPLE+. for cancelling). For all internal R commands is that the case.
I tested it and I provoked fatal errors. Even for fatal errors R asked me to quit (with the option to save the current workspace or not!). I ran big scripts, I ran R inside of R, etc. The daemon interacted stable.
I fixed dozens of tiny things, I added a package manager (for loading/ detaching), a real workspace browser with edit/delete function. edit(), fix() work now BUT these commands must be executed in the background. Otherwise TM will freeze (APPLE+. for cancelling) because I set the editor to 'mate -w'!
I discarded the idea of using an HTML window as a kind of GUI because there're some tiny hitches. I went the TM way by overloading key combinations, e.g. OPT+APPLE+G lists all relevant commands for 'Graphics' etc.
Then my next idea was to speed up that daemon. My approach is to spawn R à la R --encoding=UTF-8 --TMRdaemon 2&> r_out
Fine. That works brilliant. But if I create a ram drive of 80MB and pipe R's output to /tmp/TMRramdisk1/r_out, it's speed up the entire Rdaemon extraordinarily. Auto-completion, inserting of command templates, the output behaviour work almost instantaneously! I never saw that before. But there're two tricky side-effects:
- The ram drive is limited to 80MB. It should be enough, and it'll
cleaned up by each starting of Rdaemon. 2) Detaching a ram drive. If one uses hdiutil detach, well, sometimes it works, sometimes not. It unmounts it all the time but it couldn't eject it, caused by the issue that the device is busy(?). I only can guess that QuickSilver, spotlight, anti-virus programs have a handle to that device. OK. If one restarts Mac that ram drive is gone. If one logs out and in the ram drive will be still there. If I start the Rdaemon the script is checking if that ram drive is available, if not it will create it. Thus one can work as usual, one 'only' looses 80MB of ram.
So, my BIG question is whether we should use a ram drive. By my opinion, yes, because it is so fast and it makes fun. 80MB is not too much.
Any comments?
Cheers, --Hans
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate