I have been having problems with package loading the last few days on two different machines.
dplyr isn't loaded, so bind_rows isn't found during simInit. Neither are a few packages listed under the reqdPgks, e.g. mgcv. Anyone else experiencing this? I can file an issue, I just thought I'd check if there was some easy fix..> packageVersion('SpaDES.core')
[1] ‘1.0.4.9003’
> packageVersion('Require')
[1] ‘0.0.9.9006’
The
newModule code now does not use bind_rows in the metadata, but old modules will. The simplest ways are either 1) add dplyr to your reqdPkgs or remove the _ in the function call so it is bindrows (in SpaDES.core)
i.e., this is not a bug
search and replace whole github directories on one of our machines? I think it is easier to just tell everyone we know to update the modules they are using now. Alternatively, we mask the
dplyr::bind_rows, which I don't like. Or we temporarily mask dplyr::bind_rows with a message to say, "change it"
It might be my module's fault. I have to do weird things with environments to run
mgcv::gamm, but I don't remember why :confused:
Dear maintainer,
Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_reproducible.html.
Please correct before 2020-12-03 to safely retain your package on CRAN.
Best,
-k
Re: file links in reproducible:
I see in the code that I am confounding things: there are 3 places that file.links could happen.
1) Cache objects (not the file backed rasters, but everything else)
e.g., Cache(mean, 1) should produce the same result as Cache(median, 1), so make a file.link. This is done in reproducible
2) preProcess via getOption("reproducible.inputPaths") ... if you are using this mechanism, and there are 2 preProcess calls that result in the same data file, then make a file.link. This is done in reproducible
3) Cache of file-backed rasters. Check for raster object on disk and if it is identical to one that is already there, then make a file.link. This is NOT currently done.
I don't recall what the decision was to not do the 3rd option. Or whether it was just a case of "not done yet". Can make an issue...
Dear maintainer,
Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_reproducible.html.Please correct before 2021-01-23 to safely retain your package on CRAN.
The CRAN Team
I forgot, I fixed them! Lol!!
Dear maintainer,
Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_reproducible.html.Please correct before 2021-02-06 to safely retain your package on CRAN.
Note that this will be the final reminder.
The CRAN Team
2 replies
this started happening today, after having worked several times (with the same cache call/object):
source("Rscripts/Data_prep/newScripts_inProg/CompileRes_allMetrics.R") ## cache id f240263cfe4a88bc
...(Object to retrieve (f240263cfe4a88bc.rds) is large: 708.5 Mb)
loaded cached result from previous loadResultsMetrics call,
Waiting for 3.4 seconds to retry; the attempt is failing
tries to do it and keeps failing
this, however, works:
loadFromCache(cacheId = "f240263cfe4a88bc")
will post an issue on GitHub
tried restarting R/RStudio/PC, none worked
loadFromCache is working
Does it happen to have lots of file-backed rasters?
I'm easily bypassing this with loadFromCache and I have the feeling it's something to do with my hard drive or something, because it was working fine. Maybe I accessed it so many times that something got corrupted some how.
so I don't think it's waiting for anything, It's just a "normal"
I also just found out the issue is also happening in the ubuntu VBM in the BC cluster - so not a problem related to my HDD
Cache call that used to be running fine.I also just found out the issue is also happening in the ubuntu VBM in the BC cluster - so not a problem related to my HDD
The source version is on CRAN now ... 1.2.6 ...
install.packages("reproducible", type = "source")
The
options("reproducible.inputPaths") is intended to be used across projects ... so it should be set to a place outside the project folders, e.g., for me ~/data. It is not intended to be a "human readable" location. It is simply a common repository so that large objects, e.g., KNN_whatever, only has one copy on a disk drive, no matter how many projects are being run on that disk.options("reproducible.inputPaths" = "~/data")
x-posted in Gitter:
did
I'm getting this error with
did
prepInputs/postProcess change in the way they process and save rasters?I'm getting this error with
gdaldem but the input DEM raster is not supposed to be a brick . I didn't have any issues before - and mind you that "before" is likely many many versions of reproducible ago because I haven't need to prepInputs/postProcess this layer in ages (working from a clean project for the first time in months/years...)slopeRas <- gdaldem(mode = "slope",
# input_dem = filename(sim$DEMRas),
input_dem = "D:/GitHub/FoothillsBurnSeasonality/inputs/DEMRas_NA.tif",
output = file.path(inputPath(sim), "slopeRas.tif"),
output_Raster = TRUE,
compute_edges = TRUE,
p = TRUE)
Error in .local(.Object, ...) :
In addition: Warning message:
In system(cmd, intern = TRUE) :
running command '"C:\Program Files\QGIS 3.16\bin\gdaldem.exe" "slope" "D:/GitHub/FoothillsBurnSeasonality/inputs/DEMRas_NA.tif" "D:/GitHub/FoothillsBurnSeasonality/inputs/slopeRas.tif" -compute_edges -p ' had status 5
Error in .rasterObjectFromFile(x, objecttype = "RasterBrick", ...) :
Cannot create a RasterLayer object from this file.
Browse[1]> sim$DEMRas
class : RasterLayer
dimensions : 1081, 408, 441048 (nrow, ncol, ncell)
resolution : 250, 250 (x, y)
extent : -1405750, -1303750, 6777500, 7047750 (xmin, xmax, ymin, ymax)
crs : +proj=lcc +lat_0=0 +lon_0=-95 +lat_1=49 +lat_2=77 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs
source : D:/GitHub/FoothillsBurnSeasonality/inputs/DEMRas_NA.tif
names : DEMRas_NA
values : 0, 3148.289 (min, max)
Browse[1]> class(sim$DEMRas)
[1] "RasterLayer"
attr(,"package")
[1] "raster"