Known Issues & Solutions
If your issue is not listed here, please email Uri about it, or create an issue on groundhog’s github page.
Current issues
Issue #1. Error in readRDS(cran.toc.path) : embedded nul in string: 'multitap ' When using Groundhog 3.0.0 & 3.1.0, installed in R-3.4 or R-3.5 (but not older nor newer R versions), .rds file downloads used by groundhog (e.g.. cran.toc.rds) get corrupted during download. This issue has been fixed, and the fix is included in groundhog V3.1.1 to be uploaded to CRAN in August 2023 (after their recess). In the meantime see https://github.com/CredibilityLab/groundhog/issues/100 for a solution with R-3.1.0. It is possible that this is related to Issue #2 below. Issue #2. Error: package or namespace load failed for ‘groundhog’ For not yet identified reasons, some users get this error message when loading a freshly installed groundhog v>3.0.0 version. It seems to have to do with previous versions of groundhog not fully updating. The full error/warning message reads: library(“groundhog”) Issue #3. Failure to install from source There are two likely causes behind a failure to install from source. Possible cause #1. Missing package in the operating system. MAC example the installation of the package Matrix will fail. Among the copious output in your console you will find this line indicating that gfortran is missing. You just need to install it from here https://mac.r-project.org/tools/, then Old issue #1. Installation fails reading 'the condition has length > 1' With groundhog 3.0.0 a bug was introduced that is manifested when groundhog relies on a backup method for moving packages from installation directory to the directory where packages are used. You can tell if you are relying on the backup method (which has the bug) if you get TRUE when running The bug has been solved but updated groundhog package with it has not been sent to CRAN yet, pending further testing on April 26th or 27th of 2023. The development version with that fix, and which differs from the CRAN version v3.0.0, only in having a fix to this bug, is available from github and can also be installed with Another option is to use the previous version of groundhog till release 3.0.1 hits CRAN. To do that Old Issue #2. Persistent package version conflict With groundhog v<2.0, conflicts with a different version of the same package would sometimes persist after restarting R session (when R Studio would automatically load needed packages) and the solution was to uninstall the packages creating the conflict. Since v2.0 that is handled automatically. Old Issue #3. 'This does not look like a tar archive' With groundhog v<1.5, older Windows machines would produce error ‘This does not look like a tar archive’ when installing binaries.
Error: package or namespace load failed for ‘groundhog’:
.onLoad failed in loadNamespace() for ‘groundhog’, details:
call: readRDS(cran.times.path)
error: error reading from connection
In addition: Warning message:
In readRDS(cran.times.path) : lzma decoding result 10path1<-paste0(path.expand("~"),"/R_groundhog") #find path to folder
unlink(path1,recursive=TRUE) #delete it
A more likely problem is actually unrelated to groundhog. It involves not having a piece of software that R needs to install packages from ‘source’. If you read the error message in your console you are likely to find the piece of software that’s missing indicated.
If on Mac Big Sur OSX 11, you run
groundhog.library('lme4', '2020-12-01')Matrix, and thus lme4, will successfully install.Solved issues, affecting older versions of groundhog
groundhog:::cookie.exists("copy_instead_of_renaming")
install.packages('https://groundhogr.com/groundhog_3.0.0.9001.tar.gz')
meta.groundhog('2023-04-01') will load groundhog 2.2.1