I am asking this question out of curiosity. I have noticed that whenever I boot R, the instance starts up with this error message
As you can see, R boots with the error message "object 'a' not found" Is there any reason for this?
R reads and executes several files at startup, most prominently the ~/.Rprofile file (That is, the file .Rprofile in your home directory). Check these files to see if they contain anything weird.
You can quickly check whether .Rprofile is the culprit by running R with the --vanilla command line argument: this argument prevents the user profile to be read, thus the error should vanish.
Related
I am writing a vignette in RMarkdown and I want to point out a programming mistake.
listofnumbers <- as.list(1:4)
listofnumbers[2] + listofnumbers[3]
This code snippet produces an error:
Error in listofnumbers[2] + listofnumbers[3] : non-numeric argument
to binary operator
However, I am working on a system localised to German. The error message I get is in German:
Error in listofnumbers[2] + listofnumbers[3]: nicht-numerisches Argument für binären Operator
If anyone renders the vignette themselves that may be good. But to pre-render it with the package I would need the English message.
Also, I do not want to change my system settings permanently to English.
I investigated using an output hook. But I do not know how to translate the German message to English.
I am working on Windows 10.
If the environment variable LANGUAGE is set to en, error messages will be displayed in English. This needs to be in place at the time R starts.
If you are using RStudio, then it starts a new copy of R to process vignettes when you click on Knit, so you can do this in the current session using
Sys.setenv(LANGUAGE="en")
That should also work if the vignette is processed when you build the package as long as you start a new session to do the build. By default devtools::build() and related functions do that.
If you are running RMarkdown within the current session (e.g. by calling rmarkdown::render()) that won't work, because it happens too late. In that case you can use OS features to set the environment variable, or set it in the .Renviron file in your home directory as
LANGUAGE=en
Since you say you are on Windows, you have to do this carefully: Windows doesn't like filenames like .Renviron, and may try to change it to something else.
This method should work if you use R CMD build to build your packages outside of RStudio.
I have the API credentials in one separate R script to keep it out of Git. I want to run this script in the beginning of the scripts that actually interact with the different servers. I have successfully used the same strategy for all my global functions.
setwd("G:/script")
source("API_credentials.R") # gives always an error
# > source("API_credentials.R")
# Error: '\s' is an unrecognized escape in character string starting ""g:\s"
source("ProVeg_functions.R") # runs fine
Problem:
Why does the first source() not work, while the second one does? The error message does not make any sense to me.
Solutions tried:
I have tried different escape chars \.
I have tried writing full path & file names.
I have tried putting the file name in as a variable, which gets its
content from a dir() search, to make sure that the file exists and
the name is correctly written.
Order of source() does not change situation.
Isolating the piece of code with error, and restarting R.
upgraded all my packages and R to version 4.0.2.
The API_credentials.r script works fine when run on its own. the Sys.setenv() works fine and I can read the API keys with Sys.getenv().
I am not sure if it is related to my problem, but if I do usethis::edit_r_environ() I can not see my API keys.
Setup
Windows 10, R-Studio 1.3.1093, R version 4.0.2 (2020-06-22)
I mistakenly assumed that the error message was related to the script calling the API_credentials.R, but it actually was an error message indicating an error in the API_credentials.R script. Fixed a typo and all is good.
I am trying to run an executable called swat_edit.exe in R. It works perfectly when I run it directly in the command prompt, and also when I run it directly in the Terminal tab in R. However, when I try to write a function in R to run the executable, I get an error (I get a number of different errors...).
I have tried to use different methods of running the file:
1: I used system("swat_edit"), which returns the following error:
Unhandled Exception: System.IO.IOException: The handle is invalid.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.Console.set_CursorVisible(Boolean value)
at SWEdit.Program.Run(String[] args)
at SWEdit.Program.Main(String[] args)
[1] 17234
2: I used shell("swat_edit"), which returns the exact same error as (1).
3: I used shell.exec("swat_edit"). This works, but it opens the executable in a new window, which then runs for a few seconds and closes (as intended). I need the program to run in the R terminal window so it can run many iterations in the background without disrupting other things. This is not a viable option.
4: I tried using terminalSend(ID,"swat_edit") (from the rstudioapi package). This works in that it sends the command to the terminal window in R. When I move there and hit enter it executes perfectly, running in the terminal window like I want it to. However, I need to run many iterations so this is not viable either. I tried using KeyboardSimulator to go to the Terminal tab and hitting enter (which worked), but this also does not let me use the PC for other purposes while running my code.
5: I tried using terminalExecute("swat_edit"), which returns the following error code:
Error calling capture_console_output: 87
[Process completed]
[Exit code: -532462766]
6: I tried making a python file that runs swat_edit.exe, and then running that file in R. The python file works when I run it by itself, from the command prompt, or from the terminal in R. It does not, however, work when I try to run it in the R terminal using terminalExecute (same error as in (5)).
NOTE: I have another executable called swat.exe (entirely different program) that works with all of the above-mentioned methods.
So in summary: swat_edit.exe runs perfectly in command prompt and R terminal, but does not work when I try to run it using R code (either system(), shell(), or terminalExecute().
I can't figure out the difference between terminalExecute() and typing the string into terminal and hitting enter, but apparently there is something happening in between...
It will be tedious to reproduce this since it uses external programs, but if anyone has any idea about the error messages or how I can copy a string and run it in the terminal without any interference, that would be greatly appreciated.
EDIT: I found a method that solves my problem. I created a .bat file that runs swat_edit minimized. I was able to run this .bat file with the shell function (or any of the other commands I mentioned) in R. This doesn't answer why I was having the issues I described, and it doesn't let me run swat_edit in the R terminal, but it's good enough for me.
The .bat file was simply the following:
"START /MIN /WAIT C:\~\SWAT_Edit.exe"
First, apologies for a lack of a reproducible example, but I cannot really provide one as I believe the problem lies within my network settings. Please treat this question as a call for help in debugging the issue...
After opening in RStudio a project stored on a network drive and running the very first instruction (being it a package load or even a <- 1) I am seeing a really weird output in the console:
> a <- 1
Warning message:
In dir.create(tempPath, recursive = TRUE) :
cannot create dir 'F:\Marketing', reason 'Permission denied'
I have all possible temp dirs set up in user environment variables (TEMP, TMP, TMPDIR) and Sys.getenv() is printing them correctly.
"F:\Marketing" is a valid path on my network drive and it is a root directory of the project.
I have tried to debugonce(dir.create) in .RProfile to see what the tempPath is, but unfortunately this resulted in an "invalid 'envir' argument" error.
After copying the project to a local drive the problem disappears, so this is clearly a network drive/network setup problem, but I do not know where to dig more and my IT dept. is not really useful here...
Any ideas how to debug this warning?
I've often been frustrated by R's cryptic error messages. I'm not talking about during an interactive session, I mean when you're running a script. Error messages don't print out line numbers, and it's often hard to trace the offending line, and the reason for the error (even if you can find the location).
Most recently my R script failed with the the incredibly insightful message: "Execution halted." The way I usually trace such errors is by putting a lot of print statements throughout the script -- but this is a pain. I sometimes have to go through the script line by line in an interactive session to find the error.
Does anyone have a better solution for how to make R error output more informative?
EDIT: Many R-debugging things work for interactive sessions. I'm looking for help on command-line scripts run through Rscript. I'm not in the middle of an R session when the error happens, I'm at the bash shell. I can't run "traceback()"
Try some of the suggestions in this post:
General suggestions for debugging in R
Specifically, findLineNum() and traceback()/setBreakpoint().
#Nathan Well add this line sink(stdout(), type="message") at the beginning of the script and you should get in console message both script content and output along with error message so you can see it as in interactive mode in the console. (you can then also redirect to a log file if you prefer keeping the console "clean")
Have a look at my package tryCatchLog (https://github.com/aryoda/tryCatchLog).
While it is impossible to improve the R error messages directly you can save a lot of time by identifying the exact code line of the error and have actual variables at the moment of the error stored in a dump for "post mortem" analysis!
The main advantages of the tryCatchLog function over tryCatch are
easy logging of errors, warnings and messages into a file or console
warnings do not stop the program execution (tryCatch stops the execution if you pass a warning handler function)
identifies the source of errors and warnings by logging a stack trace with a reference to the source file name and line number (since traceback does not contain the full stack trace)
allows post-mortem analysis after errors by creating a dump file with all variables of the global environment (workspace) and each function called (via dump.frames) - very helpful for batch jobs that you cannot debug on the server directly to reproduce the error!
This will show a more detailed traceback, but not the line number:
options(error = function() {traceback(2, max.lines=100); if(!interactive()) quit(save="no", status=1, runLast=T)})
One way inside a script to get more info on where the error occurred is to redirect R message to the same stream as errors :
sink(stdout(), type="message")
This way you get both messages and errors in the same output so you see which line raised the error...