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
Related
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.
I am using the svDialogs (an R wrapper library for zenity) to create GUI pop-up boxes, and this works fine when I run the code through either R studio, or from an R terminal session (running Ubuntu 16.04).
A minimal example is:
library(svDialogs)
dlgMessage("Hello Stackoverflow!")
However, when I run the code directly through the terminal it does not work:
Rscript --vanilla -e 'source("path/to/file.R")'
The terminal shows that the library loaded, and does not display an error message: but the pop-up does not appear! If I add an additional line after the call to dlgMessage, that line runs. i.e. if I run the modified code
library(svDialogs)
dlgMessage("Hello Stackoverflow!")
print("Goodbye Stackoverflow!")
then the second line does show in the terminal window (i.e. the code is not crashing at dlgMessage).
Happy for solutions not relying on dlgMessage if there is a workarond: I'd previously tried using Zenity natively through R using system() but couldn't get this to work.
R can be run in either interactive or non-interactive modes, with the default depending on whether or not it is assumed that there is a human operator, see documentation for interactive.
When run in non-interactive mode, R will not display any pop-up boxes. The default is that when running code in the terminal, R runs in non-interactive mode. Following the documentation above, this can be overwritten by using the command in linux
R --vanilla --interactive < "path/to/file.R"
Similarly in Windows using --ess with Rterm.exe
Is it possible to determine - from within the script - whether the script is running in the R-GUI (specifically R.app on OS X) or whether it has been called from Terminal/command line (i.e. R --vanilla -f script.R)? If so, how is this possible?
I'm asking because I have a script that can run parallelized (using the doMC library), which should not be used from the GUI. Sometimes I need to further process the data calculated in the script, so I'd like to call the script from the GUI on these occasions.
Perhaps you are looking for interactive()?
In C, you would use the isatty function. If you could find an equivalent function in R (probably in a UNIX or file system library), that should help.
When I run a Julia Script that prints "Hello World" on HTCondor, I get the following error
fatal: error thrown and no exception handler available.
Base.InitError(mod=:Pkg, error=Base.KeyError(key="HOME"))
The code runs without a problem on my local Ubuntu machine. I can run
eval julia --version
in a bash script on condor and the output is
julia version 0.5.0
This problem has been discussed in two places on github: one, two.
ENV["HOME"] is used in a single file and the common recommendation is to modify that. However, I cannot change the julia installation on condor.
Is there a way to fix this on the fly before running a script without sudo?
As #sujeet suggested, it is possible to set environmental parameters in condor. The issue is resolved by adding the following line in the condor submit script
Environment = "HOME=""/tmp"""
, which sets the home directory to the tmp. Julia code runs fine then (as long one is careful not to write to home before resetting it in the script itself).
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).