I have a long calculation running (for days). I can stop it and restart it as desired, as I can save the output and start from where I left off, but I would appreciate the option of doing so without quitting (or force quitting) R, i.e. by just pressing the red stop button in the GUI. However this seems to be impossible in some instances of running the exact same calculation (or sort of calculation): the stop button is greyed out. I would like to know if there's a criterion determining when and why this happens, and a solution to avoid the force quit option.
I'm running R version 3.0.1 (GUI Cocoa 1.61) on a Mac OS 10.7.5,
Thanks
Related
I often include View() statements in my R scripts. If I accidentally forget the closing bracket at the end of the line, and then run the line of code from the script window using ctrl-enter, R just keeps trying to execute the remainder of my script. I don't know why it does that (rather than using the + symbol to prompt me to provide further input).
Moreover, I've tried to stop this by setting break points in my code - I can click on the LHS of the page and a little red circle appears. But the breakpoints don't seem to work - R just ignores them and keeps going.
The only way I can get out of it is by killing the process in the Windows task manager and then going back in afterwards. But it's wasting a lot of time.
Does anyone know how I can fix this please?
Thank you.
In effect, what your function is processing looks like that:
... %>% View(
lm(am~cyl, mtcars)
...
...
As R can't find the bracket for ) it includes remaining statements as input to View and searches for the bracket.
Solutions
Kind of depends on what you want to do with those scripts but if the intention is to run them in the background consider using callr. This package lets you run R from R and offers kill methods to kill the process you started that way.
On Windows pressing Esc should enable you to get back to the console but if it's a memory intense process it may be difficult.
You may try pressing Ctrl+c in order to kill the process.
I was wondering if it was possible to snapshot a workspace, i.e. save state not only of the layout but also of the windows which were opened.
Why do I need this?
Because I switch between different workflows. I may program for a while and then I may want to switch to a different activity, then switch back again to programming. On the average I have up to 7 windows on my workspace.
I need to save RAM for (freeze and lag)-less workflow.
I want to be able to close workspace 1, switch to another - workspace 2, then restore workspace 1 from the point when I had left it.
This should be totally manual, so I still can work on multiple workspaces. I have to control whether I want to close and restore previous workspace session.
When I restore the workspace, it should be just like I had left it, given that I hadn't changed the files or deleted programs that were opened.
Can this be done at all or at least some part of it with any WM?
Is this a stupid idea?
Does not running a graphical UI saves me RAM (how much)? - so maybe the windows should not be killed when closed, but rather run in the background (daemon), like in Tmux.
Earlier I tried i3 and Awesome(briefly). The biggest struggle was the toolbar, manual set up of volume, brightness, language switching control and proper fonts (on Arch Linux), I didn't fully succeed in setting my environment(I skimmed through wikis) so I fled.
Is it easier to set up Awesome in this respect?
Currently I use Cinnamon+Debian, and I'm almost happy with it.
I'd like to use touchpad less and therefore ask for advice.
I'll try to set WM up on VM first for painless transition.
I've done something similar before in i3-wm. I created a keybind to a bash script in my path that opens four terminator terminals on an empty screen. It uses the i3 command i3-msg to tell the window manager how the behavior of the next window opened will change. Here is my script:
terminator # opens terminal, change to the terminal that you use
i3-msg split h # tells i3 that the next window should split screen vertically
terminator # opens terminal
i3-msg split v # tells i3 that next window should split current one horizontally
terminator # opens terminal
i3-msg focus left # Changes selected window to the left one
i3-msg split v # tells i3 that the next window should split screen vertically
terminator
You should be able to take the i3-msg command and use it to control how windows of your applications open.
This is a quick, hacky solution, but it does work.
I hope this was able to help!
phylo
I'm doing some very basic commands in RStudio (in Windows 10), and suddenly/randomly the command prompt ">" disappeared. This is not the first time this has happened for me. Pressing escape, enter, or anything else doesn't get me back the >. Moreover, when I try to close RStudio, it just stays on "quitting r session" and never closes. I tried to embed a screen shot of the console I'm seeing, but I'm not sure if it worked. If anyone can help me with this issue (being able to get back the > and execute commands again) or direct me to another post where this was addressed, I would really appreciate it (otherwise I have to restart my whole system every time to fix it).
I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.
UPDATE (April 2013): As per answer below, RStudio no longer jumps cursor on selection.
I'm running RStudio 0.97.168.
I like to use the script editor in RStudio like a console. Thus, I run a line of code and then edit it a little bit and re-run it. I often also explore objects by selecting some of the code and running the selection and then progressively altering the selection. At present RStudio always moves the cursor after running a line of code. The cursor can move to a variety of places. Typically the cursor moves to the next line of R code, but depending on the context, it could move to the end of the code block or the next line. It's really frustrating having to constantly move the cursor back to where I want it.
While I often appreciate the default cursor movement behaviour, I'd like to have the option to run the selection or the current line without the cursor moving.
I've raised this as a suggestion on RStudio support.
I'd like to be able to have a shortcut key like "Cmd+Alt+Enter" that runs the current line or selection and does not move the cursor in the script editor.
I realise that this is not currently supported, but I was wondering whether there might be some creative hack that could enable the cursor not to move after running a command or even a patch or perhaps some sort of external macro.
For anyone who ends up here in 2020:
Ctrl(or Cmd) + Enter: Will run current line and jump to the next one. If a code portion is selected, run the selected code without jumping further.
Alt + Enter: – Will run the current line of code without moving the cursor to the next line, useful if you want to run it multiple times.
(Source)
For this kind of flexibility, I suggest you use the editor Sublime Text 2, add in the package installer by Will Bond and then install the SublimeREPL package which will allow you to use an R interpreter within ST2 (or BASH prompt, Python / Ruby / whatever interpeter, concurrently if you wish).
You can then alternate between your code and the interpreter without lifting your fingers from the keyboard and your cursor will be at the same point every time when you want to switch back.
Sublime Text will also allow you to write a custom keybinding to automate this task.
I cannot recommend using Sublime Text 2 highly enough when coding for R. You can even pass files directly from ST2 into RStudio very easily if you like using the plot panes (very easy to do with the SidebarEnhancements package in ST2).
RStudio is awesome for many things -- especially now with Knitr, builds etc etc. But ST2 with an R REPL is many orders of magnitude more powerful for general code writing / editing than RStudio.
Sorry it's not RStudio specific, but it is a nice workaround!
I updated to version 0.98.83 of RStudio using the daily build section.
It appears that at some point in recent versions of RStudio, the cursor no longer jumps when code is run from a selection in the script window.
That's great news.