R script execution of different machines lead to different outcomes - r

I am new to R and I am working on a script which gets data from a REST API, processes it and saves the outcome locally on the machine. So when I execute the script on my machine it works perfectly fine but when I execute the SAME script on a different machine I get an error("missing where TRUE/FALSE needed" if that helps).
I know this is kind of a vague description of the problem but I wouldn't know what else to say besides posting the whole source code...
R, RStudio and all the packages are up-to-date. The script doesn't have any parameters.
I am looking for an explaination why the same script works on machine 1 and fails to run on machine 2.
Am I missing something R-related which might explain this strange behaviour?

I found the origin of the problem:
RStudios locale(check with sessionInfo()) differed on both machines. For some reason the unix time was given in microseconds instead of seconds. I noticed that a function argument was "NA". It seems that the numerical value of that argument was too high und resulted in "NA" which ultimatively resulted in errors.
I used Sys.setlocale("LC_ALL","English") to adjust the settings.

Related

Rcmd check and wrong ZLIB1.dll: How to set environment variables for Rcmd specifically?

I'm running into a weird problem when I want to check (Rcmd check) an R package. Every few steps of the checking process, I receive the following error message:
I can close the message and everything works as expected, but it's pretty annoying to close the message since it pops up every few seconds.
The error stems from fact that R also comes with it's own zlib1.dll (C:\Program Files\R\Tcl\bin64\zlib1.dll) but finds the one from IBM Notes.
This seems to be connected with the PATH environment variable. In PATH, C:\Program Files (x86)\IBM\Notes\ZLIB1.dll appears earlier than the R related directories. I can't change that, since I hhave only rights to alter the user-specific environment variables.
Is there a possibility to tell R specifically, where to search for ZLIB1.dll?
EDIT:
If I change the directory from which RStudio is started, the error does not occur any more, but RStudio does not remember the last used project.

When should I restart R session, GUI or computer?

I use R, Rstudio and Rcpp and I spent over a week debugging some code, that was just giving errors and warnings in unexpected places, in some cases with direct sample code from online or package documentation.
I often restart the R session or Rstudio if there are obvious problems and they usually go away.
But this morning it was really bad to the point were basic R commands would fail and restarting R did nothing. I closed all the Rstudio sessions and restarted the machine for good measure, (which was unnecessary).
When it came back and I re-loaded the sessions everything seems to be working.
Even the some rcpp code I was working on for weeks with outside packages will now compile and run where it gave gibberish errors before.
I have known for a while that R needs to be restarted once in a while, but I know it when basic functions don't run, how can I know earlier.
I am looking for a good general resource or function that can tell me I need to restart because something is not running right. I would be nice if I can also know what to restart.
Whether the R session, the GUI such as Rstudio, all sessions and GUIs or a full machine restart.
For as long as I have been dabbling with or actually using R (ie more than two decades), it has always been recommended to start a clean and fresh session.
Which is why I prefer to work on command-line for tests. When you invoke R, or Rscript, or, in my case, r (from littler) you know you get a fresh session free of possible side-effects. By keeping these tests to the command-line, my main sessions (often multiple instances inside Emacs via ESS, possibly multiple RStudio sessions too) are less affected.
Even RStudio defaults to 'install and restart' when you rebuild a package.
(I will note that a certain development package implies you could cleanly unload a package. That has been debated at length, and I think by now even its authors qualify that claim. I don't really know or case as I don't use it, having had established workflows before it appeared.)
And to add: You almost never need to restart the computer. But a fresh clean process is a something to use often. Your computer can create millions of those for you.

RStudio Project stalls even without running anything

One of my RStudio projects stalls even before I've run any code or loaded any packages or data. I can edit scripts but it won't save them and it won't run code in the console. I am still able to use R from the terminal. After some time (in the range of an hour or so), multiple dialog boxes will pop up with the message Unable to establish connection with R session. I've seen a similar thing before when loading big datasets or running something computationally intensive but never before I've even run any code or loaded any data.
My other Projects don't seem to have the same problem.
I've also filed an issue here on the RStudio github with some screenshots and log files in case that's helpful.
The solution was to update the data.table package. See the issue I filed or this thread on RStudio community

"Invalid BXL stream" in MS-SQL server while executing R scripts

I am executing an R script as ms-sql stored procedure. I'm trying to use the "geosphere" package, however when I execute the stored procedure, I'm getting the error "Invalid BXL stream" and the execution halts. The package is already installed on the machine and simply loading the package causes this error i.e library("geosphere") causes the error.
I can however, use this package independently with R Studio, so there doesn't seem to be any issue with the package.
I know this question is dated but I've run into the same issue multiple times so I wanted to leave my results here.
What I've found in using sp_execute_external_script to run R and Python scripts in MS-SQL 2016/17 is that the BXL error comes for 2 different reasons
Bad data types - Often, SQL doesn't understand the data types being sent out of the script. Usually explicitly casting the data as a certain datatype helps here.
Bad package configuration - Certain packages in the R and Anaconda distributions don't sync well with the stored procedure since the database blocks certain dependencies in these packages. Try reinstalling the package in the SQL installed instance of R or Python.
It seems that your problem falls in the latter category. I hope that helped!
Had a similar issue today but with a different package. Getting "invalid BXL stream from MSSQL stored procedure. However, i found that If i opened up Rterm.exe and typed the command 'require(packagename)' then Rterm crashes with "Rterm frontend has stopped working". This looks like a memory issue - which has also been suggested causes the "invalid BXL stream" error.
However, my issue turned out to be the fact that the dependencies for the packages had not been installed correctly (perhaps you are working through a proxy?).
I basically removed all the library packages that had been created when I first installed the problem package and did a install.packages("packagename"). All started working!
Apologies - just noticed that you stated that the package worked independently with R studio - this is probably an issue with R Memory allocation with SQL - See http://henkvandervalk.com/introducing-microsoft-sql-server-2016-r-services

multiple Rstudio sessions following the use of the parallel package

I've recently run into an issue when using Rstudio-Server that multiple sessions are spawned instead of a single session. In my case (see below) five sessions are created instead of one. This happens even after trying the normal solutions: deleting ~/.rstudio, clearing .GlobalEnv, and restarting R. Note, there is no spawning issue when using the R command prompt.
My belief about the source of this problem is that it is due to a prematurely terminated mclapply. Here are the relevant docs from the parallel package. (discovered after the fact)
It is strongly discouraged to use these functions in GUI or embedded environments, because it leads to several processes sharing the same GUI which will likely cause chaos (and possibly crashes). Child processes should never use on-screen graphics devices.
At least one other person has had the same error as me but there is no documented solution that I can find. As the warning has already been ignored, I would appreciate any pointers that can help me get untangled.
Edit:
I am still encountering the error but was able to catch the ephemeral script sourcing issue that I believe is causing this problem. Unfortunately, I don't know what other files are being sourced and therefore what settings need to be changed. Grrrrr.....

Resources