I am trying to use the R {forecast} package on Windows using RDotNet.
Question: Is there a way to control the level of logging output across RDotNet/R?
For example, executing the RdotNet code
var accuracy = rengine.Evaluate("accuracy(fcst)").AsNumeric();
causes the result of evaluation to get logged to console (or log file) as well.
Is there a way to control this either in RDotNet or R or {forecast} ?
(I had tried this sometime ago using R 3.1.1 and RdotNet 1.5.15. Recently I upgraded to the latest - R 3.2.2 and RdotNet 1.6.5. I don't recall seeing this in the previous versions.)
The REngine object has a property AutoPrint, set to true by default (mirroring the default behavior of R). Setting it to false will not print things out unless explicitly requested via the print function (I think, as I recall).
You can look at this sample code to see it used. Also, a recent discussion touched on this.
Related
I'm having this weird issue where my target, which interfaces a slightly customized python module (installed with pip install --editable) through reticulate, gives different results when it's being called from an interactive session in R from when targets is being started from the command line directly, even when I make sure the other argument(s) to tar_make are identical (callr_function = NULL, which I use for interactive debugging). The function is deterministic and should be returning the exact same result but isn't.
It's tricky to provide a reproducible example but if truly necessary I'll invest the required time in it. I'd like to get tips on how to debug this and identify the exact issue. I already safeguarded against potential pointer issues; the python object is not getting passed around between different targets/environments (anymore), rather it's immediately used to compute the result of interest. I also checked that the same python version is being used by printing the result of reticulate::pyconfig() to screen. I also verified both approaches are using the same version of the customized module.
Thanks in advance..!
I try to access user32.dll functions in R Session. I used the code:
dyn.load("c://windows//system32//user32.dll")
.External("MessageBeep", 0L)
But R session crashes. According to documentation .External is intended to use during R package creation. However there was no prohibition to use it as shown above.
I am using Windows 8 and RStudio (1.1.453) / R (3.5.0). Could you advise a proper way to call external Windows functions from R session?
Artem,
You are accessing the Win32 C API, thus you can load the user32.dll, and then use the Foreign {base} .C() call too access the Window32 MessageBeep function.
Example Code
dyn.load("c://windows//system32//user32.dll")
.C("MessageBeep")
Runtime Output
> dyn.load("c://windows//system32//user32.dll")
> .C("MessageBeep")
list()
>
You should hear the Windows Message "Beep" - Alas, I have yet to figure out how to include sounds in solutions (Chuckle). I hope the above helps address your problem.
Note: I'd also recommend you take a look at the Rcpp package, I am a big fan.
I'd need to be able to grab data straight from into R without going through using its GUI. I've found that the RSAP package seems to be exactly what I'm looking for.
I followed the steps recommended by Piers and Alvaro Tejada Galindo (made it work on windows environment) and here is where I'm stuck:
managed to compile the RSAP package
managed to install it
everything is looking in good shape when I run library(RSAP)
whatever i try in the RSAPConnect command, my R session crashes without any log or tools to be able to debug.
Of course I've tried a few combinations of arguments in this command, but in every single case it still crashed without me knowing why. It does not matter whether i enter a valid ashost or just aaa for instance, still crashes...
Here is the code I was thinking would work (of course I added stars in there):
conn <- RSAPConnect(ashost = "*****.****.com", sysnr = "00", client = "410",
user = "*****", passwd = "*********", TRACE = "3")
Has anyone experienced something similar ? I don't even know in which direction to look to try and make this work. In fact I'd have expected some error message like "server could not be reach" for instance should the ashost not be right, but none of that happens.
I'd appreciate any assistance on this.
Thanks ahead for your support.
Kind regards
After some talking with Piers Harding, it appears that the segfault happens because of some code changes between previous version and version 3.x, which I use.
M. Alvaro Tejada Galindo also tried to use RSAP on a windows machine like me, but if you read his post, you'll see that he was using R 2.15.0 at the time.
Unfortunately I do not have the skills to locate these changes and make the required adjustments within the RSAP code.
Piers did confirm though that RSAP is still working great using R latest build for linux.
Lastly, for those like me who struggled to find the NW RFC library, you can find it on GitHub.
If this can help anyone...
Well I thought I'd add this as another answer.
It is possible to code some vba embedded in an excel file to go fetch stuff into SAP. The interesting part is that I just ran into some code to run a specific vba macro from a specific excel file, all from R :
# Open a specific workbook in Excel:
xlApp <- COMCreate("Excel.Application")
xlWbk <- xlApp$Workbooks()$Open("C:\\Excel_file.xlsm")
# Run the macro called "MyMacro"
vxlApp$Run("MyMacro")
# Close the workbook (and save it) and quit the app:
xlWbk$Close(TRUE)
vxlApp$Quit()
# Release resources:
rm(xlWbk, xlApp)
So in the end, if your macro is set up to grab and store the SAP data, all you have to do next is just read this file using XLConnect or any other package as you'd normally do, and you're all set !
This is an issue I am encountering for different pieces of codes I am writing in R.
Basically, I would like to generate a window that displays a picture (a .png file). Following for instance guidances from this or this, I come up with this kind of code:
library(tcltk)
tmpFile <- tempfile(fileext = ".png")
download.file("https://www.r-project.org/logo/Rlogo.png", tmpFile)
tcl("image","create","photo", "imageLogo", file=tmpFile)
win1 <- tktoplevel()
tkpack(ttklabel(win1, image="imageLogo", compound="image"))
This works fine under Mac OS, but not on Linux nor on Windows, where I am displayed such an error message:
[tcl] couldn't recognize data in image file
I can find some workarounds when I want to display graphs, using for instance packages tkrplot or igraph. Nonetheless, I would be really eager to understand why I got such errors when running my scripts on Linux or Windows, whereas it works just fine on Mac OS.
Apologies in case this issue is obvious, but I haven't found anything about potential differences with the tcltk package depending on the OS.
Tk's native support for PNG was added in 8.6. Prior to that, you need to have the tkimg extension loaded into Tk to add the image format handler required. If your installation of Tcl/Tk that R is using is set up right, you can probably make it work with:
tclRequire("Img")
once you've initialised things sufficiently. Yes, the name used internally is “Img” for historical reasons, but that's just impossible to search for! (This is the key thing in this mailing list message from way back.)
However, upgrading the versions of Tcl and Tk to 8.6 is likely to be a better move.
Finally and a bit lately, I would like to close this issue and sum up the different suggestions that were kindly made in response of my question:
R comes along with Tcl 8.5, even with the latest version 3.3.2, which means that there is no way for embedding a PNG file with the usual command into a window created thanks to Tcl/Tk. For some reasons it is working on Mac OS, but do not expect this to work easily on other OSs.
In order to display pictures, graphs, etc. in a window generated by Tcl/Tk in R, better look for either using the GIF support (when possible) or trying alternative solutions (see the question for possible alternative options).
In case one really wants to display PNG files, the solution consists of installing Tcl 8.5 (for instance ActiveTcl) along with the extension Img. In order to use the Tcl/Tk package that you've just installed on your computer, you can refer to the R FAQ for Windows for instance (as stated in the FAQ, you need to install Tcl 8.5 - I tried with Tcl 8.6, thereby hoping to solve my issue, but it didn't work). Basically, you need to set up an environment variable (MY_TCLTK) and put the path where the package Tcl/Tk is installed. Needless to be said, Tcl/Tk is commonly used in R in order to implement GUIs; if you have to go through very complex procedures to set up the system, the package definitely loses its advantages.
Finally, since Tcl 8.6 should be available soon or later with R (already implemented in the devel version), this issue will be de facto outdated.
I tried to load my R workspace and received this error:
Error: bad restore file magic number (file may be corrupted) -- no data loaded
In addition: Warning message:
file ‘WORKSPACE_Wedding_Weekend_September’ has magic number '#gets'
Use of save versions prior to 2 is deprecated
I'm not particularly interested in the technical details, but mostly in how I caused it and how I can prevent it in the future. Here's some notes on the situation:
I'm running R 2.15.1 on a MacBook Pro running Windows XP on a bootcamp partition.
There is something obviously wrong this workspace file, since it weighs in at only ~80kb while all my others are usually >10,000
Over the weekend I was running an external modeling program in R and storing its output to different objects. I ran several iterations of the model over the course of several days, eg output_Saturday <- call_model()
There is nothing special to the model output, its just a list with slots for betas, VC-matrices, model specification, etc.
I got that error when I accidentally used load() instead of source() or readRDS().
Also worth noting the following from a document by the R Core Team summarizing changes in versions of R after v3.5.0 (here):
R has new serialization format (version 3) which supports custom serialization of
ALTREP framework objects... Serialized data in format 3 cannot be read by versions of R prior to version 3.5.0.
I encountered this issue when I saved a workspace in v3.6.0, and then shared the file with a colleague that was using v3.4.2. I was able to resolve the issue by adding "version=2" to my save function.
Assuming your file is named "myfile.ext"
If the file you're trying to load is not an R-script, for which you would use
source("myfile.ext")
you might try the readRDSfunction and assign it to a variable-name:
my.data <- readRDS("myfile.ext")
The magic number comes from UNIX-type systems where the first few bytes of a file held a marker indicating the file type.
This error indicates you are trying to load a non-valid file type into R. For some reason, R no longer recognizes this file as an R workspace file.
Install the readr package, then use library(readr).
It also occurs when you try to load() an rds object instead of using
object <- readRDS("object.rds")
I got the error when saved with saveRDS() rather than save(). E.g. save(iris, file="data/iris.RData")
This fixed the issue for me. I found this info here
Also note that with save() / load() the object is loaded in with the same name it is initially saved with (i.e you can't rename it until it's already loaded into the R environment under the name it had when you initially saved it).
I had this problem when I saved the Rdata file in an older version of R and then I tried to open in a new one. I solved by updating my R version to the newest.
If you are working with devtools try to save the files with:
devtools::use_data(x, internal = TRUE)
Then, delete all files saved previously.
From doc:
internal If FALSE, saves each object in individual .rda files in the data directory. These are available whenever the package is loaded. If
TRUE, stores all objects in a single R/sysdata.rda file. These objects
are only available within the package.
This error occured when I updated my R and R Studio versions and loaded files I created under my prior version. So I reinstalled my prior R version and everything worked as it should.