I tried to use dyn.load command for loading external dll libraries, but it close my R session after running the command every time. I'm using windows 10 and here is my R version:
version
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 1.3
year 2015
month 03
day 09
svn rev 67962
language R
version.string R version 3.1.3 (2015-03-09)
nickname Smooth Sidewalk
to test this, here is a simple code to lock screen using windows native dll:
dyn.load("C:\\Windows\\System32\\user32.dll")
.Call("LockWorkStation")
It is locking my screen, but when I log in back, my R session is crashing.
dyn.load() is not meant to be a way to load DLLs in general, but rather to load DLLs created by R's compiler tool chain as described in the Writing R Extensions manual.
DLLs can be used by linking to them in the Makevars.win file
PKG_LIBS = -L$(XXX_DIR)/lib -lxxx
as discussed at the end of section 1.2.1 Using Makevars, but this implies writing C wrappers around the DLL.
I'm not an expert on Windows and R, and it's unusual in R to rely on platform-specific libraries, so please take my comments with a grain of salt.
It seems it is going to work if I change .Call to .C.
I conclude if you know how to run functions in DLL (using .Call, .C, .External or maybe .Fortran)you can use general DLLs in R.
Related
For months I have been working with a script which gathers a bunch of tweets with Rtweets, does an rbind, and then saves the output to an .rds file with saveRDS. Up until now, I had no idea of this "version=" argument so I was not including it. But since last week, I have a problem where when ever I execute:
file <- readRDS("file.rds")
I get the following error:
Error in readRDS("bullshit.rds") :
cannot read workspace version 541346889 written by R 17741.73.84; need R 19777.84.83 or newer
I cannot figure out the solution. I saw something about updating packages, I tried that and it also was unsuccessful. I tried to find out which versions these are, but I cannot find any information about an R version 17741.73.84. I also tried with two different devices, and I got the same error.
Could anyone tell me what is going on, and how could I try fixing it? - It is more important for me to actually be able to read the file, and then I can try saving it on new ways, but the data is not salvageable if the file is lost (I will save it in multiple formats - learnt through the worst way i guess)
This is my current version:
> version
platform x86_64-w64-mingw32
arch x86_64
os mingw32
crt ucrt
system x86_64, mingw32
status
major 4
minor 2.1
year 2022
month 06
day 23
svn rev 82513
language R
version.string R version 4.2.1 (2022-06-23 ucrt)
nickname Funny-Looking Kid
Good day one and all.
I have been using RCurl to load https://raw. tables from our GitHub repository for data cleanup and analysis. Recently (maybe two weeks) every script using:
read.csv(text = getURL())
stopped working, throwing an error as such:
Error in function (type, msg, asError = TRUE) : error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unfortunately my understanding of SSL and related issues is very limited (I still git using login credentials in bash).
The thing is, on my Debian machine at work, the code executes flawlessly. And upon removing geURL() and sticking to simple read.csv(), even the Windows code works.
Which is fine but I have functions dependent on url.exists() which also get broken and I have been unable to find a replacement for that.
version
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 4
minor 0.3
year 2020
month 10
day 10
svn rev 79318
language R
version.string R version 4.0.3 (2020-10-10)
nickname Bunny-Wunnies Freak Out
Thank you in advance for anything that might get me closer to a solution.
The problem is, that the RCurl package for Windows is linked to a very old version of curl (7.40). For reasons I do not know, even the most current packages of RCurl still link to that old version.
In order to use a recent version of curl, you have to install RCurl from the source by using https://cran.r-project.org/bin/windows/Rtools/ .
For compiling RCurl you need to install curl with the relevant header files using "Rtools bash" by the following commands:
pacman -Sy
pacman -S mingw-w64-{i686,x86_64}-curl
After that, you can install RCurl from the source:
install.packages("RCurl", type="source)
After installing either anaconda or jupyter, RStudio now shows some logs when installing packages, which indicate it's using R installed by anaconda, rather than the original version I had installed.
This is not a problem, until I try to install various packages, and I get some maze of frustrating c++ issues (due to graph dependencies).
What I've tried so far
Changed .libPaths() from the anaconda path to the default locations (but this doesn't help for R, only for R libraries)
Question
How can I tell which R installation RStudio is using, and how do I change it (from the anaconda version, back to the vanilla R version I previously had installed)
If you type version in the Rstudio console window it will tell you which version of R you are using...
> version
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 6.3
year 2020
month 02
day 29
svn rev 77875
language R
version.string R version 3.6.3 (2020-02-29)
nickname Holding the Windsock
>
previous relaeases of R can be found here:
https://cran.r-project.org/bin/windows/base/old/
To those still searching for an answer and stumbled here
As listed above, basic info on the current R version is found entering this in the console of your RStudio
version
To view which R version is being used:
R.home() #tells you the R working directory
RSTUDIO_WHICH_R #tells you the source location of the R instance being used
Changing the version of R being used is much trickier. Consulting the official documentation can help, but realistically its easiest on Windows and a hassle on Mac/Linux. There might be some sneakier issues with Mac/Linux profiles and config variables, detailed more here
Best of luck!
I recently updated my macbook to macOS Sierra (Version 10.12.3 (16D32)), and I am no longer able to run R directly from Terminal:
DN51ssqi:~ kjytay$ R
-bash: R: command not found
DN51ssqi:~ kjytay$ R --version
-bash: R: command not found
Opening R from the Applications folder or from RStudio works fine. Anyone experience this issue/has been able to fix it?
Here is my R version information:
platform x86_64-apple-darwin13.4.0
arch x86_64
os darwin13.4.0
system x86_64, darwin13.4.0
status
major 3
minor 3.2
year 2016
month 10
day 31
svn rev 71607
language R
version.string R version 3.3.2 (2016-10-31)
nickname Sincere Pumpkin Patch
This is just a guess, but I'm thinking this is probably an issue with your PATH settings, which might have been overwritten when you upgraded*. Seems worth a try at least. This is from the RStudio support pages**:
R from source (including MacPorts and Homebrew)
When R is installed from CRAN on OS X the R executable is installed at
/usr/bin/R. However, if R is installed directly from source or via a
package manager like MacPorts or Homebrew, then the R executable is
installed to either /usr/local/bin/R (Homebrew) or /opt/local/bin/R
(MacPorts). In order to support these variations, RStudio scans for
the R executable in the following sequence:
/usr/bin/R
/usr/local/bin/R
/opt/local/bin/R
If RStudio is not able to locate R by scanning these locations, it
will fall back to using whatever version of R is located at
/Library/Frameworks/R.framework/.
If RStudio is finding R OK, then you must have it at one of these locations. Make sure these locations are in your $PATH list:
In the Terminal:
echo $PATH
Will display your current PATHs list. If any of the locations in the RStudio quote are missing, you can see if that's where R is located by trying to specify that location. For example:
/usr/local/bin/R
If that works to start R, just add that location to your PATHs list:
export PATH=$PATH:/usr/local/bin
So that OSX knows where to find it!
* It's been noted elsewhere that homebrew breaks, for example, on upgrade to Sierra. Here's a blog post outlining some steps an R user might like to take after the upgrade: http://www.statsblogs.com/2017/01/26/upgrading-to-macos-sierra-nee-osx-for-r-users/
** Here's the support page where the quote is from https://support.rstudio.com/hc/en-us/articles/200486138-Using-Different-Versions-of-R
Using an alternative BLAS for R has several advantages, see e.g. https://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf.
Microsoft R Open https://mran.revolutionanalytics.com/documents/rro/installation/#sysreq is using Intel's MKL instead of the default Reference BLAS to speed up calculations.
My question is:
What would be the exact steps to link Intel's MKL library **manually to R**'s most recent version on Windows (https://cran.r-project.org/bin/windows/base/)?
UPDATE 20-07-2016:
Here is very detailed description on how to build a OpenBLAS-based Rblas.dll for 64-bit R for Windows for R ≥ 3.3.0: http://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
Easier solution than having to recompile R against the Intel MKL libraries on Windows is just to
Install Microsoft R Open from https://mran.microsoft.com/download, which comes with the outdated R version 3.5.3 but also with the Intel MKL multithreaded BLAS libraries
Install the latest version of R from https://cran.r-project.org/bin/windows/base/, i.e. currently R 3.6.2
copy files libiomp5md.dll, Rblas.dll and Rlapack.dll from C:\Program Files\Microsoft\R Open\R-3.5.3\bin\x64 to C:\Program Files\R\R-3.6.2\bin\x64 (you can back up your existing default non-hyperthreaded Rblas.dll and Rlapack.dll files first if you like)
copy Microsoft R Open libraries/packages MicrosoftR, RevoIOQ, RevoMods, RevoUtils, RevoUtilsMath and doParallel from C:\Program Files\Microsoft\R Open\R-3.5.5\library to your default package directory, e.g. C:\Documents\R\win-library\3.6
copy files Rprofile.site and Renviron.site from directory C:\Program Files\Microsoft\R Open\R-3.5.5\etc to C:\Progral Files\R\R-3.6.2\etc
replace line 24 in file Rprofile.site options(repos=r) with options(repos="https://cran.rstudio.com") (or your favourite CRAN repository - you can also use "https://cran.revolutionanalytics.com", the MRO repository that has the latest daily builds of all packages) to make sure that it will install the latest CRAN packages as opposed to the outdated mran.microsoft.com mirror that has outdated package versions, frozen at the 15th of April 2019. Also comment out lines 153, 154 and 155 with a #
Then restart RStudio to check that it works, with small SVD benchmark on my Intel Core i7-4700HQ 2.4GHz 4 core/8 thread laptop:
getMKLthreads()
4
# Singular Value Decomposition
m <- 10000
n <- 2000
A <- matrix (runif (m*n),m,n)
system.time (S <- svd (A,nu=0,nv=0))
user system elapsed
15.20 0.64 4.17
That same benchmark without Intel MKL installed ran at
user system elapsed
35.11 0.10 35.21
so we get a >8 fold speed increase here!
Screenshot of Microsoft R Open 6.2 with Intel MKL up and running:
Alternatively, if you don't like copying files from MRO to your latest R installation, you can also copy the files from the free Intel MKL installation to your R installation to get multithreaded operation (as outlined in the other answer below):
Install Intel MKL from https://software.intel.com/en-us/mkl/choose-download (free)
Copy all the contents from inside these folders
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\mkl
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\compiler
to
C:\Program Files\R\R-3.6.1\bin\x64
Inside the destination folder, create 2 copies of mkl_rt.dll and rename one of them Rblas.dll and the other Rlapack.dll replacing the originals and also keeping mkl_rt.dll.
This will not provide you with the function setMKLthreads() and getMKLthreads() functions though to set the nr of intel MKL threads, as these come with the MRO package RevoUtilsMath. But for most people the default nr of threads set equal to the nr of physical cores will be OK though...
Not sure what's up with Microsoft, and why they are no longer updatig MRO... And why they also dropped Mac OS X support...
I hope that, given that Intel MKL is free now, the R core people will sooner or later provide a precompiled R version that is compiled to use the Intel MKL libs, or possibly detect at run time if Intel MKL is installed, and if it is, use it. I think this is important, especially since the easy availability of a good multithreaded BLAS also determines how one would develop packages - e.g. if a good multithreaded BLAS would be available for all OSes one would veer towards using RcppArmadillo, which falls back on whatever BLAS one has installed (but on Windows would give drastically worse timings if Intel MKL is not installed), and if not RcppEigen would be the best option, as that has its own multithreaded matrix algebra, irrespective of the BLAS against which R is compiled......
On Ubuntu btw it's very easy to make R use Intel MKL, without having to recompile R, as outlined here: https://github.com/eddelbuettel/mkl4deb
PS Slight problem is that running setMKLthreads(4) will crash RStudio (that was already a problem in the official MRO 3.5.3 though) but it does work OK in the R console...
I was able to link R 3.6.0 with custom dlls you create using the builder. Basically you have to export the same symbols Rblas.dll and Rlapack.dll do. Start the Compiler 19.0 Update 4 for Intel 64 Visual Studio 2017 environment command prompt:
Get the symbols:
dumpbin /exports Rblas.dll > Rblas_list
dumpbin /exports Rlapack.dll > Rlapack_list_R
Edit both files deleting the "header" and "footer" and have all the lines with the symbol names (ex.: 248 F7 00138CE0 dgeevx_) be like dgeevx_ (only with the names).
Copy the builder directory to somewhere in your pc and inside it run:
# blas links fine
nmake libintel64 export=..path..\Rblas_list name=Rblas
# save lapack errors in another list
nmake libintel64 export=..path..\Rlapack_list_R name=Rlapack 1> undefined_symbols_list
Edit undefined_symbols_list keep only the names in each line and create a new
list with the difference
findstr /v /g:undefined_symbols_list Rlapack_list_R > Rlapack_list
nmake libintel64 export=..path..\Rlapack_list name=Rlapack
With dumpbin /dependents Rlapack.dll, you can see that they depend on libiomp5md.dll, which you can find inside the redist folder in mkl installation.
Method 2
This method uses more disk space, but it's simpler. Copy all the contents from inside these folders
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\mkl
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\compiler
to
C:\Program Files\R\R-3.6.1\bin\x64
Inside the destination folder, create 2 copies of mkl_rt.dll and rename one of them Rblas.dll and the other Rlapack.dll replacing the originals and also keeping mkl_rt.dll.
just tried for R 3.5.1 installation. I installed Microsoft R Open alongside with the CRAN R and copy libiomp5md.dll and overwrite Rblas.dll, Rlapack.dll from MRO MKL counterparts to link to CRAN R on Windows (similar to another answer above but need to copy the file libiomp5md.dll as well). This worked out fine and the CRAN R runs as fast as MRO according to the version.compare package on Github (https://github.com/andrie/version.compare)
The solution presented by Tom Weenseleers worked for me with the latest R version. Thank you.
I wanted to add something to this discussion, as its related, and I was unsure how to add this to the greater community. Please forgive my descriptions, I am an amateur.
This workaround seems to break at least two other R packages, igraph, and clusterProfiler. Clusterprofiler depends on igraph, so the root cause was igraph. Likely other igraph dependent packages as well.
I am posting this because I found a simple workaround, and after extensive searching I never found this addressed explicitly on any forum, and this may help someone else.
for reference,
clusterProfiler_4.4.4 and igraph_1.3.4
R version 4.2.1, Platform: x86_64-w64-mingw32/x64 (64-bit)
Windows 10 x64 (build 22000)
calling library(igraph) after implementing the above workaround yielded the following error in a popup:
rsession-utf8.exe Entry Point Not Found
The procedure entry point quadmath_snprintf could not be located in the dynamic link library C:Program Files\R\R->4.2.1\library\graph\libs\x64\igraph.dll.
Pressing OK yields an error message in R
Error: package or namespace load failed for ‘igraph’ in inDL(x, >as.logical(local), as.logical(now), ...):
unable to load shared object 'C:/Program Files/R/R->4.2.1/library/igraph/libs/x64/igraph.dll':
LoadLibrary failure: The specified procedure could not be found.
The workaround - When implementing the workaround to use MKL in R, keep the original Rlapack.dll and Rlablas.dll (i simply renamed these i.e Rblas_orig.dll) To use igraph or dependent packages, swap the .dll filenames, such that the two original R blas file has the original name, and the MKL file is renamed (i.e. Rblas_mkl.dll). Restart R, and igraph/clusterprofiler loads fine.
Unfortunately, this will disable the MKL until you revert the .dll filenames again and restart R, but as long as you don't need to use both igraph and MKL at the same time it works, although frustrating.
If anyone finds a better solution please let me know.