I am running R on a highperformance cluster running red hat. When using R in interactive mode I get the typical untranslated key inputs when attempting to use the arrow keys. Eg. ^[[a
Not exactly sure what is going on, especially since I am calling R while in a bash shell where the arrow keys work fine..
Thanks to Ista tip in comment, my guess it that you have libreadline installed before installing R and readline is activated by default
See Appendix C in An Introduction to R
When the GNU readline library is available at the time R is configured
for compilation under UNIX, an inbuilt command line editor allowing
recall, editing and re-submission of prior commands is used. Note that
other versions of readline exist and may be used by the inbuilt
command line editor: this used to happen on macOS.
It can be disabled (useful for usage with ESS1 ) using the startup option --no-readline.
Related
For python jupyter notebooks I am currently using VSCode python extension. However I cannot find any way to use alternative kernels. I am interested in jupyter R kernel in particular.
Is there any way to work with jupyter notebooks using R kernel in VSCode?
Yes, it is possible. It just requires an additional configuration to connect with the R kernel in VSCode.
It's worth noting that, if you prefer, you can use the notebook in VSCode Insiders where there is native support for notebooks in many languages, including R.
If you're using Jupyter in VSCode, firstly install IRkernel (R kernel).
According to the docs, run both lines to perform the installation:
install.packages('IRkernel')
IRkernel::installspec() # to register the kernel in the current R installation
Now, you should:
Reload Window Ctrl + R
Type Ctrl + Shift + P to search for "Jupyter: Create New Blank Notebook"
Click on the button right below ellipsis in upper right corner to choose kernel
Switch to the desired kernel, in this case, R's
That's it!
Agreed with #essicolo, if you are 100% stuck on using vscode this is a no-go.
[About kernels] Sorry, but as of right now this feature is only supported with Python. We are looking at supporting other languages in the future.
Yeah, that's the case for now, even if you start an external server. I hate having to say that, as we really want to support more of the various language kernels. But we started out with a Python focus and we still are pretty locked into that for the near future. Polyglot support is coming, but it won't be right away
per Microsoft Employee IanMatthewHuff
https://github.com/microsoft/vscode-python/issues/5109#issuecomment-480097310
preface - based on the phrasing of your question, I am making the assumption that you are trying to perform IRkernel in-line execution from your text ide without having to use a jupyter notebook / jupyterlab.
That said, if you're willing to go to the dark side, there might be some alternatives:
nteract's Hydrogen kernel for Atom IDE - the only text ide that I'm aware of that still supports execution against IRkernel. I know, I know - it's not vscode but it's as close as you'll probably get for now.
TwoSigma's Beaker notebook - it's been a lonngggg time for me but this a branch of jupyter that used to support polyglot editing, I'm not sure if that's still supported and it seems like you aren't that interested in notebooks anyway.
#testing_22 it works with me too
just add some note from my experience
It will failed If you run IRkernel::installspec() from RStudio or from Jupyter Conda environment failed way
Please run this syntax with VSCode terminal
install.packages('IRkernel')
IRkernel::installspec()
The rest is same, please restart VSCode and select "R" kernel from VSCode
I installed a new version of R but rstudio still uses the old version. The command "which R" is just a shell script and I'm not sure how to get rstudio and the new version of R integrated. R base installed in /usr/share/doc.
Any tips?
Thanks,
Bob
See the RStudio support pages. In particular, for Linux, you have to set the RSTUDIO_WHICH_R environment variable.
As found out in the comments, you're on a Linux system, specifically Linux Mint 17. I can see three basic scenarios here:
You want to ensure RStudio uses a specific version of R when you are launching RStudio from the terminal as a one-time event.
You want to ensure RStudio uses a specific version of R every time you launch RStudio from the terminal.
You want RStudio to use a specific version of R when you launch RStudio from the applications menu (or, equivalently, via something like Synapse).
They are dealt with in turn below. I assume throughout that the path to the R binary you want RStudio to use is /opt/R/3.1.0/bin/R, which you should change as appropriate.
One-time Terminal Launch
After opening a terminal via Ctrl-Alt-T, run
export RSTUDIO_WHICH_R=/opt/R/3.1.0/bin/R
Then, anytime you launch RStudio from the terminal via the rstudio command in that terminal session, it will use the specified R version. However, after you exit, the next time you open the terminal, it will no longer respect that choice.
Every Terminal Launch
Use your favorite text editor to edit the file ~/.bashrc. At the end, on a new line, add
export RSTUDIO_WHICH_R=/opt/R/3.1.0/bin/R
Then, either launch the terminal, or if you already have it open run the command source .bashrc. Then, you can launch RStudio via the command rstudio and it will use the version of R you want.
Launching from the Applications Menu
Use your favorite text editor to edit the file ~/.profile. At the end, on a new line, add
export RSTUDIO_WHICH_R=/opt/R/3.1.0/bin/R
Then you need to log out of your system and log back in. After that, anytime you launch RStudio from the application menu, it will use the specified R version.
I am trying to use gdb to debug compiled code in an R package in the same way as specified in the video: https://vimeo.com/11937905 and Writing R Extensions section 4.4.
These sources say to use the command
R -d gdb when starting R. However, whenever I try to do this I get a message saying WARNING: unknown option '-d' and R is started under normal conditions.
Why isn't R recognizing the -d flag? I am using Windows 10.
As #MatthewLueder has found out himself finally debugging on Windows does not work as on Linux.
A how-to is described in the R for Windows FAQ
The main reason for the missing -d argument in R seems to be that Windows cannot send a signal to a process to interrupt the execution and pass the control to the (gdb) debugger:
Without interrupting R you cannot set a breakpoint.
Without starting R into the R console you cannot load libraries to be debugged (without making your hands dirty).
Therefore R on Windows offers a work-around using RGui instead of R:
gdb /path/to/R-3.x.x/bin/x64/Rgui.exe
(gdb) run
After starting the RGui you are in an R shell and can load your packages
that contain the DLLs to be debugged.
To set breakpoints for debugging you can interrupt R to break into the debugger via a menu item that is only visible if RGui was started with gdb:
Now you can set breakpoints in your code via b a_function_name, enter c to continue R, call the function in R and voilà: gdb shows the breakpoint hit and
you can debug (stepping through the code and printing variable values).
PS: I am currently developing an R package to improve the debugging of C++ code in R packages since it is quite difficult to view the current values of R variables or Rcpp data types in gdb: https://github.com/aryoda/R_CppDebugHelper
I'm using Fedora 21 with GNU Emacs 24.5.1 and ESS version 15.03. In GUI mode I can use C-RET to pass code from an R script I'm editing to an inferior R process (it starts one up if I haven't yet), but that doesn't seem to work in console mode. Now C-RET just creates a new line in my R script. I've tried this using both emacs and emacs-nox installations.
I compiled ESS from source instead of using the outdated version in Fedora's package manager. Could that have anything to do with it?
The problem is that C-RET isn't a valid sequence in the terminal, so the C- is getting ignored and it's just interpreting the RET. See this answer for more explanation. Following some of the links there will take you to some workarounds, but they are not ideal. It doesn't look like there are any ways to completely change this behavior in the terminal (but I'd love to be told I'm wrong).
I'm using a Macbook Pro (Snow Leopard, 10.6.8) and have been a regular emacs user for the past few months. I'm trying to install a modified version of Emacs 24.2 provided here to utilize Emacs Speaks Statistics (ESS) from the downloads page. I currently have 22.1.1:
M-x emacs-version
GNU Emacs 22.1.1 (mac-apple-darwin) of 2011-06-07 on b1030.apple.com
I installed the emacs linked earlier, put it in Applications, and set this in .bashrc:
alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
So it seems like it's working correctly as I wrote and successfully ran a short R program.
M-x emacs-version
GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org
Is this the usual way to upgrade to a "newer version" of Emacs? Sorry if this question seems trivial, but I've never done this before (I typically used emacs on a different computer) and the Installation step on the previous website consists of just one sentence. The all-in-one installation method also isn't explained in the official documentation.
A brief side note while I was searching on the web: I believe calling 'emacs file_name' should open a GUI version, while 'emacs -nw file_name' is the console, so I remain using the terminal. But on my Mac, using emacs has the same effect as using emacs -nw. In other words, I can't get a GUI or separate window to show up. Can anyone confirm that this Super User question has the 'correct' answer? (I don't really have a problem with this, as I hate having another pop-up window, but it would be nice to know for completeness.)
The Emacs that comes with Mac OS X /usr/bin/emacs does not have a graphical interface, just the terminal one, so calling emacs is the same as emacs -nw.
Your upgraded Emacs by default starts with the graphical interface, so you need to specify -nw to force it to use the terminal.
There is no "usual" way to upgrade OS X's default Emacs (i.e. Apple does not provide an upgraded Emacs); what you've done is fine. Or you could install a binary from http://emacsformacosx.com/ or use a package manager like homebrew.