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

[Jon Clayden]

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 at 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:
> 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
> much.
>
> Any comments?
>
> Cheers,
> --Hans
>
>
> ______________________________________________________________________
> For new threads USE THIS: textmate at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
> http://lists.macromates.com/mailman/listinfo/textmate
>