In order to aid myself with displaying debugging information, I decided to create the following tiny function that would dynamically switch between displaying data in RStudio's internal data browser and simple character-based output, depending on capabilities of the platform, where my modules are being sourced at:
View <- function (...) {
if (.Platform$GUI == "RStudio")
View(...)
else
print(...)
}
This function is located, along with other utility functions, in the module <PROJ_HOME>/utils/debug.R. All modules that need these functions, include it via source("../utils/debug.R").
Running my project's code on my Amazon EC2 instance's Linux console is fine. However, running it on the same virtual machine via RStudio Server results in the following error message:
Error: evaluation nested too deeply: infinite recursion / options(expressions=)?
Error during wrapup: evaluation nested too deeply: infinite recursion / options(expressions=)?
It seems to me that R gets confused as to which View() function needs to be called. Initially, I assumed that RStudio overloads the utils::View() and I tried to call it explicitly, but it failed. Then I thought that RStudio somehow defines its View() implementation in global environment, so that it just needs to be called View() without package/library reference. However, as I you see, it doesn't work either. Another potential reason of the error might be that I overestimated the "smartness" of R in terms of my use of ... arguments.
So, what is wrong and how to fix it?
RStudio hooks the View function. One approach might be to see if anyone has overridden the View function from utils, and to call the override if it exists. What about this?
View <- if (identical(utils::View, View)) print else View
Related
I am developing a small R package to define custom color palettes. I have two functions that I expose to the user with the #export roxygen/doxygen tag. Both of these functions rely on an internal function, which I marked with #keywords internal. When I run devtools::check() I get an error that the examples provided for my two external functions could not be run because the internal function was not found. This happens whether or not I prefix the internal function with my_package:::my_internal_function or not (just my_internal_function). I found this blogpost which states that the example code can be wrapped into a \dontrun{}, which is what I do to avoid the error from R CMD check. however, this seems a bit of a hack. so what is the preferred way to deal with examples that rely on an internal function?
Update:
I cannot reproduce the problem anymore :-/ sorry for the bother, now it seems to run without issues. I don't know what is different now, but kind of problem solved.
In line with this question, the debugger browser does not show me where it has stopped when it is called from within a do.call statement. First it prints all the arguments to the console and then generally the browser is unresponsive leaving no other option than to force quit RStudio. Does anyone have experience with anything equivalent and can point to any fixes?
This also seems to describe a similar issue.
This is likely occurring because you have passed some dataset to a function called using do.call. R's default behavior when an error occurs is to enter debugging mode and print the entire function call for context. However, because do.call deparses each argument before calling the function, this can result in a very long statement, causing R to hang.
To limit the length of the call returned when entering browser() model for debugging, you can set the maximum deparse length:
options(deparse.max.lines = 10)
As of R 4.0, you can limit the length of the function call printed when entering debugging mode without changing other uses of deparse() by setting option traceback.max.lines:
options(traceback.max.lines = 10)
This should prevent the hangs caused by printing deparsed function calls when debugging within functions called by do.call.
A bug has been identified with Rstudio that causes it to hang even when these options are set. You may be able to debug this code within the R console or using other tools.
How can I debug efficiently in R if packages are unknown due to lazy evaluation. I would like to keep the basic browser() functionality as it works great - even with the testthat package. As explained in the following post, --with-keep.source is set for my project in "project options => Build Tools".
To reproduce the behavior, create a package TestDebug containing
myfun <- function(a,b) {return(a+b)}
and a script example.R
{
browser()
TestDebug::myfun(1,2)
}
Edit: The situation where TestDebug::myfun(1,2) calls otherpackage::myfun2(1,2) should be also covered. I think the situation should occur in every "real" package?
The following works for me.
I have my package TestDebug with my function
myfun <- function(a,b) {return(a+b)}
If I run the script
debug(TestDebug::myfun)
TestDebug::myfun(1,2)
The debugger steps right into the source of TestDebug::myfun() not into the :: function as it does when you place a browser() before the call to TestDebug::myfun(1,2).
As you mention in your question: in real-life situations TestDebug::myfun(1,2) often calls otherpackage::myfun2(1,2). If you try to step into otherpackage::myfun2(1,2) you will end up inside the :: function again.
To prevent this I add this functions called inside other functions to the debug index on the fly:
As soon as you are on the line inside TestDebug::myfun() where otherpackage::myfun2(1,2) is called I run debug(otherpackage::myfun2(1,2)) in the console. After that I can step into otherpackage::myfun2(1,2) without problems and end up in the source code of otherpackage::myfun2(1,2). (..and not in the source code of ::)
Don't forget to call undebug(otherpackage::myfun2(1,2)) after you're sure that your problem is not inside otherpackage::myfun2(1,2) to prevent the debugger to jump into otherpackage::myfun2(1,2) the next time it is called.
If you prefer you can also use debugonce(otherpackage::myfun(1,2)) (instead of debug(..)) to only debug a function once.
I have a longer, complex code (>7000 lines) with many nested functions, each of them enclosed in a separate tryCatch. The code works perfectly except for a "pseudo-error":
Error in doWithOneRestart(return(expr), restart): no function to return from, jumping to top level
doWithOneRestart() is internal in R as an element of the tryCatch function. I call it "pseudo-error", because the tryCatch should lead to stop() if an error ocurrs and write the error message in a log file. Instead, this "error" is not stopping the program (actually not influencing it at all) and it is shown only on the console and not written into the log file. Usual debugging procedures did not help, because the error is not reproducible (!): it may ocurr at different processing stages of the program. Changing the warning options to 0 or -1 will not help.
Since the program does the job, this error is not critical. But I would like to understand what is happening. Maybe someone has already experienced the same problem, or could come up with an original debugging strategy ...
Update (28.10.2013):
I found out where the problem came from. It's linked to a problem with java heap overflow (I was using the xlsx package to read Excel files). Among many other problems: although the connection to the Excel file is closed (definitely!), the system considers it as an unused connection (shown in traceback()), tries to close it, but finds out it is already closed: you get the "pseudo-error" described above, and never exactly at the same moment (not reproducible). Using the garbage collector gc() at the right place solved the problem. The script is now running stable for several days.
Advice from Peter Dalgaard on R-help.
The easiest way to get that message is to execute return() from the
top level:
return(1)
You might be trying to return() from source()d file. Or maybe
source()ing something that was intended to be inside a function body
(extraneous '}' characters can do that).
The usual debugging strategies should work: calling traceback() after the error, or setting options(error = recover).
Have an R function ( let's call it MyFunction ) that sometimes crashes the R session , most of the time it does not.
Have to apply this function to a large number of objects in a sequential manner.
for(i in 1:nrow(objects))
{
result[i] <- MyFunction(objects[i]);
}
I'm coming from a C# background - where functions rarely crash the "session" and programmers normally surround such function calls in try - catch blocks. However, in R I've seen some functions that just crash the session and using tryCatch is of no help since the function does not cause an exception but a full blast session crash ;-)
Just wondering what's the best way of "catching" the crash.
I'm considering writing a Python script that calls the R function from Python ( via one of the R-Python connectors ) and catching the R crash in Python. Would that work ?
Any advise ?
Cheers !
Use the mcparallel function from the parallel package to run the function in a forked process. That way, if it crashes R, only the subprocess crashes, and an error is returned to the main process. If you want to apply this function to a large number of objects and collect the results in a list, use mclapply
Hello such behaviour is very rare in my experience. You might not know that there is a debuger that can help you to go step by step in you function.
install.packages('debug') #install the debug package
library(debug)
mtrace(myFunctionToBeDebuged) #this function will start the debuger
mtrace(myFunctionToBeDebuged, FALSE) #to stop the function to be traced
NOTE: when you are in the debuger, should you want to quit it do qqq()