I'm trying to create error messages similar to those you can find in R package dplyr that don't invoke RStudio's debugger and simply stop and print an informative message.
So for example in RStudio if you use:
library(dplyr)
group_by(blah)
You get an informative error but the debugger is not invoked so the "interruption" to the user is minimal, they realize the issue and fix the code. But when I use
myfunc<-function(val){
if(val>3) stop("This is error", call.=FALSE)
}
myfunc(4)
The debugger is triggered and it's more unpleasant. How do I simply give a nice error message with out starting the debugger? What is the difference in how dplyr is creating error messages and mine? I did look at the GitHub repo but wasn't sure.
Related
When I just open the Rstudio and press entre on the Console, it always give me the warning message
>
Warning message:
In .recacheSubclasses(def#className, def, env) :
undefined subclass "numericVector" of class "Mnumeric"; definition not updated
>
How to get rid of this warning message?
Thank you!
I previously ran boot::boot() function using multicore processing, and after that when I start Rstudio and run the first command, the warning message always appears.
Try these steps:
Update R to the newest version [click here]
Re-install the boot package of whatever packages that face this warning. I suggest the following code for that:
remove.packages('boot')
install.packages('boot', dependencies=T)
library(boot)
Restart your R or Rstudio and try to use your function again. If it bothers you again, you can ignore it using options(warn=-1).
Best of Luck.
From the linux console I run a windows console tool using:
wine console_tool.exe ....
The console tool does not involve any windows. It's output is just textual.
Some output is added repeatedly after a given delay time.
However, besides the output of the console_tool.exe I get repeatedly the following error message also interleaved with the other output:
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
I already tried to export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 but then the only change is that the error message changes:
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
I also attempted to apt install the :i386 version of the libgtk3-nocsd.so.0 but it doesn't seem to exists.
I don't know why a console application may trigger a gtk error message. This is beyond my knowledge.
My preferred goal would be to tell wine that the .exe does not use windows and it does not need to not use gtk for windows emulation at all. However, as this may not be possible, my second preferred goal would be to solve the gtk issue.
Can you help me achieve at least one of those goals?
I do not know what the error messages mean. However, the wineconsole command runs console executable using wine. Example:
wineconsole console_tool.exe
Our automated build process incorporates a grunt task that periodically (more times than I'd like) generates a 6 return code.
According to the grunt web page 6 is a "Warning". Well okay, a warning for what? It's breaking our build since we would only pass on a 0 exit case. I'm looking at wrapping this in a script so I can catch this warning condition and generate a success exit code, though without any idea what the Warning might be I'm hesitant. It appears to work when I get this exit condition but would like a better understanding on what it may be.
Any ideas?
So this turned out to be an issue with grunt-contrib-less. I didn't recognize the associated less compiler error in our build log:
[39mnon_object_property_loadError: Cannot read property 'rules' of undefined in ../../XXXX/styles/modules/SomeLessFile.less on line null, column 0: [31m
Once I found this line a google search quickly found this in GitHub:
And have updated the grunt-contrib-less package. So far so good.
check http://gruntjs.com/api/grunt.fail:
If --stack is specified on the command-line and an error object was
specified, a stack trace will be logged.
Or try to run "grunt --verbose --force"
I started playing with OpenCPU a couple of weeks back and am getting hooked to it. I was able to succesfully install the "knitr" and "opencpu.demo" apps. The issue I am running into is when I try to invoke the R functions I packaged under a new r package and call it from within knitr-app. I get a message saying no such package exists. I ran installed.packages(lib.loc="/usr/lib/R/library") from an R shell and from knitr-app interface and indeed my packages shows up in the former but not in the latter case. No idea whats going on here ! Will greatly appreciate if anyone can answer this.
omments:
when i run find.package("DummyPkg") through the /R/pub/base/identity/json API , I do get back
[
"/usr/lib/R/library/DummyPkg"
]
However the same query from within knitr-app webpage returns:
# write R code here
find.package("DummyPkg")
## Error: there is no package called 'DummyPkg'
The default html page for knitr app has links to opencpu.org server, so the POST was going to public server instead of going to my server, no wonder my packages weren't showing up !
Comments:
when i run find.package("DummyPkg") through the /R/pub/base/identity/json API , I do get back
[
"/usr/lib/R/library/DummyPkg"
]
However the same query from within knitr-app webpage returns:
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...