MonetDB embedded R code debugging - r

In my efforts to work around the issue mentioned here:
MonetDB connect to GO.db within R code that is run in-database
I went ahead and copied the code from WGCNA that I needed to my own package and installed it. Obviously, I now can load the package without any issues (since I didn't need the GO.db part).
However, I seem to run into another issue:
Server says '!Error running R expression. Error message: Error in
.C("corFast", x = as.double(x), nrow = as.integer(nrow(x)), ncolx =
as.integer(ncol(x)), : '.
I indeed wanted to use the faster cor function from WGCNA, but apparently the C call now creates another issue.
Unfortunately, the message is not informative. I already tried to run the query interactively and adding debug to the statement. This did not provide me with more information.
Is there anything that I can do to increase the verbosity, so that I can debug the proces?
I also tried:
options(monetdb.debug.query=F)
This resulted in a bit of extra output prior to the query, but no extra output on the error that occurred.
Using the suggestion of Hannes Muehleisen I added:
options(monetdb.debug.mapi=T)
It does add a little more information, which allowed me to proceed a bit further. I am now stuck with the following error, which seems again truncated.
QQ: 'SELECT * FROM cor_test();' TX: 'sSELECT * FROM cor_test(); ; RX:
'!Error running R expression. Error message: Error in .C("corFast", x
= as.double(x), nrow = as.integer(nrow(x)), ncolx = as.integer(ncol(x)), : ! "corFast" not available for .C() for
package "MRMRF Error in .local(conn, statement, ...) : Unable to
execute statement 'SELECT * FROM cor_test();'. Server says '!Error
running R expression. Error message: Error in .C("corFast", x =
as.double(x), nrow = as.integer(nrow(x)), ncolx = as.integer(ncol(x)),
: '.

Yes this is a known issue where only the first line of the error message is returned. We should fix this. I always use stop(whatever) to return some info from within the UDF.

Related

Error when using ggstatsplot - Error in 'mutate()': Caused by error in vapply()':

Just installed ggstatsplot and tried running the Example in the Documentation to just see what inputs it requires and how to manipulate the function.
library(ggstatsplot)
ggbetweenstats(mtcars, am, mpg)
I was immediately met with the error:
Error in `mutate()`:
! Problem while computing `n_label = paste0(am, "\n(n = ", .prettyNum(n), ")")`.
Caused by error in `vapply()`:
! values must be length 1,
but FUN(X[[1]]) result is length 3
I have tried multiple examples I found online of how to use the package and all result in the same error. I also tried ggwithinstats and received the same error. I updated all of my packages and have restarted R Studio at each step.
Any help would be appreciated, please let me know if I can provide any other information.
Sorry for the troubles.
This is due to update to insight package (https://github.com/IndrajeetPatil/ggstatsplot/issues/749).
EDIT on 21 May 22:
Both statsExpressions and ggstatsplot updates are now on CRAN, so all these issues should go away.
I get the exact same error.
#for reproducibility and data
set.seed(123)
library(WRS2)
library(ggstatsplot)
ggwithinstats(
data = bugs_long,
x = condition,
y = desire
)
May it is a bug?

Spotfire TERR text mining error: "name must be a single string"

I am trying to create a script that does text mining (tm) combining property and action controls with TERR.
I have run my script successfully in open-source R but keep getting an error in TERR. I have narrowed down the function causing the error to VCorpus, part of the tm package. Here is the portion of the script causing errors:
myinput <- do.call(paste, c(as.list(col1), sep=" "))
Col1 is a document property (string) based on selection from property
control drop down list.
b <- VCorpus(VectorSource(myinput), readerControl = list(language = 'eng'))
... and the error message I get in TERR is:
TIBCO Enterprise Runtime for R returned an error: 'Error in
getS3method("pGetElem", class(x), TRUE) : 'name' must be a single
string'.
I am at this point too.
I can do well using open R engine but in TERR I am trying to solve this error.
I am suspecting about the data format expected by TERR.
Got a solution from Tibco developers community
Answer:
You will not face this error if you use TERR 4.1.
There was a bug which got fixed in version 4.1
Reference :
https://docs.tibco.com/pub/enterprise-runtime-for-R/4.1.0/TIB_terr_4.1.0_relnotes.pdf
See below fix on page 16
TERR-6049 The getS3method function now works when the class argument is of
length greater than 1.

How can I find the mean of three rasters?

I have three dataframes, for which I am trying to find a cell-by-cell mean.
r1<-raster('a.tif')
r2<-raster('b.tif')
r3<-raster('c.tif')
However, doing this is giving me the following error
q<-mean(r1,r2,r3)
or
q<-(r1+r2+r3)/3
Error
Error in .local(.Object, ...) : options(warn) not set
Warning message:
closing unused connection 4 .....
That is a weird error message. Often this type of situation goes away if you restart R without loading an old workspace (which may be stale). If that is what is going on use unlink(".RData"), exit R without saving and start again.
To answer your aside question, yes it is much easier to stack them. E.g.
f <- list.files(pattern='tif$')
s <- stack(f)
x <- sum(s)

Problems building an R package (NAs introduced by coercion)

I have written the Boggler package which includes a Play.Boggle() function that calls, on line 87, a progress bar script using shell:
shell(cmd = sprintf('Rscript.exe R/progress_bar.R "%i"', time.limit + 1), wait=FALSE)
Everything works fine when sourcing the files individually and then calling the main Play.Boggle() function, but when I try to check/build the package (under Win7-64 using RStudio), I get a failure message -- here's what the 00install.out reports:
** preparing package for lazy loading
Warning in eval(expr, envir, enclos) : NAs introduced by coercion
Error in time.limit:0 : NA/NaN argument
To make sure the argument "%i" (time.limit + 1) was correctly passed to the progress_bar.R, I added a cat(time.limit) to the script (commenting the rest out to make sure the package would build without any errors) and directed its output to a log file like this:
'Rscript.exe R/progress_bar.R "%i" > out.log'
Conclusion: the time limit is indeed passed along as expected. So I can't figure out why I get this "NA/NaN argument" error message. It must have something to do with lazy loading, concept that I haven't fully got my head around yet.
So my question is: what can I do to successfully check/build this package with full functionality (including progress_bar.R)?
Note: On github, the progress_bar.R script is there but all its content is commented out so that the package can successfully be installed. The shell(...) function call is still active, doing nothing but executing an empty script.
So the problem arises when trying to build or check, in which case all R scripts are executed, as pointed out by Roland. A simple workaround allows the package to check/build without any problems. The fix is just to add to the progress_bar.R the following lines after it tries to recuperate the commandargs (lines 10-11):
if(time.limit %in% c(NA, NaN))
time.limit <- 10 # or any minimal number
There's surely other ways to go about this. But this being a game programmed for fun, I'll happily go with that patch. Hopefully this can be of help to someone down the road and I won't have wasted 50 precious rep points in vain for that bounty! :D

tryCatch does not catch an error if called though RScript

I'm facing a strange issue in R.
Consider the following code (a really simplified version of the real code but still having the problem) :
library(timeSeries)
tryCatch(
{
specificWeekDay <- 2
currTs <- timeSeries(c(1,2),c('2012-01-01','2012-01-02'),
format='%Y-%m-%d',units='A')
# just 2 dates out of range
start <- time(currTs)[2]+100*24*3600
end <- time(currTs)[2]+110*24*3600
# this line returns an empty timeSeries
currTs <- window(currTs,start=start,end=end)
message("Up to now, everything is OK")
# this is the line with the uncatchable error
currTs[!(as.POSIXlt(time(currTs))$wday %in% specificWeekDay),] <- NA
message("I'm after the bugged line !")
},error=function(e){message(e)})
message("End")
When I run that code in RGui, I correctly get the following output:
Up to now, everything is OK
error in evaluating the argument 'i' in
selecting a method for function '[<-': Error in
as.POSIXlt.numeric(time(currTs)) : 'origin' must be supplied
End
Instead, when I run it through RScript (in windows) using the following line:
RScript.exe --vanilla "myscript.R"
I get this output:
Up to now, everything is OK
Execution interrupted
It seems like RScript crashes...
Any idea about the reason?
Is this a timeSeries package bug, or I'm doing something wrong ?
If the latter, what's the right way to be sure to catch all the errors ?
Thanks in advance.
EDIT :
Here's a smaller example reproducing the issue that doesn't use timeSeries package. To test it, just run it as described above:
library(methods)
# define a generic function
setGeneric("foo",
function(x, ...){standardGeneric("foo")})
# set a method for the generic function
setMethod("foo", signature("character"),
function(x) {x})
tryCatch(
{
foo("abc")
foo(notExisting)
},error=function(e)print(e))
It seems something related to generic method dispatching; when an argument of a method causes an error, the dispatcher cannot find the signature of the method and conseguently raises an exception that tryCatch function seems unable to handle when run through RScript.
Strangely, it doesn't happen for example with print(notExisting); in that case the exception is correctly handled.
Any idea about the reason and how to catch this kind of errors ?
Note:
I'm using R-2.14.2 on Windows 7
The issue is in the way the internal C code implementing S4 method dispatch tries to catch and handle some errors and how the non-interactive case is treated in this approach. A work-around should be in place in R-devel and R-patched soon.
Work-around now committed to R-devel and R-patched.
Information about tryCatch() [that the OP already knew and used but I didn't notice]
I think you are missing that your tryCatch() is not doing anything special with the error, hence you are raising an error in the normal fashion. In interactive use the error is thrown and handled in the usual fashion, but an error inside a script run in a non-interactive session (a la Rscript) will abort the running script.
tryCatch() is a complex function that allows the potential to trap and handle all sorts of events in R, not just errors. However by default it is set up to mimic the standard R error handling procedure; basically allow the error to be thrown and reported by R. If you want R to do anything other than the basic behaviour then you need to add a specific handler for the error:
> e <- simpleError("test error")
> tryCatch(foo, error = function(e) e,
+ finally = writeLines("There was a problem!"))
There was a problem!
<simpleError in doTryCatch(return(expr), name, parentenv, handler): object 'foo'
not found>
I suggest you read ?tryCatch in more detail to understand better what it does.
An alternative is to use try(). To modify your script I would just do:
# this is the line with the uncatchable error
tried <- try(currTs[!(as.POSIXlt(time(currTs))$wday %in% specificWeekDay),] <- NA,
silent = TRUE)
if(inherits(tried, "try-error")) {
writeLines("There was an error!")
} else {
writeLines("Everything worked fine!")
}
The key bit is to save the object returned from try() so you can test the class, and to have try() operate silently. Consider the difference:
> bar <- try(foo)
Error in try(foo) : object 'foo' not found
> bar <- try(foo, silent = TRUE)
> class(bar)
[1] "try-error"
Note that in the first call above, the error is caught and reported as a message. In the second, it is not reported. In both cases an object of class "try-error" is returned.
Internally, try() is written as a single call to tryCatch() which sets up a custom function for the error handler which reports the error as a message and sets up the returned object. You might wish to study the R code for try() as another example of using tryCatch().

Resources