When I use fix() in terminal/R Studio the XQuartz version of R data editor is invoked. However this editor is way slower than the one used by the official R.app.
Xquartz R data editor is so slow that I can identify every single update on cells when loading the data with my bare eyes. I have XQuartz 2.7.8, running in Mac OS El Capitan.
I wonder is there anyway to invoke the "official" editor instead of the XQuartz version?
I may or may not be the correct useR to answer this question because I almost never use fix or the function it depends on, edit. I also don't know how to find "the one used by the official R.app". I instead use [<- with logical indexing for my data management "fixes". I'm wondering if you are attempting to do editing operations on large objects, for which invoking a data editor might not be the most efficient strategy?
Nonetheless, I looked at the code of edit and notice that at the top of the function is some OS-specific code that may offer a way to modify your environment:
if (.Platform$OS.type == "unix" && .Platform$GUI != "AQUA")
if (.Platform$GUI == "unknown" || Sys.getenv("DISPLAY") ==
"")
return(edit.default(name, ...))
is.vector.unclass <- function(x) is.vector(unclass(x))
if (length(name) && !all(sapply(name, is.vector.unclass) |
sapply(name, is.factor)))
stop("can only handle vector and factor elements")
if (grepl("darwin", R.version$os))
check_for_XQuartz()
When you are running R.app you get "AQUA" for .Platform$GUI, and for my machine I get "/private/tmp/com.apple.launchd.KImNTikz8K/org.macosforge.xquartz:0" from Sys.getenv("DISPLAY"). You can change that by using Sys.setenv("DISPLAY" = "") or Sys.setenv("DISPLAY" = "quartz")
Related
I am new to programming and I am trying to use parallel processing for R in windows, using an existing code.
Following is the snippet of my code:
if (length(grep("linux", R.version$os)) == 1){
num_cores = detectCores()
impact_list <- mclapply(len_a, impact_func, mc.cores = (num_cores - 1))
}
# else if(length(grep("mingw32", R.version$os)) == 1){
# num_cores = detectCores()
# impact_list <- mclapply(len_a, impact_func, mc.cores = (num_cores - 1))
#
# }
else{
impact_list <- lapply(len_a, impact_func)
}
return(sum(unlist(impact_list, use.names = F)))
This works fine, I am using R on windows so the code enters in 'else' statement and it runs the code using lapply() and not by parallel processing.
I have added the 'else if' statement to make it work for windows. So when I un-comment 'else if' block of code and run it, I am getting an error "'mc.cores' > 1 is not supported on Windows".
Please suggest how can I use parallel processing in windows, so that less time is taken to run the code.
Any help will be appreciated.
(disclaimer: I'm author of the future framework here)
The future.apply package provides parallel versions of R's built-in "apply" functions. It's cross platform, i.e. it works on Linux, macOS, and Windows. The package allows you to often just replace an existing lapply() with a future_lapply() call, e.g.
library(future.apply)
plan(multisession)
your_fcn <- function(len_a) {
impact_list <- future_lapply(len_a, impact_func)
sum(unlist(impact_list, use.names = FALSE))
}
Regarding mclapply() per se: If you use parallel::mclapply() in your code, make sure that there is always an option not to use it. The reason is that it is not guaranteed to work in all environment, that is, it might be unstable and crash R. In R-devel thread 'mclapply returns NULLs on MacOS when running GAM' (https://stat.ethz.ch/pipermail/r-devel/2020-April/079384.html), the author of mclapply() wrote on 2020-04-28:
Do NOT use mcparallel() in packages except as a non-default option that user can set for the reasons Henrik explained. Multicore is intended for HPC applications that need to use many cores for computing-heavy jobs, but it does not play well with RStudio and more importantly you don't know the resource available so only the user can tell you when it's safe to use. Multi-core machines are often shared so using all detected cores is a very bad idea. The user should be able to explicitly enable it, but it should not be enabled by default.
My problem arose when downloading data from EuroSTAT using the R package eurostat:
# Population data by NUTS3
pop_data <- subset(eurostat::get_eurostat("demo_r_pjangrp3", time_format = "num"),
(age == "TOTAL") & (sex == "T") &
(nchar(trimws(geo)) == 5))[, c("time","geo","values")]
#Fejl i eurostat::get_eurostat("demo_r_pjangrp3", time_format = "num") :
# You have no internet connection, please reconnect!
Seaching, I have found out that it is the statement (in the eurostat-package code):
if (curl::has_internet() {stop("You have no inernet connection, please connnect") that cause the problem.
However, I have interconnection and can e.g. ping www.eurostat.eu
I have tried curl::has_internet() on different computers, all with internet connection. On some it work (respond TRUE) on others it don't.
I have talked with our IT department, and we tried if it could be a firewall problem. Removing the firewall, did not solve the problem.
Unfortunately, I am ignorant on network-settings. Hence, when trying to read the documentation for the curl-package I am lost.
Downloading data from EuroSTAT using the command above have worked for the last at least 2 years, and for me the problem arose at the start of 2020 (January 7).
Hope someone can help with this, as downloading population data from EuroSTAT is a mandatory part in more of my/our regular work.
In the special case of curl::has_internet, you don't need to modify the function to return a specific value. It has its own enclosing environment, from which it reads a state variable indicating whether a proxy connection exists. You can modify that state variable instead.
assign("has_internet_via_proxy", TRUE, environment(curl::has_internet))
curl::has_internet() # will always be TRUE
# [1] TRUE
It's difficult to tell without knowing your settings but there are a couple of things to try. This issue has been noted and possibly addressed in a development version which you can install with
install.packages("https://github.com/jeroen/curl/archive/master.tar.gz", repos = NULL)
You could also try updating libcurl, which is the C library for which the R package acts as an R interface. The problem you describe seems to be more common with older versions of libcurl.
If all else fails, you could overwrite the curl::has_internet function like this:
remove_has_internet <- function()
{
unlockBinding(sym = "has_internet", asNamespace("curl"))
assign("has_internet", function() return(TRUE), envir = asNamespace("curl"))
lockBinding(sym = "has_internet", asNamespace("curl"))
}
Now if you run remove_has_internet(), any call to curl::has_internet() will return TRUE for the remainder of your R session. However, this will only work if other curl functionality is working properly with your network settings. If it isn't then you will get other strange errors and should abandon this approach.
If, for any reason, you want to restore the functionality of the original curl::has_internet without restarting an R session, you can do this:
restore_has_internet <- function()
{
unlockBinding(sym = "has_internet", asNamespace("curl"))
assign("has_internet",
function() {!is.null(nslookup("r-project.org", error = FALSE))},
envir = asNamespace("curl"))
lockBinding(sym = "has_internet", asNamespace("curl"))
}
I just got into this problem, so here's an additional solution, blending both previous answers. It's reversible and checks if we actually have internet to avoid bigger problems later.
# old value
op = get("has_internet_via_proxy", environment(curl::has_internet))
# check for internet
np = !is.null(curl::nslookup("r-project.org", error = FALSE))
assign("has_internet_via_proxy", np, environment(curl::has_internet))
Within a function, this line can be added to automatically revert the process:
on.exit(assign("has_internet_via_proxy", op, environment(curl::has_internet)))
I search for a command to compute Walsh-Hadamard Transform of an image in R, but I don't find anything. In MATLAB fwht use for this. this command implement Walsh-Hadamard Tranform to each row of matrix. Can anyone introduce a similar way to compute Walsh-Hadamard on rows or columns of Matrix in R?
I find a package here:
http://www2.uaem.mx/r-mirror/web/packages/boolfun/boolfun.pdf
But why this package is not available when I want to install it?
Packages that are not maintained get put in the Archive. They get put there when that aren't updated to match changing requirements or start making errors with changing R code base. https://cran.r-project.org/web/packages/boolfun/index.html
It's possible that you might be able to extract useful code from the archive version, despite the relatively ancient version of R that package was written under.
The R code for walshTransform calls an object code routine:
walshTransform <- function ( truthTable ) # /!\ should check truthTable values are in {0,1}
{
len <- log(length(truthTable),base=2)
if( len != round(len) )
stop("bad truth table length")
res <- .Call( "walshTransform",
as.integer(truthTable),
as.integer(len))
res
}
Installing the package succeeded on my Mac, but would require the appropriate toolchain on whatever OS you are working in.
What are the workarounds on Windows to make it so Sys.which finds the proper executables? Two cases that are reoccuring problems:
convert.exe which is both a windows program and the ImageMagik program, but Sys.which only finds the windows one which is never wanted from R no matter how I seem to arrange things on my PATH.
tar.exe is packaged along with various things like git or mingw or whatever, and even when I have Rtools and Rbuildtools first in my path, the tar program from Rtools is never found, for example when installing a package from source.
So, I have resorted to writing a wrapper that calls 7-zip instead whenever I am on windows. This can't be the thing to do can it?
Edit
Actually just adding an environment variable to .Renviron: TAR=path/to/tar.exe works fine for the install.packages example, and I am having trouble remembering where else the tar.exe was biting me, but Josh answered the main one, convert.exe.
I asked a +/- identical question earlier this year over on R-devel. Among the replies was this one, by Henrik Bengtsson, who kindly provided the following useful function:
Sys.which2 <- function(cmd) {
stopifnot(length(cmd) == 1)
if (.Platform$OS.type == "windows") {
suppressWarnings({
pathname <- shell(sprintf("where %s 2> NUL", cmd), intern=TRUE)[1]
})
if (!is.na(pathname)) return(setNames(pathname, cmd))
}
Sys.which(cmd)
}
## Trying out Sys.which & Sys.which2 on my Windows box gives the following:
Sys.which("convert")
# convert
# "C:\\Windows\\system32\\convert.exe"
Sys.which2("convert")
# convert
# "C:\\Program Files\\ImageMagick-6.8.8-Q16\\convert.exe"
I'm really not sure why R-core don't just fix Sys.which() to make it actually portable, but they at least do document root cause of this behavior in ?system (whose functionality is afflicted by the same problem):
The search path for 'command' may be system-dependent: it will
include the R 'bin' directory, the working directory and the
Windows system directories before 'PATH'.
Because Sys.which() is vectorized–and since I think that is useful–I've modified the Henrik Bengtsson code in the following function sys_which(), which should be a more robust and more similar version of Sys.which():
## check if unix
is_unix <- function() grepl("unix", .Platform$OS.type, ignore.case = TRUE)
## robust version of Sys.which
sys_which <- function(x) {
if (is_unix()) {
return(Sys.which(x))
}
sys_win <- function(x) {
if (grepl("\\S", path <- Sys.which(x))) {
return(path)
}
path <- tryCatch(
suppressWarnings(system(sprintf("where %s", x), intern = TRUE)[1]),
warning = function(w) "",
error = function(e) "")
if (!grepl("\\S", path)) {
return(`names<-`("", x))
}
`names<-`(path, x)
}
vapply(x, sys_win, character(1))
}
This has the following advantages:
It's vectorized–sys_which() can handle a vector (one or more input values) e.g., sys_which(c("python", "python3"))
It's more error resistant–use of tryCatch(...) ensures any inputs that result in an error from the system call get passed on to the normal Sys.which() function.
Example:
> sys_which(c("python", "python2.7", "python3", "asdf"))
#> python python2.7 python3 asdf
#> "/usr/bin/python" "/usr/bin/python2.7" "/usr/local/bin/python3" ""
Different IDEs have quirks, and so it's occasionally useful to be able to know what IDE you are using to run R.
You can test if you are running RStudio by testing for the RSTUDIO environment variable.
is_rstudio <- function()
{
env <- Sys.getenv("RSTUDIO")
!is.null(env) && env == "1"
}
(Or, as Hadley commented, gui <- .Platform$GUI; !is.null(gui) && gui == "RStudio".)
You can test for Revolution R by check for a list named Revo.version in the base environment.
is_revo_r <- function()
{
exists("Revo.version", "package:base", inherits = FALSE) && is.list(Revo.version)
}
Is there a similar check that can be done to see if you are running Architect or StatET?
The closest thing I've found is that by default Architect prepends the path to its embedded copy of Rtools to the PATH environment variable.
strsplit(Sys.getenv("PATH"), ";")[[1]][1]
## [1] "D:\\Program Files\\Architect\\plugins\\eu.openanalytics.architect.rtools.win32.win32_0.9.3.201307232256\\rtools\\bin"
It isn't clear to me how to make a reliable cross-platform test out of this. Can you find a better test?
I haven't found any really nice tests, but there are a couple more signs of tweaking by Architect.
Firstly, it loads a package named rj. We can test for this using
"package:rj" %in% search()
Secondly, it overrides the default graphics device (take a look at getOption("device")). This is an anonymous function, so we can't test by name, but I think the value of the name argument should distinguish it from other devices like windows or png.
device_name <- formals(getOption("device"))$name
!is.null(device_name) && device_name == "rj.gd"
Combining these two tests should be reasonably accurate for checking if you are running Architect.
is_architect <- function()
{
"package:rj" %in% search() &&
!is.null(device_name <- formals(getOption("device"))$name) &&
device_name == "rj.gd"
}