Re: [Bioc-devel] Error when building in command line but not in RStudio
Let's keep this conversation on the bioc-devel mailing list where it started. On 3/25/21 5:31 PM, Xinan Yang wrote: Herve, on March 25, 2021 3:58 PM Hervé Pagès wrote: With Bioconductor packages you push changes to your package git repo at > https://git.bioconductor.org/packages/seq2pathway <https://git.bioconductor.org/packages/seq2pathway>and we do the rest. Thank you for the help. I have a related question. Seq2pathway dependents on a package, called seq2pathway.data, for which AJ also upgraded its supporting genomes. For this data package, should we build new git for it? I don't understand the question. seq2pathway.data is already in Bioconductor in the category of data-experiment packages: https://bioconductor.org/packages/3.13/seq2pathway.data Like with software package seq2pathway, you also need to update seq2pathway.data by pushing your changes to the git repo at https://git.bioconductor.org/packages/seq2pathway.data The build/check report for BioC 3.13 **data-experiment** packages is published here: https://bioconductor.org/checkResults/3.13/data-experiment-LATEST/ Unlike the builds for software packages, which run daily, the data-experiment builds run only twice a week (Mondays and Thursdays). Another difference with software packages is that we only build and distribute source tarballs for the data-experiment packages. No Windows or Mac binaries for these packages. Cheers, H. Thank you, Holly *From:* Bioc-devel on behalf of Hervé Pagès *Sent:* Thursday, March 25, 2021 3:58 PM *To:* AJ Kinstlick ; bioc-devel@r-project.org *Subject:* Re: [Bioc-devel] Error when building in command line but not in RStudio On 3/25/21 1:50 PM, AJ Kinstlick wrote: Any help on this would be greatly appreciated, but once again I'm not sure it's even necessary if I can just build the package in RStudio and submit it to Bioconductor. That's not how Bioconductor works. With Bioconductor packages you push changes to your package git repo at https://git.bioconductor.org/packages/seq2pathway <https://git.bioconductor.org/packages/seq2pathway> and we do the rest. Of course 'R CMD build' needs to work on your package because that's what the daily builds are going to do to produce the source tarball. The daily build/check report for BioC 3.13 is published here: https://bioconductor.org/checkResults/3.13/bioc-LATEST/ <https://bioconductor.org/checkResults/3.13/bioc-LATEST/> Note that seq2pathway is currently broken on nebbiolo1 (Linux builder). Maybe that is the same error that you are seeing when you do 'R CMD build seq2pathway' on your own machine? H. Thank you, AJ Kinstlick [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel <https://stat.ethz.ch/mailman/listinfo/bioc-devel> -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel <https://stat.ethz.ch/mailman/listinfo/bioc-devel> -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Package failed build on Windows - couldn't load related ExperimentHub dataset
@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Error when building in command line but not in RStudio
On 3/25/21 1:50 PM, AJ Kinstlick wrote: Any help on this would be greatly appreciated, but once again I'm not sure it's even necessary if I can just build the package in RStudio and submit it to Bioconductor. That's not how Bioconductor works. With Bioconductor packages you push changes to your package git repo at https://git.bioconductor.org/packages/seq2pathway and we do the rest. Of course 'R CMD build' needs to work on your package because that's what the daily builds are going to do to produce the source tarball. The daily build/check report for BioC 3.13 is published here: https://bioconductor.org/checkResults/3.13/bioc-LATEST/ Note that seq2pathway is currently broken on nebbiolo1 (Linux builder). Maybe that is the same error that you are seeing when you do 'R CMD build seq2pathway' on your own machine? H. Thank you, AJ Kinstlick [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] devel builds are down
Yes, the other devel builds (data-experiment, workflows, and long tests)
are also affected (they were all relying on rex3). I'm slowly moving
things to nebbiolo1. I'll do the workflows next.
H.
On 3/24/21 12:31 PM, James Perkins wrote:
Thanks for the info Hervé,
Has the workflow build been affected? There appears to have been no
build since last Tuesday, I understand there *should* have been one last
night:
https://bioconductor.org/checkResults/3.13/workflows-LATEST/
<https://bioconductor.org/checkResults/3.13/workflows-LATEST/>
Cheers,
Jim
On Wed, 24 Mar 2021 at 19:25, Hervé Pagès <mailto:hpages.on.git...@gmail.com>> wrote:
The devel builds are up and running again, with nebbiolo1 instead of
rex3:
https://bioconductor.org/checkResults/3.13/bioc-LATEST/
<https://bioconductor.org/checkResults/3.13/bioc-LATEST/>
The fate of rex3 is still unclear.
Cheers,
H.
On 3/19/21 1:56 PM, Hervé Pagès wrote:
> Hi maintainers,
>
> If you've not noticed already, the build report for the BioC 3.13
builds
> (devel builds) didn't get updated for the last 3 days:
>
> https://bioconductor.org/checkResults/3.13/bioc-LATEST/
<https://bioconductor.org/checkResults/3.13/bioc-LATEST/>
>
> This is unusual. The reason is that our build machine rex3 has been
> experiencing connectivity issues that have prevented the daily
builds
> from running normally. The problem is being investigated and we'll
> provide updates here as the situation evolves.
>
> Thanks for your patience and sorry for the inconvenience.
>
> H.
>
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com <mailto:hpages.on.git...@gmail.com>
___
Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
--
James R Perkins PhD
Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER)
Department of Molecular Biology and Biochemistry
<https://goo.gl/maps/UCLQXZLR2W12>
Science Faculty, University of Malaga
29071 Malaga, Spain
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] devel builds are down
The devel builds are up and running again, with nebbiolo1 instead of rex3: https://bioconductor.org/checkResults/3.13/bioc-LATEST/ The fate of rex3 is still unclear. Cheers, H. On 3/19/21 1:56 PM, Hervé Pagès wrote: Hi maintainers, If you've not noticed already, the build report for the BioC 3.13 builds (devel builds) didn't get updated for the last 3 days: https://bioconductor.org/checkResults/3.13/bioc-LATEST/ This is unusual. The reason is that our build machine rex3 has been experiencing connectivity issues that have prevented the daily builds from running normally. The problem is being investigated and we'll provide updates here as the situation evolves. Thanks for your patience and sorry for the inconvenience. H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] ChIPseeker failing on r-devel on CRAN checks
Hi Onur, AFAICT ChIPseeker is currently available on all platforms in BioC devel: https://bioconductor.org/packages/3.13/ChIPseeker Same for all the other Bioconductor packages that the CRAN check results for cinaR say are not available: - CRAN check results: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/cinaR-00check.html https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/cinaR-00check.html https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/cinaR-00check.html https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-gcc/cinaR-00check.html - Packages reported as not available are available: pkgs_reported_as_not_available <- c( 'ChIPseeker', 'DESeq2', 'TxDb.Hsapiens.UCSC.hg38.knownGene', 'TxDb.Hsapiens.UCSC.hg19.knownGene', 'TxDb.Mmusculus.UCSC.mm10.knownGene') library(BiocManager) # Bioconductor version 3.13 (BiocManager 1.30.11), ?BiocManager::install for help available_pkgs <- rownames(available.packages(contrib.url(repositories( pkgs_reported_as_not_available %in% available_pkgs # [1] TRUE TRUE TRUE TRUE TRUE So to me it looks like some hiccup in the CRAN builds. H. On 3/23/21 3:12 PM, Onur Karakaslar wrote: Hi all, I have a CRAN package called cinaR which depends on ChIPseeker. Yet, I recently learned that ChIPseeker is actually failing on r-devel checks of CRAN, which possibly fails my package as well. You can find the detailed info here: https://support.bioconductor.org/p/9135778/ Can anyone help me figure this out? Thank you very much for your help! Best, Onur [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Methods to speed up R CMD Check
On 3/23/21 1:31 PM, Murphy, Alan E wrote:
Hi Hervé,
My apologies but I don't think I follow your approach. I have put your
code below into a utils.R script in ewceData:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
get_ExperimentHub <- function()
{
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
eh <- ExperimentHub::ExperimentHub()
.set_eh(eh)
}
eh
}
Then in EWCE, I have made a script for each dataset containing the
function you outlined. Note I had to use ewceData:::get_ExperimentHub to
access the function, not sure if this is wrong by me up to this point:
## Exported.
tt_alzh <- function()
{
eh <- ewceData:::get_ExperimentHub()
eh[["EH5373"]]
}
Lastly to call a dataset I simply use tt_alzh(). However, now when I run
a test script I believe the eh statement is being repeatedly called
still as I get multiple warnings and the runtime doesn't improve any.
'eh' is a variable so I'm not sure how can it be "repeatedly called".
Also not sure why you want to move tt_alzh() from ewceData to EWCE.
Nothing wrong in having it in the former which is actually the natural
place for it.
I made these changes to ewceData (see full patch below, note that I
renamed my tt_alzh -> load_tt_alzh to avoid conflict with your tt_alzh)
and things seem to work as expected for me:
> library(ewceData)
> system.time(tt_alzh <- tt_alzh())
snapshotDate(): 2021-03-23
see ?ewceData and browseVignettes('ewceData') for documentation
loading from cache
user system elapsed
2.441 0.028 4.720
> system.time(tt_alzh <- load_tt_alzh())
see ?ewceData and browseVignettes('ewceData') for documentation
loading from cache
user system elapsed
1.215 0.012 1.727
No warning.
H.
hpages@spectre:~/sandbox/ewceData$ git diff --cached
diff --git a/NAMESPACE b/NAMESPACE
index 0144dc9..8ad9b64 100644
--- a/NAMESPACE
+++ b/NAMESPACE
@@ -6,3 +6,5 @@ import(ExperimentHubData)
import(utils)
importFrom(AnnotationHub,query)
importFrom(utils,read.csv)
+
+export(load_tt_alzh)
diff --git a/R/utils.R b/R/utils.R
new file mode 100644
index 000..c295aef
--- /dev/null
+++ b/R/utils.R
@@ -0,0 +1,15 @@
+.my_internal_global_variables <- new.env(parent=emptyenv())
+
+.get_eh <- function() get("eh", envir=.my_internal_global_variables)
+.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
+
+get_ExperimentHub <- function()
+{
+eh <- try(.get_eh(), silent=TRUE)
+if (inherits(eh, "try-error")) {
+eh <- ExperimentHub::ExperimentHub()
+.set_eh(eh)
+}
+eh
+}
+
diff --git a/R/zzz.R b/R/zzz.R
index cf0d87e..b1159b0 100644
--- a/R/zzz.R
+++ b/R/zzz.R
@@ -34,4 +34,12 @@
assign(xx, func, envir=ns)
namespaceExport(ns, xx)
})
-}
\ No newline at end of file
+}
+
+## Exported.
+load_tt_alzh <- function()
+{
+eh <- get_ExperimentHub()
+eh[["EH5373"]]
+}
Sorry again if I have misinterpreted your approach.
Kind regards,
Alan.
*From:* Hervé Pagès
*Sent:* 23 March 2021 19:08
*To:* Murphy, Alan E ; Martin Morgan
; Kern, Lori ;
bioc-devel@r-project.org
*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
Doesn't really matter where you put them but
.my_internal_global_variables, .get_eh(), .set_eh(), and toto() don't
need to be defined inside the .onLoad() hook, and it's actually
cleaner/easier to not define them there. You can define there anywhere
in your ewceData/R/* files.
Here is a slightly improved version of the code:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
get_ExperimentHub <- function()
{
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
eh <- ExperimentHub::ExperimentHub()
.set_eh(eh)
}
eh
}
In my packages I like to put this kind of low-level stuff in R/utils.R.
None of this is exported.
Then anywhere in your package when you need an ExperimentHub instance, do:
## Exported.
tt_alzh <- function()
{
eh <- get_ExperimentHub()
eh[["EH5373"]]
}
H.
On 3/23/21 10:53 AM, Murphy, Alan E wrote:
HeyHervé,
Thanks for this it is very helpful and I'm very sorry but I have one
more question, where to put option 3? I thought making an onload r
script for it:
.onLoa
Re: [Bioc-devel] Methods to speed up R CMD Check
Doesn't really matter where you put them but
.my_internal_global_variables, .get_eh(), .set_eh(), and toto() don't
need to be defined inside the .onLoad() hook, and it's actually
cleaner/easier to not define them there. You can define there anywhere
in your ewceData/R/* files.
Here is a slightly improved version of the code:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
get_ExperimentHub <- function()
{
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
eh <- ExperimentHub::ExperimentHub()
.set_eh(eh)
}
eh
}
In my packages I like to put this kind of low-level stuff in R/utils.R.
None of this is exported.
Then anywhere in your package when you need an ExperimentHub instance, do:
## Exported.
tt_alzh <- function()
{
eh <- get_ExperimentHub()
eh[["EH5373"]]
}
H.
On 3/23/21 10:53 AM, Murphy, Alan E wrote:
HeyHervé,
Thanks for this it is very helpful and I'm very sorry but I have one
more question, where to put option 3? I thought making an onload r
script for it:
.onLoad <- function(libname, pkgname) {
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
toto <- function()
{
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
eh <- ExperimentHub()
.set_eh(eh)
}
eh
}
toto()
}
This seems to work in that the script runs (I can tell based on the
output with devtools::check()) but I still get an error that eh doesn't
exist in my test functions.
Kind regards,
Alan.
*From:* Hervé Pagès
*Sent:* 23 March 2021 17:31
*To:* Murphy, Alan E ; Martin Morgan
; Kern, Lori ;
bioc-devel@r-project.org
*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
3 ways to do this, one that doesn't work, and two that work ;-)
1. Simple way that doesn't work:
## Just a place holder. Will be initialized at run-time the first
## time it's needed.
.some_internal_global_variable <- NULL
toto <- function()
{
if (is.null(.some_global_variable))
.some_internal_global_variable <<- 55L
}
However, if you put this in your package, you'll get the following
error the first time toto() is called:
cannot change value of locked binding for
'.some_internal_global_variable'
2. Simple way that works: initialize the global variable in the
.onLoad() hook. This works because the .onLoad() hook is executed
right before the package namespace gets locked.
## Just a place holder. Will be initialized at load-time.
.some_internal_global_variable <- NULL
.onLoad <- function(libname, pkgname)
{
.some_internal_global_variable <<- 55L
}
However, I don't really like using this approach when initialization
of the global variable requires access to the internet. It means that
in case of connectivity issue your users won't be able to load the
package and troubleshooting can become really tricky when you can't
even load a package. So in that case I prefer the solution below.
3. Define the internal global variable in an environment:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
toto <- function()
{
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
eh <- ExperimentHub()
.set_eh(eh)
}
eh
}
Hope this helps,
H.
On 3/23/21 10:05 AM, Murphy, Alan E wrote:
Hey Hervé,
I get the idea now thanks for clarifying. Where do I place the call to
ExperimentHub in the package?:
eh <- ExperimentHub() # the only call to ExperimentHub() in
# the entire R session
The package contains calls to the datasets in internal functions,
examples, tests and the vignette so eh it would need to be available to
all. Sorry I don't have much experience using experiment datasets.
Kind regards,
Alan.
*From:* Hervé Pagès
*Sent:* 23 March 2021 16:46
*To:* Murphy, Alan E ; Martin Morgan
; Kern, Lori ;
bioc-devel@r-project.org
*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
***
This email originates
Re: [Bioc-devel] Methods to speed up R CMD Check
3 ways to do this, one that doesn't work, and two that work ;-)
1. Simple way that doesn't work:
## Just a place holder. Will be initialized at run-time the first
## time it's needed.
.some_internal_global_variable <- NULL
toto <- function()
{
if (is.null(.some_global_variable))
.some_internal_global_variable <<- 55L
}
However, if you put this in your package, you'll get the following
error the first time toto() is called:
cannot change value of locked binding for
'.some_internal_global_variable'
2. Simple way that works: initialize the global variable in the
.onLoad() hook. This works because the .onLoad() hook is executed
right before the package namespace gets locked.
## Just a place holder. Will be initialized at load-time.
.some_internal_global_variable <- NULL
.onLoad <- function(libname, pkgname)
{
.some_internal_global_variable <<- 55L
}
However, I don't really like using this approach when initialization
of the global variable requires access to the internet. It means that
in case of connectivity issue your users won't be able to load the
package and troubleshooting can become really tricky when you can't
even load a package. So in that case I prefer the solution below.
3. Define the internal global variable in an environment:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value) assign("eh", value,
envir=.my_internal_global_variables)
toto <- function()
{
eh <- try(.get_eh(), silent=TRUE)
if (inherits(eh, "try-error")) {
eh <- ExperimentHub()
.set_eh(eh)
}
eh
}
Hope this helps,
H.
On 3/23/21 10:05 AM, Murphy, Alan E wrote:
Hey Hervé,
I get the idea now thanks for clarifying. Where do I place the call to
ExperimentHub in the package?:
eh <- ExperimentHub() # the only call to ExperimentHub() in
# the entire R session
The package contains calls to the datasets in internal functions,
examples, tests and the vignette so eh it would need to be available to
all. Sorry I don't have much experience using experiment datasets.
Kind regards,
Alan.
--------
*From:* Hervé Pagès
*Sent:* 23 March 2021 16:46
*To:* Murphy, Alan E ; Martin Morgan
; Kern, Lori ;
bioc-devel@r-project.org
*Subject:* Re: [Bioc-devel] Methods to speed up R CMD Check
***
This email originates from outside Imperial. Do not click on links and
attachments unless you recognise the sender.
If you trust the sender, add them to your safe senders list
https://spam.ic.ac.uk/SpamConsole/Senders.aspx
<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email
stamping for this address.
***
On 3/23/21 4:11 AM, Murphy, Alan E wrote:
Hi,
Thank you very much Martin and Hervé for your suggestions. I have reverted my zzz.R on load function to that advised by ExperimentHub and had used the ID look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions and unit tests. However, the check is still taking ~18 minutes so I need to do a bit more work. Even with
my new on load function, calling datasets by name still takes
substantially longer, see below for the example Hervé gave on my new code:
a<-function(){
eh <- query(ExperimentHub(), "ewceData")
The above line is not needed. Creating an ExperimentHub instance can be
quite expensive and with the current approach 'R CMD check' will do it
dozens of times. My suggestion was to create an ExperimentHub instance
once for all the first time you need it, and reuse it in all your data
access functions:
eh <- ExperimentHub() # the only call to ExperimentHub() in
# the entire R session
Also there's no need to query(). Just use the EHb ID directly on the
ExperimentHub instance to load your data:
eh[["EH5373"]]
This should reduce 'R CMD check' by a few more minutes.
H.
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Methods to speed up R CMD Check
caching mechanism is functioning properly on all of our Bioconductor builders. Lori Shepherd Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel on behalf of Murphy, Alan E Sent: Monday, March 22, 2021 5:38 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] Methods to speed up R CMD Check Hi all, I am working on the development of [EWCE]( https://secure-web.cisco.com/1uG0LGgCjdg85VowwaeRHk2fMjXFkOtQWsgL8p2MQD2j2PZFh_tqvJWaCHJfArA8O4B2WLG1JOwn31NISgSrPW3syUdiPlWNi7cHAMCWKZUQ8d9RrlR-d81LDXXx0xtfCI5ZjjTyFS2xxM2tDea27Y51bWk4Y7jpSnC8Bx768AHBeaJAg3YAK_HTxR6hMzFW99X6Pg8bETgPYi92ccneqdgAJcDBIdfwZnd9OMaM4JS0kY9kYT3F58ho2jM_k0n6EqMzhuXl3HEM7uneL7twMxTTxSZ-vFC1U1eFSkAr0sp38AyD3g6gTbf-vUbghaGV-JBKoybZto3ZDmHhs8OE6cQ/https%3A%2F%2Fgithub.com%2FNathanSkene%2FEWCE) but have hit an issue with R CMD check's runtime. I have been informed this test needs to be completed in 15 minutes but mine is currently running in ~24 minutes and I am looking for methods to speed this up. The main culprits for the runtime issue are: checking examples (5m 49.8s) Running �testthat.R� [308s/469s] (7m 49.1s) checking for unstated dependencies in vignettes (7m 49.4s) checking re-building of vignette outputs (5m 12s) With the exception of using smaller datasets which I will consider myself, is there known ways of speeding these up? EWCE derives data from an Experimenthub package [ewceData]( https://secure-web.cisco.com/1r4B8NJkUGCpdQsdBW8RWLwGvwEA9TlvXY7VUYgAKS-TBmT7s-6a3zMLfS6rXRVUUxG4x8SCYzXUXZKYMtZ_ysyEzk56tVxfvju-9mo6l11KLQ7CzEpFMikVqdyT25f0G3SQK5u9b0_5JK2gNhR4l0j_5_b_B-uPxzyFF0jtLCZFHKW2-pD7e2P4RVOfbgRALwBXM-hQvhcoaxxrR8tWz3JLjKxWqNIhTrsJdATsAnUO0EnQ5U8JNXClmS9LvWwyTf-0ZqokYXTkjdfYDUAm6KiAGNJo4oX99GUBQZllyiIDprF07KeqjsMNMg4dbmMh0t6jl-UEiUaV3j1xRG8UyyA/https%3A%2F%2Fgithub.com%2Fneurogenomics%2FewceData) for its examples, tests and vignette. This is run repeatedly and I have noted this takes a significant amount of time to load a dataset. Is there anyway of caching the datasets for all the checks or more generally of speeding this up? I have heard of the use of [long tests]( http://secure-web.cisco.com/1yfwFXFFfUKBuFTwUeuS8XGYbh53YduG9ZGKMVmVU9Yrgxg4DbKA0_prEIOCNcgc8uANWYzUw115x_8njawa33mjqM5ZBEvTPTJhmXRzttl1eaRVu3Pa0FTA-d-wPRK3Xxa4miiXob79k_exN0isifYlHPTK7WRxh9_LbFye17PwVVOGsfxjEFKi8WF27D6LWJynf8k-L7iEqB2MSDkf_1zWmfA2qJByna147_Jkaa-nLx9FFl4VhsosBoNDE_qnC939XrCLLCT7RgV0jPukrVdahccxXfT6bgtGBR8ZKfj25BoCeE1_hTJXFgGP0CGmegMYqqmsbd3pGTbo63vTW-A/http://bioconductor.org/developers/how-to/long-tests/) which aren't run daily by Bioconductor but are these still checked in R CMD Check? Is there any other way to exclude my tests from the R CMD Check given they aren't a necessity from Bioconductor? Does checking for unstated dependencies in vignettes have a long runtime based on the number of package dependencies? If I just export specific functions from packages will this check time reduce? Lastly, is there any way to get an exception of the 15 minute maximum? I may be ill-informed but is the max time for packages on Bioconductor's daily check 40 minutes which my code in its current state would complete by. Kind regards, Alan. [[alternative HTML version deleted]] This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Methods to speed up R CMD Check
On 3/23/21 4:11 AM, Murphy, Alan E wrote:
Hi,
Thank you very much Martin and Hervé for your suggestions. I have reverted my zzz.R on load
function to that advised by ExperimentHub and had used the ID look up (system.time(tt_alzh
<- eh[["EH5373"]])) on internal functions and unit tests. However, the check is
still taking ~18 minutes so I need to do a bit more work. Even with my new on load function,
calling datasets by name still takes substantially longer, see below for the example Hervé
gave on my new code:
a<-function(){
eh <- query(ExperimentHub(), "ewceData")
The above line is not needed. Creating an ExperimentHub instance can be
quite expensive and with the current approach 'R CMD check' will do it
dozens of times. My suggestion was to create an ExperimentHub instance
once for all the first time you need it, and reuse it in all your data
access functions:
eh <- ExperimentHub() # the only call to ExperimentHub() in
# the entire R session
Also there's no need to query(). Just use the EHb ID directly on the
ExperimentHub instance to load your data:
eh[["EH5373"]]
This should reduce 'R CMD check' by a few more minutes.
H.
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Methods to speed up R CMD Check
Hi Alan,
It looks like what is slowing everything down significantly is the
approach you've taken to look up the ExperimentHub resources that you
control by name every time you need to access them. E.g:
Look up by name:
> system.time(tt_alzh <- ewceData::tt_alzh())
snapshotDate(): 2021-03-22
see ?ewceData and browseVignettes('ewceData') for documentation
loading from cache
user system elapsed
2.496 0.024 9.460
Direct access:
> system.time(tt_alzh <- eh[["EH5373"]])
see ?ewceData and browseVignettes('ewceData') for documentation
loading from cache
user system elapsed
1.195 0.012 2.060
ewceData::tt_alzh() is just one of the 18 utility functions defined in
ewceData that perform this lookup over and over again in the vignette
and man page. This lookup is expensive and not needed since the
ExperimentHub IDs that were assigned to your resources are fixed and
known in advance.
Note however that it's a good idea to not expose these IDs to the end
user (they might change at some point if you need to update these
resources on ExperimentHub) so it's actually recommended to lookup by
name in user-visible code.
Another easy improvement is that you drop dependency on
ExperimentHubData. This will reduce the nb of deps (direct and indirect)
from 130 to 94. There are likely other deps that you could try to get
rid of.
Hope this helps,
H.
On 3/22/21 2:38 AM, Murphy, Alan E wrote:
Hi all,
I am working on the development of [EWCE](https://github.com/NathanSkene/EWCE)
but have hit an issue with R CMD check's runtime. I have been informed this
test needs to be completed in 15 minutes but mine is currently running in ~24
minutes and I am looking for methods to speed this up. The main culprits for
the runtime issue are:
checking examples (5m 49.8s)
Running �testthat.R� [308s/469s] (7m 49.1s)
checking for unstated dependencies in vignettes (7m 49.4s)
checking re-building of vignette outputs (5m 12s)
With the exception of using smaller datasets which I will consider myself, is
there known ways of speeding these up? EWCE derives data from an Experimenthub
package [ewceData](https://github.com/neurogenomics/ewceData) for its examples,
tests and vignette. This is run repeatedly and I have noted this takes a
significant amount of time to load a dataset. Is there anyway of caching the
datasets for all the checks or more generally of speeding this up?
I have heard of the use of [long
tests](http://bioconductor.org/developers/how-to/long-tests/) which aren't run
daily by Bioconductor but are these still checked in R CMD Check? Is there any
other way to exclude my tests from the R CMD Check given they aren't a
necessity from Bioconductor?
Does checking for unstated dependencies in vignettes have a long runtime based
on the number of package dependencies? If I just export specific functions from
packages will this check time reduce?
Lastly, is there any way to get an exception of the 15 minute maximum? I may be
ill-informed but is the max time for packages on Bioconductor's daily check 40
minutes which my code in its current state would complete by.
Kind regards,
Alan.
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] is it possible to disable i386 builds on bioconductor
Hi Thomas, Kevin, Looks like ChemmineOB 1.28.2 is finally green on malbec1 and is now available in BioC 3.12 via BiocManager::install(): https://bioconductor.org/checkResults/3.12/bioc-LATEST/ChemmineOB/ Cheers, H. On 3/17/21 10:23 AM, Thomas Girke wrote: Awesome, thanks! On Tue, Mar 16, 2021 at 11:40 PM Hervé Pagès <mailto:hpages.on.git...@gmail.com>> wrote: Hi Thomas, Kevin, openbabel3 is now on malbec1 (Ubuntu 18.04). Kevin's ubuntu_18.04_openbabel3_debs.tar.gz worked like a charm. Thanks for making it so easy. Note that this addition will affect ChemmineOB build/check results on malbec1 on Thursday only: https://bioconductor.org/checkResults/3.12/bioc-LATEST/ChemmineOB/malbec1-install.html <https://bioconductor.org/checkResults/3.12/bioc-LATEST/ChemmineOB/malbec1-install.html> Cheers, H. On 3/16/21 10:24 AM, Hervé Pagès wrote: > @Kevin: Thanks for providing openbabel3 for Ubuntu 18.04. Will take a > look ASAP. > > @Thomas: Yes, the Ubuntu 18.04 builds are only used for the BioC 3.12 > builds (release). BioC 3.13 and further BioC releases are/will be using > Ubuntu >= 20.04. > > Best, > H. > > > On 3/15/21 1:59 PM, Thomas Girke wrote: >> Thanks Hervé for your help with this. >> >> Kevin has provided the *.deb package for installing OpenBabel 3.x on >> Ubuntu 18.04. Just in case, below is how we usually install OpenBabel >> 3.x.x across different Ubuntu/Debian systems. >> >> BTW: is it correct to assume that the Ubuntu 18.04 builds will be >> discontinued in the next release in April? >> >> Thanks, >> >> Thomas >> >> >> ## Install ChemmineOB with OpenBabel 3.x from source >> >> ## First uninstall libopenbabel-dev (which is version 2.x.x) if >> already installed via >> sudo apt-get remove libopenbabel-dev; sudo apt-get purge >> libopenbabel-dev; sudo apt-get --purge autoremove libopenbabel-dev >> ## Some dependencies to install >> sudo apt install cmake libeigen3-dev libboost-all-dev >> ## Clone OpenBabel 3.x.x from GitHub here: >> https://github.com/openbabel/openbabel <https://github.com/openbabel/openbabel> >> <https://github.com/openbabel/openbabel <https://github.com/openbabel/openbabel>> >> git clone g...@github.com:openbabel/openbabel.git >> mkdir build; cd build >> cmake ../openbabel >> make >> sudo make install >> ## Install ChemmineOB where you provide environment variables >> including header files and ChemmineOB package iprovided as *.tar.gz >> (adjust paths if not correct) >> R CMD INSTALL >> --configure-args='--with-openbabel-include=/usr/local/include/openbabel3/ >> --with-openbabel-lib=/usr/local/lib/openbabel/3.1.1' >> ChemmineOB_1.28.0.tar.gz >> >> On Mon, Mar 15, 2021 at 1:12 PM Kevin Horan mailto:kho...@cs.ucr.edu> >> <mailto:kho...@cs.ucr.edu <mailto:kho...@cs.ucr.edu>>> wrote: >> >> Herve, >> >> I've backported openbabel3 from 20.04 to 18.04. You can >> download a >> tarball with all the deb files in here: >> >> >> http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz <http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz> >> >> <http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz <http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz>> >> >> Kevin >> >> On 3/15/21 10:10 AM, Hervé Pagès wrote: >> > Hi Thomas, Kevin, >> > >> > We still need to install the system deps on the devel Windows >> builders >> > (riesling1 and tokay2). We'll do it this week. Thanks for the >> reminder >> > and for making the OpenBabel-3.0.0 Windows Binaries available on >> your >> > GitHub repo. >> > >> > Note that OpenBabel 3 is installed on machv2 (devel macOS >> builders): >> > >> > machv2:~ biocbuild$ which obabel >> > /usr/local/bin/obabel >> > >> > machv2:~ biocbuild$ obabel -V >> > Open Babel
[Bioc-devel] devel builds are down
Hi maintainers, If you've not noticed already, the build report for the BioC 3.13 builds (devel builds) didn't get updated for the last 3 days: https://bioconductor.org/checkResults/3.13/bioc-LATEST/ This is unusual. The reason is that our build machine rex3 has been experiencing connectivity issues that have prevented the daily builds from running normally. The problem is being investigated and we'll provide updates here as the situation evolves. Thanks for your patience and sorry for the inconvenience. H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] is it possible to disable i386 builds on bioconductor
Hi Thomas, Kevin, openbabel3 is now on malbec1 (Ubuntu 18.04). Kevin's ubuntu_18.04_openbabel3_debs.tar.gz worked like a charm. Thanks for making it so easy. Note that this addition will affect ChemmineOB build/check results on malbec1 on Thursday only: https://bioconductor.org/checkResults/3.12/bioc-LATEST/ChemmineOB/malbec1-install.html Cheers, H. On 3/16/21 10:24 AM, Hervé Pagès wrote: @Kevin: Thanks for providing openbabel3 for Ubuntu 18.04. Will take a look ASAP. @Thomas: Yes, the Ubuntu 18.04 builds are only used for the BioC 3.12 builds (release). BioC 3.13 and further BioC releases are/will be using Ubuntu >= 20.04. Best, H. On 3/15/21 1:59 PM, Thomas Girke wrote: Thanks Hervé for your help with this. Kevin has provided the *.deb package for installing OpenBabel 3.x on Ubuntu 18.04. Just in case, below is how we usually install OpenBabel 3.x.x across different Ubuntu/Debian systems. BTW: is it correct to assume that the Ubuntu 18.04 builds will be discontinued in the next release in April? Thanks, Thomas ## Install ChemmineOB with OpenBabel 3.x from source ## First uninstall libopenbabel-dev (which is version 2.x.x) if already installed via sudo apt-get remove libopenbabel-dev; sudo apt-get purge libopenbabel-dev; sudo apt-get --purge autoremove libopenbabel-dev ## Some dependencies to install sudo apt install cmake libeigen3-dev libboost-all-dev ## Clone OpenBabel 3.x.x from GitHub here: https://github.com/openbabel/openbabel <https://github.com/openbabel/openbabel> git clone g...@github.com:openbabel/openbabel.git mkdir build; cd build cmake ../openbabel make sudo make install ## Install ChemmineOB where you provide environment variables including header files and ChemmineOB package iprovided as *.tar.gz (adjust paths if not correct) R CMD INSTALL --configure-args='--with-openbabel-include=/usr/local/include/openbabel3/ --with-openbabel-lib=/usr/local/lib/openbabel/3.1.1' ChemmineOB_1.28.0.tar.gz On Mon, Mar 15, 2021 at 1:12 PM Kevin Horan <mailto:kho...@cs.ucr.edu>> wrote: Herve, I've backported openbabel3 from 20.04 to 18.04. You can download a tarball with all the deb files in here: http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz <http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz> Kevin On 3/15/21 10:10 AM, Hervé Pagès wrote: > Hi Thomas, Kevin, > > We still need to install the system deps on the devel Windows builders > (riesling1 and tokay2). We'll do it this week. Thanks for the reminder > and for making the OpenBabel-3.0.0 Windows Binaries available on your > GitHub repo. > > Note that OpenBabel 3 is installed on machv2 (devel macOS builders): > > machv2:~ biocbuild$ which obabel > /usr/local/bin/obabel > > machv2:~ biocbuild$ obabel -V > Open Babel 3.1.0 -- Oct 21 2020 -- 21:57:42 > > machv2:~ biocbuild$ pkg-config --cflags openbabel-3 > -I/usr/local/Cellar/open-babel/3.1.1_1/include/openbabel3 > > machv2:~ biocbuild$ pkg-config --libs openbabel-3 > -L/usr/local/Cellar/open-babel/3.1.1_1/lib -lopenbabel > > In release: The reason ChemmineOB does not compile on malbec1 is > because it requires OpenBabel 3 but malbec1 only has OpenBabel 2 which > is what Ubuntu 18.04 comes with. OpenBabel 3 only became available > starting with Ubuntu 20.04. > > To workaround this we could propagate the ChemmineOB_1.28.2.tar.gz > source tarball produced on nebbiolo1 (Ubuntu 20.04), or, if you know > an easy way to get OpenBabel 3 installed on an Ubuntu 18.04 system, > let us know and we will do that. The best thing would be to be able to > use a .deb package for this. The easiest the procedure, the more > likely people that are still using Ubuntu 18.04 will be able to > install ChemmineOB. > > Best, > H. > > > > On 3/12/21 11:10 AM, Thomas Girke wrote: >> Dear Hervé and Martin, >> >> It seems the above problem on the Windows builds has been resolved >> for some >> time now. However, any updates on Linux in the release branch are not >> taking effect since some/all of the Openbabel dependencies are not >> available on the corresponding Linux build system (here Ubuntu 18.04). >> However, Ubuntu 20.04 seems to be fine but may not be used to create the >> source download instance at the moment? As a result, the package is only >> up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not Linux >> (still at >> ChemmineOB_1.28.0.tar.gz
Re: [Bioc-devel] is it possible to disable i386 builds on bioconductor
@Kevin: Thanks for providing openbabel3 for Ubuntu 18.04. Will take a
look ASAP.
@Thomas: Yes, the Ubuntu 18.04 builds are only used for the BioC 3.12
builds (release). BioC 3.13 and further BioC releases are/will be using
Ubuntu >= 20.04.
Best,
H.
On 3/15/21 1:59 PM, Thomas Girke wrote:
Thanks Hervé for your help with this.
Kevin has provided the *.deb package for installing OpenBabel 3.x on
Ubuntu 18.04. Just in case, below is how we usually install OpenBabel
3.x.x across different Ubuntu/Debian systems.
BTW: is it correct to assume that the Ubuntu 18.04 builds will be
discontinued in the next release in April?
Thanks,
Thomas
## Install ChemmineOB with OpenBabel 3.x from source
## First uninstall libopenbabel-dev (which is version 2.x.x) if already
installed via
sudo apt-get remove libopenbabel-dev; sudo apt-get purge
libopenbabel-dev; sudo apt-get --purge autoremove libopenbabel-dev
## Some dependencies to install
sudo apt install cmake libeigen3-dev libboost-all-dev
## Clone OpenBabel 3.x.x from GitHub here:
https://github.com/openbabel/openbabel
<https://github.com/openbabel/openbabel>
git clone g...@github.com:openbabel/openbabel.git
mkdir build; cd build
cmake ../openbabel
make
sudo make install
## Install ChemmineOB where you provide environment variables including
header files and ChemmineOB package iprovided as *.tar.gz (adjust paths
if not correct)
R CMD INSTALL
--configure-args='--with-openbabel-include=/usr/local/include/openbabel3/ --with-openbabel-lib=/usr/local/lib/openbabel/3.1.1'
ChemmineOB_1.28.0.tar.gz
On Mon, Mar 15, 2021 at 1:12 PM Kevin Horan <mailto:kho...@cs.ucr.edu>> wrote:
Herve,
I've backported openbabel3 from 20.04 to 18.04. You can
download a
tarball with all the deb files in here:
http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz
<http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz>
Kevin
On 3/15/21 10:10 AM, Hervé Pagès wrote:
> Hi Thomas, Kevin,
>
> We still need to install the system deps on the devel Windows
builders
> (riesling1 and tokay2). We'll do it this week. Thanks for the
reminder
> and for making the OpenBabel-3.0.0 Windows Binaries available on
your
> GitHub repo.
>
> Note that OpenBabel 3 is installed on machv2 (devel macOS builders):
>
> machv2:~ biocbuild$ which obabel
> /usr/local/bin/obabel
>
> machv2:~ biocbuild$ obabel -V
> Open Babel 3.1.0 -- Oct 21 2020 -- 21:57:42
>
> machv2:~ biocbuild$ pkg-config --cflags openbabel-3
> -I/usr/local/Cellar/open-babel/3.1.1_1/include/openbabel3
>
> machv2:~ biocbuild$ pkg-config --libs openbabel-3
> -L/usr/local/Cellar/open-babel/3.1.1_1/lib -lopenbabel
>
> In release: The reason ChemmineOB does not compile on malbec1 is
> because it requires OpenBabel 3 but malbec1 only has OpenBabel 2
which
> is what Ubuntu 18.04 comes with. OpenBabel 3 only became available
> starting with Ubuntu 20.04.
>
> To workaround this we could propagate the ChemmineOB_1.28.2.tar.gz
> source tarball produced on nebbiolo1 (Ubuntu 20.04), or, if you know
> an easy way to get OpenBabel 3 installed on an Ubuntu 18.04 system,
> let us know and we will do that. The best thing would be to be
able to
> use a .deb package for this. The easiest the procedure, the more
> likely people that are still using Ubuntu 18.04 will be able to
> install ChemmineOB.
>
> Best,
> H.
>
>
>
> On 3/12/21 11:10 AM, Thomas Girke wrote:
>> Dear Hervé and Martin,
>>
>> It seems the above problem on the Windows builds has been resolved
>> for some
>> time now. However, any updates on Linux in the release branch
are not
>> taking effect since some/all of the Openbabel dependencies are not
>> available on the corresponding Linux build system (here Ubuntu
18.04).
>> However, Ubuntu 20.04 seems to be fine but may not be used to
create the
>> source download instance at the moment? As a result, the package
is only
>> up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not Linux
>> (still at
>> ChemmineOB_1.28.0.tar.gz):
>>
http://bioconductor.org/packages/release/bioc/html/ChemmineOB.html
<http://bioconductor.org/packages/release/bioc/html/ChemmineOB.html>.
>> To fix
>> this, one suggestion would be whether the functional build from the
>> 20.04
>> system could be pushed instead of 18.04? Not sure whether this
is less
>> effort than installing the depen
Re: [Bioc-devel] is it possible to disable i386 builds on bioconductor
Hi Thomas, Kevin, We still need to install the system deps on the devel Windows builders (riesling1 and tokay2). We'll do it this week. Thanks for the reminder and for making the OpenBabel-3.0.0 Windows Binaries available on your GitHub repo. Note that OpenBabel 3 is installed on machv2 (devel macOS builders): machv2:~ biocbuild$ which obabel /usr/local/bin/obabel machv2:~ biocbuild$ obabel -V Open Babel 3.1.0 -- Oct 21 2020 -- 21:57:42 machv2:~ biocbuild$ pkg-config --cflags openbabel-3 -I/usr/local/Cellar/open-babel/3.1.1_1/include/openbabel3 machv2:~ biocbuild$ pkg-config --libs openbabel-3 -L/usr/local/Cellar/open-babel/3.1.1_1/lib -lopenbabel In release: The reason ChemmineOB does not compile on malbec1 is because it requires OpenBabel 3 but malbec1 only has OpenBabel 2 which is what Ubuntu 18.04 comes with. OpenBabel 3 only became available starting with Ubuntu 20.04. To workaround this we could propagate the ChemmineOB_1.28.2.tar.gz source tarball produced on nebbiolo1 (Ubuntu 20.04), or, if you know an easy way to get OpenBabel 3 installed on an Ubuntu 18.04 system, let us know and we will do that. The best thing would be to be able to use a .deb package for this. The easiest the procedure, the more likely people that are still using Ubuntu 18.04 will be able to install ChemmineOB. Best, H. On 3/12/21 11:10 AM, Thomas Girke wrote: Dear Hervé and Martin, It seems the above problem on the Windows builds has been resolved for some time now. However, any updates on Linux in the release branch are not taking effect since some/all of the Openbabel dependencies are not available on the corresponding Linux build system (here Ubuntu 18.04). However, Ubuntu 20.04 seems to be fine but may not be used to create the source download instance at the moment? As a result, the package is only up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not Linux (still at ChemmineOB_1.28.0.tar.gz): http://bioconductor.org/packages/release/bioc/html/ChemmineOB.html. To fix this, one suggestion would be whether the functional build from the 20.04 system could be pushed instead of 18.04? Not sure whether this is less effort than installing the dependencies on 18.04 that may be discontinued soon - just a suggestion/question? On the development branch the situation is opposite where the dependencies are missing on Windows and OSX but Linux is fine: http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineOB/. We realize that the dependencies of the ChemmineOB package creates extra workload for the Bioc team, and we are extremely grateful for the support by the Bioc core team. Please let us know if there is anything on our end that could be done to resolve this and/or to minimize your workload as much as possible. Thanks, Thomas On Mon, Feb 8, 2021 at 10:02 AM Martin Morgan wrote: It's likely failing because your package has C source code that accesses memory in an invalid way. Likely the bug is present on all platforms, but only apparent, for the tests you have written, on Windows. The right thing to do is to fix the bug, rather than avoid by not running on the troublesome platform. Under Linux you'd likely have success with valgrind or UBSAN; if you were reasonably confident that the package occurred in unit tests, and you have a script to run the unit tests run_tests.R then something like R -d valgrind -f run_tests.R may be productive. valgrind is slow so it pays to narrow the problem down as much as possible. Maartin On 2/8/21, 12:43 PM, "Bioc-devel on behalf of Kevin Horan" < bioc-devel-boun...@r-project.org on behalf of kho...@cs.ucr.edu> wrote: I have a package which randomly segfaults when running my unit tests only on windows i386, but never on x64, or any other OS. I can't imagine there are many out there still running i386 systems are there? Is it possible to just disable the i386 build on bioconductor so that the tests are not run on that architecture? I have of course done my best to debug the issue, but all I get is an error in some nt dll file, with no useful message or location. I'm I Linux guy, I don't know how to do the in-depth debugging that would be required to track this bug down on windows. I tried disabling each test one by one to see which one caused the crash, but as is typical with segfaults, changing the setup can mask the bug even when the bad code is still be executed. Each test runs fine in isolation. Thanks Kevin ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-pro
Re: [Bioc-devel] rfaRm suddenly failing on all platforms
Hi Lara,
When you're trying to reproduce an error that you see on the build
system, it's important that you make sure that you're using the latest
version of all CRAN and Bioconductor packages. You can use
BiocManager::valid() for that:
> library(BiocManager)
Bioconductor version 3.12 (BiocManager 1.30.10),
?BiocManager::install for help
> valid()
[1] TRUE
With this, I can reproduce the rfaRm error on my laptop. It occurs in
the rfamGetClanDefinitions() function which is called at installation
time to initialize the 'rfamClanDefinitions' internal variable. The
error can be reproduced with:
library(xml2)
library(rvest)
rfamClanLookUpURL <- 'http://rfam.xfam.org/clan/'
rfamClansListURL <- "http://rfam.xfam.org/clans;
clanHTMLTable <- html_table(xml_find_all(read_html(rfamClansListURL),
"//table[@id]"))
clanAccessions <- clanHTMLTable[[1]][,3]
for (clan in clanAccessions) {
read_html(paste(rfamClanLookUpURL, clan, sep=""))
}
# Error: `x` must be a string of length 1
See my sessionInfo() below.
Note that CRAN package rvest got recently update (on March 9) from
version 0.3.6 to 1.0.0 (see https://cran.r-project.org/package=rvest)
and I suspect that the above error might be related to a change in the
rvest::html_table() function.
Finally I would advice against accessing remote resources to initialize
an internal variable at installation time like you do with for
'rfamClanDefinitions'. Better do it at **load time** with something like
this:
1. Replace
rfamClanDefinitions <- rfamGetClanDefinitions()
with
rfamClanDefinitions <- NULL
2. Create a zzz.R file and add the following onLoad hook to it:
.onLoad <- function(libname, pkgname)
{
rfamClanDefinitions <<- rfamGetClanDefinitions()
}
Hope this helps,
H.
R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.10
Matrix products: default
BLAS: /home/hpages/R/R-4.0.3/lib/libRblas.so
LAPACK: /home/hpages/R/R-4.0.3/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rvest_1.0.0 xml2_1.3.2
loaded via a namespace (and not attached):
[1] httr_1.4.2 compiler_4.0.3 ellipsis_0.3.1 magrittr_2.0.1
[5] R6_2.5.0pillar_1.5.1tibble_3.1.0curl_4.3
[9] crayon_1.4.1utf8_1.2.1 fansi_0.4.2 vctrs_0.3.6
[13] lifecycle_1.0.0 pkgconfig_2.0.3 rlang_0.4.10
On 3/13/21 3:47 AM, Selles Vidal, Lara wrote:
Dear all,
I have recently observed that my package rfaRm started failing at INSTALL step
on all platforms
(http://bioconductor.org/checkResults/release/bioc-LATEST/rfaRm/ ).
In all cases, the error is the same and occurs both in release and devel:
Error : `x` must be a string of length 1
Error: unable to load R code in package �rfaRm�
This is quite puzzling, since we have not pushed any changes recently.
Additionally, I have confirmed I can install rfaRm with no problem through
standard procedure from Bioconductor.
Does anyone have any idea what could be possible happening?
Thanks a lot in advance.
Best wishes,
Lara
Lara Selles
lara.selle...@imperial.ac.uk
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Warnings on R CMD check on Mac OS and Linux
On 3/11/21 7:45 AM, Oluwafemi OLUSOJI wrote:
Hello Herves,
I finally solved this. It had more to do with my commits than the
package itself.
There is this error message when the package is built on a Windows
server. What am I to do about this?
The flowCore package cannot currently be installed because it requires
cytolib >= 2.3.4 which doesn't compile on Windows at the moment. The
cytolib maintainers are aware of the situation and working on it.
Not much we can do so let's ignore for now.
Thanks,
H.
Regards,
Daniel
===
R CMD BUILD
===
* checking for file 'cyanoFilter/DESCRIPTION' ... OK
* preparing 'cyanoFilter':
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
---
ERROR: dependency 'flowCore' is not available for package 'cyanoFilter'
* removing
'C:/Users/pkgbuild/AppData/Local/Temp/RtmpYhB4xB/Rinst1ce0655031d2/cyanoFilter'
---
ERROR: package installation failed
Op do 11 mrt. 2021 om 15:54 schreef Oluwafemi OLUSOJI
mailto:oluwafemi.olus...@uhasselt.be>>:
Hello Herve,
Thank you for the insight, but after rewriting the man pages by
hand. I still get the same error after the latest commit. I am
really at a loss here because this builds perfectly on my system.
Regards,
Daniel
Op do 11 mrt. 2021 om 03:11 schreef Hervé Pagès
mailto:hpages.on.git...@gmail.com>>:
Hi,
I don't see that you have aliases for these symbols, hence the
warning:
hpages@spectre:~/cyanoFilter/man$ grep 'alias{PhytoFilter}' *.Rd
hpages@spectre:~/cyanoFilter/man$ grep
'alias{clusterExtract}' *.Rd
etc...
Note that even though you have aliases for some PhytoFilter
**methods**:
hpages@spectre:~/cyanoFilter/man$ grep -w PhytoFilter *.Rd |
grep
alias | grep method
fullFlowframe-PhytoFilter-method.Rd:\alias{fullFlowframe,PhytoFilter-method}
plot-PhytoFilter-ANY-method.Rd:\alias{plot,PhytoFilter,ANY-method}
reducedFlowframe-PhytoFilter-method.Rd:\alias{reducedFlowframe,PhytoFilter-method}
here 'R CMD check' is complaining about the lack of an alias for
the
PhytoFilter **object** (which turns out to be a function). Since
you
export this symbol (via the export(PhytoFilter) directive in your
NAMESPACE file), you need to provide an alias for it in one of
your man
pages.
Hope this helps,
H.
On 3/8/21 2:45 PM, Oluwafemi OLUSOJI via Bioc-devel wrote:
> Dear All,
>
> I get this warning on the latest update of my package. The
warning occurs
> only with Mac and Linux. I am a bit at loss here. These
errors don't
> actually exist because these functions and methods are
properly documented.
> The missing link doesn't even exist anymore.
>
> I have rebuilt both the documentation and rebuilt the source.
R CMD check
> and R CMS check --as.cran doesn't report either on my system
as well. I
> will appreciate any heads-up here.
>
> Regards,
> Daniel
>
>
> Missing link or links in documentation object 'oneDgate.Rd':
> getChannel
>
> See section 'Cross-references' in the 'Writing R Extensions'
manual.
> * checking for missing documentation entries ... WARNING
> Undocumented code objects:
> PhytoFilter clusterExtract clusterExtractp debrisNc
> getChannel newFlowframe newFlowframe2 pairsPlot pigmentGate
> reducedFlowframe rowNumbers summaries
> Undocumented S4 methods:
> generic 'summaries' and siglist 'DebrisFilter'
> generic 'summaries' and siglist 'MarginEvents'
> generic 'summaries' and siglist 'PhytoFilter'
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>
mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com <mailto:hpages.on.git...@gmail.com>
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Warnings on R CMD check on Mac OS and Linux
Hi,
I don't see that you have aliases for these symbols, hence the warning:
hpages@spectre:~/cyanoFilter/man$ grep 'alias{PhytoFilter}' *.Rd
hpages@spectre:~/cyanoFilter/man$ grep 'alias{clusterExtract}' *.Rd
etc...
Note that even though you have aliases for some PhytoFilter **methods**:
hpages@spectre:~/cyanoFilter/man$ grep -w PhytoFilter *.Rd | grep
alias | grep method
fullFlowframe-PhytoFilter-method.Rd:\alias{fullFlowframe,PhytoFilter-method}
plot-PhytoFilter-ANY-method.Rd:\alias{plot,PhytoFilter,ANY-method}
reducedFlowframe-PhytoFilter-method.Rd:\alias{reducedFlowframe,PhytoFilter-method}
here 'R CMD check' is complaining about the lack of an alias for the
PhytoFilter **object** (which turns out to be a function). Since you
export this symbol (via the export(PhytoFilter) directive in your
NAMESPACE file), you need to provide an alias for it in one of your man
pages.
Hope this helps,
H.
On 3/8/21 2:45 PM, Oluwafemi OLUSOJI via Bioc-devel wrote:
Dear All,
I get this warning on the latest update of my package. The warning occurs
only with Mac and Linux. I am a bit at loss here. These errors don't
actually exist because these functions and methods are properly documented.
The missing link doesn't even exist anymore.
I have rebuilt both the documentation and rebuilt the source. R CMD check
and R CMS check --as.cran doesn't report either on my system as well. I
will appreciate any heads-up here.
Regards,
Daniel
Missing link or links in documentation object 'oneDgate.Rd':
getChannel
See section 'Cross-references' in the 'Writing R Extensions' manual.
* checking for missing documentation entries ... WARNING
Undocumented code objects:
PhytoFilter clusterExtract clusterExtractp debrisNc
getChannel newFlowframe newFlowframe2 pairsPlot pigmentGate
reducedFlowframe rowNumbers summaries
Undocumented S4 methods:
generic 'summaries' and siglist 'DebrisFilter'
generic 'summaries' and siglist 'MarginEvents'
generic 'summaries' and siglist 'PhytoFilter'
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] download stats problem
Thanks for bringing this to our attention. The script that we use to compute the stats had problems accessing the latest CloudFront log files on S3, resulting in package downloads from the last few days being ignored. This is now repaired and hopefully the stats will get updated tomorrow with the full counts. Best, H. On 3/10/21 3:15 PM, Luo Weijun via Bioc-devel wrote: Dear BioC team, download stats for BioC packages don’t seem to be updated. The graphs were generated on 03-09, but the stats are much lower than expected for 9 days: https://bioconductor.org/packages/stats/bioc/SBGNview/ https://bioconductor.org/packages/stats/bioc/pathview/ https://bioconductor.org/packages/stats/bioc/BiocGenerics/ can you check on this? thanks. Weijun Luo ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] surprised matrix (1:256, 8, 8) doesn't cause error/warning
Hi Martin, It kind of does make sense to issue the warning when **recycling** (and this is consistent with what happens with recycling in general): > matrix(1:4, 6, 6) [,1] [,2] [,3] [,4] [,5] [,6] [1,]131313 [2,]242424 [3,]313131 [4,]424242 [5,]131313 [6,]242424 > matrix(1:4, 5, 6) [,1] [,2] [,3] [,4] [,5] [,6] [1,]123412 [2,]234123 [3,]341234 [4,]412341 [5,]123412 Warning message: In matrix(1:4, 5, 6) : data length [4] is not a sub-multiple or multiple of the number of rows [5] (Note that the warning is misleading. matrix() is happy to take data with a length that is not a sub-multiple of the number of rows or cols as long as it's a sub-multiple of the length of the matrix.) However I'm not sure that **truncating** the data is desirable behavior: > matrix(1:6, 1, 3) [,1] [,2] [,3] [1,]123 > matrix(1:6, 1, 5) [,1] [,2] [,3] [,4] [,5] [1,]12345 Warning message: In matrix(1:6, 1, 5) : data length [6] is not a sub-multiple or multiple of the number of columns [5] Maybe you get a warning sometimes, if you are lucky, but still. Finally note that you never get any warning with array(): > array(1:4, c(5, 6)) [,1] [,2] [,3] [,4] [,5] [,6] [1,]123412 [2,]234123 [3,]341234 [4,]412341 [5,]123412 > array(1:6, c(1, 5)) [,1] [,2] [,3] [,4] [,5] [1,]12345 Cheers, H. On 2/1/21 1:08 AM, Martin Maechler wrote: Abby Spurdle (/əˈbi/) on Mon, 1 Feb 2021 19:50:32 +1300 writes: > I'm a little surprised that the following doesn't trigger an error or a warning. > matrix (1:256, 8, 8) > The help file says that the main argument is recycled, if it's too short. > But doesn't say what happens if it's too long. It's somewhat subtler than one may assume : matrix(1:9, 2,3) [,1] [,2] [,3] [1,]135 [2,]246 Warning message: In matrix(1:9, 2, 3) : data length [9] is not a sub-multiple or multiple of the number of rows [2] matrix(1:8, 2,3) [,1] [,2] [,3] [1,]135 [2,]246 Warning message: In matrix(1:8, 2, 3) : data length [8] is not a sub-multiple or multiple of the number of columns [3] matrix(1:12, 2,3) [,1] [,2] [,3] [1,]135 [2,]246 So it looks to me the current behavior is quite on purpose. Are you sure it's not documented at all when reading the docs carefully? (I did *not*, just now). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] R-CMD-check fails on ubuntu-20.04 (release)
On 2/16/21 4:39 PM, Martin Morgan wrote: Binary packages are installed, but unlike source packages R does not try to load them after they are installed, somehow assuming that the installation was correct. Note that this assumption kind of makes sense with Windows and Mac binaries because they are usually statically linked, but installing Linux binary packages is an entirely new game. H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Any consensus around data structures for methylation data?
Many many packages in the methylation business (methylation array or MethylSeq) define dozens of data structures (S4 classes) for the purpose of representing methylation data. Some of the most outstanding data structures seem to be RnBeadSet in RnBeads, MethylSet in minfi, MethyLumiSet in methylumi, BSdataSet in methylPipe, BSrel and BSraw in BiSeq, etc... Some are SummarizedExperiment derivatives, some are eSet derivatives, others don't extend anything and reimplement a lot of things from scratch. I wonder if some kind of unification/standardization effort has been considered. Would be great to achieve some sort of consensus like has been done with SingleCellExperiment for single cell data. Having the consensual classes implemented in their own package, and separated from any particular application like in the case of SCE, would help with exposure and reusability. For the context: I'm currently looking at a new submission (MAGAR) that implements yet another set of S4 classes (methQTLInput and methQTLResult) almost from scratch: - https://github.com/MPIIComputationalEpigenetics/MAGAR/blob/a5281222426441ed48581cd5b45d1d81d6537ed4/R/methQTLResult-class.R#L38-L57 - https://github.com/MPIIComputationalEpigenetics/MAGAR/blob/a5281222426441ed48581cd5b45d1d81d6537ed4/R/methQTLResult-class.R#L38-L57. I'm hoping that they can avoid that by reusing (either directly or by extending) something that's already available in the ecosystem but it's not clear to me what to recommend. Thanks, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BSgenome changes
Kasper,
The tradition so far has been to package all UCSC human genomes since
hg17. We could also start producing BSgenome packages for other non-UCSC
Human assemblies. We just need to draw a line somewhere. If there is a
need for it we can make BSgenome.Hsapiens.NCBI.GRCh37.p13 available, as
I said earlier. Is this what you are asking for?
H.
On 8/20/20 03:23, Kasper Daniel Hansen wrote:
Well, the presence of two mitochondrial genomes is to fix a mistake by
UCSC. I can appreciate the importance of representing this mistake when
you build off UCSC. But it strikes me as not actually representing the
h37 version of the genome, and it seems to me that we want such a
representation in the project - not everything comes through UCSC. But
perhaps I have not given this sufficient thought, this is just my
immediate reaction.
On Tue, Aug 18, 2020 at 8:18 PM Leonard Goldstein
mailto:goldstein.leon...@gene.com>> wrote:
Thanks for the explanation Hervé.
Best wishes
Leonard
On Tue, Aug 18, 2020 at 10:06 AM Hervé Pagès mailto:hpa...@fredhutch.org>> wrote:
On 8/18/20 01:40, Kasper Daniel Hansen wrote:
> In light of this, could we get a version of GRCh37 with only
a single
> mitochondrial genome?
You mean a BSgenome.Hsapiens.NCBI.GRCh37.p13 package? So it would
contain the same sequences as BSgenome.Hsapiens.UCSC.hg19 but
without
the hg19:chrM sequence?
Certainly doable but note that by using
BSgenome.Hsapiens.UCSC.hg38 you
stay away from this mess. I'm not sure that adding yet another
BSgenome
package would make the situation less confusing.
>
> On Fri, Aug 14, 2020 at 6:17 PM Hervé Pagès
mailto:hpa...@fredhutch.org>
> <mailto:hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>>>
wrote:
>
> Hi Felix,
>
> On 8/13/20 21:43, Felix Ernst wrote:
> > Hi Leonard, Hi Herve,
> >
> > I followed your conversation, since I have noticed the
same
> problem. Thanks, Herve, for the explanation of the recent
changes on
> hg19.
> >
> > The GRCh37.P13 report states in its last line:
> >
> > MT assembled-molecule MT Mitochondrion
J01415.2
> = NC_012920.1 non-nuclear 16569 chrM
> >
> > Since the last name is called "UCSC-style-name",
wouldn't that
> mean that chrM has to be renamed to MT and not chrMT?
>
> This is a mistake in the sequence report for GRCh37.p13.
GRCh37.p13:MT
> is the same as hg19:chrMT, not hg19:chrM.
>
> hg19:chrM and hg19:chrMT are **not** the same sequences.
The former is
> NC_001807 and has length 16571 and the latter is
NC_012920.1 and has
> length 16569.
>
> Yes, seqlevelsStyle() is sorting out all this mess for
you ;-)
>
> Cheers,
> H.
>
> >
> > Thanks again for the explanation.
> >
> > Cheers,
> > Felix
> >
> > -Ursprüngliche Nachricht-
> > Von: Bioc-devel mailto:bioc-devel-boun...@r-project.org>
> <mailto:bioc-devel-boun...@r-project.org
<mailto:bioc-devel-boun...@r-project.org>>> Im Auftrag von Hervé
Pagès
> > Gesendet: Freitag, 14. August 2020 01:08
> > An: Leonard Goldstein mailto:goldstein.leon...@gene.com>
> <mailto:goldstein.leon...@gene.com
<mailto:goldstein.leon...@gene.com>>>; bioc-devel@r-project.org
<mailto:bioc-devel@r-project.org>
> <mailto:bioc-devel@r-project.org
<mailto:bioc-devel@r-project.org>>
> > Cc: charlotte.sone...@fmi.ch
<mailto:charlotte.sone...@fmi.ch>
<mailto:charlotte.sone...@fmi.ch <mailto:charlotte.sone...@fmi.ch>>
> > Betreff: Re: [Bioc-devel] BSgenome changes
> >
> > Hi Leonard,
> >
> > On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote:
> >> Dear Bioc team,
> >>
> >> I'm following up on this recent GitHub issue
> >>
Re: [Bioc-devel] BSgenome changes
On 8/18/20 01:40, Kasper Daniel Hansen wrote: In light of this, could we get a version of GRCh37 with only a single mitochondrial genome? You mean a BSgenome.Hsapiens.NCBI.GRCh37.p13 package? So it would contain the same sequences as BSgenome.Hsapiens.UCSC.hg19 but without the hg19:chrM sequence? Certainly doable but note that by using BSgenome.Hsapiens.UCSC.hg38 you stay away from this mess. I'm not sure that adding yet another BSgenome package would make the situation less confusing. On Fri, Aug 14, 2020 at 6:17 PM Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote: Hi Felix, On 8/13/20 21:43, Felix Ernst wrote: > Hi Leonard, Hi Herve, > > I followed your conversation, since I have noticed the same problem. Thanks, Herve, for the explanation of the recent changes on hg19. > > The GRCh37.P13 report states in its last line: > > MT assembled-molecule MT Mitochondrion J01415.2 = NC_012920.1 non-nuclear 16569 chrM > > Since the last name is called "UCSC-style-name", wouldn't that mean that chrM has to be renamed to MT and not chrMT? This is a mistake in the sequence report for GRCh37.p13. GRCh37.p13:MT is the same as hg19:chrMT, not hg19:chrM. hg19:chrM and hg19:chrMT are **not** the same sequences. The former is NC_001807 and has length 16571 and the latter is NC_012920.1 and has length 16569. Yes, seqlevelsStyle() is sorting out all this mess for you ;-) Cheers, H. > > Thanks again for the explanation. > > Cheers, > Felix > > -Ursprüngliche Nachricht- > Von: Bioc-devel mailto:bioc-devel-boun...@r-project.org>> Im Auftrag von Hervé Pagès > Gesendet: Freitag, 14. August 2020 01:08 > An: Leonard Goldstein mailto:goldstein.leon...@gene.com>>; bioc-devel@r-project.org <mailto:bioc-devel@r-project.org> > Cc: charlotte.sone...@fmi.ch <mailto:charlotte.sone...@fmi.ch> > Betreff: Re: [Bioc-devel] BSgenome changes > > Hi Leonard, > > On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote: >> Dear Bioc team, >> >> I'm following up on this recent GitHub issue >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ldg21 >> _SGSeq_issues_5=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=Tfk-tDM99P63dnsvMydG2phv5WQPVbJzPk0hzi-_1SE= >. Please see the issue for more details and code examples. >> >> It looks like changes in Bioc devel result in two copies of the >> mitochondrial chromosome for BSgenome.Hsapiens.UCSC.hg19 -- one named >> chrM like in previous package versions (length 16571) and one named >> chrMT (length 16569). >> >> When using seqlevelsStyle() to change chromosome names from UCSC to >> NCBI format, this results in new behavior -- in the past chrM was >> simply renamed MT, now the different sequence chrMT is used. Is this intended? > > Absolutely intended. > > There is a long story behind the unfortunate fate of the mitochondrial chromosome in hg19. I'll try to keep it short. > > When the UCSC folks released the hg19 browser more than 10 years ago, they based it on assembly GRCh37: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.13=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=jWtgKVQGC-SQp6i4prhKBiD5cBh2kEc8R1gL2uPlzy0= > > See sequence report for GRCh37: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__ftp.ncbi.nlm.nih.gov_genomes_all_GCF_000_001_405_GCF-5F01405.13-5FGRCh37_GCF-5F01405.13-5FGRCh37-5Fassembly-5Freport.txt=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=2mzBk6ksCERabHcDIy7tR6p1aQvFGkLM8lZNrsWrA18= > > For some mysterious reason GRCh37 didn't include the mitochondrial chromosome so the UCSC folks decided to use mitochondrial sequence > NC_001807 and called it chrM. > > However, UCSC has recently decided to base hg19 on GRCh37.p13 instead of GRCh37. A rather surprising move after many years of hg19 being based on the latter. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.25_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=gxOOdwtmHjZfz-
Re: [Bioc-devel] BSgenome changes
Hi Felix, On 8/13/20 21:43, Felix Ernst wrote: Hi Leonard, Hi Herve, I followed your conversation, since I have noticed the same problem. Thanks, Herve, for the explanation of the recent changes on hg19. The GRCh37.P13 report states in its last line: MT assembled-molecule MT Mitochondrion J01415.2= NC_012920.1 non-nuclear 16569 chrM Since the last name is called "UCSC-style-name", wouldn't that mean that chrM has to be renamed to MT and not chrMT? This is a mistake in the sequence report for GRCh37.p13. GRCh37.p13:MT is the same as hg19:chrMT, not hg19:chrM. hg19:chrM and hg19:chrMT are **not** the same sequences. The former is NC_001807 and has length 16571 and the latter is NC_012920.1 and has length 16569. Yes, seqlevelsStyle() is sorting out all this mess for you ;-) Cheers, H. Thanks again for the explanation. Cheers, Felix -Ursprüngliche Nachricht- Von: Bioc-devel Im Auftrag von Hervé Pagès Gesendet: Freitag, 14. August 2020 01:08 An: Leonard Goldstein ; bioc-devel@r-project.org Cc: charlotte.sone...@fmi.ch Betreff: Re: [Bioc-devel] BSgenome changes Hi Leonard, On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote: Dear Bioc team, I'm following up on this recent GitHub issue <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ldg21 _SGSeq_issues_5=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=Tfk-tDM99P63dnsvMydG2phv5WQPVbJzPk0hzi-_1SE= >. Please see the issue for more details and code examples. It looks like changes in Bioc devel result in two copies of the mitochondrial chromosome for BSgenome.Hsapiens.UCSC.hg19 -- one named chrM like in previous package versions (length 16571) and one named chrMT (length 16569). When using seqlevelsStyle() to change chromosome names from UCSC to NCBI format, this results in new behavior -- in the past chrM was simply renamed MT, now the different sequence chrMT is used. Is this intended? Absolutely intended. There is a long story behind the unfortunate fate of the mitochondrial chromosome in hg19. I'll try to keep it short. When the UCSC folks released the hg19 browser more than 10 years ago, they based it on assembly GRCh37: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.13=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=jWtgKVQGC-SQp6i4prhKBiD5cBh2kEc8R1gL2uPlzy0= See sequence report for GRCh37: https://urldefense.proofpoint.com/v2/url?u=https-3A__ftp.ncbi.nlm.nih.gov_genomes_all_GCF_000_001_405_GCF-5F01405.13-5FGRCh37_GCF-5F01405.13-5FGRCh37-5Fassembly-5Freport.txt=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=2mzBk6ksCERabHcDIy7tR6p1aQvFGkLM8lZNrsWrA18= For some mysterious reason GRCh37 didn't include the mitochondrial chromosome so the UCSC folks decided to use mitochondrial sequence NC_001807 and called it chrM. However, UCSC has recently decided to base hg19 on GRCh37.p13 instead of GRCh37. A rather surprising move after many years of hg19 being based on the latter. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.25_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=gxOOdwtmHjZfz-EAFblY0cm-7upZ9useI3sEgDD87o8= See sequence report for GRCh37.p13: https://urldefense.proofpoint.com/v2/url?u=https-3A__ftp.ncbi.nlm.nih.gov_genomes_all_GCF_000_001_405_GCF-5F01405.25-5FGRCh37.p13_GCF-5F01405.25-5FGRCh37.p13-5Fassembly-5Freport.txt=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=49jni5SmG_DH80nnPZXXqvFNceB5jkZtlb7eKEA8558=epUg7bSfwCEF_WUOPlT5hPmLXHY7V51Mau09UaQNB5o= Note that GRCh37.p13 does include the mitochondrial chromosome. It's called MT in the official sequence report above and chrMT in hg19. At the same time the UCSC folks decided to keep chrM so now hg19 contains 2 mitochondrial sequences: chrM and chrMT. Previously it has only one: chrM. So what you see in BioC devel in BSgenome.Hsapiens.UCSC.hg19 and with seqlevelsStyle(genome) is only reflecting this. In particular seqlevelsStyle(genome) <- "NCBI" now does the following: - Rename chrMT -> MT. - chrM does NOT get renamed. There is no point in renaming this sequence because it has no equivalent in GRCh37.p13. Hope this helps, H. Leonard [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail man_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeA vimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYv fbojaqTJZVg=IczvesjTwEk
Re: [Bioc-devel] BSgenome changes
Hi Leonard, On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote: Dear Bioc team, I'm following up on this recent GitHub issue <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ldg21_SGSeq_issues_5=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=Tfk-tDM99P63dnsvMydG2phv5WQPVbJzPk0hzi-_1SE= >. Please see the issue for more details and code examples. It looks like changes in Bioc devel result in two copies of the mitochondrial chromosome for BSgenome.Hsapiens.UCSC.hg19 -- one named chrM like in previous package versions (length 16571) and one named chrMT (length 16569). When using seqlevelsStyle() to change chromosome names from UCSC to NCBI format, this results in new behavior -- in the past chrM was simply renamed MT, now the different sequence chrMT is used. Is this intended? Absolutely intended. There is a long story behind the unfortunate fate of the mitochondrial chromosome in hg19. I'll try to keep it short. When the UCSC folks released the hg19 browser more than 10 years ago, they based it on assembly GRCh37: https://www.ncbi.nlm.nih.gov/assembly/GCF_01405.13 See sequence report for GRCh37: https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/001/405/GCF_01405.13_GRCh37/GCF_01405.13_GRCh37_assembly_report.txt For some mysterious reason GRCh37 didn't include the mitochondrial chromosome so the UCSC folks decided to use mitochondrial sequence NC_001807 and called it chrM. However, UCSC has recently decided to base hg19 on GRCh37.p13 instead of GRCh37. A rather surprising move after many years of hg19 being based on the latter. https://www.ncbi.nlm.nih.gov/assembly/GCF_01405.25/ See sequence report for GRCh37.p13: https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/001/405/GCF_01405.25_GRCh37.p13/GCF_01405.25_GRCh37.p13_assembly_report.txt Note that GRCh37.p13 does include the mitochondrial chromosome. It's called MT in the official sequence report above and chrMT in hg19. At the same time the UCSC folks decided to keep chrM so now hg19 contains 2 mitochondrial sequences: chrM and chrMT. Previously it has only one: chrM. So what you see in BioC devel in BSgenome.Hsapiens.UCSC.hg19 and with seqlevelsStyle(genome) is only reflecting this. In particular seqlevelsStyle(genome) <- "NCBI" now does the following: - Rename chrMT -> MT. - chrM does NOT get renamed. There is no point in renaming this sequence because it has no equivalent in GRCh37.p13. Hope this helps, H. Leonard [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=IczvesjTwEkPQVlFX5wKSJLUHyjNHE0sk71a-kMAVEI= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] msa: call for help/support
se, thank you very much in advance! Best regards, Ulrich ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=wYD6AeRFq_AWqJYrR2yTLQ=ltX8frDE6n47-tywLeYGT6r9gnh9DGw8pO0yPOEcQNU=6oK3h-46Hallx4AJJ4luNvOxPhwXZ3bmqY4Eavj9M_0= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] VariantAnnotation::readVcf() sets the wrong seqlevelsStyle in devel
Hi Robert,
Yes seqlevelsStyle's new behavior is slightly different and less
forgiving. The thing is that it will generally reveal dormant issues
which is not such a bad thing after all.
Note that it doesn't seem completely straightforward to retrieve the
reference genome/assembly directly from the VCF header. AFAICT this
information is either missing or weirdly formatted. For example the
headers of the 1000genomes VCF files located at
ftp://ftp-trace.ncbi.nih.gov/1000genomes/ftp/release/20101123/interim_phase1_release/
contain
##reference=1000Genomes-NCBI37
or in the ex2.vcf file included in VariantAnnotation it's:
##reference=file:///seq/references/1000GenomesPilot-NCBI36.fasta
so not clear that importing this in the genome field of the returned VCF
object would be that helpful.
Thanks for pointing me to the VariantAnnotation vignette. I'll fix the
calls to readVcf() to use GRCh37 instead of hg19. Seems like one call
(on ex2.vcf) is using the wrong genome: ex2.vcf is based on hg18/NCBI36,
not on hg19/GRCh37. Will fix that too.
Sure readVcf() could probably be improved to perform some sanity checks
by making sure that the user-supplied genome is compatible with the
chromosome names. However that still won't prevent the user from
specifying the wrong genome (e.g. GRCh37 instead of NCBI36) like in the
ex2.vcf case. Anyway this is a feature request for readVcf().
In the end I'm not sure what's the purpose of specifying the genome
anyway. What does it give us? Maybe the vignette and examples in
VariantAnnotation should stop doing that? Better to not specify the
genome than specifying the wrong one.
Best,
H.
On 8/6/20 07:42, Robert Castelo wrote:
hi Hervé,
thank you very much for your clarifications, but this behavior is
different in release and has been different until now, this is BioC 3.11:
library(VariantAnnotation)
fl <- system.file("extdata", "chr22.vcf.gz", package="VariantAnnotation")
vcf <- readVcf(fl, "hg19")
seqlevels(vcf)
[1] "22"
seqlevelsStyle(vcf)
[1] "NCBI" "Ensembl"
i appreciate that the behavior now in devel is more consistent, i
actually never understood the need to specify the 'genome="hg19"'
argument since this in principle can be figured out from the VCF header
information. However, the documentation has become right now confusing,
if you go to subsection 2.1 and 2.1.2 from the introductory vignette, it
shows using readVcf() with "hg19" but then the sequence names are
literally what they are in the VCF file (NCBI style)
because of the large user base of VariantAnnotation (top-49 download)
and the many possible reverse dependencies downstream, i'd suggest that
either readVcf() issues an error or, maybe even better, overrides the
sequence level style in the VCF file maybe with a warning, when the
'genome' argument does not match the sequence style of the VCF file.
cheers,
robert.
On 04/08/2020 18:29, Hervé Pagès wrote:
Hi Robert,
The VCF file uses "22" for the chromosome name which is the name used
by NCBI. So explicitly specifying "hg19" in the readVcf() call is like
saying that this chromosome name is a UCSC name which is why
seqlevelsStyle() gets confused later.
If you specify the name of the NCBI assembly, things work as expected:
fl <- system.file("extdata", "chr22.vcf.gz",
package="VariantAnnotation")
vcf <- readVcf(fl, "GRCh37")
seqlevels(vcf)
# [1] "22"
seqlevelsStyle(vcf)
# [1] "NCBI"
seqlevelsStyle(vcf) <- "UCSC"
seqlevels(vcf)
# [1] "chr22"
Or, if you don't know what reference genome the file is based on,
don't specify it:
fl <- system.file("extdata", "chr22.vcf.gz",
package="VariantAnnotation")
vcf <- readVcf(fl)
seqlevels(vcf)
# [1] "22"
seqlevelsStyle(vcf)
# [1] "NCBI" "Ensembl"
seqlevelsStyle(vcf) <- "UCSC"
seqlevels(vcf)
# [1] "chr22"
or specify it later:
genome(vcf) <- "hg19"
seqinfo(vcf)
# Seqinfo object with 1 sequence from hg19 genome; no seqlengths:
# seqnames seqlengths isCircular genome
# chr22 NA NA hg19
Hope this helps,
H.
On 7/29/20 08:30, Robert Castelo wrote:
hi,
it looks like either VariantAnnotation::readVcf() or something in the
CollapsedVCF class broke in devel with respect to reading and setting
sequence styles:
library(VariantAnnotation)
fl <- system.file("extdata", "chr22.vcf.gz",
package="VariantAnnotation")
vcf <- readVcf(fl, "hg19")
seqlevels(vcf)
[1] "22"
seqlevelsStyle(vcf)
[1] "UCSC"
seqlevelsStyle(vcf) <- "UCSC"
seqlevels(vcf)
[1] "22"
you can find my session information below. l
Re: [Bioc-devel] VariantAnnotation::readVcf() sets the wrong seqlevelsStyle in devel
Hi Robert,
The VCF file uses "22" for the chromosome name which is the name used by
NCBI. So explicitly specifying "hg19" in the readVcf() call is like
saying that this chromosome name is a UCSC name which is why
seqlevelsStyle() gets confused later.
If you specify the name of the NCBI assembly, things work as expected:
fl <- system.file("extdata", "chr22.vcf.gz", package="VariantAnnotation")
vcf <- readVcf(fl, "GRCh37")
seqlevels(vcf)
# [1] "22"
seqlevelsStyle(vcf)
# [1] "NCBI"
seqlevelsStyle(vcf) <- "UCSC"
seqlevels(vcf)
# [1] "chr22"
Or, if you don't know what reference genome the file is based on, don't
specify it:
fl <- system.file("extdata", "chr22.vcf.gz", package="VariantAnnotation")
vcf <- readVcf(fl)
seqlevels(vcf)
# [1] "22"
seqlevelsStyle(vcf)
# [1] "NCBI""Ensembl"
seqlevelsStyle(vcf) <- "UCSC"
seqlevels(vcf)
# [1] "chr22"
or specify it later:
genome(vcf) <- "hg19"
seqinfo(vcf)
# Seqinfo object with 1 sequence from hg19 genome; no seqlengths:
# seqnames seqlengths isCircular genome
# chr22NA NA hg19
Hope this helps,
H.
On 7/29/20 08:30, Robert Castelo wrote:
hi,
it looks like either VariantAnnotation::readVcf() or something in the
CollapsedVCF class broke in devel with respect to reading and setting
sequence styles:
library(VariantAnnotation)
fl <- system.file("extdata", "chr22.vcf.gz", package="VariantAnnotation")
vcf <- readVcf(fl, "hg19")
seqlevels(vcf)
[1] "22"
seqlevelsStyle(vcf)
[1] "UCSC"
seqlevelsStyle(vcf) <- "UCSC"
seqlevels(vcf)
[1] "22"
you can find my session information below. let me know if you want me to
open an issue at the GitHub repo (VariantAnnotatoin or GenomeInfoDb?).
thanks!
robert.
BiocManager::version()
[1] ‘3.12’
sessionInfo()
R version 4.0.0 (2020-04-24)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS
Matrix products: default
BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=C
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats4 parallel stats graphics grDevices utils datasets
[8] methods base
other attached packages:
[1] VariantAnnotation_1.35.3 Rsamtools_2.5.3
[3] Biostrings_2.57.2 XVector_0.29.3
[5] SummarizedExperiment_1.19.6 DelayedArray_0.15.7
[7] matrixStats_0.56.0 Matrix_1.2-18
[9] Biobase_2.49.0 GenomicRanges_1.41.5
[11] GenomeInfoDb_1.25.8 IRanges_2.23.10
[13] S4Vectors_0.27.12 BiocGenerics_0.35.4
[15] BiocManager_1.30.10
loaded via a namespace (and not attached):
[1] progress_1.2.2 tidyselect_1.1.0 purrr_0.3.4
[4] lattice_0.20-41 vctrs_0.3.1 generics_0.0.2
[7] BiocFileCache_1.13.0 rtracklayer_1.49.4 GenomicFeatures_1.41.2
[10] blob_1.2.1 XML_3.99-0.4 rlang_0.4.6
[13] pillar_1.4.4 glue_1.4.1 DBI_1.1.0
[16] rappdirs_0.3.1 BiocParallel_1.23.2 bit64_0.9-7.1
[19] dbplyr_1.4.4 GenomeInfoDbData_1.2.3 lifecycle_0.2.0
[22] stringr_1.4.0 zlibbioc_1.35.0 memoise_1.1.0
[25] biomaRt_2.45.2 curl_4.3 AnnotationDbi_1.51.3
[28] Rcpp_1.0.4.6 BSgenome_1.57.5 openssl_1.4.1
[31] bit_1.1-15.2 hms_0.5.3 askpass_1.1
[34] digest_0.6.25 stringi_1.4.6 dplyr_1.0.0
[37] grid_4.0.0 tools_4.0.0 bitops_1.0-6
[40] magrittr_1.5 RCurl_1.98-1.2 RSQLite_2.2.0
[43] tibble_3.0.1 crayon_1.3.4 pkgconfig_2.0.3
[46] ellipsis_0.3.1 prettyunits_1.1.1 assertthat_0.2.1
[49] httr_1.4.1 R6_2.4.1 GenomicAlignments_1.25.3
[52] compiler_4.0.0
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=gp0KKC6W1uS1YnyFI5iSuxF5WSUpOhbHwL94GRP8yu0=Co1P5SErF64uPYhHMltM3De48hQLl-XHK3gfZOEnSKc=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel?
On 7/7/20 02:50, Hervé Pagès wrote:
On 7/7/20 02:46, Bhagwat, Aditya wrote:
Thankyou Herve!
I guess that means that I can pull the fix in a day or two, is that
right?
Yes, as soon as BSgenome 1.57.4 propagates, which should take between
24h and 48h.
To be clear: BSgenome 1.57.4 will become available for installation with
BiocManager::install("BSgenome") only in a couple of days but you can
get it now by installing directly from GitHub with
BiocManager::install("Bioconductor/BSgenome").
H.
H.
Aditya
________
From: Hervé Pagès [hpa...@fredhutch.org]
Sent: Tuesday, July 07, 2020 11:45 AM
To: Bhagwat, Aditya; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in
bioc-devel?
Hi Aditya,
This change was not intended, sorry. Should be fixed in BSgenome 1.57.4.
Cheers,
H.
On 7/7/20 01:53, Bhagwat, Aditya wrote:
Sorry, my earlier email had a copy/paste error - corrected now
From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of
Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de]
Sent: Tuesday, July 07, 2020 10:50 AM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in
bioc-devel?
It's the BSgenome to GenomeDescription coercer that seems to be
missing - is this on purpose?
# bsgenomeName(BSgenomeObj) FAILS
#---
bsname <- GenomeInfoDb::bsgenomeName(bsgenome)
index_genome(bsgenome, indexedgenomesdir = tempdir())
Error in h(simpleError(msg, call)) :
unable to find an inherited method for function 'bsgenomeName'
for signature '"BSgenome"
# as(bsgenome, 'GenomeDescription') also FAILS
#
bsname <- GenomeInfoDb::bsgenomeName(as(bsgenome,
'GenomeDescription')) # ALSO FAILS
index_genome(bsgenome, indexedgenomesdir = tempdir())
Error in h(simpleError(msg, call)) :
error in evaluating the argument 'x' in selecting a method for
function 'bsgenomeName': no method or default for coercing "BSgenome"
to "GenomeDescription"
Aditya
From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of
Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de]
Sent: Tuesday, July 07, 2020 10:22 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in
bioc-devel?
Dear bioc-devel,
multicrispr is having an error on the bioc-devel build
machines<https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.12_bioc-2DLATEST_multicrispr_malbec1-2Dchecksrc.html=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=N-MGRsB-Th9-Po32CSpim6CogpSSPciuLCjci-Uuh8g=
>, caused by:
unable to find an inherited method for function 'bsgenomeName' for
signature '"BSgenome"
This is a bit strange, because normally a BSgenome object gets
automatically converted to a GenomeDescription object before being
sent to the method bsgenomeName. In bioc-devel, for some reason this
mechanism seems to be broken. Is it on purpose? What would be the
best fix/patch?
Right now, I'm checking whether explicitation fixes things:
bsname <-
GenomeInfoDb::bsgenomeName(bsgenome)
# FAILS
bsname <- GenomeInfoDb::bsgenomeName(as(bsgenome,
'GenomeDescription')) # WORKS ? (VERIFYING)
Thank you for feedback :-)
Aditya
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk=
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk=
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
--
Hervé Pagès
Program in C
Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel?
On 7/7/20 02:46, Bhagwat, Aditya wrote: Thankyou Herve! I guess that means that I can pull the fix in a day or two, is that right? Yes, as soon as BSgenome 1.57.4 propagates, which should take between 24h and 48h. H. Aditya From: Hervé Pagès [hpa...@fredhutch.org] Sent: Tuesday, July 07, 2020 11:45 AM To: Bhagwat, Aditya; bioc-devel@r-project.org Subject: Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel? Hi Aditya, This change was not intended, sorry. Should be fixed in BSgenome 1.57.4. Cheers, H. On 7/7/20 01:53, Bhagwat, Aditya wrote: Sorry, my earlier email had a copy/paste error - corrected now From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de] Sent: Tuesday, July 07, 2020 10:50 AM To: bioc-devel@r-project.org Subject: Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel? It's the BSgenome to GenomeDescription coercer that seems to be missing - is this on purpose? # bsgenomeName(BSgenomeObj) FAILS #--- bsname <- GenomeInfoDb::bsgenomeName(bsgenome) index_genome(bsgenome, indexedgenomesdir = tempdir()) Error in h(simpleError(msg, call)) : unable to find an inherited method for function 'bsgenomeName' for signature '"BSgenome" # as(bsgenome, 'GenomeDescription') also FAILS # bsname <- GenomeInfoDb::bsgenomeName(as(bsgenome, 'GenomeDescription')) # ALSO FAILS index_genome(bsgenome, indexedgenomesdir = tempdir()) Error in h(simpleError(msg, call)) : error in evaluating the argument 'x' in selecting a method for function 'bsgenomeName': no method or default for coercing "BSgenome" to "GenomeDescription" Aditya From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de] Sent: Tuesday, July 07, 2020 10:22 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel? Dear bioc-devel, multicrispr is having an error on the bioc-devel build machines<https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.12_bioc-2DLATEST_multicrispr_malbec1-2Dchecksrc.html=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=N-MGRsB-Th9-Po32CSpim6CogpSSPciuLCjci-Uuh8g= >, caused by: unable to find an inherited method for function 'bsgenomeName' for signature '"BSgenome" This is a bit strange, because normally a BSgenome object gets automatically converted to a GenomeDescription object before being sent to the method bsgenomeName. In bioc-devel, for some reason this mechanism seems to be broken. Is it on purpose? What would be the best fix/patch? Right now, I'm checking whether explicitation fixes things: bsname <- GenomeInfoDb::bsgenomeName(bsgenome) # FAILS bsname <- GenomeInfoDb::bsgenomeName(as(bsgenome, 'GenomeDescription')) # WORKS ? (VERIFYING) Thank you for feedback :-) Aditya [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel?
Hi Aditya, This change was not intended, sorry. Should be fixed in BSgenome 1.57.4. Cheers, H. On 7/7/20 01:53, Bhagwat, Aditya wrote: Sorry, my earlier email had a copy/paste error - corrected now From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de] Sent: Tuesday, July 07, 2020 10:50 AM To: bioc-devel@r-project.org Subject: Re: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel? It's the BSgenome to GenomeDescription coercer that seems to be missing - is this on purpose? # bsgenomeName(BSgenomeObj) FAILS #--- bsname <- GenomeInfoDb::bsgenomeName(bsgenome) index_genome(bsgenome, indexedgenomesdir = tempdir()) Error in h(simpleError(msg, call)) : unable to find an inherited method for function 'bsgenomeName' for signature '"BSgenome" # as(bsgenome, 'GenomeDescription') also FAILS # bsname <- GenomeInfoDb::bsgenomeName(as(bsgenome, 'GenomeDescription')) # ALSO FAILS index_genome(bsgenome, indexedgenomesdir = tempdir()) Error in h(simpleError(msg, call)) : error in evaluating the argument 'x' in selecting a method for function 'bsgenomeName': no method or default for coercing "BSgenome" to "GenomeDescription" Aditya From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de] Sent: Tuesday, July 07, 2020 10:22 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] bsGenomeName(BSgenomeObject) disappeared in bioc-devel? Dear bioc-devel, multicrispr is having an error on the bioc-devel build machines<https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.12_bioc-2DLATEST_multicrispr_malbec1-2Dchecksrc.html=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=N-MGRsB-Th9-Po32CSpim6CogpSSPciuLCjci-Uuh8g= >, caused by: unable to find an inherited method for function 'bsgenomeName' for signature '"BSgenome" This is a bit strange, because normally a BSgenome object gets automatically converted to a GenomeDescription object before being sent to the method bsgenomeName. In bioc-devel, for some reason this mechanism seems to be broken. Is it on purpose? What would be the best fix/patch? Right now, I'm checking whether explicitation fixes things: bsname <- GenomeInfoDb::bsgenomeName(bsgenome) # FAILS bsname <- GenomeInfoDb::bsgenomeName(as(bsgenome, 'GenomeDescription')) # WORKS ? (VERIFYING) Thank you for feedback :-) Aditya [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=_1eFc4UGidLaNS3zXQqjaaIUIU5zu68VT0g6PN0b24E=aAOK1NFWIMal4FrsocE13hvo95BTk3RL18eVMCncRzk= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] proposal for additional seqlevelsStyle
Hi Vince, Robert, Kasper,
I've done some work on this. Starting with GenomeInfoDb_1.25.7 the
seqlevelsStyle() setter has 2 major improvements:
1. It knows how to rename contigs and scaffolds, not just the chromosomes:
library(TxDb.Mmusculus.UCSC.mm10.knownGene)
seqinfo(txdb)
# Seqinfo object with 66 sequences (1 circular) from mm10 genome:
# seqnames seqlengths isCircular genome
# chr1195471971 mm10
# chr2182113224 mm10
# chr3160039680 mm10
# chr4156508116 mm10
# chr5151834684 mm10
# ... .........
# chrUn_GL456392 23629 mm10
# chrUn_GL456393 55711 mm10
# chrUn_GL456394 24323 mm10
# chrUn_GL456396 21240 mm10
# chrUn_JH584304 114452 mm10
seqlevelsStyle(txdb) <- "NCBI"
seqinfo(txdb)
# Seqinfo object with 66 sequences (1 circular) from GRCm38 genome:
# seqnames seqlengths isCircular genome
# 1 195471971GRCm38
# 2 182113224GRCm38
# 3 160039680GRCm38
# 4 156508116GRCm38
# 5 151834684GRCm38
# ... .........
# MSCHRUN_CTG10 23629GRCm38
# MSCHRUN_CTG11 55711GRCm38
# MSCHRUN_CTG12 24323GRCm38
# MSCHRUN_CTG15 21240GRCm38
# MSCHRUN_CTG23 114452GRCm38
2. It supports new style RefSeq for renaming to/from RefSeq accessions:
seqlevelsStyle(txdb) <- "RefSeq"
seqinfo(txdb)
# Seqinfo object with 66 sequences (1 circular) from GRCm38 genome:
# seqnamesseqlengths isCircular genome
# NC_67.6 195471971GRCm38
# NC_68.7 182113224GRCm38
# NC_69.6 160039680GRCm38
# NC_70.6 156508116GRCm38
# NC_71.6 151834684GRCm38
# ............
# NT_166476.1 23629GRCm38
# NT_166477.1 55711GRCm38
# NT_166478.1 24323GRCm38
# NT_166480.1 21240GRCm38
# NT_187064.1 114452GRCm38
These new features only work on objects for which the genome is set to
an NCBI assembly (e.g. WBcel235) or UCSC genome (e.g. ce11). This is the
case with TxDb, BSgenome, and SNPlocs objects.
The workhorses behind them are new low-level utilities
getChromInfoFromNCBI() and getChromInfoFromUCSC(). These support 141
NCBI assemblies and 74 UCSC genomes at the moment, respectively. It's
easy to add new organisms. The gotcha is that they require internet
access and so does the seqlevelsStyle() setter. This could be mitigated
by caching the data via BiocFileCache.
Next thing on the list is to support the GenBank style (Vince's original
request) to rename to/from GenBank accessions.
Cheers,
H.
On 12/13/19 10:51, Kasper Daniel Hansen wrote:
If the chromosome name depends on the assembly, that makes GenomeInfoDb
even more useful and necessary. Provided it is supported of course.
On Fri, Dec 13, 2019 at 11:45 AM Vincent Carey
wrote:
I tried an inline png but I think it was rejected by bioc-devel. Here's
another try.
On Fri, Dec 13, 2019 at 11:40 AM Vincent Carey
wrote:
Thanks -- It is good to know more about the complications of adding
seqlevelsStyle elements.
I am not sure how pervasive this will be in SNP annotation in the future.
The "new API" for dbSNP
references SPDI annotation conventions.
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.ncbi.nlm.nih.gov_variation_v0_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q-r9L4kC5cjCxRXc33m9n1hKs7WLWiYhNB2t6B_b7nU=1jolcMxvVlDvdU0u8LZeWnWHJFt-R6ZweevICNvw2oo=
at least one dbsnp build 152 resource uses this nomenclature. The one
referenced below is the "go-to" resource for current rsid-coordinate
correspondence, as far as I know.
library(VariantAnnotation)
*0/0 packages newly attached/loaded, see sessionInfo() for details.*
mypar = GRanges("NC_01.11", IRanges(10,12)) # note seqnames
nn = readVcf("
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ncbi.nih.gov_snp_redesign_latest-5Frelease_VCF_GCF-5F01405.38.gz=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q-r9L4kC5cjCxRXc33m9n1hKs7WLWiYhNB2t6B_b7nU=SXqRWrv1IK1WpNOf3cjMC82-fvChoJ6za48WzlRGeAU=
",
+ genome="GRCh38", param=mypar)
head(rowRanges(nn), 3)
GRanges object with 3 ranges and 5 metadata columns:
seqnamesranges strand | paramRangeID
REF
|
rs1331956057 NC_01.1110 * |
C
rs1252351580 NC_01.11100036 * |
T
rs1238523913 NC_01.11100051 * |
T
ALT QUAL FILTER
rs1331956057
Re: [Bioc-devel] Deprecated a contained class
Hi Martin,
Don't know how/where to implement a deprecation message that wouldn't be
confusing for the end users.
FWIW if the replacement of class Original with class New is just a
renaming (everything else remains the same), a situation I've dealt with
a lot in the S4Vectors/IRanges/GenomicRanges infrastructure, I like to
use the following pragmatic approach:
In package A:
## Replace Original with New in the Original class definition.
setClass("New", ...)
## Define Original as an "alias" for New:
setClass("Original", contains="New", representation("VIRTUAL"))
Then contact maintainers of packages that implement subclasses of
Original that they should use New instead of Original. They can take
their time because the cost of keeping the Original alias around is
virtually zero.
H.
On 6/26/20 08:10, Martin Morgan wrote:
Pkg A provides a (virtual) class "Original".
Pkg B creates a derived class setClass("Derived", contains = "Original")
Pkg A would like to deprecate "Original" and replace with "New".
Any ideas on how to implement a deprecation message so that the Pkg B
maintainer knows that their use of class Original is deprecated, but users
aren't bothered by more-or-less incomprehensible messages on use? I guess using
.Deprecated() somehow associated with setClass(); implementing something in
initialize,Original-method would be too irritating to the user.
Thanks,
Martin
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ZKKJsd3wTpxv3iRPiOQc8jk8ptFPwzh5TRNm8J6qDvA=TPnb__JeD-SoYXG79uR2hkfYDjmT6apkCdSfqyF1bKA=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] How to set dimnames inside constructor function?
Hi Muad,
I'm not able to reproduce this. With a naked 'count' matrix:
library(SummarizedExperiment)
count <- matrix(1:15, ncol=3)
row_data <- DataFrame(stuff=runif(5))
se1 <- SummarizedExperiment(list(count=count), rowData=row_data)
dimnames(se1) <- list(sprintf("Gene%04d", 1:5), sprintf("ID%03d", 1:3))
dimnames(se1)
# [[1]]
# [1] "Gene0001" "Gene0002" "Gene0003" "Gene0004" "Gene0005"
#
# [[2]]
# [1] "ID001" "ID002" "ID003"
With dimnames on the 'count' matrix:
dimnames(count) <- list(LETTERS[1:5], LETTERS[1:3])
se2 <- SummarizedExperiment(list(count=count), rowData=row_data)
dimnames(se2) <- list(sprintf("Gene%04d", 1:5), sprintf("ID%03d", 1:3))
dimnames(se2)
# [[1]]
# [1] "Gene0001" "Gene0002" "Gene0003" "Gene0004" "Gene0005"
#
# [[2]]
# [1] "ID001" "ID002" "ID003"
So I don't know how/when you get the error you reported. If the error
occurs in your .CalciumExperiment() internal function I would need to
have access to it in order to understand why it fails. Note that if the
function calls the assay() or assays() setter at some point then it
probably needs to use 'withDimnames=FALSE', as indicated by the error
message.
Thanks,
H.
> sessionInfo()
R version 4.0.0 Patched (2020-04-27 r78316)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.6 LTS
Matrix products: default
BLAS: /home/hpages/R/R-4.0.r78316/lib/libRblas.so
LAPACK: /home/hpages/R/R-4.0.r78316/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] parallel stats4stats graphics grDevices utils datasets
[8] methods base
other attached packages:
[1] SummarizedExperiment_1.19.5 DelayedArray_0.15.5
[3] matrixStats_0.56.0 Matrix_1.2-18
[5] Biobase_2.49.0 GenomicRanges_1.41.5
[7] GenomeInfoDb_1.25.4 IRanges_2.23.10
[9] S4Vectors_0.27.12 BiocGenerics_0.35.4
loaded via a namespace (and not attached):
[1] lattice_0.20-41bitops_1.0-6 grid_4.0.0
[4] zlibbioc_1.35.0XVector_0.29.3 tools_4.0.0
[7] RCurl_1.98-1.2 compiler_4.0.0 GenomeInfoDbData_1.2.3
On 6/18/20 02:17, Muad Abd El Hay wrote:
Hello everyone,
This is my first attempt at writing a package (wrote it in S3 and nowHi
porting it to S4). So it might be a trivial question.
I am trying to extend the SummarizedExperiment object for calcium
imaging data (no gene names as features). Features/rownames are the
number of the frames and colnames are the cells/ROIs.
Inside the constructor function, I wanted to set the rownames and
colnames as below:
```R
se <- SummarizedExperiment(list(raw=raw),
rowData = DataFrame(time = time),
...)
dimnames(se) <- list(paste("f", 1:nrow(se), sep=""),
paste("name", 1:ncol(se), sep="_"))
.CalciumExperiment(se)
```
But I keep getting the following error:
```R
Error in `assays<-`(`*tmp*`, withDimnames = withDimnames, ..., value =
`*vtmp*`) :
please use 'assay(x, withDimnames=FALSE)) <- value' or 'assays(x,
withDimnames=FALSE)) <- value' when the dimnames on the supplied
assay(s) are not identical to the dimnames on CalciumExperiment
object
'x'
```
I also tried using `rownames(se)`and `colnames(se)`with the same error.
Setting the `dimnames`, `colnames`, or `rownames` on the `raw` matrix
beforehand also did not work.
Am I missing something fundamental here?
Thank you in advance!
Best wishes,
Muad Abd El Hay
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FNTL6nWceeRQEmN0D59W-TTsONVBwTUFGHIAnpeD31U=kxDXq2jEie3hJB-VfrLFyIhhjHx9VyV27-HvJQ7i1VU=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] lipidr: Unable to reproduce error (possibly from S4Vectors)
Hi Ahmed,
Just a heads up that Lori's workaround (reinstalling iheatmap from
source on all the builders) should be considered a temporary one and
that the fundamental problem remains. The fundamental problem being that
the iheatmap's Windows and Mac binaries that are on CRAN are broken. And
the reason they are broken is because they contain stale information in
their method cache.
As a consequence, the lipidr error you were seeing a few days ago on our
build report is back today on the devel report:
https://bioconductor.org/checkResults/3.12/bioc-LATEST/lipidr/
Note that this time it's only on Windows and Mac. This is because
yesterday we updated R to R 4.0.2 on the devel builders so the build
machines automatically reinstalled all the deps from scratch. iheatmap
is one of them and the build system picked up the Windows and Mac
binaries from CRAN, which are broken :-/
We'll see the same problem on the release builds when we update R to R
4.0.2 there too.
Bottom line: the only true fix is that the iheatmap authors/maintainers
upload a new version of their package to CRAN. The only change they need
to do is bump the version. Alternatively, they could reconsider
depending on S4Vectors. Bioconductor moves fast and CRAN packages that
depend on Bioconductor packages are inherently at the risk of seeing
their binaries become stale.
Hope this helps,
H.
On 6/22/20 04:50, Shepherd, Lori wrote:
I reinstalled iheatmap yesterday and it should be reflected in today's
(Mondays) report.
Cheers,
Lori Shepherd
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263
*From:* Ahmed Mohamed
*Sent:* Monday, June 22, 2020 2:18 AM
*To:* Martin Morgan
*Cc:* Vincent Carey ; Hervé Pagès
; bioc-devel ; Shepherd,
Lori
*Subject:* Re: [Bioc-devel] lipidr: Unable to reproduce error (possibly
from S4Vectors)
Excellent catch Martin.
I was able to confirm the issue using the script below (on Bioc-Devel
Docker). The issue was also resolved by simply reinstalling iheatmapr.
It would be great if iheatmapr is reinstalled manually on the devel
build systems.
remove.packages(c("iheatmapr", "S4Vectors"))
devtools::install_github("Bioconductor/S4Vectors",
ref="e8dffc0157f2c4779fce3c85e5ef601bb0a35d33")
install.packages("iheatmapr")
packageVersion("S4Vectors")
# "0.27.0"
packageVersion("iheatmapr")
# "0.4.12"
library(lipidr)
library(iheatmapr)
example("iheatmap")
# Runs successfully
## Update S4Vector
rm(list = ls())
rstudioapi::restartSession()
devtools::install_github("Bioconductor/S4Vectors")
packageVersion("S4Vectors")
# "0.27.12"
library(iheatmapr)
example("iheatmap")
# Error in .wrap_in_length_one_list_like_object(value, name, x) :
# failed to coerce 'list(value)' to a IheatmapPlots object of length 1
## Reinstall iheatmapr
rm(list = ls())
rstudioapi::restartSession()
install.packages("iheatmapr")
library(iheatmapr)
example("iheatmap")
# Runs successfully
Cheers.
Ahmed.
On Thu, 18 Jun 2020 at 00:52, Martin Morgan <mailto:mtmorgan.b...@gmail.com>> wrote:
You can see package versions on the build system from
https://bioconductor.org/checkResults/devel/bioc-LATEST/index.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1HWo5rIWA1m5ihxjEdHQES7eiiUCH5lqvmKOON4J2Nm8lJSd6ncmMQs2-5FhUktt5pXPTp1smrU6cKa4190T7elc944QS2Ydfuvp0t0c29VorU11a-5FJwrxBfbADYAfJGX5CDQJNzcBds5IVb-5FLtdmsg7t8Ld-5FJyXp3M7L7uW2MvmMMnH8ci3Phnzvw-5FiaOi0u9G-2Dl54dBJQI5av1sYcF-2DXB-2DchvqVtJ-5FdoIbdWZgo0cQbvpDTl4qwhMSI3-2DT5j57ghQcQiG5qiGemiudrobXzA6XqKDpvteiE2tnv1JEegc1WaEKcl6RRjDDR3DXUQOSDD-2Diwfdcr-5FfKL4y8BIfVSxVcfA9foqFw5ODRUoVPtzsaS0_https-253A-252F-252Fbioconductor.org-252FcheckResults-252Fdevel-252Fbioc-2DLATEST-252Findex.html=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=KMYCcC6SjfUiCjL5IgcN30_DGaTKHyt5xAmA2OaY-2s=HMLRRZSzTs8eBf-GQBqLOx4AlcpY2d5kNsLvFPq7SQY=>
clicking on 'installed pkgs' link in the center top table. iheatmapr
is at version 0.4.12.
I think what is happening is like
https://support.bioconductor.org/p/131689/#131695
<https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1CwyVIg3N8SoBBwdD-5FFZCiSutr81swQb4KYpE6AXzbu-2DD36e-5F5eSxfAEMhJSyL-2DJ7KoruFV35JklCfpumYnw-5FPV4SpILT4B7wuZtuwXsxnWJYFdapO9ukunWgWn39PwtvG1o5zkiJjv1wwLOio-2D63U40zo3qPGplTSe3XQN4LtamopYmUBwTYsEewP58hJ4qna2-2DBpptSChUQo998UFg55JhNHe8ejCjdB1IvVvZSikJx2zpcqfEQZ-2DkvLK-5FNcASuHZk8jVRxH9LtAiCXae2enWAZvaXxUDc-2D-5F0Oiov8GTnMdglDnbpl2KouhuA9-5F2xdNAvcsZwWynXeOmu0sJhz8GA_https-253A-252F-252Fsupport.bioconductor.org-252Fp-252F131689-252F-2523131695=DwMFAw=eRAMFD45gAfqt
Re: [Bioc-devel] GenomicScores: irreproducible build error caused by gwascat
On 6/9/20 06:57, Martin Morgan wrote:
I wrote a small gist
https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_mtmorgan_21e18991c6ebdb388e8828bcc0fe72f6=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-O2S2vunnN1XaaLDV0ShKsYOmdWVHU3VPC5w9GUdeDI=HWmLUbVyv6NbkJJ97AdGYpmXeit0Ip7ZLCU34ZB0Pqo=
that queries for broken dependencies. Using two packages that have been
mentioned recently on this mailing list
> tbl <- deps_broken(c("EnrichmentBrowser", "GenomicScores"))
> tbl
# A tibble: 1 x 5
pkg dep install buildsrc checksrc
1 EnrichmentBrowser safe OK OK ERROR
> tbl %>% count(pkg, .drop=FALSE)
# A tibble: 2 x 2
pkg n
1 EnrichmentBrowser 1
2 GenomicScores 0
Trying to install 'safe' from public repositories fails
> BiocManager::install("safe")
Bioconductor version 3.12 (BiocManager 1.30.10), R 4.0.0 Patched (2020-05-14
r78465)
Installing package(s) 'safe'
Warning message:
package 'safe' is not available (for R version 4.0.0 Patched)
but it can be installed directly from git using the 'remotes' package
Cool! I never realized that remotes::install_git() could be used to
install from arbitrary git servers but I guess that makes sense.
remotes::install_git(
"https://urldefense.proofpoint.com/v2/url?u=https-3A__git.bioconductor.org_packages_safe=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-O2S2vunnN1XaaLDV0ShKsYOmdWVHU3VPC5w9GUdeDI=erDWnwZtrMpHgSrJJ4Z219hyyi9K5Xq2cJVgtRBP9qU=
",
repos = BiocManager::repositories()
)
I do not think it would be a good idea for BiocManager::install(version =
"devel") to use a repository that included packages that installed but did not
build or check. One interpretation of the GenomicScores exchange is that it helped alert
the maintainer of gwascat about an error in their package, and encouraged a prompt fix.
Well one could argue that the primary alert is the red glyphs on the
build report.
Also BiocManager is really meant to help users follow best practices, rather
than to make Bioconductor developer's lives easier.
Perhaps there could be some other easy developer-oriented approach to
installing broken packages?
Maybe via a different function then? E.g. BiocManager::install_master().
Would point to the master branch of software, data-exp and workflows, in
addition to CRAN. Called with no argument it would be an easy way for
developers to get their packages in sync with what's on the build
machines so would make it easier to reproduce the errors they see on the
build report.
H.
Martin
On 6/8/20, 10:20 PM, "Hervé Pagès" wrote:
On 6/5/20 07:52, Martin Morgan wrote:
> no, the build system should only propagate packages that have passed
build and check -- the goal is to make the life of the user easier and more
reliable, us developers have to sweat the details!
This makes a lot of sense for release but for devel maybe the criteria
for propagating a package could be relaxed? It doesn't sound too insane
to do that but I realize it does introduce a difference between release
and devel that could also cause its own confusion.
Another approach that is currently under consideration is to make
BiocManager::install() capable of installing/updating packages directly
from git.bioconductor.org in BioC devel. This could be achieved by
making the source tarballs resulting from
git checkout master
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.bioconductor.org_packages_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-O2S2vunnN1XaaLDV0ShKsYOmdWVHU3VPC5w9GUdeDI=byFAKeaah2EIS-mdsi3iT0Bek2Y-SqLNX5M007ZT82w=
&&
R CMD build --no-build-vignettes
available in their own repo (e.g.
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_devel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-O2S2vunnN1XaaLDV0ShKsYOmdWVHU3VPC5w9GUdeDI=oIWaJnqFZ1SL9SIDDDc5IChaAr0NtnraSpAcJSHcBw4=
) and add this repo to
BiocManager::repositories() in devel. Note that these no-vignettes
source tarballs are actually those used by the build system during the
INSTALL stage.
How do people feel about that?
H.
>
> Usually there is a single package that has changed and causes problems,
and like in the present case a little detective work (once one knows what to look
for) leads quickly to the suspect.
>
> Martin
>
> On 6/5/20, 10:18 AM, "Robert Castelo" wrote:
>
> Thanks Martin, i wasn't aware about that fact. i've cloned the
gwascat
> repo and been able to dire
Re: [Bioc-devel] GenomicScores: irreproducible build error caused by gwascat
On 6/8/20 19:20, Hervé Pagès wrote:
On 6/5/20 07:52, Martin Morgan wrote:
no, the build system should only propagate packages that have passed
build and check -- the goal is to make the life of the user easier and
more reliable, us developers have to sweat the details!
This makes a lot of sense for release but for devel maybe the criteria
for propagating a package could be relaxed? It doesn't sound too insane
to do that but I realize it does introduce a difference between release
and devel that could also cause its own confusion.
Another approach that is currently under consideration is to make
BiocManager::install() capable of installing/updating packages directly
from git.bioconductor.org in BioC devel. This could be achieved by
making the source tarballs resulting from
git checkout master https://git.bioconductor.org/packages/ &&
R CMD build --no-build-vignettes
available in their own repo (e.g.
https://bioconductor.org/packages/devel) and add this repo to
That URL (https://bioconductor.org/packages/devel) is already in use.
So maybe better at https://bioconductor.org/packages/master/ or
something like that.
H.
BiocManager::repositories() in devel. Note that these no-vignettes
source tarballs are actually those used by the build system during the
INSTALL stage.
How do people feel about that?
H.
Usually there is a single package that has changed and causes
problems, and like in the present case a little detective work (once
one knows what to look for) leads quickly to the suspect.
Martin
On 6/5/20, 10:18 AM, "Robert Castelo" wrote:
Thanks Martin, i wasn't aware about that fact. i've cloned the
gwascat
repo and been able to directly install from the directory and
reproduce
the error. in this case, this was easy because it involved just one
package but with multiple broken package dependencies, i'd have to
manually clone each of them and install them to reproduce the error.
would it be a good idea in the devel build system to propagate
the tar
ball resulting of
R CMD build --no-build-vignettes
so that we get automatically updates for at least those whose
problem is
in the vignettes only?
robert.
On 05/06/2020 15:37, Martin Morgan wrote:
> R CMD INSTALL or install.packages("foo", repos = NULL) on
a clone of the repository. A build might fail because the examples or
vignette fail to build, whereas for installation the only requirement
is that the package is syntactically correct.
>
> Martin
>
> On 6/5/20, 7:58 AM, "Robert Castelo"
wrote:
>
> never thought about it this way, but how can the system
install
> something that does not build?
>
> how should *i* install something that does not build to
reproduce the error?
>
> sorry if these are very naive questions!!
>
> robert.
>
> On 05/06/2020 13:34, Martin Morgan wrote:
> > The build system installs the version of gwascat that is
available from git checkout (anticipating that this will propagate).
gwascat installs, but fails to pass check -- it is likely broken
> >
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_gwascat_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uJnw6vW_sTWKb9l6DPFY7NEqPq_zkEzDFbIrir-Xis8=r_GJJMDdjgc6nXTDSC0OhJW6gho041eSiWwKrw3h00w=
> >
> > in a way that causes your package to fail
> >
> > Martin
> >
> > On 6/5/20, 6:27 AM, "Bioc-devel on behalf of Robert
Castelo" robert.cast...@upf.edu> wrote:
> >
> > hi,
> >
> > my package GenomicScores is not building, see:
> >
> >
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_GenomicScores_malbec1-2Dbuildsrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uJnw6vW_sTWKb9l6DPFY7NEqPq_zkEzDFbIrir-Xis8=-TxA290vxOPuMjHcxETokMk-jPL8H_YJpKMIr3UL50E=
> >
> > apparently, it is breaking in the following lines
of its vignette:
> >
> > library(gwascat)
> > data(ebicat37)
> >
> > which in the report from the bioc build machine says:
> >
> > gwascat loaded. Use makeCurrentGwascat() to
extract current image.
> > from EBI. The data folder of this package has
some legacy extracts.
> > Quitting from lines 404-408 (Genomi
Re: [Bioc-devel] GenomicScores: irreproducible build error caused by gwascat
> > > however, in my installation of current bioc-devel on R-4.0 with all > > packages up to date, GenomicScores builds fine and i cannot reproduce > > this error. below you can find my session information after the previous > > two instructions. the logs of 'gwascat' show changes in May 2nd that > > could be potentially responsible for this but the fact is that 'gwascat' > > is not building either and it does not seem that the changes propagate > > through the build system, its version is still 2.21.0, on which > > GenomicScores built without problems for the current release. > > > > i'm cc'ing this email to Vince, as maintainer of 'gwascat', in case he > > has some more specific suggestion about this but any hint will be > > greatly appreciated. > > > > thanks!! > > > > sessionInfo() > > R version 4.0.0 (2020-04-24) > > Platform: x86_64-pc-linux-gnu (64-bit) > > Running under: CentOS Linux 7 (Core) > > > > Matrix products: default > > BLAS: /opt/R/R-4.0.0/lib64/R/lib/libRblas.so > > LAPACK: /opt/R/R-4.0.0/lib64/R/lib/libRlapack.so > > > > locale: > >[1] LC_CTYPE=en_US.UTF8 LC_NUMERIC=C > >[3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8 > >[5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8 > >[7] LC_PAPER=en_US.UTF8 LC_NAME=C > >[9] LC_ADDRESS=C LC_TELEPHONE=C > > [11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > other attached packages: > > [1] gwascat_2.21.0 colorout_1.2-2 > > > > loaded via a namespace (and not attached): > >[1] Rcpp_1.0.4.6 lattice_0.20-41 > >[3] prettyunits_1.1.1 Rsamtools_2.5.1 > >[5] Biostrings_2.57.1 assertthat_0.2.1 > >[7] digest_0.6.25 BiocFileCache_1.13.0 > >[9] R6_2.4.1 GenomeInfoDb_1.25.1 > > [11] stats4_4.0.0 RSQLite_2.2.0 > > [13] httr_1.4.1 ggplot2_3.3.1 > > [15] pillar_1.4.4 zlibbioc_1.35.0 > > [17] rlang_0.4.6 GenomicFeatures_1.41.0 > > [19] progress_1.2.2 curl_4.3 > > [21] blob_1.2.1 S4Vectors_0.27.11 > > [23] Matrix_1.2-18 BiocParallel_1.23.0 > > [25] stringr_1.4.0 RCurl_1.98-1.2 > > [27] bit_1.1-15.2 biomaRt_2.45.0 > > [29] munsell_0.5.0 DelayedArray_0.15.1 > > [31] compiler_4.0.0 rtracklayer_1.49.3 > > [33] pkgconfig_2.0.3 askpass_1.1 > > [35] BiocGenerics_0.35.3 openssl_1.4.1 > > [37] tidyselect_1.1.0 SummarizedExperiment_1.19.4 > > [39] tibble_3.0.1 GenomeInfoDbData_1.2.3 > > [41] IRanges_2.23.7 matrixStats_0.56.0 > > [43] XML_3.99-0.3 crayon_1.3.4 > > [45] dplyr_1.0.0 dbplyr_1.4.4 > > [47] GenomicAlignments_1.25.1 bitops_1.0-6 > > [49] rappdirs_0.3.1 grid_4.0.0 > > [51] gtable_0.3.0 lifecycle_0.2.0 > > [53] DBI_1.1.0 magrittr_1.5 > > [55] scales_1.1.1 stringi_1.4.6 > > [57] XVector_0.29.1 ellipsis_0.3.1 > > [59] generics_0.0.2 vctrs_0.3.0 > > [61] tools_4.0.0 bit64_0.9-7 > > [63] Biobase_2.49.0 glue_1.4.1 > > [65] purrr_0.3.4 hms_0.5.3 > > [67] parallel_4.0.0 colorspace_1.4-1 > > [69] AnnotationDbi_1.51.0 GenomicRanges_1.41.3 > > [71] memoise_1.1.0 > > > > > > > > [[alternative HTML version deleted]] > > > > ___ > > Bioc-devel@r-project.org mailing list > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAf
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Excellent! Thanks Martin. H. On 5/28/20 00:39, Martin Maechler wrote: Martin Maechler on Wed, 27 May 2020 13:35:44 +0200 writes: Hervé Pagès on Tue, 26 May 2020 12:38:13 -0700 writes: >> Hi Martin, On 5/26/20 06:24, Martin Maechler wrote: ... >>> >>> What about remaining back-compatible, not only to R 3.y.z >>> with default recycle0=FALSE, but also to R 4.0.0 with >>> recycle0=TRUE >> What back-compatibility with R 4.0.0 are we talking about? >> The 'recycle0' arg was added **after** the R 4.0.0 release >> and has never been part of an official release yet. > Yes, of course. It was *planned* for R 4.0.0 and finally was > too late (feature freeze etc)... I'm sorry I was wrong and > misleading above. >> This is the time to fix it. > Well, R 4.0.1 is already in 'beta' and does contain it too. > So the "fix" should happen really really fast, or we (R core) > take it out from there entirely. Well, in the end your repeated good reasoning has prevailed: I've committed a change (to R-devel; most probably in time to be ported to 4.0.1 beta). I think this implements the recycle0 = TRUE behavior you have been advocating for, in svn r78591 (2020-05-27 19:45:07 +0200) with message paste(), paste0(): collapse= always gives a string (also w/ `recycle0=TRUE`) Best regards, Martin -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Hi Martin, On 5/26/20 06:24, Martin Maechler wrote: ... What about remaining back-compatible, not only to R 3.y.z with default recycle0=FALSE, but also to R 4.0.0 with recycle0=TRUE What back-compatibility with R 4.0.0 are we talking about? The 'recycle0' arg was added **after** the R 4.0.0 release and has never been part of an official release yet. This is the time to fix it. *and* add a new option for the Suharto-Bill-Hervé-Gabe behavior, e.g., recycle0="sep.only" or just recycle0="sep" ? OMG! As (for back-compatibility reasons) you have to specify 'recycle0 = ..' anyway, you would get what makes most sense to you by using such a third option. ? (WDYT ?) Don't bother. I'd rather use paste(paste(x, y, z, sep="#", recycle0=TRUE), collapse=",") i.e. explicitly break down the 2 operations (sep and collapse). Might be slightly less efficient but I find it way more readable than paste(x, y, z, sep="#", collapse=",", recycle0="sep.only") BTW I appreciate you trying to accomodate everybody's taste. That doesn't sound like an easy task ;-) I'll just reiterate my earlier comment that controlling the collapse operation via an argument named 'recycle0' doesn't make sense (collapse involves NO recycling). So I don't know if the current 'recyle0=TRUE' behavior is "the correct one" but at the very least the name of the argument is a misnomer and misleading. More generally speaking using the same argument to control 2 distinct operations is not good API design. A better design is to use 2 arguments. Then the 2 arguments can generally be made orthogonal (like in this case) i.e. all possible combinations are valid (4 combinations in this case). Thanks, H. Martin > Switching to scheme (3) or to a new custom scheme > would be a completely different proposal. >> >> At least I'm consistent right? > Yes :-) > Anyway discussing recycling schemes is interesting but not directly > related with what the OP brought up (behavior of the 'collapse' operation). > Cheers, > H. >> >> ~G -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
On 5/24/20 00:26, Gabriel Becker wrote: On Sat, May 23, 2020 at 9:59 PM Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote: On 5/23/20 17:45, Gabriel Becker wrote: > Maybe my intuition is just > different but when I collapse multiple character vectors together, I > expect all the characters from each of those vectors to be in the > resulting collapsed one. Yes I'd expect that too. But the **collapse** operation in paste() has never been about collapsing **multiple** character vectors together. What it does is collapse the **single** character vector that comes out of the 'sep' operation. I understand what it does, I broke ti down the same way in my post earlier in the thread. the fact remains is that it is a single function which significantly muddies the waters. so you can say paste0(x,y, collapse=",", recycle0=TRUE) is not a collapse operation on multiple vectors, and of course there's a sense in which you're not wrong (again I understand what these functions do), but it sure looks like one in the invocation, doesn't it? Honestly the thing that this whole discussion has shown me most clearly is that, imho, collapse (accepting ONLY one data vector) and paste(accepting multiple) should never have been a single function to begin with. But that ship sailed long long ago. Yes :-( So paste(x, y, z, sep="", collapse=",") is analogous to sum(x + y + z) Honestly, I'd be significantly more comfortable if 1:10 + integer(0) + 5 were an error too. This is actually the recycling scheme used by mapply(): > mapply(function(x, y, z) c(x, y, z), 1:10, integer(0), 5) Error in mapply(FUN = FUN, ...) : zero-length inputs cannot be mixed with those of non-zero length AFAIK base R uses 3 different recycling schemes for n-ary operations: (1) The recycling scheme used by arithmetic and comparison operations (Arith, Compare, Logic group generics). (2) The recycling scheme used by classic paste(). (3) The recycling scheme used by mapply(). Having such a core mechanism like recycling being inconsistent across base R is sad. It makes it really hard to predict how a given n-ary function will recycle its arguments unless you spend some time trying it yourself with several combinations of vector lengths. It is of course the source of numerous latent bugs. I wish there was only one but that's just a dream. None of these 3 recycling schemes is perfect. IMO (2) is by far the worst. (3) is too restrictive and would need to be refined if we wanted to make it a good universal recycling scheme. Anyway I don't think it makes sense to introduce a 4th recycling scheme at this point even though it would be a nice item to put on the wish list for R 7.0.0 with the ultimate goal that it will universally adopted in R 11.0.0 ;-) So if we have to do with what we have IMO (1) is the scheme that makes most sense although I agree that it can do some surprising things for some unusual combinations of vector lengths. It's the scheme I adhere to in my own binary operations e.g. in S4Vector::pcompare(). The modest proposal of the 'recycle0' argument is only to let the user switch from recycling scheme (2) to (1) if they're not happy with scheme (2) (I'm one of them). Switching to scheme (3) or to a new custom scheme would be a completely different proposal. At least I'm consistent right? Yes :-) Anyway discussing recycling schemes is interesting but not directly related with what the OP brought up (behavior of the 'collapse' operation). Cheers, H. ~G -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
On 5/23/20 17:45, Gabriel Becker wrote: Maybe my intuition is just different but when I collapse multiple character vectors together, I expect all the characters from each of those vectors to be in the resulting collapsed one. Yes I'd expect that too. But the **collapse** operation in paste() has never been about collapsing **multiple** character vectors together. What it does is collapse the **single** character vector that comes out of the 'sep' operation. So paste(x, y, z, sep="", collapse=",") is analogous to sum(x + y + z) The element-wise addition is analog to the 'sep' operation. The sum() operation is analog to the 'collapse' operation. H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
On 5/22/20 18:12, brodie gaslam wrote: FWIW what convinces me is consistency with other aggregating functions applied to zero length inputs: sum(numeric(0)) ## [1] 0 Right. And 1 is the identity element of multiplication: > prod(numeric(0)) [1] 1 And the empty string is the identity element of string aggregation by concatenation. H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Gabe,
It's the current behavior of paste() that is a major source of bugs:
## Add "rs" prefix to SNP ids and collapse them in a
## comma-separated string.
collapse_snp_ids <- function(snp_ids)
paste("rs", snp_ids, sep="", collapse=",")
snp_groups <- list(
group1=c(55, 22, 200),
group2=integer(0),
group3=c(99, 550)
)
vapply(snp_groups, collapse_snp_ids, character(1))
#group1group2group3
# "rs55,rs22,rs200" "rs" "rs99,rs550"
This has hit me so many times!
Now with 'collapse0=TRUE', we finally have the opportunity to make it do
the right thing. Let's not miss that opportunity.
Cheers,
H.
On 5/22/20 11:26, Gabriel Becker wrote:
I understand that this is consistent but it also strikes me as an
enormous 'gotcha' of a magnitude that 'we' are trying to avoid/smooth
over at this point in user-facing R space.
For the record I'm not suggesting it should return something other than
"", and in particular I'm not arguing that any call to paste /that does
not return an error/ with non-NULL collapse should return a character
vector of length one.
Rather I'm pointing out that it could (perhaps should, imo) simply be an
error, which is also consistent, in the strict sense, with
previous behavior in that it is the developer simply declining to extend
the recycle0 argument to the full parameter space (there is no rule that
says we must do so, arguments whose use is incompatible with other
arguments can be reasonable and called for).
I don't feel feel super strongly that reeturning "" in this and similar
cases horrible and should never happen, but i'd bet dollars to donuts
that to the extent that behavior occurs it will be a disproportionately
major source of bugs, and i think thats at least worth considering in
addition to pure consistency.
~G
On Fri, May 22, 2020 at 9:50 AM William Dunlap <mailto:wdun...@tibco.com>> wrote:
I agree with Herve, processing collapse happens last so
collapse=non-NULL always leads to a single character string being
returned, the same as paste(collapse=""). See the altPaste function
I posted yesterday.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__tibco.com=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Z1o-HO3_OqxOR9LaRguGvnG7X4vF_z1_q13I7zmjcfY=7ZT1IjmexPqsDBhrV3NspPTr8M8XiMweEwJWErgAlqw=>
On Fri, May 22, 2020 at 9:12 AM Hervé Pagès mailto:hpa...@fredhutch.org>> wrote:
I think that
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse
= ",",
recycle0=TRUE)
should just return an empty string and don't see why it needs to
emit a
warning or raise an error. To me it does exactly what the user
is asking
for, which is to change how the 3 arguments are recycled
**before** the
'sep' operation.
The 'recycle0' argument has no business in the 'collapse' operation
(which comes after the 'sep' operation): this operation still
behaves
like it always had.
That's all there is to it.
H.
On 5/22/20 03:00, Gabriel Becker wrote:
> Hi Martin et al,
>
>
>
> On Thu, May 21, 2020 at 9:42 AM Martin Maechler
> mailto:maech...@stat.math.ethz.ch>
<mailto:maech...@stat.math.ethz.ch
<mailto:maech...@stat.math.ethz.ch>>> wrote:
>
> >>>>> Hervé Pagès
> >>>>> on Fri, 15 May 2020 13:44:28 -0700 writes:
>
> > There is still the situation where **both** 'sep' and
> 'collapse' are
> > specified:
>
> >> paste(integer(0), "nth", sep="", collapse=",")
> > [1] "nth"
>
> > In that case 'recycle0' should **not** be ignored i.e.
>
> > paste(integer(0), "nth", sep="", collapse=",",
recycle0=TRUE)
>
> > should return the empty string (and not
character(0) like it
> does at the
> > moment).
>
> > In other words, 'recycle0' should only control the
first
> operation (the
> > operation controlled by 'sep'). Which makes plenty
of sense:
> the 1st
> > operation is binary (or n-ary) wh
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
I think that
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
should just return an empty string and don't see why it needs to emit a
warning or raise an error. To me it does exactly what the user is asking
for, which is to change how the 3 arguments are recycled **before** the
'sep' operation.
The 'recycle0' argument has no business in the 'collapse' operation
(which comes after the 'sep' operation): this operation still behaves
like it always had.
That's all there is to it.
H.
On 5/22/20 03:00, Gabriel Becker wrote:
Hi Martin et al,
On Thu, May 21, 2020 at 9:42 AM Martin Maechler
mailto:maech...@stat.math.ethz.ch>> wrote:
>>>>> Hervé Pagès
>>>>> on Fri, 15 May 2020 13:44:28 -0700 writes:
> There is still the situation where **both** 'sep' and
'collapse' are
> specified:
>> paste(integer(0), "nth", sep="", collapse=",")
> [1] "nth"
> In that case 'recycle0' should **not** be ignored i.e.
> paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)
> should return the empty string (and not character(0) like it
does at the
> moment).
> In other words, 'recycle0' should only control the first
operation (the
> operation controlled by 'sep'). Which makes plenty of sense:
the 1st
> operation is binary (or n-ary) while the collapse operation
is unary.
> There is no concept of recycling in the context of unary
operations.
Interesting, ..., and sounding somewhat convincing.
> On 5/15/20 11:25, Gabriel Becker wrote:
>> Hi all,
>>
>> This makes sense to me, but I would think that recycle0 and
collapse
>> should actually be incompatible and paste should throw an
error if
>> recycle0 were TRUE and collapse were declared in the same
call. I don't
>> think the value of recycle0 should be silently ignored if it
is actively
>> specified.
>>
>> ~G
Just to summarize what I think we should know and agree (or be
be "disproven") and where this comes from ...
1) recycle0 is a new R 4.0.0 option in paste() / paste0() which by
default
(recycle0 = FALSE) should (and *does* AFAIK) not change anything,
hence paste() / paste0() behave completely back-compatible
if recycle0 is kept to FALSE.
2) recycle0 = TRUE is meant to give different behavior, notably
0-length arguments (among '...') should result in 0-length results.
The above does not specify what this means in detail, see 3)
3) The current R 4.0.0 implementation (for which I'm primarily
responsible)
and help(paste) are in accordance.
Notably the help page (Arguments -> 'recycle0' ; Details 1st
para ; Examples)
says and shows how the 4.0.0 implementation has been meant to work.
4) Several provenly smart members of the R community argue that
both the implementation and the documentation of 'recycle0 =
TRUE' should be changed to be more logical / coherent / sensical ..
Is the above all correct in your view?
Assuming yes, I read basically two proposals, both agreeing
that recycle0 = TRUE should only ever apply to the action of 'sep'
but not the action of 'collapse'.
1) Bill and Hervé (I think) propose that 'recycle0' should have
no effect whenever 'collapse = '
2) Gabe proposes that 'collapse = ' and 'recycle0 = TRUE'
should be declared incompatible and error. If going in that
direction, I could also see them to give a warning (and
continue as if recycle = FALSE).
Herve makes a good point about when sep and collapse are both set. That
said, if the user explicitly sets recycle0, Personally, I don't think it
should be silently ignored under any configuration of other arguments.
If all of the arguments are to go into effect, the question then becomes
one of ordering, I think.
Consider
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
Currently that returns character(0), becuase the logic is
essenttially (in pseudo-code)
collapse(paste(c("a", "b"), NULL, c("c", "d"), sep = " ",
recycle0=TRUE), collapse = ", ", recycle0=TRUE)
-> collapse(character(0), collapse = ", " recycle0=TRUE)
-> character(0)
Now Bill Dunlap argued, fairly convincingly I think, that paste(...,
collapse=) should /alw
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
There is still the situation where **both** 'sep' and 'collapse' are
specified:
> paste(integer(0), "nth", sep="", collapse=",")
[1] "nth"
In that case 'recycle0' should **not** be ignored i.e.
paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)
should return the empty string (and not character(0) like it does at the
moment).
In other words, 'recycle0' should only control the first operation (the
operation controlled by 'sep'). Which makes plenty of sense: the 1st
operation is binary (or n-ary) while the collapse operation is unary.
There is no concept of recycling in the context of unary operations.
H.
On 5/15/20 11:25, Gabriel Becker wrote:
Hi all,
This makes sense to me, but I would think that recycle0 and collapse
should actually be incompatible and paste should throw an error if
recycle0 were TRUE and collapse were declared in the same call. I don't
think the value of recycle0 should be silently ignored if it is actively
specified.
~G
On Fri, May 15, 2020 at 11:05 AM Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Totally agree with that.
H.
On 5/15/20 10:34, William Dunlap via R-devel wrote:
> I agree: paste(collapse="something", ...) should always return a
single
> character string, regardless of the value of recycle0. This would be
> similar to when there are no non-NULL arguments to paste;
collapse="."
> gives a single empty string and collapse=NULL gives a zero long
character
> vector.
>> paste()
> character(0)
>> paste(collapse=", ")
> [1] ""
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__tibco.com=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cC2qctlVXd0qHMPvCyYvuVMqR8GU3DjTTqKJ0zjIFj8=rXIwWqf4U4HZS_bjUT3KfA9ARaV5YTb_kEcXWHnkt-c=>
>
>
> On Thu, Apr 30, 2020 at 9:56 PM suharto_anggono--- via R-devel <
> r-devel@r-project.org <mailto:r-devel@r-project.org>> wrote:
>
>> Without 'collapse', 'paste' pastes (concatenates) its arguments
>> elementwise (separated by 'sep', " " by default). New in R devel
and R
>> patched, specifying recycle0 = FALSE makes mixing zero-length and
>> nonzero-length arguments results in length zero. The result of
paste(n,
>> "th", sep = "", recycle0 = FALSE) always have the same length as
'n'.
>> Previously, the result is still as long as the longest argument,
with the
>> zero-length argument like "". If all og the arguments have
length zero,
>> 'recycle0' doesn't matter.
>>
>> As far as I understand, 'paste' with 'collapse' as a character
string is
>> supposed to put together elements of a vector into a single
character
>> string. I think 'recycle0' shouldn't change it.
>>
>> In current R devel and R patched, paste(character(0), collapse = "",
>> recycle0 = FALSE) is character(0). I think it should be "", like
>> paste(character(0), collapse="").
>>
>> paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 =
FALSE)
>> is
>> "4th, 5th".
>> paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 =
FALSE)
>> is
>> "4th".
>> I think
>> paste(c( ), "th", sep = "", collapse = ", ", recycle0 =
FALSE)
>> should be
>> "",
>> not character(0).
>>
>> __
>> R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Totally agree with that.
H.
On 5/15/20 10:34, William Dunlap via R-devel wrote:
I agree: paste(collapse="something", ...) should always return a single
character string, regardless of the value of recycle0. This would be
similar to when there are no non-NULL arguments to paste; collapse="."
gives a single empty string and collapse=NULL gives a zero long character
vector.
paste()
character(0)
paste(collapse=", ")
[1] ""
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Apr 30, 2020 at 9:56 PM suharto_anggono--- via R-devel <
r-devel@r-project.org> wrote:
Without 'collapse', 'paste' pastes (concatenates) its arguments
elementwise (separated by 'sep', " " by default). New in R devel and R
patched, specifying recycle0 = FALSE makes mixing zero-length and
nonzero-length arguments results in length zero. The result of paste(n,
"th", sep = "", recycle0 = FALSE) always have the same length as 'n'.
Previously, the result is still as long as the longest argument, with the
zero-length argument like "". If all og the arguments have length zero,
'recycle0' doesn't matter.
As far as I understand, 'paste' with 'collapse' as a character string is
supposed to put together elements of a vector into a single character
string. I think 'recycle0' shouldn't change it.
In current R devel and R patched, paste(character(0), collapse = "",
recycle0 = FALSE) is character(0). I think it should be "", like
paste(character(0), collapse="").
paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE)
is
"4th, 5th".
paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
is
"4th".
I think
paste(c(), "th", sep = "", collapse = ", ", recycle0 = FALSE)
should be
"",
not character(0).
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=776IovW06eUHr1EDrabHLY7F47rU9CCUEItSDI96zc0=xN84DhkZeoxzn6SG0QTMpOGg2w_ThmjZmZymGUuD0Uw=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "cd" floating in the air in the man page for paste/paste0
Thanks for the fix.
H.
On 5/12/20 23:29, Tomas Kalibera wrote:
Thanks, fixed.
Tomas
On 5/13/20 5:14 AM, Dirk Eddelbuettel wrote:
On 12 May 2020 at 19:59, Hervé Pagès wrote:
| While reading about the new 'recycle0' argument of paste/paste0, I
| spotted a mysterious "cd" floating in the air in the man page:
|
| recycle0: ‘logical’ indicating if zero-length character arguments
(and
| all zero-length or no arguments when ‘collapse’ is not
| ‘NULL’) should lead to the zero-length ‘character(0)’.
| cd
| ^^
|
| This is in R 4.0.0 Patched and R devel.
Also still in r-devel as of svn r78432:
\item{recycle0}{\code{\link{logical}} indicating if zero-length
character arguments (and all zero-length or no arguments when
\code{collapse} is not \code{NULL}) should lead to the zero-length
\code{\link{character}(0)}.}cd
^^
Dirk
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "cd" floating in the air in the man page for paste/paste0
Hi, While reading about the new 'recycle0' argument of paste/paste0, I spotted a mysterious "cd" floating in the air in the man page: recycle0: ‘logical’ indicating if zero-length character arguments (and all zero-length or no arguments when ‘collapse’ is not ‘NULL’) should lead to the zero-length ‘character(0)’. cd ^^ This is in R 4.0.0 Patched and R devel. Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Debugging not updated for coexnet package
Hi Juan, On 5/12/20 13:37, Juan David Henao Sanchez wrote: Dear all. I received an error regarding my package coexnet when it is checking for multiple platforms. I already fix the problem a couple of days ago and I push the solution like: git push origin master Indeed the package is now green in Bioc devel (the master branch of your package): https://bioconductor.org/checkResults/3.12/bioc-LATEST/ However, as I mentioned in the email I sent you off list, the package is still broken in BioC 3.11 (the current release): https://bioconductor.org/checkResults/3.11/bioc-LATEST/ So you also need to fix the RELEASE_3_11 branch of your package. Best, H. However, I continue receiving the same error message and it is the same previous version of my package. There is something additional I have to do to update my package? Thanks on advance, I look forward to hearing from you soon. Juan -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] The new version of the package 'cbaf' is not downloadable for BioC 3.11
Hi Arman, On 5/7/20 08:57, Arman Shahrisa wrote: Hi to all, I�m maintainer of the package �cbaf�. I have pushed changes to both devel and stable branches almost two days ago. The package check has only been carried out for the stable release so far. There has been only one error on macOS server as a result of the version of Java used on the server. Not sure what is wrong with the version of Java used on our Mac server machv2. cbaf fails to load with the following error message: Error: .onLoad failed in loadNamespace() for 'xlsx', details: call: fun(libname, pkgname) error: Your java version is 14. Need 1.5.0 or higher. Execution halted ERROR: lazy loading failed for package ‘cbaf’ Obviously version 14 is higher than version 1.5.0 so to me it just looks like the Java checking code in xlsx is broken. Something you might want to report to the xlsx maintainer. Alternatively you might want to choose the packages you depend on more carefully. Cheers, H. Despite this, the older version is listed on the cbaf web page for BioC 3.11. https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_release_bioc_html_cbaf.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=A59d3JuLgSK3niLkKLga7vyA-vcQsy8q7riknf75RJ0=UAhMnh0UmS_h5m4zNRZ_6GE4yemBR0PNGc1WWIARybI= Am I missing something? Best regards, Arman [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=A59d3JuLgSK3niLkKLga7vyA-vcQsy8q7riknf75RJ0=A-xLxbM3GGrLmBYZzTnC17RTyvyKEL4QRFNK8DoDq8A= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] How to import a setAs method in one's package?
Hi Aditya, It is very hard to get selective imports from the methods package right and there is no real benefit in doing so. I would strongly recommend that you just import its full namespace with: import(methods) Best, H. On 5/8/20 02:48, Bhagwat, Aditya wrote: Looks like this can be successfully done by @importFrom methods as @importFrom S4Vectors DataFrame Cheers, Aditya From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Bhagwat, Aditya [aditya.bhag...@mpi-bn.mpg.de] Sent: Friday, May 08, 2020 11:04 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] How to import a setAs method in one's package? Dear BioC compatriots, How does one import a setAs method (which is generally not exported)? I in particular need to import as(., DataFrame) and am a bit puzzled on how to do this. Thank you! Aditya [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GvFB77RR45gI9MsOLDdWB-TapO-hwYBrAw1bBNVzTFE=ClOtwGLvXVUdxZgwOVZBOEaLrAvVEEa6rjOE5uzPyGM= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GvFB77RR45gI9MsOLDdWB-TapO-hwYBrAw1bBNVzTFE=ClOtwGLvXVUdxZgwOVZBOEaLrAvVEEa6rjOE5uzPyGM= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] 3.11 builds: no new report since last Friday
Fellow Bioconductor developers, The release builds (3.11 builds) are experiencing problems since last Friday (April 30) which is why the latest published report is still from that day: https://bioconductor.org/checkResults/3.11/bioc-LATEST/ We're working on it and hopefully we'll get a new report before the end of the week. Thanks for your comprehension and sorry for the inconvenience. Best, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] a day in the life of gwascat
Everything works fine for me with quote="":
> system.time(gwas
<-read.delim("gwas_catalog_v1.0.2-associations_e98_r2020-03-08.tsv",
quote=""))
user system elapsed
4.435 0.052 4.487
> dim(gwas)
[1] 179364 38
> sessionInfo()
R version 4.0.0 Patched (2020-04-27 r78316)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.6 LTS
Matrix products: default
BLAS: /home/hpages/R/R-4.0.r78316/lib/libRblas.so
LAPACK: /home/hpages/R/R-4.0.r78316/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.0
On 4/30/20 04:48, Vincent Carey wrote:
This file trips up fread around record 170349, inconsistently ... I haven't
figured that out yet.
readLines, strsplit may be the ultimate solution.
On Thu, Apr 30, 2020 at 7:15 AM Vincent Carey
wrote:
right, line 35265 of
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ebi.ac.uk_gwas_api_search_downloads_alternative=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=oM6e8C3QAbH860EUSfLCLlCa2Q2xqXbeOojfJo_0GDg=sJ8FryxOQ9eoMTUfGAbArTqR9f5L51ynwMntfimjbpQ=
has an
unclosed quote in a field.
35265 2019-04-10 30804558Grove J 2019-02-25 Nat Genet
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ncbi.nlm.nih.gov_pubmed_30804558=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=oM6e8C3QAbH860EUSfLCLlCa2Q2xqXbeOojfJo_0GDg=3yK9fsZtA_2bCHWktLA1ny1Wr7RRciU2QTOoE1xaWyg=
I dentification of
common genetic risk variants for autism spectrum disorder.Autism
spectrum disorder18 ,381 European ancestry cases, 27,969
European ancestry controls 2,119 European ancestry cases, 142,379
Euro pean ancestry controls Intergenic
chr11:102751102"-? chr11:102751102 0 1 0.037
8E-65.096910013008056 1.1641443 [NR]
Illumina
[9112387] (imputed)N autism spectrum disorderhttp:/
/https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ebi.ac.uk_efo_EFO-5F0003756=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=oM6e8C3QAbH860EUSfLCLlCa2Q2xqXbeOojfJo_0GDg=wWA7LPEZrntrqx5SpL9Y1q5_Kzo-w1L2Ymz6P_6jf00=
GCST007556 Genome-wide
genotyping array
On Thu, Apr 30, 2020 at 6:59 AM Martin Morgan
wrote:
I'd look instead at or around line 35264 for use of quotes, e.g., "3'
DNA", and change the argument read.delim(quote = "") (though I never get
that right so probably wrong again...). A comment character might also be a
problem.
If you point to the location of the file I could investigate further...
Martin
On 4/30/20, 6:55 AM, "Bioc-devel on behalf of Vincent Carey" <
bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
wrote:
The EBI GWAS catalog is large -- now the download is over 100MB for
179K
associations. A "bug" in the
package was reported, so I acquired the file by hand.
> nn =
read.delim("gwas_catalog_v1.0.2-associations_e98_r2020-03-08.tsv",
sep="\t")
*Warning message:*
*In scan(file = file, what = what, sep = sep, quote = quote, dec =
dec, :*
* EOF within quoted string*
> dim(nn)
[1] 3526438
The "bug" is the number 35264 ...
>
[1]+ Stopped R
%vjcair> wc gwas_cat*tsv
179365 13243516 120140148
gwas_catalog_v1.0.2-associations_e98_r2020-03-08.tsv
%vjcair> vi gwas_cat*tsv
%vjcair> fg
R
> tail(nn)
*Error: C stack usage 98161262 is too close to the limit*
*Maybe my R needs to be updated.*
*If I use data.table::fread to consume the tsv over HTTP all seems
well,
and perhaps*
*I will switch to that.*
--
The information in this e-mail is intended only for the
...{{dropped:18}}
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=oM6e8C3QAbH860EUSfLCLlCa2Q2xqXbeOojfJo_0GDg=mnmrbhNqYbx1zpyO1DBuCFg14rcd8ZVFEKuCgPqfQAQ=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-ma
Re: [Bioc-devel] No build report
DxTJ0RjI4Nd6HbAu1Q7mT-2D3EQ_https-253A-252F-252Fstat.ethz.ch-252Fmailman-252Flistinfo-252Fbioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8FW13IFEzMh6ofnZWE-pQBRqriZB_wUdNPOJFK6VqjQ=uG0mjXnc-KjPS9oEny8nCbqcjIiF_-ttDi77eDjOcIQ= ___ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1FPy1mLnCRO4TAB6gES9DdpTKRi0nfju4Jo8fdrpIXLGRb6TToHLD-5FSrdXWMkprVgbO8wD0WP8jv0AMFq3SwEhj5qefE3vKBK6ty-5FSrnB38W89nw16Qnwpdl6rJJ-5Fj-2DkAc-2DIBG15lXpt9ZGMltamh6dSEhN8kr74OiP2Eu8YkHa6qtt5KrH9mEAo8qqiKfrKunI9YBghKaNGwhpf1WnhkUwYwt3EI75Q98sMy91lhyEd1KtF5HUTY-5F-2Dj2JBCugvhu4i2Ugx4B5578ISwRLAtUwpdIFGfuznPilVZmV-2D1BuTqkq8CfwNkks5x3obLruDxTJ0RjI4Nd6HbAu1Q7mT-2D3EQ_https-253A-252F-252Fstat.ethz.ch-252Fmailman-252Flistinfo-252Fbioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8FW13IFEzMh6ofnZWE-pQBRqriZB_wUdNPOJFK6VqjQ=uG0mjXnc-KjPS9oEny8nCbqcjIiF_-ttDi77eDjOcIQ= ___ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1FPy1mLnCRO4TAB6gES9DdpTKRi0nfju4Jo8fdrpIXLGRb6TToHLD-5FSrdXWMkprVgbO8wD0WP8jv0AMFq3SwEhj5qefE3vKBK6ty-5FSrnB38W89nw16Qnwpdl6rJJ-5Fj-2DkAc-2DIBG15lXpt9ZGMltamh6dSEhN8kr74OiP2Eu8YkHa6qtt5KrH9mEAo8qqiKfrKunI9YBghKaNGwhpf1WnhkUwYwt3EI75Q98sMy91lhyEd1KtF5HUTY-5F-2Dj2JBCugvhu4i2Ugx4B5578ISwRLAtUwpdIFGfuznPilVZmV-2D1BuTqkq8CfwNkks5x3obLruDxTJ0RjI4Nd6HbAu1Q7mT-2D3EQ_https-253A-252F-252Fstat.ethz.ch-252Fmailman-252Flistinfo-252Fbioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8FW13IFEzMh6ofnZWE-pQBRqriZB_wUdNPOJFK6VqjQ=uG0mjXnc-KjPS9oEny8nCbqcjIiF_-ttDi77eDjOcIQ= This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8FW13IFEzMh6ofnZWE-pQBRqriZB_wUdNPOJFK6VqjQ=E-6YLbSDBVvhQMqPB9FHupxl3Qa9py6-rYgGkE9Tmvk= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Rtools and R 4.0.0?
Thanks Jeroen!
On Tue, Apr 7, 2020 at 6:07 PM Kevin Ushey wrote:
Regardless, I would like to thank R core, CRAN, and Jeroen for all of
the time that has gone into creating and validating this new
toolchain. This is arduous work at an especially arduous time, so I'd
like to voice my appreciation for all the time and energy they have
spent on making this possible.
Absolutely. Thanks to R core, CRAN, Jeroen, and all the other people
involved in creating the new Windows toolchain.
Cheers,
H.
Best,
Kevin
On Tue, Apr 7, 2020 at 7:47 AM Dirk Eddelbuettel wrote:
There appears to have been some progress on this matter:
-Note that @command{g++} 4.9.x (as used for @R{} on Windows up to 3.6.x)
+Note that @command{g++} 4.9.x (as used on Windows prior to @R{} 4.0.0)
See SVN commit r78169 titled 'anticipate change in Windows toolchain', or the
mirrored git commit at
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wch_r-2Dsource_commit_bd674e2b76b2384169424e3d899fbfb5ac174978=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=oQL_LnqplfOV3qS3_v0vWloGk5Qhr6pWl4Yjzs4Tzzo=
Dirk
--
https://urldefense.proofpoint.com/v2/url?u=http-3A__dirk.eddelbuettel.com=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=nOplDwpoh_urogK65Old_l1Qi-EbVpyC0Mv4LgeLl64=
| @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=vUQZdkVyqq3iT9HukcKqEjg80sI-OZoKuy9DKiufquw=
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=vUQZdkVyqq3iT9HukcKqEjg80sI-OZoKuy9DKiufquw=
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=vUQZdkVyqq3iT9HukcKqEjg80sI-OZoKuy9DKiufquw=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Windows Development Build Error Message for COHCAP
It is not clear what the purpose of these "if" statement is. Apparently
to set the $os_name variable but then where is this variable used and
for what?
So you might want to revisit the need for these tests. Maybe you don't
need them after all.
Another problem is that the temporary files generated by your Perl
scripts are generated in the current working directory. As discussed
earlier, this is not good. Please make sure that all temporary files are
generated in tempdir().
Thanks!
H.
On 4/28/20 10:43, Charles Warden wrote:
Hi H,
Thank you for pointing that out.
I am currently not seeing errors on my Windows computer, but I see that I need to add
"msys" for Windows on your system (and add quotes as well as make the error
message more clear). I have a 64-bit Windows computer and I didn't get an error message,
but I can see how this could cause problems. I apologize for not realizing that.
It sounds like I should wait a little while to do that. However, I think this
does sound correct, and I will make that change.
Thank You,
Charles
-Original Message-----
From: Hervé Pagès
Sent: Tuesday, April 28, 2020 10:32 AM
To: Charles Warden ; Shepherd, Lori ;
'bioc-devel@r-project.org'
Subject: Re: [Bioc-devel] Windows Development Build Error Message for COHCAP
Hi Charles,
The error you get on Windows is because your Perl script integrate_island.pl
fails on this platform. It contains the following code:
if (($os eq "MacOS")||($os eq "darwin")||($os eq "linux"))
{
#Mac
$os_name = "MAC";
}#end if ($os eq "MacOS")
elsif ($os eq "MSWin32")
{
#PC
$os_name = "PC";
}#end if ($os eq "MacOS")
else
{
print "Need to specify folder structure for $os!\n";
exit;
}#end else
The major problem with this code is that the script will exit
**normally** without doing anything if the detected OS is not one of the
expected ones. So the 'temp_paired_367853.txt' file is not produced and your R
code later fails to open it (when you try to read the file with read.table()).
Note that before exiting, your Perl script displays:
Need to specify folder structure for msys!
which you can see in the report. This gives you a BIG clue of what the problem
is and how to fix it.
If you develop your package on Windows (and it seems you do), the problem
should be very reproducible for you, granted that you use R
4.0.0 for that of course.
Thanks,
H.
On 4/28/20 09:02, Charles Warden wrote:
Hi Lori,
Thank you very much.
I was thinking about reverting the change to test not specifying the
full file path at one point (in *v1.33.6*), but I was planning on
keeping the change to using a temporary directory in *v1.33.4*.
Essentially, I tested making that change in *v1.33.6* because there
was still an error message in *v1.33.4.*
However, I will wait to see what else you suggest, before making any
additional changes. From my end, there is no need to rush, and I can
wait until next week (or later).
You probably already know this, but it looks like *v1.33.6 *is in the
release version without any errors (although it does look like the
Windows version is different):
https://urldefense.com/v3/__https://www.bioconductor.org/packages/rele
ase/bioc/html/COHCAP.html__;!!Fou38LsQmgU!_wdP4PPRbzvocGetxQ4gXCipwd4_
1cOH4l3X1xkG8DChTNm0z7KryGwjVxBW$
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bioconductor
.org_packages_release_bioc_html_COHCAP.html=DwMGaQ=eRAMFD45gAfqt84
VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=OANP0q_4ipib1q
0Y0KadeY9Api_-E4mZFZDodVQ8gMY=9TOVgc79RcLRStlZDJLBYL-wmdRF4rBN6aWrEG
gHdGQ=>
So, if I understand everything, I think this is OK.
Thanks Again,
Charles
*From:*Shepherd, Lori
*Sent:* Tuesday, April 28, 2020 5:29 AM
*To:* Charles Warden ; Hervé Pagès
; 'bioc-devel@r-project.org'
*Subject:* Re: [Bioc-devel] Windows Development Build Error Message
for COHCAP
I can investigate more on the windows machine after we are done with
the release (later this week -- possibly early next)
I would highly recommend not reverting the change to using a
temporary directory. We don't normally allow anyone to write to
anywhere but a temporary directory except in extreme circumstances.
New packages that are reviewed would not get accepted in Bioconductor if they
did this.
We appreciate your effort on trying to debug this and will help you
shortly.
Cheers,
Lori Shepherd
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263
------
--
*From:*Charles Warden mailto:cwar...@coh.org>>
*Sent:* Monday, April 27, 2020 12:27 PM
Re: [Bioc-devel] Windows Development Build Error Message for COHCAP
Hi Charles,
The error you get on Windows is because your Perl script
integrate_island.pl fails on this platform. It contains the following code:
if (($os eq "MacOS")||($os eq "darwin")||($os eq "linux"))
{
#Mac
$os_name = "MAC";
}#end if ($os eq "MacOS")
elsif ($os eq "MSWin32")
{
#PC
$os_name = "PC";
}#end if ($os eq "MacOS")
else
{
print "Need to specify folder structure for $os!\n";
exit;
}#end else
The major problem with this code is that the script will exit
**normally** without doing anything if the detected OS is not one of the
expected ones. So the 'temp_paired_367853.txt' file is not produced and
your R code later fails to open it (when you try to read the file with
read.table()).
Note that before exiting, your Perl script displays:
Need to specify folder structure for msys!
which you can see in the report. This gives you a BIG clue of what the
problem is and how to fix it.
If you develop your package on Windows (and it seems you do), the
problem should be very reproducible for you, granted that you use R
4.0.0 for that of course.
Thanks,
H.
On 4/28/20 09:02, Charles Warden wrote:
Hi Lori,
Thank you very much.
I was thinking about reverting the change to test not specifying the
full file path at one point (in *v1.33.6*), but I was planning on
keeping the change to using a temporary directory in *v1.33.4*.
Essentially, I tested making that change in *v1.33.6* because there was
still an error message in *v1.33.4.*
However, I will wait to see what else you suggest, before making any
additional changes. From my end, there is no need to rush, and I can
wait until next week (or later).
You probably already know this, but it looks like *v1.33.6 *is in the
release version without any errors (although it does look like the
Windows version is different):
https://www.bioconductor.org/packages/release/bioc/html/COHCAP.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bioconductor.org_packages_release_bioc_html_COHCAP.html=DwMGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=OANP0q_4ipib1q0Y0KadeY9Api_-E4mZFZDodVQ8gMY=9TOVgc79RcLRStlZDJLBYL-wmdRF4rBN6aWrEGgHdGQ=>
So, if I understand everything, I think this is OK.
Thanks Again,
Charles
*From:*Shepherd, Lori
*Sent:* Tuesday, April 28, 2020 5:29 AM
*To:* Charles Warden ; Hervé Pagès
; 'bioc-devel@r-project.org'
*Subject:* Re: [Bioc-devel] Windows Development Build Error Message for
COHCAP
I can investigate more on the windows machine after we are done with the
release (later this week -- possibly early next)
I would highly recommend not reverting the change to using a temporary
directory. We don't normally allow anyone to write to anywhere but a
temporary directory except in extreme circumstances. New packages that
are reviewed would not get accepted in Bioconductor if they did this.
We appreciate your effort on trying to debug this and will help you
shortly.
Cheers,
Lori Shepherd
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263
--------
*From:*Charles Warden mailto:cwar...@coh.org>>
*Sent:* Monday, April 27, 2020 12:27 PM
*To:* Hervé Pagès mailto:hpa...@fredhutch.org>>;
Shepherd, Lori <mailto:lori.sheph...@roswellpark.org>>; 'bioc-devel@r-project.org'
mailto:bioc-devel@r-project.org>>
*Subject:* RE: [Bioc-devel] Windows Development Build Error Message for
COHCAP
Hi,
I am not sure if I am going to have to wait to submit extra revisions.
However, I am unfortunately having the same issue (even though I tested
using the temporary directory instead of the current working directory,
in COHCAP (v.1.33.4).
I also tested changing the file path to the temporary in v.1.33.6, but
that also didn't fix the problem (and I might change that back).
I am also still not able to reproduce this error message on my end.
For example, this is what the output of the build command looks like:
C:\Users\Charles\Documents>"C:\Program Files\R\R-4.0.0\bin\R.exe" CMD
build COHCAP
* checking for file 'COHCAP/DESCRIPTION' ... OK
* preparing 'COHCAP':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... OK
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building 'COHCAP_1.33.6.tar.gz'
And, I can also install COHCAP successfully using devtools (in R-4.0.0),
although it does have some warnings:
library("devtools")
Loading required package
Re: [Bioc-devel] To Push or Not To Push?
Hi Chris, That is the question :-) The last run of the builds got delayed (that's because we updated R to final 4.0.0 on all build machines on Friday) so we weren't able to update the report in time today with the results of the builds. Today's builds have started already and I see that CoreGx is on the build machines. So if everything goes as expected it should show up on tomorrow's report. I would say push your updates to PharmacoGx. HOWEVER, it's important that you run R CMD build/check on PharmacoGx before you do so. Make sure you use R 4.0.0 when you do this, that all your packages are up-to-date (BiocManager::valid() will tell you that), and that you are using the same version of CoreGx that is currently on the build machines (which is the one at 'git clone https://git.bioconductor.org/packages/CoreGx'). If every looks good then you can push with confidence. Since today's builds have already started they won't pick up your changes to PharmacoGx. But tomorrow's builds will. This means that you won't be able to see the full picture before Monday's report. So yes, that's kind of last minute but, again, if you're cautious before pushing, everything should be fine ;-) Cheers, H. On 4/25/20 17:27, Chris Eeles wrote: Hello Bioc-Devel community, We recently submitted CoreGx to Bioconductor and am happy to announce it was accepted. However, the package has not yet made it into the 3.11 build and we are concerned it may not make the release. Our existing Bioconductor package, PharmacoGx, has significant updates which depend on CoreGx; thus we are hesitant to push our updates without CoreGx being available in 3.11. I wonder if anyone can provide guidance on how best to move forward? We would very much like to get the updated PharmacoGx into this release, but don't want to risk releasing a package without a dependency. Should we push and hope for the best or wait until tomorrow to see if we make the final build? Any advice would be appreciated. Thanks for your support. Best, --- Christopher Eeles Software Developer BHK Laboratory<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bhklab.ca_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=La4zNgzQBGQqABiXaILnttyOue2enaUkt_LSHyWgZFY=9d3um0IkW59E0g04Fa5xFUEGdh-JKYmp18FB2kBZAVo= > Princess Margaret Cancer Centre<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.pmgenomics.ca_pmgenomics_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=La4zNgzQBGQqABiXaILnttyOue2enaUkt_LSHyWgZFY=ZmT2DJ7Sv4CDUXyFY6lsScGGAR7rbD5P6kd0Mtn1EB0= > University Health Network<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.uhn.ca_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=La4zNgzQBGQqABiXaILnttyOue2enaUkt_LSHyWgZFY=oB-YG0x2fv5AReP-wm78Uyt6jjN6d8-myJnIihcu-Po= > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=La4zNgzQBGQqABiXaILnttyOue2enaUkt_LSHyWgZFY=Gn6YGSpCs8u_WJP9Gx81MxYBbIJAu-7Haa1WHOhY33I= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Got timeout for machv2 BUILD
LOL
On 4/24/20 15:00, Jianhong Ou, Ph.D. wrote:
Hi Hervé,
Thank you! You saved me.
Best!
Your sincerely,
Jianhong Ou
On Apr 24, 2020, at 5:59 PM, Hervé Pagès wrote:
Hi Jianhong,
I just updated R from R 4.0 alpha to the final R 4.0.0 on machv2 and the good
news is that I no longer get a TIMEOUT with this new R:
machv2:meat biocbuild$ time R CMD build motifStack
* checking for file ‘motifStack/DESCRIPTION’ ... OK
* preparing ‘motifStack’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘motifStack_1.31.2.tar.gz’
real1m33.576s
user1m26.714s
sys0m3.815s
So maybe it was a temporary issue with early Mac builds of R 4.0.
Please keep an eye on tomorrow's report (Saturday) and let me know if the
TIMEOUT is still there.
Thanks,
H.
On 4/17/20 13:16, Jianhong Ou, Ph.D. wrote:
Hi Herve,
Thank you for your help.
Jianhong.
On 4/17/20, 4:14 PM, "Hervé Pagès" wrote:
For some reasons the generation of the plots in the vignette is VERY
slow on machv2. 'R CMD build' actually completed... after 6h! This is
still under investigation.
Best,
H.
On 4/17/20 12:11, Jianhong Ou, Ph.D. wrote:
> Hi,
>
> I got timeout for my package motifStack in machv2. But I don't know what
cuased the issue.
>
> Any help would be greatly appreciated.
>
> Jianhong.
>
> From: Jianhong Ou, Ph.D.
> Sent: Wednesday, April 15, 2020 7:53 AM
> To: bioc-devel@r-project.org
> Subject: Got timeout for machv2 BUILD
>
> Hi,
>
> Hope you are doing well.
>
> I got timeout for my package motifStack in machv2. The ellapsedTime is
2403.0 seconds while in tokay2 is 82.1 seconds and in malbec2 is 126.1 seconds. I
have limited information how to debug.
> Could you share your suggestion? Thank you.
>
>
>
> Yours Sincerely,
>
> Jianhong Ou
>
> Email: jianhong...@duke.edu
> Bioinformatician II
> Department of Cell Biology
> Duke University School of Medicine
> Durham, NC, 27710
>
> Confidentiality Notice:\ This e-mail message, including ...{{dropped:12}}
>
> ___
> Bioc-devel@r-project.org mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=a83aImZ7c6KpUeEwr7eFpQuhOhlc-gRDnLp6RuQ9Q54=_7BtJGe9UeLXCftvPCoyrq3FIKBxCMLUVZwuU9GOx7w=
>
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Got timeout for machv2 BUILD
Hi Jianhong,
I just updated R from R 4.0 alpha to the final R 4.0.0 on machv2 and the
good news is that I no longer get a TIMEOUT with this new R:
machv2:meat biocbuild$ time R CMD build motifStack
* checking for file ‘motifStack/DESCRIPTION’ ... OK
* preparing ‘motifStack’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘motifStack_1.31.2.tar.gz’
real1m33.576s
user1m26.714s
sys 0m3.815s
So maybe it was a temporary issue with early Mac builds of R 4.0.
Please keep an eye on tomorrow's report (Saturday) and let me know if
the TIMEOUT is still there.
Thanks,
H.
On 4/17/20 13:16, Jianhong Ou, Ph.D. wrote:
Hi Herve,
Thank you for your help.
Jianhong.
On 4/17/20, 4:14 PM, "Hervé Pagès" wrote:
For some reasons the generation of the plots in the vignette is VERY
slow on machv2. 'R CMD build' actually completed... after 6h! This is
still under investigation.
Best,
H.
On 4/17/20 12:11, Jianhong Ou, Ph.D. wrote:
> Hi,
>
> I got timeout for my package motifStack in machv2. But I don't know what
cuased the issue.
>
> Any help would be greatly appreciated.
>
> Jianhong.
>
> From: Jianhong Ou, Ph.D.
> Sent: Wednesday, April 15, 2020 7:53 AM
> To: bioc-devel@r-project.org
> Subject: Got timeout for machv2 BUILD
>
> Hi,
>
> Hope you are doing well.
>
> I got timeout for my package motifStack in machv2. The ellapsedTime is
2403.0 seconds while in tokay2 is 82.1 seconds and in malbec2 is 126.1 seconds. I
have limited information how to debug.
> Could you share your suggestion? Thank you.
>
>
>
> Yours Sincerely,
>
> Jianhong Ou
>
> Email: jianhong...@duke.edu
> Bioinformatician II
> Department of Cell Biology
> Duke University School of Medicine
> Durham, NC, 27710
>
> Confidentiality Notice:\ This e-mail message, including ...{{dropped:12}}
>
> ___
> Bioc-devel@r-project.org mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=a83aImZ7c6KpUeEwr7eFpQuhOhlc-gRDnLp6RuQ9Q54=_7BtJGe9UeLXCftvPCoyrq3FIKBxCMLUVZwuU9GOx7w=
>
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Need help figuring out GeometryDoesNotContainImage-error on machv2-build for chimeraviz
OK, thanks testing that. This suggests that the problem is on our
side... sigh! I will need to dig deeper into this.
Best,
H.
On 4/23/20 22:57, Bemis, Kylie wrote:
Worked for me without errors or warnings:
kuwisdelu@Eva-02-Dash Projects % R CMD build chimeraviz
* checking for file ‘chimeraviz/DESCRIPTION’ ... OK
* preparing ‘chimeraviz’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
Removed empty directory ‘chimeraviz/docker’
* building ‘chimeraviz_1.13.8.tar.gz’
kuwisdelu@Eva-02-Dash Projects % R CMD INSTALL chimeraviz_1.13.8.tar.gz
* installing to library ‘/Users/kuwisdelu/Library/R/4.0/library’
* installing *source* package ‘chimeraviz’ ...
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation
path
* DONE (chimeraviz)
Under:
sessionInfo()
R version 4.0.0 RC (2020-04-18 r78249)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.3
Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.0 tools_4.0.0
The vignette looks okay as far as I can tell.
-Kylie
On Apr 24, 2020, at 1:40 AM, Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Interesting indeed. Thanks for checking this.
Even though I'm not sure what conclusion to draw from all this.
Since you are on a Mac, can I ask you another big favor? Do you think
you could run 'R CMD build' on chimeraviz and see if you can reproduce
the error we see on the build report here:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbioconductor.org%2FcheckResults%2F3.11%2Fbioc-LATEST%2Fchimeraviz%2Fmachv2-buildsrc.htmldata=02%7C01%7Ck.bemis%40northeastern.edu%7Ca50b7fbb03654f8b503208d7e811f4b5%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637233036132939427sdata=s9fJRfwSMO0UkPEwdmrW7mZhEM%2FgCOYtQm3HO12DknA%3Dreserved=0
<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam05.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fbioconductor.org-252FcheckResults-252F3.11-252Fbioc-2DLATEST-252Fchimeraviz-252Fmachv2-2Dbuildsrc.html-26amp-3Bdata-3D02-257C01-257Ck.bemis-2540northeastern.edu-257Ca50b7fbb03654f8b503208d7e811f4b5-257Ca8eec281aaa34daeac9b9a398b9215e7-257C0-257C0-257C637233036132939427-26amp-3Bsdata-3Ds9fJRfwSMO0UkPEwdmrW7mZhEM-252FgCOYtQm3HO12DknA-253D-26amp-3Breserved-3D0=DwMGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ChvNTQebsUvVKYAGSEtFgFNOcwgSzxXYjQ69oO9oBM0=Rkoe-LwrUsVZyqv9zyv00KH__7fWXhf-n8-ZTmYFdP4=>
Get the source with
git clone
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.bioconductor.org%2Fpackages%2Fchimeravizdata=02%7C01%7Ck.bemis%40northeastern.edu%7Ca50b7fbb03654f8b503208d7e811f4b5%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637233036132939427sdata=cTfgpg28qU2zPXAZn2DZs7k8TQKk290wYyj2vjD6Khw%3Dreserved=0
Thanks,
H.
On 4/23/20 21:55, Bemis, Kylie wrote:
That’s interesting. I did:
BiocManager::install("Cardinal", type="mac.binary.el-capitan”)
browseVignettes("Cardinal")
from R 3.6.3, and the figures using transparency in the vignettes
look fine to me.
When I use X11() to reproduce the warning locally, the transparent
colors get truncated, so that the higher-alpha colors appear opaque
and the lower-alpha colors don’t appear at all.
However, in the merida1 vignette, the figures appear as I’d normally
get form quartz() or pdf() locally, which don’t produce warnings for
me on macOS 10.15.3.
-Kylie
On Apr 24, 2020, at 12:39 AM, Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Hi Kylie,
I get the warnings on merida1 for Cardinal too e.g. when I run the
code in the Cardinal-2-stats vignette:
merida1:vignettes biocbuild$ pwd
/Users/biocbuild/bbs-3.10-bioc/meat/Cardinal/vignettes
merida1:vignettes biocbuild$ R CMD Stangle Cardinal-2-stats.Rmd
Output file: Cardinal-2-stats.R
merida1:vignettes biocbuild$ R
...
> source("Cardinal-2-stats.R", echo=TRUE)
...
There were 14 warnings (use warnings() to see them)
> warnings()
Warning messages:
1: In rect(left, top, r, b, angle = angle, density = density, ... :
semi-
Re: [Bioc-devel] Need help figuring out GeometryDoesNotContainImage-error on machv2-build for chimeraviz
Interesting indeed. Thanks for checking this.
Even though I'm not sure what conclusion to draw from all this.
Since you are on a Mac, can I ask you another big favor? Do you think
you could run 'R CMD build' on chimeraviz and see if you can reproduce
the error we see on the build report here:
https://bioconductor.org/checkResults/3.11/bioc-LATEST/chimeraviz/machv2-buildsrc.html
Get the source with
git clone https://git.bioconductor.org/packages/chimeraviz
Thanks,
H.
On 4/23/20 21:55, Bemis, Kylie wrote:
That’s interesting. I did:
BiocManager::install("Cardinal", type="mac.binary.el-capitan”)
browseVignettes("Cardinal")
from R 3.6.3, and the figures using transparency in the vignettes look
fine to me.
When I use X11() to reproduce the warning locally, the transparent
colors get truncated, so that the higher-alpha colors appear opaque and
the lower-alpha colors don’t appear at all.
However, in the merida1 vignette, the figures appear as I’d normally get
form quartz() or pdf() locally, which don’t produce warnings for me on
macOS 10.15.3.
-Kylie
On Apr 24, 2020, at 12:39 AM, Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Hi Kylie,
I get the warnings on merida1 for Cardinal too e.g. when I run the
code in the Cardinal-2-stats vignette:
merida1:vignettes biocbuild$ pwd
/Users/biocbuild/bbs-3.10-bioc/meat/Cardinal/vignettes
merida1:vignettes biocbuild$ R CMD Stangle Cardinal-2-stats.Rmd
Output file: Cardinal-2-stats.R
merida1:vignettes biocbuild$ R
...
> source("Cardinal-2-stats.R", echo=TRUE)
...
There were 14 warnings (use warnings() to see them)
> warnings()
Warning messages:
1: In rect(left, top, r, b, angle = angle, density = density, ... :
semi-transparency is not supported on this device: reported only
once per page
2: In rect(left, top, r, b, angle = angle, density = density, ... :
semi-transparency is not supported on this device: reported only
once per page
...
The thing is that 'R CMD build' does not display warnings, unless
there is an error. Maybe that's why you've never seen them until now
because of the error you have on machv2 (and other platforms).
It's be interesting to know if the plots included in the vignette are
actually OK. Have you checked them? You can do this by installing the
Mac binary for Cardinal in BioC 3.10 with:
BiocManager::install("Cardinal", type="mac.el-capitan.binary")
(make sure you do this in R 3.6). This will install the vignette
generated on merida1. Then open the vignette via
browseVignettes("Cardinal") and check the plots. Do they look ok
despite the "semi-transparency" problem?
Thanks,
H.
On 4/23/20 20:39, Bemis, Kylie wrote:
I’m now seeing the same "semi-transparency" error on my Mac builds
for Cardinal. My vignettes have used transparency for years now and
this has never been an issue before (on merida1 or otherwise).
I can reproduce the error locally with an X11() device, but not with
quartz(), png(), png(), etc.
(Note that my Cardinal 2.5.9 builds are currently failing due to an
unrelated issue that I’ve since fixed, but the build system hasn’t
gotten to 2.5.11 yet.)
~~~
Kylie Ariel Bemis (she/her)
Khoury College of Computer Sciences
Northeastern University
kuwisdelu.github.io
<https://urldefense.proofpoint.com/v2/url?u=http-3A__kuwisdelu.github.io=DwMGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=CO4n__SJ6oQxnPyEFpNoDuHw2Pa0aC_CznlpINGGORQ=Nl-SFGWHUlZqtDsccYwD2EHptbV_1lbboQkoGIwfeKI=>
<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__kuwisdelu.github.io%26d%3DDwMGaQ%26c%3DeRAMFD45gAfqt84VtBcfhQ%26r%3DBK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA%26m%3DiIfSQOsSomvKm_1GHwSPKYxnfvicYz3rNyk04PTXhxU%26s%3DitZMZz7G1z4hEn_h6m-WLnSXgIbD-41KOovzdseVHT4%26e%3Ddata=02%7C01%7Ck.bemis%40northeastern.edu%7C557e92d7107a41f63ec208d7e8098af2%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C63723308658074sdata=9TmRy1lpNBJjGLZcqPqJY%2BMP32z2kgbsmTdvSn4RUk8%3Dreserved=0
<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam05.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fkuwisdelu.github.io-2526d-253DDwMGaQ-2526c-253DeRAMFD45gAfqt84VtBcfhQ-2526r-253DBK7q3XeAvimeWdGbWY-5FwJYbW0WYiZvSXAJJKaaPhzWA-2526m-253DiIfSQOsSomvKm-5F1GHwSPKYxnfvicYz3rNyk04PTXhxU-2526s-253DitZMZz7G1z4hEn-5Fh6m-2DWLnSXgIbD-2D41KOovzdseVHT4-2526e-253D-26amp-3Bdata-3D02-257C01-257Ck.bemis-2540northeastern.edu-257C557e92d7107a41f63ec208d7e8098af2-257Ca8eec281aaa34daeac9b9a398b9215e7-257C0-257C0-257C63723308658074-26amp-3Bsdata-3D9TmRy1lpNBJjGLZcqPqJY-252BMP32z2kgbsmTdvSn4RUk8-253D-26amp-3Breserved-3D0=DwMGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=CO4n__SJ6oQxnP
Re: [Bioc-devel] Need help figuring out GeometryDoesNotContainImage-error on machv2-build for chimeraviz
Hi Kylie,
I get the warnings on merida1 for Cardinal too e.g. when I run the code
in the Cardinal-2-stats vignette:
merida1:vignettes biocbuild$ pwd
/Users/biocbuild/bbs-3.10-bioc/meat/Cardinal/vignettes
merida1:vignettes biocbuild$ R CMD Stangle Cardinal-2-stats.Rmd
Output file: Cardinal-2-stats.R
merida1:vignettes biocbuild$ R
...
> source("Cardinal-2-stats.R", echo=TRUE)
...
There were 14 warnings (use warnings() to see them)
> warnings()
Warning messages:
1: In rect(left, top, r, b, angle = angle, density = density, ... :
semi-transparency is not supported on this device: reported only
once per page
2: In rect(left, top, r, b, angle = angle, density = density, ... :
semi-transparency is not supported on this device: reported only
once per page
...
The thing is that 'R CMD build' does not display warnings, unless there
is an error. Maybe that's why you've never seen them until now because
of the error you have on machv2 (and other platforms).
It's be interesting to know if the plots included in the vignette are
actually OK. Have you checked them? You can do this by installing the
Mac binary for Cardinal in BioC 3.10 with:
BiocManager::install("Cardinal", type="mac.el-capitan.binary")
(make sure you do this in R 3.6). This will install the vignette
generated on merida1. Then open the vignette via
browseVignettes("Cardinal") and check the plots. Do they look ok despite
the "semi-transparency" problem?
Thanks,
H.
On 4/23/20 20:39, Bemis, Kylie wrote:
I’m now seeing the same "semi-transparency" error on my Mac builds for
Cardinal. My vignettes have used transparency for years now and this has
never been an issue before (on merida1 or otherwise).
I can reproduce the error locally with an X11() device, but not with
quartz(), png(), png(), etc.
(Note that my Cardinal 2.5.9 builds are currently failing due to an
unrelated issue that I’ve since fixed, but the build system hasn’t
gotten to 2.5.11 yet.)
~~~
Kylie Ariel Bemis (she/her)
Khoury College of Computer Sciences
Northeastern University
kuwisdelu.github.io
<https://urldefense.proofpoint.com/v2/url?u=https-3A__kuwisdelu.github.io=DwMGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=iIfSQOsSomvKm_1GHwSPKYxnfvicYz3rNyk04PTXhxU=itZMZz7G1z4hEn_h6m-WLnSXgIbD-41KOovzdseVHT4=>
On Apr 23, 2020, at 11:28 PM, Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Ok so I'm changing my mind about this. I suspect that the error is
actually related to the warning. The error comes from the magick
package (a wrapper around the ImageMagick software) and it indicates a
failure to crop an empty image. It can easily be reproduced with:
## Generate an empty image.
png("myplot.png", bg="transparent")
plot.new()
dev.off()
## Try to crop it.
magick::image_trim(magick::image_read("myplot.png"))
# Error in magick_image_trim(image, fuzz) :
# R: GeometryDoesNotContainImage `/Users/biocbuild/myplot.png' @ #
warning/attribute.c/GetImageBoundingBox/247
So I suspect that what happens is that the images generated on Mac by
the code in the vignette are empty (because of the semi-transparency
problem on Mac) which would explain why later knitr fails to crop them
(it uses magick::image_trim() for that).
I don't exactly understand why we wouldn't have seen the problem on
merida1 though (same version of knitr (1.28) and magick (2.3) on both
machines) but it seems that chimeraviz has changed significantly
between BioC 3.10 and 3.11. Did you start using semi-transparency
recently in your plots?
Best,
H.
On 4/23/20 19:42, Hervé Pagès wrote:
Hi Stian,
I went on machv2 and gave this a shot. I can reproduce the
GeometryDoesNotContainImage error in an interactive session. I don't
have an answer yet but I was curious about the "semi-transparency is
not supported on this device" warning and was wondering if it could
somehow be related with the error.
It turns out that the warning is actually easy to reproduce on a Mac
with something like this:
plot.new()
lines(c(0.1, 0.22), c(0.5, 0.44), type = "l", lwd = 1, col = "#FF80")
I think that the 4th byte (80) in the color specification
("#FF80") is the level of transparency.
I can get this warning on machv2 **and** merida1. Some googling
indicates that this is a pretty common warning on Mac. Since we don't
get the vignette error on merida1 I think it's unlikely that the
warning is related to the error.
I'll keep investigating the GeometryDoesNotContainImage error...
H.
On 4/22/20 01:59, Stian Lågstad wrote:
I'm still unable to reproduce this error on my end. If anyone with a mac
could try building locally I would be very grateful. Thanks.
On Sat, Apr 18, 2020 at 4:06 PM Stian Lågstad
mailto:stianlags...@gmail.c
Re: [Bioc-devel] Need help figuring out GeometryDoesNotContainImage-error on machv2-build for chimeraviz
Ok so I'm changing my mind about this. I suspect that the error is
actually related to the warning. The error comes from the magick package
(a wrapper around the ImageMagick software) and it indicates a failure
to crop an empty image. It can easily be reproduced with:
## Generate an empty image.
png("myplot.png", bg="transparent")
plot.new()
dev.off()
## Try to crop it.
magick::image_trim(magick::image_read("myplot.png"))
# Error in magick_image_trim(image, fuzz) :
# R: GeometryDoesNotContainImage `/Users/biocbuild/myplot.png' @ #
warning/attribute.c/GetImageBoundingBox/247
So I suspect that what happens is that the images generated on Mac by
the code in the vignette are empty (because of the semi-transparency
problem on Mac) which would explain why later knitr fails to crop them
(it uses magick::image_trim() for that).
I don't exactly understand why we wouldn't have seen the problem on
merida1 though (same version of knitr (1.28) and magick (2.3) on both
machines) but it seems that chimeraviz has changed significantly between
BioC 3.10 and 3.11. Did you start using semi-transparency recently in
your plots?
Best,
H.
On 4/23/20 19:42, Hervé Pagès wrote:
Hi Stian,
I went on machv2 and gave this a shot. I can reproduce the
GeometryDoesNotContainImage error in an interactive session. I don't
have an answer yet but I was curious about the "semi-transparency is not
supported on this device" warning and was wondering if it could somehow
be related with the error.
It turns out that the warning is actually easy to reproduce on a Mac
with something like this:
plot.new()
lines(c(0.1, 0.22), c(0.5, 0.44), type = "l", lwd = 1, col =
"#FF80")
I think that the 4th byte (80) in the color specification ("#FF80")
is the level of transparency.
I can get this warning on machv2 **and** merida1. Some googling
indicates that this is a pretty common warning on Mac. Since we don't
get the vignette error on merida1 I think it's unlikely that the warning
is related to the error.
I'll keep investigating the GeometryDoesNotContainImage error...
H.
On 4/22/20 01:59, Stian Lågstad wrote:
I'm still unable to reproduce this error on my end. If anyone with a mac
could try building locally I would be very grateful. Thanks.
On Sat, Apr 18, 2020 at 4:06 PM Stian Lågstad
wrote:
Hi,
I'm haven't been able to figure out this error for the latest machv2
build
for chimeraviz:
```
Warning in doTryCatch(return(expr), name, parentenv, handler) :
semi-transparency is not supported on this device: reported only once
per page
Quitting from lines 108-126 (chimeraviz-vignette.Rmd)
Error: processing vignette 'chimeraviz-vignette.Rmd' failed with
diagnostics:
R: GeometryDoesNotContainImage
`/private/tmp/RtmpdBrrvk/Rbuild9ed5154894cc/chimeraviz/vignettes/chimeraviz-vignette_files/figure-html/unnamed-chunk-7-1.png'
@ warning/attribute.c/GetImageBoundingBox/247
--- failed re-building ‘chimeraviz-vignette.Rmd’
```
The build in question:
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_3.11_bioc-2DLATEST_chimeraviz_machv2-2Dbuildsrc.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Q1W5ctHOQ2Hjw49pX7VAGBn7-u5l3mAqH1rt9tFNnZM=A7jGEFF5ehz2Hsxmlr_vGmPSX3Xy2SwZErgyi1mPIuw=
If anyone has seen something like this before then I'd appreciate some
help. Thank you!
--
Stian Lågstad
+47 41 80 80 25
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Need help figuring out GeometryDoesNotContainImage-error on machv2-build for chimeraviz
Hi Stian,
I went on machv2 and gave this a shot. I can reproduce the
GeometryDoesNotContainImage error in an interactive session. I don't
have an answer yet but I was curious about the "semi-transparency is not
supported on this device" warning and was wondering if it could somehow
be related with the error.
It turns out that the warning is actually easy to reproduce on a Mac
with something like this:
plot.new()
lines(c(0.1, 0.22), c(0.5, 0.44), type = "l", lwd = 1, col = "#FF80")
I think that the 4th byte (80) in the color specification ("#FF80")
is the level of transparency.
I can get this warning on machv2 **and** merida1. Some googling
indicates that this is a pretty common warning on Mac. Since we don't
get the vignette error on merida1 I think it's unlikely that the warning
is related to the error.
I'll keep investigating the GeometryDoesNotContainImage error...
H.
On 4/22/20 01:59, Stian Lågstad wrote:
I'm still unable to reproduce this error on my end. If anyone with a mac
could try building locally I would be very grateful. Thanks.
On Sat, Apr 18, 2020 at 4:06 PM Stian Lågstad
wrote:
Hi,
I'm haven't been able to figure out this error for the latest machv2 build
for chimeraviz:
```
Warning in doTryCatch(return(expr), name, parentenv, handler) :
semi-transparency is not supported on this device: reported only once
per page
Quitting from lines 108-126 (chimeraviz-vignette.Rmd)
Error: processing vignette 'chimeraviz-vignette.Rmd' failed with
diagnostics:
R: GeometryDoesNotContainImage
`/private/tmp/RtmpdBrrvk/Rbuild9ed5154894cc/chimeraviz/vignettes/chimeraviz-vignette_files/figure-html/unnamed-chunk-7-1.png'
@ warning/attribute.c/GetImageBoundingBox/247
--- failed re-building ‘chimeraviz-vignette.Rmd’
```
The build in question:
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_3.11_bioc-2DLATEST_chimeraviz_machv2-2Dbuildsrc.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Q1W5ctHOQ2Hjw49pX7VAGBn7-u5l3mAqH1rt9tFNnZM=A7jGEFF5ehz2Hsxmlr_vGmPSX3Xy2SwZErgyi1mPIuw=
If anyone has seen something like this before then I'd appreciate some
help. Thank you!
--
Stian Lågstad
+47 41 80 80 25
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] ChemmineOB build failing on windows
On 4/23/20 12:52, Hervé Pagès wrote: On 4/23/20 12:45, Hervé Pagès wrote: On 4/23/20 10:45, Kevin Horan wrote: Bioc, The build of ChemmineOB is failing on windows, which is also causing 3 other packages to fail (ChemmineR, eiR, and fmcsR). I was able to build the package on my own windows machine (Windows Server 2012 R2 Standard) without any error. I used R devel. The content of this package has not been changed since October 2018. Right but the toolchain used for R 4.0.0 on Windows now is Rtool40 which is a huge upgrade from the previous one. Could this be related to the compilation failure? It also occurs to me that we might need to recompile Open Babel with the new toolchain on tokay2. Could that be the problem? FWIW the RProtoBufLib/cytolib maintainers had to do this for the protobuf and they made the updated binaries available here: http://rglab.github.io/binaries/ It seems to be pretty typical with C++ code that the binaries tend to break with major updates of the compiler (generally because of changes to how the compiler mangles method names). H. H. Best, H. Can someone please look into it? Thanks. The build link is https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ChemmineOB_tokay2-2Dbuildsrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=hoMGH754DpRKnA8RGcuSStVub2IwW2BGrG6lvBK4io4= Kevin ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=RuXC_DouGnZ1Y3CsW5TtbzVY-lzbyy3KiFm28uqNOos= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] ChemmineOB build failing on windows
On 4/23/20 13:18, Kevin Horan wrote: Hervé, It could be. The test I did today was on a clean windows machine, so I did build open babel from scratch with Rtools40. I don't have an openbabel built with the old version to check. The INSTALL file of ChemmineOB provides detail instructions for building OpenBabel on windows. We'll try this. That is unfortunate as it requires more time than we can realistically spend on the builders to satisfy the needs of 1800+ software packages. It would be really appreciated if in the future you could provide Open Babel binaries that we can just unzip on the Windows builders. Thanks, H. Kevin On 4/23/20 12:52 PM, Hervé Pagès wrote: On 4/23/20 12:45, Hervé Pagès wrote: On 4/23/20 10:45, Kevin Horan wrote: Bioc, The build of ChemmineOB is failing on windows, which is also causing 3 other packages to fail (ChemmineR, eiR, and fmcsR). I was able to build the package on my own windows machine (Windows Server 2012 R2 Standard) without any error. I used R devel. The content of this package has not been changed since October 2018. Right but the toolchain used for R 4.0.0 on Windows now is Rtool40 which is a huge upgrade from the previous one. Could this be related to the compilation failure? It also occurs to me that we might need to recompile Open Babel with the new toolchain on tokay2. Could that be the problem? H. Best, H. Can someone please look into it? Thanks. The build link is https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ChemmineOB_tokay2-2Dbuildsrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=hoMGH754DpRKnA8RGcuSStVub2IwW2BGrG6lvBK4io4= Kevin ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=RuXC_DouGnZ1Y3CsW5TtbzVY-lzbyy3KiFm28uqNOos= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] ChemmineOB build failing on windows
On 4/23/20 10:45, Kevin Horan wrote: Bioc, The build of ChemmineOB is failing on windows, which is also causing 3 other packages to fail (ChemmineR, eiR, and fmcsR). I was able to build the package on my own windows machine (Windows Server 2012 R2 Standard) without any error. I used R devel. The content of this package has not been changed since October 2018. Right but the toolchain used for R 4.0.0 on Windows now is Rtool40 which is a huge upgrade from the previous one. Could this be related to the compilation failure? Best, H. Can someone please look into it? Thanks. The build link is https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ChemmineOB_tokay2-2Dbuildsrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=hoMGH754DpRKnA8RGcuSStVub2IwW2BGrG6lvBK4io4= Kevin ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=RuXC_DouGnZ1Y3CsW5TtbzVY-lzbyy3KiFm28uqNOos= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] ChemmineOB build failing on windows
On 4/23/20 12:45, Hervé Pagès wrote: On 4/23/20 10:45, Kevin Horan wrote: Bioc, The build of ChemmineOB is failing on windows, which is also causing 3 other packages to fail (ChemmineR, eiR, and fmcsR). I was able to build the package on my own windows machine (Windows Server 2012 R2 Standard) without any error. I used R devel. The content of this package has not been changed since October 2018. Right but the toolchain used for R 4.0.0 on Windows now is Rtool40 which is a huge upgrade from the previous one. Could this be related to the compilation failure? It also occurs to me that we might need to recompile Open Babel with the new toolchain on tokay2. Could that be the problem? H. Best, H. Can someone please look into it? Thanks. The build link is https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ChemmineOB_tokay2-2Dbuildsrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=hoMGH754DpRKnA8RGcuSStVub2IwW2BGrG6lvBK4io4= Kevin ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=wmRn4CjxRi7ewvrtWLIyKM2Tockd3ZOaWfhhytkrbCM=RuXC_DouGnZ1Y3CsW5TtbzVY-lzbyy3KiFm28uqNOos= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] current openbabel version on tokay2
Hi Kevin, The only thing I found that gives an indication of what version we have on tokay2 is this line at the top of the README.md file in the Open Babel src folder (c:\openbabel\src\i386\): Open Babel README version 2.4.0 Best, H. On 4/23/20 09:01, Kevin Horan wrote: I have a build error on my ChemmineOB package on windows, Tokay2. So that I can try to reproduce the error locally, could you let me know what version of OpenBabel is on that machine? My assumption would be that it is 2.4.1. It's not an R package, so it's not listed on your website. Thanks. Kevin Horan ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=aRO-qI4YutpGbr3A7t1gCrdGDCz2eZe5INmbDbnoRu8=XPXcrRcaBbNEyoFMIPIoktRM6TXaJ1KWsll3KDmNPHA= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Windows Development Build Error Message for COHCAP
Hi Charles, On 4/23/20 10:19, Charles Warden wrote: My guess was that creating the temporary file in the working directory instead of another folder might help. FWIW here are 2 important reasons for writing temporary stuff to tempdir() instead of the current working directory: 1. tempdir() is the only place that is guaranteed to be writable on every system. Yes the user home is very likely to be writable too but there is actually no guarantee and some systems have unconventional setups where it's not. 2. Whatever you put in tempdir() will automatically be removed at the end of the R session. Even though there are ways to achieve this with the temporary stuff you write in the user home, it's not automatic and hard to get right. Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] R-devel for Windows: Rtools3.5 vs Rtools4.0
On 4/20/20 23:28, Gordon K Smyth wrote: Thanks, that does help. So it seems that R-4.0.0 will use rtools40/mingw64/bin/gcc.exe and I'm guessing that R-4.1.0 uses rtools40/mingw64/bin/x86_64-w64-mingw32-gcc-8.3.0.exe I didn't try R 4.1.0 yet so don't know what it uses but I'm surprised it uses something different than R 4.0.0. Are you saying that 'R CMD config CC' returns /mingw64/bin/x86_64-w64-mingw32-gcc-8.3.0 with the latest Windows build of R 4.1.0? Anyway I still have 6 months to worry about what R 4.1.0 does ;-) Cheers, H. Both files in are in the same directory, so R-4.0.0 and R-4.1.0 should both work with same Windows setup (which is afterall what the Rtools webpage says). Thanks Gordon -Original Message- From: Hervé Pagès Sent: Tuesday, 21 April 2020 2:55 PM To: Gordon K Smyth ; Martin Morgan ; bioc-devel@r-project.org Cc: Yunshun Chen Subject: Re: [Bioc-devel] R-devel for Windows: Rtools3.5 vs Rtools4.0 Yes, all builds of R 4.0 and above are now using Rtools40 on Windows. See: https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_bin_windows_Rtools_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Lbl2W3r-f_jIrRVzr8IFYC0x_V3F3tjiBkHuXyGBhWA=Os0nDoCIS80pkl11embl1PwAXrLmd7lV67FCUN2db-o= AFAIK there has been no official announcement about this on the various R-* mailing lists but this is suggested by the output of 'R CMD config CC' which has changed from C:/Rtools/mingw_64/bin/gcc to /mingw64/bin/gcc with the most recent Windows builds of R 4.0.0. /mingw64/bin/gcc and /mingw32/bin/gcc are the paths to the 64-bit and 32-bit compilers **in the Msys environment** that is shipped with Rtools40. These paths are relative to the location of Rtools40, which by default is C:\Rtools40. Hope this helps, H. On 4/20/20 19:38, Gordon K Smyth wrote: Hi Herve, Ah, I see now. I was getting confused by the CRAN page that points to R-4.1.0 for Windows and says it "will eventually become the next major release of R". I see now that we should be using R-4.0.0 RC instead, which is the patched link. Can I confirm whether we should be using Rtools3.5 or Rtools4.0 with R-4.0.0 RC for Windows? The release note for R-4.0.0 RC says that it was ported by Guido Masarotto, Brian Ripley and Duncan Murdoch, which to me means it must be using the older toolchain. I had associated that toolchain in my mind with Rtool3.5, but perhaps without any proper justification. Maybe Rtools4.0 supports both the 4.0.0 and 4.1.0 pipelines. Thanks Gordon -Original Message----- From: Hervé Pagès Sent: Tuesday, 21 April 2020 12:01 PM To: Gordon K Smyth ; Martin Morgan ; bioc-devel@r-project.org Cc: Yunshun Chen Subject: Re: [Bioc-devel] R-devel for Windows: Rtools3.5 vs Rtools4.0 Hi Gordon, The Bioconductor version to be released (BioC 3.11) uses R 4.0, not R 4.1. The latest Windows built of R 4.0 is available on CRAN here: https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r- 2Dproject.org_bin_windows_base_rpatched.html=DwIGaQ=eRAMFD45gAf qt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=hj 173hPUpLOLp7dFQ_16azQNCbeFfRPfQqgksa9- 15s=H7efBWjbnmjHS7SQKjsjRlOG_7OvsT_Aq6rNUqJTK8c= Note that the upcoming devel version of Bioconductor (BioC 3.12) will still be based on R 4.0. We'll only start using R 4.1 for BioC 3.13. Cheers, H. On 4/20/20 17:42, Gordon K Smyth wrote: Hi Martin, I may have jumped to the wrong conclusion as to the cause of the problem. The problem we are observing is that BiocManager::install does not currently work with R Devel for Windows 2020-04-18 (which the installer is calling R 4.1.0) while it still works fine with R Devel for Windows 2020-02-15 (which the installer is calling R 4.0.0). In the former case, the installer is trying to find a 4.1 repository that doesn't seem to exist. Note that I have not renamed R-devel to R 4.1.0 myself. The r-devel-win.exe installer automatically labels the R shortcut as "R 4.1.0". I am assuming that Bioconductor packages that need compilation have to be build using the same toolchain as used for R itself. Since I can install Bioc packages with R 4.0.0, I assume that I am getting packages built with Rtools3.5. If there is an Rtools4.0 version of Bioc-devel, where is it? I can git clone the source code for Bioc packages and compile them successfully for R 4.1.0 using Rtools4.0, but that's more tedious that using install(). It is getting very close to the Bioc 3.11 Release, so we would like to make sure that everything works ok with the latest version of R. Regards Gordon - R Session with R 4.1.0 for Windows (fails) -- R Under development (unstable) (2020-04-18 r78255) -- "Unsuffered Consequences" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to
Re: [Bioc-devel] R-devel for Windows: Rtools3.5 vs Rtools4.0
Yes, all builds of R 4.0 and above are now using Rtools40 on Windows. See:
https://cran.r-project.org/bin/windows/Rtools/
AFAIK there has been no official announcement about this on the various
R-* mailing lists but this is suggested by the output of 'R CMD config
CC' which has changed from C:/Rtools/mingw_64/bin/gcc to
/mingw64/bin/gcc with the most recent Windows builds of R 4.0.0.
/mingw64/bin/gcc and /mingw32/bin/gcc are the paths to the 64-bit and
32-bit compilers **in the Msys environment** that is shipped with
Rtools40. These paths are relative to the location of Rtools40, which by
default is C:\Rtools40.
Hope this helps,
H.
On 4/20/20 19:38, Gordon K Smyth wrote:
Hi Herve,
Ah, I see now.
I was getting confused by the CRAN page that points to R-4.1.0 for Windows and says it
"will eventually become the next major release of R". I see now that we should
be using R-4.0.0 RC instead, which is the patched link.
Can I confirm whether we should be using Rtools3.5 or Rtools4.0 with R-4.0.0 RC
for Windows? The release note for R-4.0.0 RC says that it was ported by Guido
Masarotto, Brian Ripley and Duncan Murdoch, which to me means it must be using
the older toolchain. I had associated that toolchain in my mind with Rtool3.5,
but perhaps without any proper justification. Maybe Rtools4.0 supports both the
4.0.0 and 4.1.0 pipelines.
Thanks
Gordon
-Original Message-----
From: Hervé Pagès
Sent: Tuesday, 21 April 2020 12:01 PM
To: Gordon K Smyth ; Martin Morgan
; bioc-devel@r-project.org
Cc: Yunshun Chen
Subject: Re: [Bioc-devel] R-devel for Windows: Rtools3.5 vs Rtools4.0
Hi Gordon,
The Bioconductor version to be released (BioC 3.11) uses R 4.0, not R
4.1. The latest Windows built of R 4.0 is available on CRAN here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_bin_windows_base_rpatched.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=hj173hPUpLOLp7dFQ_16azQNCbeFfRPfQqgksa9-15s=H7efBWjbnmjHS7SQKjsjRlOG_7OvsT_Aq6rNUqJTK8c=
Note that the upcoming devel version of Bioconductor (BioC 3.12) will
still be based on R 4.0. We'll only start using R 4.1 for BioC 3.13.
Cheers,
H.
On 4/20/20 17:42, Gordon K Smyth wrote:
Hi Martin,
I may have jumped to the wrong conclusion as to the cause of the problem.
The problem we are observing is that BiocManager::install does not currently
work with R Devel for Windows 2020-04-18 (which the installer is calling R
4.1.0)
while it still works fine with R Devel for Windows 2020-02-15 (which the
installer
is calling R 4.0.0). In the former case, the installer is trying to find a 4.1
repository that doesn't seem to exist.
Note that I have not renamed R-devel to R 4.1.0 myself. The r-devel-win.exe
installer automatically labels the R shortcut as "R 4.1.0".
I am assuming that Bioconductor packages that need compilation have to be
build using the same toolchain as used for R itself. Since I can install Bioc
packages with R 4.0.0, I assume that I am getting packages built with Rtools3.5.
If there is an Rtools4.0 version of Bioc-devel, where is it?
I can git clone the source code for Bioc packages and compile them
successfully for R 4.1.0 using Rtools4.0, but that's more tedious that using
install().
It is getting very close to the Bioc 3.11 Release, so we would like to make sure
that everything works ok with the latest version of R.
Regards
Gordon
- R Session with R 4.1.0 for Windows (fails) --
R Under development (unstable) (2020-04-18 r78255) -- "Unsuffered
Consequences"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
install.packages("BiocManager")
--- Please select a CRAN mirror for use in this session ---
trying URL 'https://urldefense.proofpoint.com/v2/url?u=https-
3A__mirror.aarnet.edu.au_pub_CRAN_bin_windows_contrib_4.1_BiocManager
-
5F1.30.10.zip=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWd
GbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAM
UxFFSy3MRDadA=5nTgU8SemnUqthnJ85luoxh9XILEd0cG9DwDvaYJG9o= '
Content type 'application/zip' length 99799 bytes (97 KB)
downloaded 97 KB
package ‘BiocManager’ successfully unpacked and MD5 sums checked
The downloaded binary packages are in
C:\Users\smyth\AppData\Local\Temp\RtmpaqaFCD\downloaded_packages
library(BiocManager)
Bioconductor version 3.11 (BiocManager 1.30.10), ?BiocManager::install for
help
ins
Re: [Bioc-devel] R-devel for Windows: Rtools3.5 vs Rtools4.0
Hi Gordon,
The Bioconductor version to be released (BioC 3.11) uses R 4.0, not R
4.1. The latest Windows built of R 4.0 is available on CRAN here:
https://cran.r-project.org/bin/windows/base/rpatched.html
Note that the upcoming devel version of Bioconductor (BioC 3.12) will
still be based on R 4.0. We'll only start using R 4.1 for BioC 3.13.
Cheers,
H.
On 4/20/20 17:42, Gordon K Smyth wrote:
Hi Martin,
I may have jumped to the wrong conclusion as to the cause of the problem. The
problem we are observing is that BiocManager::install does not currently work
with R Devel for Windows 2020-04-18 (which the installer is calling R 4.1.0)
while it still works fine with R Devel for Windows 2020-02-15 (which the
installer is calling R 4.0.0). In the former case, the installer is trying to
find a 4.1 repository that doesn't seem to exist.
Note that I have not renamed R-devel to R 4.1.0 myself. The r-devel-win.exe installer
automatically labels the R shortcut as "R 4.1.0".
I am assuming that Bioconductor packages that need compilation have to be build
using the same toolchain as used for R itself. Since I can install Bioc
packages with R 4.0.0, I assume that I am getting packages built with
Rtools3.5. If there is an Rtools4.0 version of Bioc-devel, where is it?
I can git clone the source code for Bioc packages and compile them successfully
for R 4.1.0 using Rtools4.0, but that's more tedious that using install().
It is getting very close to the Bioc 3.11 Release, so we would like to make
sure that everything works ok with the latest version of R.
Regards
Gordon
- R Session with R 4.1.0 for Windows (fails) --
R Under development (unstable) (2020-04-18 r78255) -- "Unsuffered Consequences"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
install.packages("BiocManager")
--- Please select a CRAN mirror for use in this session ---
trying URL
'https://urldefense.proofpoint.com/v2/url?u=https-3A__mirror.aarnet.edu.au_pub_CRAN_bin_windows_contrib_4.1_BiocManager-5F1.30.10.zip=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAMUxFFSy3MRDadA=5nTgU8SemnUqthnJ85luoxh9XILEd0cG9DwDvaYJG9o=
'
Content type 'application/zip' length 99799 bytes (97 KB)
downloaded 97 KB
package ‘BiocManager’ successfully unpacked and MD5 sums checked
The downloaded binary packages are in
C:\Users\smyth\AppData\Local\Temp\RtmpaqaFCD\downloaded_packages
library(BiocManager)
Bioconductor version 3.11 (BiocManager 1.30.10), ?BiocManager::install for help
install("edgeR")
Bioconductor version 3.11 (BiocManager 1.30.10), R Under development (unstable)
(2020-04-18 r78255)
Installing package(s) 'BiocVersion', 'edgeR'
also installing the dependencies ‘limma’, ‘locfit’, ‘Rcpp’
Warning: unable to access index for repository
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.11_bioc_bin_windows_contrib_4.1=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAMUxFFSy3MRDadA=N1ntYHJbzM64QzE10mXfuIkCRE5EOa74pPWKyz9jXBs=
:
cannot open URL
'https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.11_bioc_bin_windows_contrib_4.1_PACKAGES=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAMUxFFSy3MRDadA=86-euOILGSDTX4uN2pbWAfyQ-7uTcpiAXMB8w1YQGeg=
'
Warning: unable to access index for repository
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.11_data_annotation_bin_windows_contrib_4.1=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAMUxFFSy3MRDadA=0XEOcyZGmPoY-0_TdNiRPRUwS4MWta2X2LPZTYeqzuQ=
:
cannot open URL
'https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.11_data_annotation_bin_windows_contrib_4.1_PACKAGES=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAMUxFFSy3MRDadA=Rsz3EC5iYpvb0gWD5S72old9UDv0C0q08i7vgyfhl-Q=
'
Warning: unable to access index for repository
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.11_data_experiment_bin_windows_contrib_4.1=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DRSQA4QbwiZ7f47ejuutRgsCIctSAMUxFFSy3MRDadA=L0PeotXMcsvCuc8RpvvheLWQKI8Wt8OeQchDK_sFgyk=
:
cannot open URL
Re: [Bioc-devel] Got timeout for machv2 BUILD
For some reasons the generation of the plots in the vignette is VERY
slow on machv2. 'R CMD build' actually completed... after 6h! This is
still under investigation.
Best,
H.
On 4/17/20 12:11, Jianhong Ou, Ph.D. wrote:
Hi,
I got timeout for my package motifStack in machv2. But I don't know what cuased
the issue.
Any help would be greatly appreciated.
Jianhong.
From: Jianhong Ou, Ph.D.
Sent: Wednesday, April 15, 2020 7:53 AM
To: bioc-devel@r-project.org
Subject: Got timeout for machv2 BUILD
Hi,
Hope you are doing well.
I got timeout for my package motifStack in machv2. The ellapsedTime is 2403.0
seconds while in tokay2 is 82.1 seconds and in malbec2 is 126.1 seconds. I have
limited information how to debug.
Could you share your suggestion? Thank you.
Yours Sincerely,
Jianhong Ou
Email: jianhong...@duke.edu
Bioinformatician II
Department of Cell Biology
Duke University School of Medicine
Durham, NC, 27710
Confidentiality Notice:\ This e-mail message, including ...{{dropped:12}}
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=a83aImZ7c6KpUeEwr7eFpQuhOhlc-gRDnLp6RuQ9Q54=_7BtJGe9UeLXCftvPCoyrq3FIKBxCMLUVZwuU9GOx7w=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] New Mac builder and availability of Mac binary packages
On 4/10/20 17:22, Yang,Peng wrote:
Hi Herve,
Ok, I will use the condition to disable OpenMP for Mac OS.
And I need to push it into the devel branch before Apr 24th? Just make sure
that I understand it right.
Yes, before Apr 24th. See our release schedule here:
https://bioconductor.org/developers/release-schedule/
Thanks,
H.
Thanks,
Peng
On 4/10/20, 7:13 PM, "Hervé Pagès" wrote:
On 4/10/20 16:54, Yang,Peng wrote:
> Hi Herve,
>
> Thank you so much for hearing back from you.
>
> Actually we are thinking to switch OpenMP into MPI or other API, which
is supported by R 4.0.0; however, it may take us for a while.
> In the meantime, I have noticed that the scheduled time to release R
4.0.0 is on Friday April 24th, so do we have to finish our package before that
time?
> If we are not be able to finish it by then, can we choose the first
option and push our updated package whenever we are done with the API switching?
Yes, the first option (use conditionals to disable OpenMP on macOS) is
probably your best option for now. Thanks for taking care of this.
Best,
H.
>
> Thanks,
> Peng
>
> On 4/10/20, 12:31 PM, "Hervé Pagès" wrote:
>
> Hi Peng,
>
> You cannot "push" binaries. DeMixT has a compilation error (+ some
> imporant warnings) that seem to be caused by the use of OpenMP in
its C
> code. Unfortunately, starting with R 4.0.0, R no longer supports
OpenMP
> on macOS.
>
> You basically have 3 options, from best to worst:
> 1. use conditionals to disable OpenMP on macOS;
> 2. drop OpenMP completely (i.e. on all platforms);
> 3. do nothing and we'll mark the package as unsupported on macOS.
>
> Thanks,
> H.
>
> On 4/9/20 20:17, Yang,Peng wrote:
> > Dear Bioconductor team,
> >
> > I just found out that our package DeMixT 1.3.5 is failed to
install for Mac under the developed version.
> >
> > Does that mean I need to rebuild the package under the official
Mac build of R 4.0.0 alpha and push it again?
> >
> > Thanks,
> > Peng
> >
> > On 4/9/20, 4:13 PM, "Bioc-devel on behalf of Hervé Pagès"
wrote:
> >
> > Hello Bioconductor developers,
> >
> > As you've probably noticed already, we're building BioC 3.11
on Mac again:
> >
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.11_bioc-2DLATEST_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=Lp71UxuNF1FLTNhqFVg1NzXogj7yQv7lckRDEXnB2AY=
> >
> > The build target now is High Sierra (used to be El Capitan),
like for
> > the official Mac built of R 4.0.0 alpha (available here
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=_fEbeaymE4PlCRQ_-LNjFj4zgEXfuztnC5NgmpXZi78=
) and for the Mac binary packages available on
> > CRAN. This means that the binaries we produce are only
compatible with
> > High Sierra or higher, as long as you're using the official
Mac built of
> > R 4.0.0.
> >
> > IMPORTANT: CRAN and Bioconductor binary packages for Mac are
NOT meant
> > to be used with an R 4.0.0 installed from source (they're
likely to
> > crash your session, typically at load time).
> >
> > Using BiocManager::install() with the official Mac built of
R 4.0.0 will
> > pick up binary packages from CRAN and Bioconductor 3.11. It
will fall
> > back on source packages only when the binaries are not
available.
> >
> > Please let us know if you run into any problem with this.
> >
> > Cheers,
> > H.
> >
> > --
> > Hervé Pagès
> >
> > Program in Computational Biology
> > Division of Public Health Sciences
> > Fred Hutchinson Cancer Research Center
> > 1100 Fairview Ave. N, M1-B514
> > P.O. Box 190
Re: [Bioc-devel] New Mac builder and availability of Mac binary packages
On 4/10/20 16:54, Yang,Peng wrote: Hi Herve, Thank you so much for hearing back from you. Actually we are thinking to switch OpenMP into MPI or other API, which is supported by R 4.0.0; however, it may take us for a while. In the meantime, I have noticed that the scheduled time to release R 4.0.0 is on Friday April 24th, so do we have to finish our package before that time? If we are not be able to finish it by then, can we choose the first option and push our updated package whenever we are done with the API switching? Yes, the first option (use conditionals to disable OpenMP on macOS) is probably your best option for now. Thanks for taking care of this. Best, H. Thanks, Peng On 4/10/20, 12:31 PM, "Hervé Pagès" wrote: Hi Peng, You cannot "push" binaries. DeMixT has a compilation error (+ some imporant warnings) that seem to be caused by the use of OpenMP in its C code. Unfortunately, starting with R 4.0.0, R no longer supports OpenMP on macOS. You basically have 3 options, from best to worst: 1. use conditionals to disable OpenMP on macOS; 2. drop OpenMP completely (i.e. on all platforms); 3. do nothing and we'll mark the package as unsupported on macOS. Thanks, H. On 4/9/20 20:17, Yang,Peng wrote: > Dear Bioconductor team, > > I just found out that our package DeMixT 1.3.5 is failed to install for Mac under the developed version. > > Does that mean I need to rebuild the package under the official Mac build of R 4.0.0 alpha and push it again? > > Thanks, > Peng > > On 4/9/20, 4:13 PM, "Bioc-devel on behalf of Hervé Pagès" wrote: > > Hello Bioconductor developers, > > As you've probably noticed already, we're building BioC 3.11 on Mac again: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.11_bioc-2DLATEST_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=Lp71UxuNF1FLTNhqFVg1NzXogj7yQv7lckRDEXnB2AY= > > The build target now is High Sierra (used to be El Capitan), like for > the official Mac built of R 4.0.0 alpha (available here > https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=_fEbeaymE4PlCRQ_-LNjFj4zgEXfuztnC5NgmpXZi78= ) and for the Mac binary packages available on > CRAN. This means that the binaries we produce are only compatible with > High Sierra or higher, as long as you're using the official Mac built of > R 4.0.0. > > IMPORTANT: CRAN and Bioconductor binary packages for Mac are NOT meant > to be used with an R 4.0.0 installed from source (they're likely to > crash your session, typically at load time). > > Using BiocManager::install() with the official Mac built of R 4.0.0 will > pick up binary packages from CRAN and Bioconductor 3.11. It will fall > back on source packages only when the binaries are not available. > > Please let us know if you run into any problem with this. > > Cheers, > H. > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > > ___ > Bioc-devel@r-project.org mailing list > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=hLf_-4C9O9l7tBrgMKlvaCI-gxFf4nZEpJmB1A9NFBA= > > > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] New Mac builder and availability of Mac binary packages
Hi Peng, You cannot "push" binaries. DeMixT has a compilation error (+ some imporant warnings) that seem to be caused by the use of OpenMP in its C code. Unfortunately, starting with R 4.0.0, R no longer supports OpenMP on macOS. You basically have 3 options, from best to worst: 1. use conditionals to disable OpenMP on macOS; 2. drop OpenMP completely (i.e. on all platforms); 3. do nothing and we'll mark the package as unsupported on macOS. Thanks, H. On 4/9/20 20:17, Yang,Peng wrote: Dear Bioconductor team, I just found out that our package DeMixT 1.3.5 is failed to install for Mac under the developed version. Does that mean I need to rebuild the package under the official Mac build of R 4.0.0 alpha and push it again? Thanks, Peng On 4/9/20, 4:13 PM, "Bioc-devel on behalf of Hervé Pagès" wrote: Hello Bioconductor developers, As you've probably noticed already, we're building BioC 3.11 on Mac again: https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.11_bioc-2DLATEST_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=Lp71UxuNF1FLTNhqFVg1NzXogj7yQv7lckRDEXnB2AY= The build target now is High Sierra (used to be El Capitan), like for the official Mac built of R 4.0.0 alpha (available here https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=_fEbeaymE4PlCRQ_-LNjFj4zgEXfuztnC5NgmpXZi78= ) and for the Mac binary packages available on CRAN. This means that the binaries we produce are only compatible with High Sierra or higher, as long as you're using the official Mac built of R 4.0.0. IMPORTANT: CRAN and Bioconductor binary packages for Mac are NOT meant to be used with an R 4.0.0 installed from source (they're likely to crash your session, typically at load time). Using BiocManager::install() with the official Mac built of R 4.0.0 will pick up binary packages from CRAN and Bioconductor 3.11. It will fall back on source packages only when the binaries are not available. Please let us know if you run into any problem with this. Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EBz1PFzIr1V4NU9MH7hPVYFFnKmMa1I6Vc8I9gjbOSg=hLf_-4C9O9l7tBrgMKlvaCI-gxFf4nZEpJmB1A9NFBA= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] New Mac builder and availability of Mac binary packages
Hello Bioconductor developers, As you've probably noticed already, we're building BioC 3.11 on Mac again: https://bioconductor.org/checkResults/3.11/bioc-LATEST/ The build target now is High Sierra (used to be El Capitan), like for the official Mac built of R 4.0.0 alpha (available here https://mac.r-project.org/) and for the Mac binary packages available on CRAN. This means that the binaries we produce are only compatible with High Sierra or higher, as long as you're using the official Mac built of R 4.0.0. IMPORTANT: CRAN and Bioconductor binary packages for Mac are NOT meant to be used with an R 4.0.0 installed from source (they're likely to crash your session, typically at load time). Using BiocManager::install() with the official Mac built of R 4.0.0 will pick up binary packages from CRAN and Bioconductor 3.11. It will fall back on source packages only when the binaries are not available. Please let us know if you run into any problem with this. Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] HDF5Array failure on windows
On 4/7/20 06:15, Kasper Daniel Hansen wrote:
Thanks for the two pointers.
Herve: we are using a number of unexpected functions from HDF5Array:
‘HDF5Array:::.create_dir’, ‘HDF5Array:::.replace_dir’,
‘HDF5Array:::.shorten_assay2h5_links’
tss tss... naughty!
That might be relevant in light of that specific test error.
OK, always good to know, thanks! The error seems to be related to the
code I added recently for handling on-disk dimnames. I only started to
look at this and will report here when I find something.
H.
On Mon, Apr 6, 2020 at 1:13 PM Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Hi Kasper, Martin,
About bsseq's timeout: An important recent change to
DelayedArray/HDF5Array is that, starting with DelayedArray 0.13.8,
nothing in these packages uses parallel evaluation **by default**.
Concretely this means that getAutoBPPARAM() now returns NULL on a fresh
session instead of one of the parallelization backends defined in
BiocParallel (e.g. MulticoreParam on Linux/Mac, SnowParam on Windows).
This could slow down some code in bsseq or other packages that were
benefiting from the automatic parallel evaluation. Now it's the
responsibility of the user to set the parallelization backend (with
setAutoBPPARAM) if they wish things like matrix multiplication,
rowsum()
or rowSums() use parallel evaluation again.
Also BiocParallel has been moved from Depends to Suggests.
About bsseq error on Windows: That seems indeed to be related to the
HDF5Array error on the same platform. The unit tests in bsseq and
HDF5Array both fail with the same error ("HDF5 dataset
'./.HDF5ArrayAUTO00014_dimnames/2' does not exist"). I'll take a look.
What's puzzling is that we see this error on both Windows archs for
bsseq (i.e. on 64-bit and 32-bit) while we only see it on 64-bit
Windows
for HDF5Array. This suggests something nasty and hard to troubleshoot..
sigh!
Cheers,
H.
On 4/6/20 06:59, Martin Morgan wrote:
> Timeouts are often related to parallel evaluation, either
competing for resources or underlying limitations in the robustness
of the (parallel) code. Something close to best practice is to limit
or eliminate parallel evaluation in examples, vignettes, and tests.
>
> Documentation issues are usually related to the use of [] in
\link[]{}, as described at
https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_doc_manuals_r-2Drelease_R-2Dexts.html-23Cross-5F002dreferences=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=2r59fOKiJQ_AJBSaOXUDB1j3dD1txuMA-cJzCnnIE9k=
. The important point is that the [] information is the NAME OF THE
HTML FILE of the documentation module, not the 'name' of the
documentation module. The solution (from my perspective) is usually
to simply omit the [] and let the R help system resolve the link
dynamically (sometimes prompting the user to choose, if there
multiple man pages).
>
> Martin Morgan
>
>
> On 4/6/20, 9:55 AM, "Bioc-devel on behalf of Kasper Daniel
Hansen" mailto:bioc-devel-boun...@r-project.org> on behalf of
kasperdanielhan...@gmail.com <mailto:kasperdanielhan...@gmail.com>>
wrote:
>
> We currently (and for a while) have had various errors in
bsseq that seems
> to have come and go. We now have a failure on Windows which
is related to
> HDF5. I see that HDF5Array also fails on Windows, which
makes me believe
> the error could be upstream. There is also a warning about
hep page links
> which HDF5Array has as well. Any comments on this is
appreciated.
>
> Perhaps relatedly: we are getting a timeout on linux. On my
own OS X setup,
> it completes in a timely fashion. Do we sometimes have
unexplained timeouts
> related to HDF5?
>
> --
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>
mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=28DlcVps0EVU-QaF8utnvHUFuj1DpJIZrrXrlPqIb28=
>
> ___
> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>
mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMF
Re: [Rd] Hard memory limit of 16GB under Windows?
n 3.6.3 (2020-02-29) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 18363) Matrix products: default locale: [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 [4] LC_NUMERIC=C LC_TIME=French_France.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.6.3 > __ R-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=r6WLJ5dXWo2qb7mQwONaCxYeeWgKwycd3y89JoqY-oY=ABvG3sGKR5ln27FVCM8dlmZ82X93ZCTigbMxHeBEb6E= [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=r6WLJ5dXWo2qb7mQwONaCxYeeWgKwycd3y89JoqY-oY=ABvG3sGKR5ln27FVCM8dlmZ82X93ZCTigbMxHeBEb6E= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] HDF5Array failure on windows
Hi Kasper, Martin,
About bsseq's timeout: An important recent change to
DelayedArray/HDF5Array is that, starting with DelayedArray 0.13.8,
nothing in these packages uses parallel evaluation **by default**.
Concretely this means that getAutoBPPARAM() now returns NULL on a fresh
session instead of one of the parallelization backends defined in
BiocParallel (e.g. MulticoreParam on Linux/Mac, SnowParam on Windows).
This could slow down some code in bsseq or other packages that were
benefiting from the automatic parallel evaluation. Now it's the
responsibility of the user to set the parallelization backend (with
setAutoBPPARAM) if they wish things like matrix multiplication, rowsum()
or rowSums() use parallel evaluation again.
Also BiocParallel has been moved from Depends to Suggests.
About bsseq error on Windows: That seems indeed to be related to the
HDF5Array error on the same platform. The unit tests in bsseq and
HDF5Array both fail with the same error ("HDF5 dataset
'./.HDF5ArrayAUTO00014_dimnames/2' does not exist"). I'll take a look.
What's puzzling is that we see this error on both Windows archs for
bsseq (i.e. on 64-bit and 32-bit) while we only see it on 64-bit Windows
for HDF5Array. This suggests something nasty and hard to troubleshoot..
sigh!
Cheers,
H.
On 4/6/20 06:59, Martin Morgan wrote:
Timeouts are often related to parallel evaluation, either competing for
resources or underlying limitations in the robustness of the (parallel) code.
Something close to best practice is to limit or eliminate parallel evaluation
in examples, vignettes, and tests.
Documentation issues are usually related to the use of [] in \link[]{}, as described at
https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_doc_manuals_r-2Drelease_R-2Dexts.html-23Cross-5F002dreferences=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=2r59fOKiJQ_AJBSaOXUDB1j3dD1txuMA-cJzCnnIE9k=
. The important point is that the [] information is the NAME OF THE HTML FILE of the documentation
module, not the 'name' of the documentation module. The solution (from my perspective) is usually to
simply omit the [] and let the R help system resolve the link dynamically (sometimes prompting the user
to choose, if there multiple man pages).
Martin Morgan
On 4/6/20, 9:55 AM, "Bioc-devel on behalf of Kasper Daniel Hansen"
wrote:
We currently (and for a while) have had various errors in bsseq that seems
to have come and go. We now have a failure on Windows which is related to
HDF5. I see that HDF5Array also fails on Windows, which makes me believe
the error could be upstream. There is also a warning about hep page links
which HDF5Array has as well. Any comments on this is appreciated.
Perhaps relatedly: we are getting a timeout on linux. On my own OS X setup,
it completes in a timely fashion. Do we sometimes have unexplained timeouts
related to HDF5?
--
Best,
Kasper
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=28DlcVps0EVU-QaF8utnvHUFuj1DpJIZrrXrlPqIb28=
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=pNn2sHW_Vo7GJjsEgdNz2QJq4GrASIW3z6QSRefcLkY=28DlcVps0EVU-QaF8utnvHUFuj1DpJIZrrXrlPqIb28=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Problems caused by earlier Rhtslib migration
Hi Antti, On 3/30/20 00:14, Antti Honkela wrote: Hi all, I am a co-maintainer of BitSeq. About a year ago, we were offered help in migration from Rsamtools to Rhtslib and we took the offer. The commit pushed by BioC team added a file src/bam_plbuf.c with just one line: #include This is now making our Windows build fail because of an infinite include loop. As I don't understand why the file was added in the first place, help in resolving the issue would be appreciated! This is a trick to put a copy of the bam_plbuf.c file from the Rhtslib package in BitSeq/src/. I used the same trick for 7 other packages that I also migrated from Rsamtools to Rhtslib and it works fine on all platforms, including Windows. Not sure what's special about BitSeq on Windows. Can you please try to rename the file e.g. to Rhtslib_bam_plbuf.c? This should avoid the "include nested too deeply" error, hopefully. You might want to do the same thing for the sam.c file. Thanks, H. Best regards, Antti ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uZWZ6Z8-kMo46tPlCV-srVxHQ6g2EjpgilOYFeyGxYw=LuTyhFobrvTJ5otx3h60JgLILxjQvqeXR4XC9xHdHEI= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] object.size vs lobstr::obj_size
On 3/27/20 15:19, Hadley Wickham wrote:
On Fri, Mar 27, 2020 at 4:01 PM Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
On 3/27/20 12:00, Hadley Wickham wrote:
>
>
> On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès
mailto:hpa...@fredhutch.org>
> <mailto:hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>>> wrote:
>
> Hi Tomas,
>
> On 3/27/20 07:01, Tomas Kalibera wrote:
> > they provide an over-approximation
>
> They can also provide an "under-approximation" (to say the
least) e.g.
> on reference objects where the entire substance of the object is
> ignored
> which makes object.size() completely meaningless in that case:
>
> setRefClass("A", fields=c(stuff="ANY"))
> object.size(new("A", stuff=raw(0))) # 680 bytes
> object.size(new("A", stuff=runif(1e8))) # 680 bytes
>
> Why wouldn't object.size() look at the content of environments?
>
>
> As the author, I'm obviously biased, but I do like
lobstr::obj_sizes()
> which allows you to see the additional size occupied by one
object given
> any number of other objects. This is particularly important for
> reference classes since individual objects appear quite large:
>
> A <- setRefClass("A", fields=c(stuff="ANY"))
> lobstr::obj_size(new("A", stuff=raw(0)))
> #> 567,056 B
>
> But the vast majority is shared across all instances of that class:
>
> lobstr::obj_size(A)
> #> 719,232 B
> lobstr::obj_sizes(A, new("A", stuff=raw(0)))
> #> * 719,232 B
> #> * 720 B
> lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
> #> * 719,232 B
> #> * 800,000,720 B
Nice. Can you clarify the situation with lobstr::obj_size vs
pryr::object_size? I've heard of the latter before and use it sometimes
but never heard of the former before seeing Stefan's post. Then I
checked the authors of both and thought maybe they should talk to each
other ;-)
pryr is basically retired :) TBH I don't know why I gave up on it,
except lobstr is a cooler name 藍 That's where all active development is
happening. (The underlying code is substantially similar although
lobstr includes bug fixes not present in pryr)
Good to know, thanks! Couldn't find any mention of pryr being abandoned
and superseded by lobster (which definitely sounds more yummy) in pryr's
README.md or DESCRIPTION file. Would be good to put this somewhere.
H.
Hadley
--
http://hadley.nz
<https://urldefense.proofpoint.com/v2/url?u=http-3A__hadley.nz=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YbZWqj-epVToKynrOqXF8TgrxHYKx1pF3q2GrOuJwBQ=qCeYCgVDbk_GzadBoAgc3cf81fQfRJXpsf0P5meMhtU=>
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] object.size vs lobstr::obj_size
On 3/27/20 12:00, Hadley Wickham wrote:
On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
Hi Tomas,
On 3/27/20 07:01, Tomas Kalibera wrote:
> they provide an over-approximation
They can also provide an "under-approximation" (to say the least) e.g.
on reference objects where the entire substance of the object is
ignored
which makes object.size() completely meaningless in that case:
setRefClass("A", fields=c(stuff="ANY"))
object.size(new("A", stuff=raw(0))) # 680 bytes
object.size(new("A", stuff=runif(1e8))) # 680 bytes
Why wouldn't object.size() look at the content of environments?
As the author, I'm obviously biased, but I do like lobstr::obj_sizes()
which allows you to see the additional size occupied by one object given
any number of other objects. This is particularly important for
reference classes since individual objects appear quite large:
A <- setRefClass("A", fields=c(stuff="ANY"))
lobstr::obj_size(new("A", stuff=raw(0)))
#> 567,056 B
But the vast majority is shared across all instances of that class:
lobstr::obj_size(A)
#> 719,232 B
lobstr::obj_sizes(A, new("A", stuff=raw(0)))
#> * 719,232 B
#> * 720 B
lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
#> * 719,232 B
#> * 800,000,720 B
Nice. Can you clarify the situation with lobstr::obj_size vs
pryr::object_size? I've heard of the latter before and use it sometimes
but never heard of the former before seeing Stefan's post. Then I
checked the authors of both and thought maybe they should talk to each
other ;-)
Thanks,
H.
Hadley
--
http://hadley.nz
<https://urldefense.proofpoint.com/v2/url?u=http-3A__hadley.nz=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MX7Olw-dGRDfJNWEqIDTTTkaagVswOEqcRnxuRBAdjw=haVkOV6bEj7VnjT4Gn4iXzRqO7IOqDZUZuEeFPSHQuM=>
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] object.size vs lobstr::obj_size
Hi Tomas,
On 3/27/20 07:01, Tomas Kalibera wrote:
they provide an over-approximation
They can also provide an "under-approximation" (to say the least) e.g.
on reference objects where the entire substance of the object is ignored
which makes object.size() completely meaningless in that case:
setRefClass("A", fields=c(stuff="ANY"))
object.size(new("A", stuff=raw(0))) # 680 bytes
object.size(new("A", stuff=runif(1e8))) # 680 bytes
Why wouldn't object.size() look at the content of environments?
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Drosophila virilis BioPackage forthcoming?
Hi Ilkka, On 3/26/20 02:11, Ilkka Havukkala wrote: Hello there Is it possible to get Drosophila virilis genome as a BSGenome data package? e.g. this one https://metazoa.ensembl.org/Drosophila_virilis/Info/Annotation/ I wrapped up this genome in the BSgenome.Dvirilis.Ensembl.dvircaf1 package. It's only available in BioC 3.11 (current devel version). Install with BiocManager::install() as usual. Cheers, H. Like to do genome analysis/comparison in BioConductor to another species which is closely related, but further from Drosophila melanogaster etc. Kind regards Ilkka Havukkala New Zealand [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=2j-XqMgkHFiUdQuOv_PEqQ9KrpllNoZTuWR7_nklpRg=XzqMAcuqzJrQgjYmNrFXftlr_eMfox7d-OEiiOLNS3c= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Question regarding the error from build report
What is the question? On 3/26/20 17:36, 유도영 wrote: ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=yOswU0969aOLHa3jBIrzVj8fAiukIOoj9_7XnCcbRqI=zbtkDPRVf5duX0qU9xSZy3MqdeBSIo3Bpl7L6zEdNBE= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] core dump in MotifDb build
Hi Paul,
I can reproduce this on my laptop. See full output below (it's big!).
Make sure to use a recent version of R devel (I updated mine 3 days
ago). The error seems to occur in MotIV's C/C++ code (in
/home/hpages/R/R-4.0.r78037/library/MotIV/libs/MotIV.so on my machine).
2 unrelated things:
- Please add MotIV and seqLogo to your Suggests field (they're used in
the vignette and/or the unit tests).
- Make sure to remove vignettes/MotifDb.tex
Best,
H.
--
hpages@spectre:~/MotifDb/vignettes$ R-4.0 CMD Stangle MotifDb.Rnw
Output file: MotifDb.R
hpages@spectre:~/MotifDb/vignettes$ R-4.0
R Under development (unstable) (2020-03-23 r78037) -- "Unsuffered
Consequences"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> source("MotifDb.R", echo=TRUE)
> ### R code from vignette source
'/home/hpages/git.bioconductor.org/software/MotifDb/vignettes/MotifDb.Rnw'
>
> [TRUNCATED]
Loading required package: BiocGenerics
Loading required package: parallel
Attaching package: ‘BiocGenerics’
The following objects are masked from ‘package:parallel’:
clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
clusterExport, clusterMap, parApply, parCapply, parLapply,
parLapplyLB, parRapply, parSapply, parSapplyLB
The following objects are masked from ‘package:stats’:
IQR, mad, sd, var, xtabs
The following objects are masked from ‘package:base’:
anyDuplicated, append, as.data.frame, basename, cbind, colnames,
dirname, do.call, duplicated, eval, evalq, Filter, Find, get, grep,
grepl, intersect, is.unsorted, lapply, Map, mapply, match, mget,
order, paste, pmax, pmax.int, pmin, pmin.int, Position, rank,
rbind, Reduce, rownames, sapply, setdiff, sort, table, tapply,
union, unique, unsplit, which, which.max, which.min
Loading required package: S4Vectors
Loading required package: stats4
Attaching package: ‘S4Vectors’
The following object is masked from ‘package:base’:
expand.grid
Loading required package: IRanges
Loading required package: GenomicRanges
Loading required package: GenomeInfoDb
Loading required package: Biostrings
Loading required package: XVector
Attaching package: ‘Biostrings’
The following object is masked from ‘package:base’:
strsplit
Registered S3 method overwritten by 'treeio':
method from
root.phylo ape
See system.file("LICENSE", package="MotifDb") for use restrictions.
> library (MotIV)
Attaching package: ‘MotIV’
The following object is masked from ‘package:stats’:
filter
> library (seqLogo)
Loading required package: grid
Attaching package: ‘seqLogo’
The following object is masked from ‘package:MotIV’:
makePWM
> ###
> ### code chunk number 2: MotifDb.Rnw:71-90
> # [TRUNCATED]
> ###
> ### code chunk number 3: sources
> ###
> lengt [TRUNCATED]
[1] 10701
> sort (table (values (MotifDb)$dataSource), decreasing=TRUE)
jaspar2018 jaspar2016 HOCOMOCOv10
156412091066
cisbp_1.02 jolma2013SwissRegulon
874 843 684
stamlab FlyFactorSurvey JASPAR_2014
683 614 592
JASPAR_COREhPDIUniPROBE
459 437 380
HOMER HOCOMOCOv11-secondary-D ScerTF
332 290 196
HOCOMOCOv11-core-A HOCOMOCOv11-core-C HOCOMOCOv11-core-B
181 135 84
HOCOMOCOv11-secondary-A HOCOMOCOv11-secondary-B HOCOMOCOv11-secondary-C
46 19 13
> ###
> ### code chunk number 4: organisms
> ###
> sor [TRUNCATED]
Hsapiens
5384
Mmusculus
1411
Dmelanogaster
Re: [Bioc-devel] Python dependency
Hi, Yes Bioconductor packages can depend on Python modules. This should only happen behind the scene and be transparent to the end user (i.e. the end user is not expected to interact directly with the Python module). You can use reticulate (from CRAN) directly or, even better, use basilisk (from Bioconductor): https://bioconductor.org/packages/basilisk basilisk was only added to the devel version of Bioconductor recently. It aims at automating module installation on the end user machine and on the Bioconductor build machines (if you use reticulate directly, we would need to manually install the Python modules on the build machines). Cheers, H. On 3/24/20 08:58, Daniele Muraro wrote: To whom it may concern, I would like to upload onto Bioconductor a package which is currently developed in python. I was wondering if Bioconductor supports python dependencies or if I should re-program the package in R exclusively. Is calling python from R using the package "reticulate" acceptable for a package submission onto Bioconductor? Thank you for your attention. All the best, Daniele Muraro -- Daniele Muraro Computational Biologist - Staff Scientist Wellcome Sanger Institute Wellcome Genome Campus Hinxton, Cambridgeshire CB10 1SA, UK Phone (direct) +44 (0)1223 494766 Phone (reception) +44 (0)1223 834244 e-mail: daniele.mur...@sanger.ac.uk Sanger profile: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.sanger.ac.uk_people_directory_muraro-2Ddaniele=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=I5byLUAug01hPl-C-VbCCk-t7h7gPtd9rcxv5fK3NHk=DDLJ47WTk9au0lfoTBoXibSvAkBi1TEyL78EqjnlszE= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.sanger.ac.uk_people_directory_muraro-2Ddaniele=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=I5byLUAug01hPl-C-VbCCk-t7h7gPtd9rcxv5fK3NHk=DDLJ47WTk9au0lfoTBoXibSvAkBi1TEyL78EqjnlszE= >LinkedIn profile: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_daniele-2Dmuraro-2Da3557630_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=I5byLUAug01hPl-C-VbCCk-t7h7gPtd9rcxv5fK3NHk=vL4MJYsNa8_56NxXoYbZEYYHZk9-HJku2hLUuZLDwqw= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] configure --with-pcre1 fails with latest R 4.0 on Ubuntu 14.04
Excellent. Thank you! H. On 3/20/20 23:55, Tomas Kalibera wrote: On 3/18/20 6:11 PM, Hervé Pagès wrote: Thanks Tomas. Any chance the old version of the error message could be restored? It would definitely be more helpful than the current one. It's confusing to get an error and be told to use --with-pcre1 when you're already using it. The message now gives the required version and UTF-8 support requirement, so one does not have to look that one line up. Thanks to Brian Ripley, Tomas H. On 3/18/20 01:08, Tomas Kalibera wrote: On 3/17/20 8:18 PM, Hervé Pagès wrote: Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on an Ubuntu 14.04.5 LTS system gives me the following error: ... checking if lzma version >= 5.0.3... yes checking for pcre2-config... no checking for pcre_fullinfo in -lpcre... yes checking pcre.h usability... yes checking pcre.h presence... yes checking for pcre.h... yes checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE1 version >= 8.32 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre2 library and headers are required, or use --with-pcre1 Maybe the real problem is that the PCRE version on this OS is 8.31? Yes, R requires PCRE version at least 8.32 as documented in R-Admin, and this is since September 2019. The error message is not particularly helpful. An earlier version of the message gave the requirement explicitly, when people would have been more likely to have that old versions of PCRE1. The few who still have it now need to see also the output line above to get the requirement and/or look into the manual. R 4.0 is still keeping support for PCRE1 (>=8.32), but PCRE2 should be used whenever possible. Best, Tomas Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] help with Win10 TLS problem?
Did it work?
On 3/18/20 15:41, Egon Willighagen wrote:
Thanks, in going to try your suggestion tomorrow!
On Wed, Mar 18, 2020, 23:22 Hervé Pagès <mailto:hpa...@fredhutch.org>> wrote:
mmh.. for some reason the original post in this thread is only showing
up now in my mailbox i.e. way after Steffen's answer (and even if
Steffen's answer includes the original post, I must confess that I
didn't really pay attention to it)
Anyway, based on that original post I see now that Egon was using
download.file() but this was not working on Windows 10 so he
switched to
the RCurl solution. And the RCurl solution works on Windows 10 but now
fails on our Windows builders (Windows Server 2012 R2 Standard). Do I
get the situation right?
H.
On 3/18/20 14:53, Hervé Pagès wrote:
> The getBridgeNames() function in BridgeDbR uses the following
code to
> download the HTML page at
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__bridgedb.github.io_data_gene-5Fdatabase_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GbdGtFXiT4WW33h7Un9R0XL7r4I1e4JAb9uSyup82Sw=qywf3a1JViBPl5ArNq4vLqt8_csFrFDG_G2MREAWwpM=
>
> url <-
>
"https://urldefense.proofpoint.com/v2/url?u=https-3A__bridgedb.github.io_data_gene-5Fdatabase_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GbdGtFXiT4WW33h7Un9R0XL7r4I1e4JAb9uSyup82Sw=qywf3a1JViBPl5ArNq4vLqt8_csFrFDG_G2MREAWwpM=
> "
> library(RCurl)
> CURL_SSLVERSION_TLSv1_2 <- 6L
> opts <- curlOptions(sslversion=CURL_SSLVERSION_TLSv1_2)
> site <- basicTextGatherer()
> curlPerform(url=url, writefunction=site$update, .opts=opts)
> html <- site$value()
>
> Not sure why this fails on our Windows builder but if it fails
there it
> might fail on other Windows systems. A more portable/reliable way
to get
> that HTML document is to use download.file():
>
> url <-
>
"https://urldefense.proofpoint.com/v2/url?u=https-3A__bridgedb.github.io_data_gene-5Fdatabase_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GbdGtFXiT4WW33h7Un9R0XL7r4I1e4JAb9uSyup82Sw=qywf3a1JViBPl5ArNq4vLqt8_csFrFDG_G2MREAWwpM=
> "
> destfile <- tempfile()
> download.file(url, destfile)
> html2 <- paste0(readLines(destfile), "\n", collapse="")
>
> identical(html, html2) # TRUE
>
> This works everywhere I tested e.g. my laptop, malbec1, merida1,
tokay2,
> etc... and doesn't rely on some obscure RCurl/SSL settings.
>
> By doing the same kind of change in their getDatabase() function,
the
> BridgeDbR maintainers can get rid of their dependency on RCurl.
>
> Hope this helps,
> H.
>
>
> On 3/18/20 12:20, Neumann, Steffen wrote:
>> Hi,
>>
>> can you get me the URL that wants to be downloaded ?
>>
>> The "tlsv1 alert protocol version" indicates that the proper
>> solution might be to notify the server to reconfigure
>> the web server supported TLS versions.
>>
>> Yours,
>> Steffen
>>
>>
>> On Wed, 2020-03-18 at 19:55 +0100, Egon Willighagen wrote:
>>> Hi all,
>>>
>>> in the BridgeDbR package I have a TSL issue, just on Windows10 [0]:
>>>
>>>> location <- getDatabase("Bacillus subtilis")
>>>
>>> Error in function (type, msg, asError = TRUE) :
>>> error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
>>> protocol version
>>> Calls: getDatabase ... getBridgeNames -> curlPerform ->
>>> -> fun
>>> Execution halted
>>>
>>> This method is using the download.file() method (see [1]). I am not
>>> sure
>>> what this method uses by default. I have been googling and found a
>>> number
>>> of suggestions on how to get RCurl to use other SSL version,
such as:
>>>
>>> CURL_SSLVERSION_TLSv1_2 <- 1Lopts <- RCurl::curlOptions( verbose =
>>> TRUE, sslversion = CURL_SSLVERSION_TLSv1_2)download.file(url, file,
>>> mode = "wb", .opts=opts)
>>>
>>>
>>> But I haven't found something that works. Error messages are very
>>> cryptic,
>>> and I'm running out of ideas.
>>>
>>> Does someone have a suggest
Re: [Bioc-devel] help with Win10 TLS problem?
mmh.. for some reason the original post in this thread is only showing
up now in my mailbox i.e. way after Steffen's answer (and even if
Steffen's answer includes the original post, I must confess that I
didn't really pay attention to it)
Anyway, based on that original post I see now that Egon was using
download.file() but this was not working on Windows 10 so he switched to
the RCurl solution. And the RCurl solution works on Windows 10 but now
fails on our Windows builders (Windows Server 2012 R2 Standard). Do I
get the situation right?
H.
On 3/18/20 14:53, Hervé Pagès wrote:
The getBridgeNames() function in BridgeDbR uses the following code to
download the HTML page at
https://urldefense.proofpoint.com/v2/url?u=https-3A__bridgedb.github.io_data_gene-5Fdatabase_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GbdGtFXiT4WW33h7Un9R0XL7r4I1e4JAb9uSyup82Sw=qywf3a1JViBPl5ArNq4vLqt8_csFrFDG_G2MREAWwpM=
url <-
"https://urldefense.proofpoint.com/v2/url?u=https-3A__bridgedb.github.io_data_gene-5Fdatabase_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GbdGtFXiT4WW33h7Un9R0XL7r4I1e4JAb9uSyup82Sw=qywf3a1JViBPl5ArNq4vLqt8_csFrFDG_G2MREAWwpM=
"
library(RCurl)
CURL_SSLVERSION_TLSv1_2 <- 6L
opts <- curlOptions(sslversion=CURL_SSLVERSION_TLSv1_2)
site <- basicTextGatherer()
curlPerform(url=url, writefunction=site$update, .opts=opts)
html <- site$value()
Not sure why this fails on our Windows builder but if it fails there it
might fail on other Windows systems. A more portable/reliable way to get
that HTML document is to use download.file():
url <-
"https://urldefense.proofpoint.com/v2/url?u=https-3A__bridgedb.github.io_data_gene-5Fdatabase_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=GbdGtFXiT4WW33h7Un9R0XL7r4I1e4JAb9uSyup82Sw=qywf3a1JViBPl5ArNq4vLqt8_csFrFDG_G2MREAWwpM=
"
destfile <- tempfile()
download.file(url, destfile)
html2 <- paste0(readLines(destfile), "\n", collapse="")
identical(html, html2) # TRUE
This works everywhere I tested e.g. my laptop, malbec1, merida1, tokay2,
etc... and doesn't rely on some obscure RCurl/SSL settings.
By doing the same kind of change in their getDatabase() function, the
BridgeDbR maintainers can get rid of their dependency on RCurl.
Hope this helps,
H.
On 3/18/20 12:20, Neumann, Steffen wrote:
Hi,
can you get me the URL that wants to be downloaded ?
The "tlsv1 alert protocol version" indicates that the proper
solution might be to notify the server to reconfigure
the web server supported TLS versions.
Yours,
Steffen
On Wed, 2020-03-18 at 19:55 +0100, Egon Willighagen wrote:
Hi all,
in the BridgeDbR package I have a TSL issue, just on Windows10 [0]:
location <- getDatabase("Bacillus subtilis")
Error in function (type, msg, asError = TRUE) :
error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
protocol version
Calls: getDatabase ... getBridgeNames -> curlPerform ->
-> fun
Execution halted
This method is using the download.file() method (see [1]). I am not
sure
what this method uses by default. I have been googling and found a
number
of suggestions on how to get RCurl to use other SSL version, such as:
CURL_SSLVERSION_TLSv1_2 <- 1Lopts <- RCurl::curlOptions( verbose =
TRUE, sslversion = CURL_SSLVERSION_TLSv1_2)download.file(url, file,
mode = "wb", .opts=opts)
But I haven't found something that works. Error messages are very
cryptic,
and I'm running out of ideas.
Does someone have a suggestion how to debug this? Maybe even have a
solution?
All feedback is very much appreciated!
Egon
0.
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_BridgeDbR_tokay1-2Dchecksrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=6ZUwYkvqkDVxUXnwM4Ny0c26DHiOZSSZMb3TcjTEhTU=SDaSu90TFdkKtZZR37pGYXHlqzxNF52W5cEYLNRIl88=
1.
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bridgedb_BridgeDbR_blob_master_R_getDatabase.R-23L23=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=6ZUwYkvqkDVxUXnwM4Ny0c26DHiOZSSZMb3TcjTEhTU=IIwoUM7vnfvLY_e0j7jr4Vd3-EFsgGD1khuegLj83KI=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] help with Win10 TLS problem?
The getBridgeNames() function in BridgeDbR uses the following code to
download the HTML page at https://bridgedb.github.io/data/gene_database/
url <- "https://bridgedb.github.io/data/gene_database/;
library(RCurl)
CURL_SSLVERSION_TLSv1_2 <- 6L
opts <- curlOptions(sslversion=CURL_SSLVERSION_TLSv1_2)
site <- basicTextGatherer()
curlPerform(url=url, writefunction=site$update, .opts=opts)
html <- site$value()
Not sure why this fails on our Windows builder but if it fails there it
might fail on other Windows systems. A more portable/reliable way to get
that HTML document is to use download.file():
url <- "https://bridgedb.github.io/data/gene_database/;
destfile <- tempfile()
download.file(url, destfile)
html2 <- paste0(readLines(destfile), "\n", collapse="")
identical(html, html2) # TRUE
This works everywhere I tested e.g. my laptop, malbec1, merida1, tokay2,
etc... and doesn't rely on some obscure RCurl/SSL settings.
By doing the same kind of change in their getDatabase() function, the
BridgeDbR maintainers can get rid of their dependency on RCurl.
Hope this helps,
H.
On 3/18/20 12:20, Neumann, Steffen wrote:
Hi,
can you get me the URL that wants to be downloaded ?
The "tlsv1 alert protocol version" indicates that the proper
solution might be to notify the server to reconfigure
the web server supported TLS versions.
Yours,
Steffen
On Wed, 2020-03-18 at 19:55 +0100, Egon Willighagen wrote:
Hi all,
in the BridgeDbR package I have a TSL issue, just on Windows10 [0]:
location <- getDatabase("Bacillus subtilis")
Error in function (type, msg, asError = TRUE) :
error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
protocol version
Calls: getDatabase ... getBridgeNames -> curlPerform ->
-> fun
Execution halted
This method is using the download.file() method (see [1]). I am not
sure
what this method uses by default. I have been googling and found a
number
of suggestions on how to get RCurl to use other SSL version, such as:
CURL_SSLVERSION_TLSv1_2 <- 1Lopts <- RCurl::curlOptions( verbose =
TRUE, sslversion = CURL_SSLVERSION_TLSv1_2)download.file(url, file,
mode = "wb", .opts=opts)
But I haven't found something that works. Error messages are very
cryptic,
and I'm running out of ideas.
Does someone have a suggestion how to debug this? Maybe even have a
solution?
All feedback is very much appreciated!
Egon
0.
https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_BridgeDbR_tokay1-2Dchecksrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=6ZUwYkvqkDVxUXnwM4Ny0c26DHiOZSSZMb3TcjTEhTU=SDaSu90TFdkKtZZR37pGYXHlqzxNF52W5cEYLNRIl88=
1.
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bridgedb_BridgeDbR_blob_master_R_getDatabase.R-23L23=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=6ZUwYkvqkDVxUXnwM4Ny0c26DHiOZSSZMb3TcjTEhTU=IIwoUM7vnfvLY_e0j7jr4Vd3-EFsgGD1khuegLj83KI=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] configure --with-pcre1 fails with latest R 4.0 on Ubuntu 14.04
Thanks Tomas. Any chance the old version of the error message could be restored? It would definitely be more helpful than the current one. It's confusing to get an error and be told to use --with-pcre1 when you're already using it. H. On 3/18/20 01:08, Tomas Kalibera wrote: On 3/17/20 8:18 PM, Hervé Pagès wrote: Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on an Ubuntu 14.04.5 LTS system gives me the following error: ... checking if lzma version >= 5.0.3... yes checking for pcre2-config... no checking for pcre_fullinfo in -lpcre... yes checking pcre.h usability... yes checking pcre.h presence... yes checking for pcre.h... yes checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE1 version >= 8.32 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre2 library and headers are required, or use --with-pcre1 Maybe the real problem is that the PCRE version on this OS is 8.31? Yes, R requires PCRE version at least 8.32 as documented in R-Admin, and this is since September 2019. The error message is not particularly helpful. An earlier version of the message gave the requirement explicitly, when people would have been more likely to have that old versions of PCRE1. The few who still have it now need to see also the output line above to get the requirement and/or look into the manual. R 4.0 is still keeping support for PCRE1 (>=8.32), but PCRE2 should be used whenever possible. Best, Tomas Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure --with-pcre1 fails with latest R 4.0 on Ubuntu 14.04
Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on an Ubuntu 14.04.5 LTS system gives me the following error: ... checking if lzma version >= 5.0.3... yes checking for pcre2-config... no checking for pcre_fullinfo in -lpcre... yes checking pcre.h usability... yes checking pcre.h presence... yes checking for pcre.h... yes checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE1 version >= 8.32 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre2 library and headers are required, or use --with-pcre1 Maybe the real problem is that the PCRE version on this OS is 8.31? The error message is not particularly helpful. Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
