[TxMt] R daemon running 'inside' of TM + QUESTION on ram drive
jon.clayden at gmail.com
Thu Dec 20 14:10:40 UTC 2007
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.
On 20/12/2007, Hans-Joerg Bibiko <bibiko at eva.mpg.de> wrote:
> 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
> I ran big scripts, I ran R inside of R, etc. The daemon interacted
> 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:
> 1) 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
> Any comments?
> For new threads USE THIS: textmate at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
More information about the textmate