I cannot install the R-package BH which I need only to install dplyr afterwards.
The download works but something is wrong with the processing afterwards, as there is no reaction or progress whatsoever. Installation of lubridate (and deinstallation of lubridate) in contrast worked smoothly without any problems.
My output is:
> install.packages("BH")
Installing package into ‘.../R/win-library/3.2’
(as ‘lib’ is unspecified)
versuche URL 'http://cran.univ-paris1.fr/bin/windows/contrib
/3.2/BH_1.58.0-1.zip'
Content type 'application/zip' length 13846684 bytes (13.2 MB)
downloaded 13.2 MB
and then nothing happens.
Any ideas what could be causing this behavior? Are there any prerequisites for the installation of BH?
> sessionInfo()
R version 3.2.1 (2015-06-18)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
[5] LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
BH, as a sizeable subset of Boost Headers is big, as in really big:
edd#max:~$ du -csm /usr/local/lib/R/site-library/BH/
111 /usr/local/lib/R/site-library/BH/
111 total
edd#max:~$
That is 111 megabytes.
You may simply have run our of patience if your Windows (network share ?) was slow in writing the files.
BH is also widely used by other CRAN packages, and there has not been a package on any of the platforms used by CRAN.
So I suggest you maybe place your R package library onto a local hard drive...
If you have an actual bug report, please consider filing an issue ticket against our BH package.
I had this problem -- there were two parts to my fix.
1/ Download the windows binary from CRAN and save to the hard disk. You then select the menu item: Packages >> Install package(s) from local files…
2/ Edit the utils:::unpackPkgZip function to increase the sleep time – so that my virus checker has time to scan it. To implement this, do the following:
trace(utils:::unpackPkgZip, edit=TRUE)
Look for the line Sys.sleep(0.5), toward the bottom of the body of the function; it's a big package so I went for Sys.sleep(10).
If you are still seeing the error: Warning: unable to move temporary installation, try a longer sleep period.
Note that you won't see the edit if you check utils:::unpackPkgZip; that is the unedited version, and it can be restored via untrace(utils:::unpackPkgZip).
So see the edited version, use body(utils:::unpackPkgZip).
Related
I have tried the solutions I found online for this, but none of them seem to work...
Even after installing blogdown from github and updating hugo, I get a timeout error.
remotes::install_github('rstudio/blogdown')
blogdown::update_hugo()
That is, when I run blogdown::serve_site I get this error:
Launching the server via the command: C:\Users\Master\AppData\Roaming\Hugo\hugo.exe server --bind 127.0.0.1 -p 4321 --themesDir themes -t hugo-future-imperfect -D -F --navigateToChanged ERROR: The process "10244" not found. Error: It took more than 30 seconds to launch the server. There may be something wrong. The process has been killed. If the site needs more time to be built and launched, set options(blogdown.server.timeout) to a larger value.
Is there another way to fix this?
What is causing this error?
Thanks!
I have the same problem on Kubuntu 20.10. I installed latest blogdown and hugo serveral days ago. I have blogdown 0.21.47 and hugo 0.79.0 on Kubuntu. Finally, I found a method to fix it.
Close Rstudio
Open terminal
Enter directory of your website
Execute hugo server -D
Press Ctrl C to stop
Open Rstudio
Click Addin -> BLOGDOWN -> Serve Site
I don't know why it works or whether it works in your case. Please test it and let us know whether it works.
I am running into the same problem.
blogdown::serve_site()
wont work:
Error: It took more than 30 seconds to launch the server. An error might have occurred with hugo. You may run blogdown::build_site() and see if it gives more info. If the site is very large and needs more time to be built, set options(blogdown.server.timeout) to a larger value.
although blogdown::build_site() works smoothly. The blogdown::serve_site() function works fine for a newly created project/website.
For repository see here.
Not sure if it is a blogdown, hugo or academic theme issue.
sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17763)
Matrix products: default
locale:
[1] LC_COLLATE=Dutch_Netherlands.1252 LC_CTYPE=Dutch_Netherlands.1252
[3] LC_MONETARY=Dutch_Netherlands.1252 LC_NUMERIC=C
[5] LC_TIME=Dutch_Netherlands.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] servr_0.20
loaded via a namespace (and not attached):
[1] Rcpp_1.0.5 rstudioapi_0.13 knitr_1.30 magrittr_2.0.1 mnormt_2.0.2 pbivnorm_0.6.0
[7] R6_2.5.0 rlang_0.4.9 tools_4.0.3 tmvnsim_1.0-2 xfun_0.19 htmltools_0.5.0
[13] yaml_2.2.1 digest_0.6.27 lavaan_0.6-7 bookdown_0.21 processx_3.4.5 later_1.1.0.1
[19] promises_1.1.1 ps_1.4.0 evaluate_0.14 rmarkdown_2.5 blogdown_0.21.50 compiler_4.0.3
[25] stats4_4.0.3 jsonlite_1.7.1 httpuv_1.5.4
I had the same problem on. Installing "go" (https://golang.org/doc/install) helped - this was missing after my clean install of big sur.
A while back, I created a fork of the RDCOMClient package to keep it working with R 3.6 (https://github.com/dkyleward/RDCOMClient). People are now running into issues again because it won't work with R 4.0. The problem doesn't seem as easy to fix, and I'm hoping for some help.
If I flip Rstudio back to R 3.6 (and rtools35), I can use the package after installing with devtools::install_github(). When I try in R 4.0 (and rtools40), the package builds and I can connect over COM to an application. The first line of code below works, and xl is a COM pointer; however, trying to do anything with it (like set Excel to visible) will crash R.
xl <- RDCOMClient::COMCreate("Excel.Application")
xl[["Visible"]] <- TRUE
Again, the above works in R 3.6.
Is there is a way to continue building with the previous rtools? I came across https://github.com/r-windows/rtools-backports#readme, which talks about using rtools35 to keep building packages, so I have hope, but I don't understand how to make it happen.
Alternatively, if there are minor changes I can make to the R or cpp code that will solve my problem, I'm all ears. I'm a cpp novice, though.
This was a quick fix :
install.packages("RDCOMClient", repos = "http://www.omegahat.net/R")
Install R-4.0.0
Install Rtools35
Edit $R_HOME/etc/x64/Makeconf (for R-4.0.0-x64)
Rcmd INSTALL RDCOMClient
Rik's answer was incredibly helpful and got a version working; however, after spending a day on it, I was able to improve on it. I want to put that here in case I have to do it again. The main improvement is being able to build a working package for both 32- and 64-bit architectures. By default, R installs both, and this makes things easier when installing dependent packages.
The first two steps are the same:
Install R-4.0.0 (https://cran.r-project.org/bin/windows/base/old/4.0.0/R-4.0.0-win.exe)
Install Rtools35 (https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe) in directory c:\Rtools
If (like me) you had already installed rtools40, a system environment variable named RTOOLS40_HOME is created. The first step is to change that to:
C:\rtools
If you don't have rtools40 installed, then create the RTOOLS40_HOME system environment variable.
Two changes are still needed in the make files. These are found in your R installation directory.
In etc\x64\Makeconf, add underscores to match the rtools35 directory structure by setting these values:
MINGW_PREFIX = /mingw_$(WIN)
BINPREF ?= "$(RTOOLS40_ROOT)/mingw_64/bin/"
Do the same in etc\i386\Makeconf:
MINGW_PREFIX = /mingw_$(WIN)
BINPREF ?= "$(RTOOLS40_ROOT)/mingw_32/bin/"
Do not set BINPREF as an environment variable, or this will overwrite the makefile changes (like RTOOLS40_HOME does). With these complete, finish off with the same steps that Rik outlined:
Open windows command prompt and change to the directory that contains the RDCOMClient subdirectory and type:
R CMD INSTALL RDCOMClient –-build RDCOMClient.zip
This installs RDCOMClient in the local installation of R-4.0.0 and additionally creates the file RDCOMClient_0.94-0.zip that can be installed on other systems using the following command:
install.packages("RDCOMClient_0.94-0.zip", repos = NULL, type = "win.binary")
I can confirm that the procedure delineated in the answer above leads in the right direction but a few extra steps may be required. I can also confirm that the procedure below produces a Windows binary file that can be installed and will run under R-4.0.0:
Install R-4.0.0 (https://cran.r-project.org/bin/windows/base/old/4.0.0/R-4.0.0-win.exe)
Install Rtools35 (https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe) in directory c:\Rtools
Edit $R_HOME/etc/x64/Makeconf (for R-4.0.0-x64) by changing
## The rtools40 installer sets RTOOLS40_HOME, default to standard install path
RTOOLS40_HOME ?= c:/rtools40
to
## The rtools40 installer sets RTOOLS40_HOME, default to standard install path
RTOOLS40_HOME ?= c:/rtools
Download RDCOMClient-master.zip from https://github.com/omegahat/RDCOMClient (click the green Clone button and select download zip)
Unpack to a directory named RDCOMClient
Ensure that the following PATH variables are set:
C:\Program Files\R\R-4.0.0\bin\x64 (assuming this is the location where R is installed)
C:\Rtools\bin
C:\Rtools\mingw_64\bin
Add environment variable BINPREF with the following value (the final slash is important):
C:/Rtools/mingw_64/bin/
Open windows command prompt and change to the directory that contains the RDCOMClient subdirectory and type:
R CMD INSTALL RDCOMClient –-build RDCOMClient.zip
This installs RDCOMClient in the local installation of R-4.0.0 and additionally creates the file RDCOMClient_0.94-0.zip that can be installed on other systems using the following command:
install.packages("RDCOMClient_0.94-0.zip", repos = NULL, type = "win.binary")
I am using R 4.1.2 and I found RDCOMClient will crash the R Session and the above solutions were not working.
Then, I further check with the source owner and found out the solution.
https://github.com/omegahat/RDCOMClient/issues/36
Duncantl gave the solution and it works.
dir.create("MyTemp")
remotes::install_github("BSchamberger/RDCOMClient", ref = "main", lib = "MyTemp")
If that is successful, we can then load the newly installed package with
library("RDCOMClient", lib.loc = "MyTemp")
So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.
To use dictionary learning and sparse coding methods, I am trying to install SPArse Modeling Software (spams) package in R. Their instruction says:
Download the .tar.gz file.
After Un-taring the file and entering the newly extracted folder, run the following command:
R CMD INSTALL --html -l \$R\_LIBS spams
In my case, I use
R CMD INSTALL --html -l /Library/Frameworks/R.framework/Resources/library spams
But I receive the following error messages:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__config:593:1: error:
templates must have C++ linkage
Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__config:594:20: error:
explicit specialization of non-template struct '__static_assert_test'
There are many other error messages which highlight some parts of the library codes (like the second error message) which seem to have the same root cause.
I am not sure if it helps but just in case, I am using Command Line Tools (OS X 10.11) Xcode 8 beta 6.
Confirmed. It's buggy code. Likely mixes C and C++ headers inside/outside of C "extern" blocks.
That uses to pass with older compilers. It does not more. You'll probably have to do some minor surgery on it -- helps if you know C(++) and R package structures.
So in short, it is not your use of R CMD INSTALL ... which is at fault here but rather the package you are trying to install. There is a reason we all prefer R software from CRAN as these issues have then been ironed out...
I have a need to make use of Chromium's Compact Language Detector library within a Python script.
AFAIK, there are two projects that leverage this library, but I have been having troubles with getting either of them set up on a Windows 7 machine.
I had some similar problems with Mike McCandless Original Project (GoogleCode), but I then spotted Matt Sanford fork on the same Project (github). For the purpose of this question, I will focus on Matts project, as it seems to have been updated more often (but happy to get an answer that works for either project).
Downloaded the project as a zip, and extracted to my local drive.
Ran vcvarsall.bat from CMD
Then ran the build.win.cmd batch file. This ran ok.
Copied the resulting libcld.lib to ports/python/cld.lib
Tried running the setup.py but it returns with the following against line 12.
exceptions.TypeError: init() keywords must be strings
++EDIT++
Found this issue:
setup.py fails on Windows. The hackish solution to fix this is to make
pkgconfig return the dict {'define_macros': [('WIN32',None)],
'libraries': packages}
Im a bit of a rookie, but not entirely sure on the steps to implement this hack. Can anyone give me some slightly more verbose steps?
Try this patch (works for me):
diff --git a/ports/python/setup.py b/ports/python/setup.py
index e1950c3..889f21a 100644
--- a/ports/python/setup.py
+++ b/ports/python/setup.py
## -9,7 +9,10 ## def pkgconfig(*packages, **kw):
module = Extension('cld',
['pycldmodule.cc'],
- **pkgconfig('cld'))
+ define_macros=[('WIN32', None)],
+ libraries=['libcld'],
+ include_dirs=['..\\..\\'],
+ library_dirs=['..\\..\\'])
setup(name='cld',
version='0.031415',