While working with GenomicRanges objects, I constantly inspect them to make sense of things, but suddenly find I get errors when trying to view them:
gr <- GRanges(ranges=IRanges(start=c(100, 200), end=c(199, 299)),
seqnames=c("chr2", "chr3"),
strand=c("+", "-"))
gr
gives an error of:
GRanges object with 2 ranges and 0 metadata columns: Error in getListElement(x, i, ...) : IRanges objects don't support [[, as.list(), lapply(), or unlist() at the moment
Subsetting doesn't work either (gr[1] fails). However, I can convert them to a dataframe for viewing:
as.data.frame(gr)
seqnames start end width strand
1 chr2 100 199 100 +
2 chr3 200 299 100 -
but that's fairly awkward. The latest documentation indicates that simply calling the object name should list a few lines of the object. What is the current proper way to inspect the object? Should I interpret the "at the moment" part of the error message quite literally? i.e. things will return to normal at any moment? Please help.
sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)
Matrix products: default
BLAS: /n/apps/CentOS7/install/r-3.6.1/lib64/R/lib/libRblas.so
LAPACK: /n/apps/CentOS7/install/r-3.6.1/lib64/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] parallel stats4 stats graphics grDevices utils datasets methods base
other attached packages:
[1] GenomicRanges_1.38.0 GenomeInfoDb_1.22.0 IRanges_2.20.0 S4Vectors_0.24.4
[5] BiocGenerics_0.32.0 RColorBrewer_1.1-2
loaded via a namespace (and not attached):
[1] Rcpp_1.0.4.6 digest_0.6.22 bitops_1.0-6
[4] evaluate_0.14 zlibbioc_1.32.0 rlang_0.4.1
[7] XVector_0.26.0 rmarkdown_1.16 tools_3.6.1
[10] RCurl_1.95-4.12 xfun_0.10 yaml_2.2.0
[13] compiler_3.6.1 htmltools_0.4.0 knitr_1.25
[16] GenomeInfoDbData_1.2.2
Martin,
Do you advise as good admin practice in managing a largish site-wide R library that whenever we install a new library (e.g. at end-user request) we take all available upgrades to other packages at that time? e.g.
BiocManager::install('newLibrary',update=TRUE,ask=FALSE)Chris & I are users of an installation which now has 686 'out-of-date' packages. My (perhaps old) understanding is that they are generally tolerated as long as they are 'consistent' with the version of Bioconductor. BTW, I used to admin our site R lib installation but no longer do, so may have fallen somewhat out of touch with subtleties and best practices for managing a largish shared installation.
Thanks for your advice. ~ Malcolm
Chris,
I took a quick look at what was added to our site-wide installation most recently, since this cropped up on Friday, and noticed updated versions of S4Vectors and BiocGenerics, along with a few others in our ../r-3.6.1/lib64/R/library:
Seeing then that IRanges is among the 688 reported as "out of date",
I did a
into my home ~/R libraries which resolved the issue for me personally (Chris' example of the problem now works).
This should work for you as a short-term fix.
Especially if Martin agrees, the longer-term fix is to ask our admins to adopt the practice of updating all packages whenever any library is installed or updated. (This had been my practice when I pulled the strings, FWIW).
I think what has happened is that .libPaths() points to a location originally populated with R-3.6.x / Bioc 3.10 (for example) and now used by R-4.0.x / Bioc 3.11. The ~700 out-of-date packages were probably installed under a previous Bioc version; I doubt that more than several 10's of 'release' packages are updated. I would instead recommend a 'one library, one Bioc version' policy, where each version of Bioconductor has it's own library.
If I were managing a shared installation, I think I would keep it current via a daily cron job or similar, rather than 'on request'. I'd make sure that the policy was as public as possible, and would provide users desiring more complete reproducibility with some mechanism to 'snapshot' a particular collection of packages.
I wrote a short (probably buggy) script that suggests that about 249 Bioconductor packages were updated during the 3.10 release cycle, so ~700 packages out-of-date probably represents either multiple releases, or a significant number of CRAN dependencies that are also installed / have been updated.
I expect you are correct.
Thanks for your thoughts on our situation and appropriate practices. I agree with your emphasis on broadly and publically advertising the policy, and its results, to the user base.
I will take your suggestions up with our admins.
Regards...
I expect you are correct.
Thanks for your thoughts on our situation and appropriate practices. I agree with your emphasis on broadly and publically advertising the policy, and its results, to the user base.
I will take your suggestions up with our admins.
Regards...