Re: [Bioc-devel] Missing knitcitations package on devel for PharmacoGx

[Vincent Carey]

This problem has been recognized:
https://github.com/cboettig/knitcitations/issues/107

In a few days it will likely clear.

On Wed, Nov 25, 2020 at 10:26 PM Eeles, Christopher <
christopher.ee...@uhnresearch.ca> wrote:

> Hello Bioc community,
>
> I am the maintainer for PharmacoGx and have noticed that I have an error
> on all platforms of the devel branch related to the knitcitations package.
>
>
> * checking for file ‘PharmacoGx/DESCRIPTION’ ... OK
> * preparing ‘PharmacoGx’:
> * checking DESCRIPTION meta-information ... OK
> * installing the package to build vignettes
> * creating vignettes ... ERROR
> --- re-building ‘CreatingPharmacoSet.Rmd’ using rmarkdown
> Quitting from lines 79-82 (CreatingPharmacoSet.Rmd)
> Error: processing vignette 'CreatingPharmacoSet.Rmd' failed with
> diagnostics:
> there is no package called 'knitcitations'
> --- failed re-building ‘CreatingPharmacoSet.Rmd’
>
> --- re-building ‘PharmacoGx.Rmd’ using rmarkdown
> Quitting from lines 79-82 (PharmacoGx.Rmd)
> Error: processing vignette 'PharmacoGx.Rmd' failed with diagnostics:
> there is no package called 'knitcitations'
> --- failed re-building ‘PharmacoGx.Rmd’
>
> SUMMARY: processing the following files failed:
>   ‘CreatingPharmacoSet.Rmd’ ‘PharmacoGx.Rmd’
>
> Error: Vignette re-building failed.
> Execution halted
>
> The package builds fine on the release branch with the same vignettes and
> knitcitations in the suggests field of the description.
>
> Any advice on how I can fix this? It seems like my suggests aren't being
> installed on the devel branch.
>
> Thanks for your assistance.
>
> Best,
> Christopher Eeles
> Software Developer
> Benjamin Haibe-Kains Lab
> Princess Margaret Cancer Centre
>
> This e-mail may contain confidential and/or privileged i...{{dropped:22}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] apologies

[Vincent Carey]

my email "topics sought ..." was not intended for this list, but i welcome
direct
contact from anyone who is interested in it

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] topics sought for bioc tab discussion dec 3 2020

[Vincent Carey]

Hi -- I know this is an inopportune moment for many but I just wanted to
reach out to the TAB to ask for topics of interest.  Mike Love and
colleagues
will be discussing *Hubs in the TAB talk section, but there is time for
other
concerns.  We do plan to discuss handling .github/workflow folders in
packages,
and package name ownership.

Email me today if possible as the TAB exec group will meet tomorrow --
yes, reducing the USA-centricity of the task calendar 

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RCurl on Windows

[Vincent Carey]

Curious situation, that we can hope will be resolved with action at CRAN.
FWIW RCurl for windows is building/checking without incident:

https://cran.r-project.org/bin/windows/contrib/checkSummaryWin.html

The UniProt.ws check failure on malbec2 etc. seems unrelated, the URL noted
in the failure report

http://bioconductor.org/checkResults/3.13/bioc-LATEST/UniProt.ws/malbec2-buildsrc.html

resolves for me when attempted manually.

There are 59 bioc packages, some quite central, that declare "depends" or
"imports" on RCurl.

On Mon, Nov 23, 2020 at 12:54 PM James W. MacDonald  wrote:

> It's not something I need, per se, but what other packages that depend on
> RCurl need. This issue was brought to my attention because someone on the
> support site had a problem with the UniProt.ws package, which uses RCurl to
> download data. Given the reverse dependency tree for RCurl I assume this
> problem will have an outsized effect, at least amongst Windows users.
>
> I know that DTL wrote the package back in the day, but apparently the CRAN
> maintainers have been de facto maintainers/authors since 2013. So I sent
> them the same reproducible error. Anyway, there isn't a current version on
> Github (there is a two-year old version at github.com/cran/RCurl), so
> there isn't a more interactive way to report the error.
>
> On Mon, Nov 23, 2020 at 12:20 PM Vincent Carey 
> wrote:
>
>> I reproduced the problem you noted.  Rebuilding RCurl with (an updated?)
>> openssl for
>> windows is not a slam-dunk for me at the moment.  Can the curl package do
>> what you need?
>>
>> On Mon, Nov 23, 2020 at 11:49 AM James W. MacDonald 
>> wrote:
>>
>>> FYI, there appears to be a problem with RCurl on Windows, most likely due
>>> to building against an old version of OpenSSL. Or at least that's what
>>> Google tells me. Anyway, reproducible code:
>>>
>>> > library(RCurl)
>>> > url <- "www.uniprot.org/mapping"
>>> > params <- c(from = "ACC+ID", to = "PDB_ID", format = "tab", query =
>>> "P31946 P62258")
>>> > getForm(url, .params = params, .opts = list(FOLLOWLOCATION = TRUE))
>>> Error in function (type, msg, asError = TRUE)  :
>>>   error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol
>>> version
>>>
>>> I sent the same to c...@r-project.org, which is the email for the
>>> maintainer. So they have been notified, but maybe somebody knows whomever
>>> is actually maintaining RCurl, and can pull a string?
>>>
>>> Best,
>>>
>>> Jim
>>>
>>>
>>>
>>> --
>>> James W. MacDonald, M.S.
>>> Biostatistician
>>> University of Washington
>>> Environmental and Occupational Health Sciences
>>> 4225 Roosevelt Way NE, # 100
>>> Seattle WA 98105-6099
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance HelpLine
>> at
>> http://www.partners.org/complianceline . If the e-mail was sent to you
>> in error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>

-- 
The information in this e-mail is intended only for the person to whom it 
is
addressed. If you believe this e-mail was sent to you in error and the 
e-mail
contains patient information, please contact the Partners Compliance 
HelpLine at
http://www.partners.org/complianceline 
<http://www.partners.org/complianceline> . If the e-mail was sent to you in 
error
but does not contain patient information, please contact the sender 
and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RCurl on Windows

[Vincent Carey]

I reproduced the problem you noted.  Rebuilding RCurl with (an updated?)
openssl for
windows is not a slam-dunk for me at the moment.  Can the curl package do
what you need?

On Mon, Nov 23, 2020 at 11:49 AM James W. MacDonald  wrote:

> FYI, there appears to be a problem with RCurl on Windows, most likely due
> to building against an old version of OpenSSL. Or at least that's what
> Google tells me. Anyway, reproducible code:
>
> > library(RCurl)
> > url <- "www.uniprot.org/mapping"
> > params <- c(from = "ACC+ID", to = "PDB_ID", format = "tab", query =
> "P31946 P62258")
> > getForm(url, .params = params, .opts = list(FOLLOWLOCATION = TRUE))
> Error in function (type, msg, asError = TRUE)  :
>   error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol
> version
>
> I sent the same to c...@r-project.org, which is the email for the
> maintainer. So they have been notified, but maybe somebody knows whomever
> is actually maintaining RCurl, and can pull a string?
>
> Best,
>
> Jim
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RCurl on Windows

[Vincent Carey]

RCurl was originally an omeghat offering by Duncan Temple Lang.  I have a
windows
machine here and will have a look.

On Mon, Nov 23, 2020 at 11:49 AM James W. MacDonald  wrote:

> FYI, there appears to be a problem with RCurl on Windows, most likely due
> to building against an old version of OpenSSL. Or at least that's what
> Google tells me. Anyway, reproducible code:
>
> > library(RCurl)
> > url <- "www.uniprot.org/mapping"
> > params <- c(from = "ACC+ID", to = "PDB_ID", format = "tab", query =
> "P31946 P62258")
> > getForm(url, .params = params, .opts = list(FOLLOWLOCATION = TRUE))
> Error in function (type, msg, asError = TRUE)  :
>   error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol
> version
>
> I sent the same to c...@r-project.org, which is the email for the
> maintainer. So they have been notified, but maybe somebody knows whomever
> is actually maintaining RCurl, and can pull a string?
>
> Best,
>
> Jim
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Would it make sense for BiocManager::install to cache downloaded packages?

[Vincent Carey]

another helpful element -- to have an option to warn early on if the
available space in R_TMPDIR value is not sufficiently large

not sure how to do that portably but perhaps there is a way

On Wed, Nov 4, 2020 at 1:52 PM Martin Morgan 
wrote:

> FWIW BiocManager::install() really delegates to install.packages(). The
> packages are downloaded to 'destdir=' as documented on ?install.packages --
> typically file.path(tempdir(), "downloaded_packages") -- and one path to
> troubleshooting installs is to tackle the problematic installation(s) using
> `install.packages(pkgs_in_downloaded_packages, repos = NULL)`, where
> pkgs_in_downloaded_packages are the packages that have failed to install on
> first pass.
>
> It does seem like this would be a reasonable feature for base R, that we
> could inherit, so one could ask on R-devel or submit a bug report / feature
> request (e.g., via `bug.report()`).
>
> Martin
>
> On 11/4/20, 1:19 PM, "Bioc-devel on behalf of Vincent Carey" <
> bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
> wrote:
>
> I certainly have run into this situation with R generally.  It seems
> like a
> patch to
> install.packages would be the best approach to introduce this
> functionality.  I wonder
> if Henrik Bengtsson or Dirk Eddelbuettel have pondered this.
>
> In any case, I am sympathetic with the suggestion but I believe this
> has to
> be done
> and tested outside the core developer team -- resources are too scant,
> and
> the
> event of concern seems relatively rare.  But maybe I overestimate the
> burden.
>
> On Wed, Nov 4, 2020 at 12:19 PM Keith Hughitt  >
> wrote:
>
> > Sometimes I will go to update a machine / do a clean Bioconductor
> install
> > and a large number of packages will need to be downloaded.
> >
> > If something goes wrong during the installation, which is not
> uncommon in
> > cases where the number of packages being installed is large, then the
> > process has to be restarted and the packages re-downloaded all-over
> again.
> >
> > Often, it may take some trial-and-error to fix the problem
> preventing the
> > install from completing, the result of which is that you may end up
> > re-downloading 50+ packages several times.
> >
> > Would it perhaps make sense for BiocManager to download
> packages/checksums
> > to somewhere like "~/.cache/bioc/pkg" so that they could be re-used
> during
> > future installs?
> >
> > Obviously, it would be good for BiocManger to have some ability to
> suggest
> > old packages for removal (e.g. outdated/haven't been used in a long
> time)
> > to avoid filling up people's hard-drives.
> >
> > Another possibility would be to build on top of the work done by
> renv,
> > which already has a very nice caching system.
> >
> > In any case, it seems like it would be something (relatively)
> > straight-forward to implement that would save a lot of bandwidth and
> time
> > for users.
> >
> > Just a thought..
> > Keith
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> --
> The information in this e-mail is intended only for the
> ...{{dropped:18}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Would it make sense for BiocManager::install to cache downloaded packages?

[Vincent Carey]

Could we think about a parameter use_unused_tarballs that automates this
reduction in redownload effort?

On Wed, Nov 4, 2020 at 1:52 PM Martin Morgan 
wrote:

> FWIW BiocManager::install() really delegates to install.packages(). The
> packages are downloaded to 'destdir=' as documented on ?install.packages --
> typically file.path(tempdir(), "downloaded_packages") -- and one path to
> troubleshooting installs is to tackle the problematic installation(s) using
> `install.packages(pkgs_in_downloaded_packages, repos = NULL)`, where
> pkgs_in_downloaded_packages are the packages that have failed to install on
> first pass.
>
> It does seem like this would be a reasonable feature for base R, that we
> could inherit, so one could ask on R-devel or submit a bug report / feature
> request (e.g., via `bug.report()`).
>
> Martin
>
> On 11/4/20, 1:19 PM, "Bioc-devel on behalf of Vincent Carey" <
> bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
> wrote:
>
> I certainly have run into this situation with R generally.  It seems
> like a
> patch to
> install.packages would be the best approach to introduce this
> functionality.  I wonder
> if Henrik Bengtsson or Dirk Eddelbuettel have pondered this.
>
> In any case, I am sympathetic with the suggestion but I believe this
> has to
> be done
> and tested outside the core developer team -- resources are too scant,
> and
> the
> event of concern seems relatively rare.  But maybe I overestimate the
> burden.
>
> On Wed, Nov 4, 2020 at 12:19 PM Keith Hughitt  >
> wrote:
>
> > Sometimes I will go to update a machine / do a clean Bioconductor
> install
> > and a large number of packages will need to be downloaded.
> >
> > If something goes wrong during the installation, which is not
> uncommon in
> > cases where the number of packages being installed is large, then the
> > process has to be restarted and the packages re-downloaded all-over
> again.
> >
> > Often, it may take some trial-and-error to fix the problem
> preventing the
> > install from completing, the result of which is that you may end up
> > re-downloading 50+ packages several times.
> >
> > Would it perhaps make sense for BiocManager to download
> packages/checksums
> > to somewhere like "~/.cache/bioc/pkg" so that they could be re-used
> during
> > future installs?
> >
> > Obviously, it would be good for BiocManger to have some ability to
> suggest
> > old packages for removal (e.g. outdated/haven't been used in a long
> time)
> > to avoid filling up people's hard-drives.
> >
> > Another possibility would be to build on top of the work done by
> renv,
> > which already has a very nice caching system.
> >
> > In any case, it seems like it would be something (relatively)
> > straight-forward to implement that would save a lot of bandwidth and
> time
> > for users.
> >
> > Just a thought..
> > Keith
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> --
> The information in this e-mail is intended only for the
> ...{{dropped:18}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Compiling a cpp source code while installing package

[Vincent Carey]

On Sun, Nov 8, 2020 at 7:40 AM Alexandru Voda 
wrote:

> Thanks for the reply, Martin!
>
> Unfortunately, the C++ software is large (
> https://ctg.cncr.nl/software/magma), not just some feature that can be
> used from R base, CRAN or Bioconductor.
>

just having a quick look at magma source -- which includes boost 1.74.  of
30Mb of text in src, 25Mb are consumed by boost

we would likely want to factor that out and use BH if at all possible


>
> Also, I wouldn't make a separate library for the C++ software because the
> *main* purpose of my package is to wrap them up for R. Other functions are
> just a secondary aim of the package.
>
> Thank you for the recommended packages! I was wondering if there's any
> standard guidance/vignette for how Rhtslib & Rhdf5lib approached this?
> There are numerous Rcpp vignettes that I could find, but couldn't find for
> pure C compiled by R?
> 
> From: Martin Morgan 
> Sent: Saturday, November 7, 2020 3:30 PM
> To: Alexandru Voda ; bioc-devel@r-project.org
> 
> Subject: Re: [Bioc-devel] Compiling a cpp source code while installing
> package
>
> It would probably help to provide additional detail here; there are
> several examples of packages that build C / C++ libraries from source, a
> common pattern is to have a package dedicated to providing the library,
> e.g., Rhtslib or Rhdf5lib, or of building the library as part of the
> software package itself.
>
> It's worth assessing whether the functionality is worth it (e.g., why use
> a random number generator from another package, when one can use the R
> random number generator) or already implemented (e.g., linear algebra in
> RcppArmadillo).
>
> Martin
>
> On 11/7/20, 10:25 AM, "Bioc-devel on behalf of Alexandru Voda" <
> bioc-devel-boun...@r-project.org on behalf of alexandru.v...@seh.ox.ac.uk>
> wrote:
>
> Hi! I tried to look this up in the FAQ & best practices but couldn't
> find it.
>
> My in-the-works package needs to call a legacy C++ software from time
> to time.
>
> Since that C++ software is open-source, is there a way to make my
> package compile the source (during R package installation) I'm going to
> include? That'd make my package's dependency localized and well-controlled,
> but any other alternative is welcome (except Rcpp, which would take too
> many months to rewrite into the legacy C++ software).
>
> Best wishes,
> Alexandru
>
>  [[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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Would it make sense for BiocManager::install to cache downloaded packages?

[Vincent Carey]

I certainly have run into this situation with R generally.  It seems like a
patch to
install.packages would be the best approach to introduce this
functionality.  I wonder
if Henrik Bengtsson or Dirk Eddelbuettel have pondered this.

In any case, I am sympathetic with the suggestion but I believe this has to
be done
and tested outside the core developer team -- resources are too scant, and
the
event of concern seems relatively rare.  But maybe I overestimate the
burden.

On Wed, Nov 4, 2020 at 12:19 PM Keith Hughitt 
wrote:

> Sometimes I will go to update a machine / do a clean Bioconductor install
> and a large number of packages will need to be downloaded.
>
> If something goes wrong during the installation, which is not uncommon in
> cases where the number of packages being installed is large, then the
> process has to be restarted and the packages re-downloaded all-over again.
>
> Often, it may take some trial-and-error to fix the problem preventing the
> install from completing, the result of which is that you may end up
> re-downloading 50+ packages several times.
>
> Would it perhaps make sense for BiocManager to download packages/checksums
> to somewhere like "~/.cache/bioc/pkg" so that they could be re-used during
> future installs?
>
> Obviously, it would be good for BiocManger to have some ability to suggest
> old packages for removal (e.g. outdated/haven't been used in a long time)
> to avoid filling up people's hard-drives.
>
> Another possibility would be to build on top of the work done by renv,
> which already has a very nice caching system.
>
> In any case, it seems like it would be something (relatively)
> straight-forward to implement that would save a lot of bandwidth and time
> for users.
>
> Just a thought..
> Keith
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Vignette building error in multiGSEA

[Vincent Carey]

Here's what happened when I tried to build your package as instructed in
the report page:

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES$ R_ENVIRON_USER=~/.Renviron.bioc
Rdev CMD build multiGSEA
1/9 packages newly attached/loaded, see sessionInfo() for details.
* checking for file ‘multiGSEA/DESCRIPTION’ ... OK
* preparing ‘multiGSEA’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building ‘multiGSEA.rmd’ using rmarkdown
Loading required package: AnnotationDbi
Loading required package: stats4
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':

Filter, Find, Map, Position, Reduce, anyDuplicated, append,
as.data.frame, basename, cbind, colnames, dirname, do.call,
duplicated, eval, evalq, get, grep, grepl, intersect, is.unsorted,
lapply, mapply, match, mget, order, paste, pmax, pmax.int, pmin,
pmin.int, rank, rbind, rownames, sapply, setdiff, sort, table,
tapply, union, unique, unsplit, which.max, which.min

Loading required package: Biobase
Welcome to Bioconductor

Vignettes contain introductory material; view with
'browseVignettes()'. To cite Bioconductor, see
'citation("Biobase")', and for packages 'citation("pkgname")'.

Loading required package: IRanges
Loading required package: S4Vectors

Attaching package: 'S4Vectors'

The following object is masked from 'package:base':

expand.grid


'select()' returned 1:1 mapping between keys and columns
'select()' returned 1:many mapping between keys and columns
'select()' returned 1:many mapping between keys and columns
'select()' returned 1:1 mapping between keys and columns
'select()' returned 1:1 mapping between keys and columns
'select()' returned 1:1 mapping between keys and columns
'select()' returned 1:1 mapping between keys and columns


this goes on for pages.   then:

select()' returned 1:many mapping between keys and columns
'select()' returned 1:many mapping between keys and columns
'select()' returned 1:many mapping between keys and columns
Quitting from lines 259-267 (multiGSEA.rmd)
Error: processing vignette 'multiGSEA.rmd' failed with diagnostics:
The necessary package metabolieIDmapping is not installed.
--- failed re-building ‘multiGSEA.rmd’

SUMMARY: processing the following file failed:
  ‘multiGSEA.rmd’

Error: Vignette re-building failed.
Execution halted

Now is "metabolieIDmapping" a spelling error?

sessionInfo:

> library(multiGSEA)
1/70 packages newly attached/loaded, see sessionInfo() for details.
> sessionInfo()
R Under development (unstable) (2020-10-29 r79387)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 LTS (fossa-melisa X20)

Matrix products: default
BLAS:   /home/stvjc/R-dev-dist/lib/R/lib/libRblas.so
LAPACK: /home/stvjc/R-dev-dist/lib/R/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] multiGSEA_1.1.0 rmarkdown_2.5

loaded via a namespace (and not attached):
 [1] Biobase_2.51.0   httr_1.4.2   bit64_4.0.5
 [4] splines_4.1.0tmvnsim_1.0-2sn_1.6-2
 [7] Rdpack_2.0   stats4_4.1.0 blob_1.2.1
[10] TFisher_0.2.0numDeriv_2016.8-1.1  pillar_1.4.6
[13] RSQLite_2.2.1backports_1.1.10 lattice_0.20-41
[16] glue_1.4.2   digest_0.6.27rbibutils_1.3
[19] checkmate_2.0.0  colorspace_1.4-1 sandwich_3.0-0
[22] htmltools_0.5.0  Matrix_1.2-18pkgconfig_2.0.3
[25] purrr_0.3.4  mvtnorm_1.1-1scales_1.1.1
[28] BiocParallel_1.25.0  tibble_3.0.4 generics_0.0.2
[31] IRanges_2.25.0   ggplot2_3.3.2ellipsis_0.3.1
[34] TH.data_1.0-10   BiocGenerics_0.37.0  mnormt_2.0.2
[37] survival_3.2-7   magrittr_1.5 crayon_1.3.4
[40] memoise_1.1.0evaluate_0.14MASS_7.3-53
[43] xml2_1.3.2   graph_1.69.0 tools_4.1.0
[46] data.table_1.13.2gbRd_0.4-11  lifecycle_0.2.0
[49] multcomp_1.4-14  mutoss_0.1-12S4Vectors_0.29.0
[52] munsell_0.5.0plotrix_3.7-8AnnotationDbi_1.53.0
[55] compiler_4.1.0   rlang_0.4.8  grid_4.1.0
[58] rappdirs_0.3.1   startup_0.15.0   multtest_2.47.0
[61] gtable_0.3.0   

Re: [Bioc-devel] Regarding installation of bioconductor version 2.13

[Vincent Carey]

You can install the package, using current R, from the source image at
https://bioconductor.org/packages/3.1/bioc/src/contrib/inSilicoDb_2.4.1.tar.gz

I did this

Then I tried to use it

> getPlatformList()

*Error: Webservice not accessible. Please check your internet connection.:
Error in function (type, msg, asError = TRUE) : Failed to connect to
insilicodb.com  port 443: Connection refused*


*Does the service still exist?  If not, the package will be of little use,
I suspect.*

On Fri, Oct 23, 2020 at 6:37 AM Anamika Thalor 
wrote:

> Dear Sir/Madam,
> I am a PhD student in ICGEB, New Delhi and I am working on GEO datasets and
> for that, I need inSilicoDb package of R. This inSilicoDb package needs
> Bioconductor version 2.13 but I tried every thing but still not able to
> install it on my mac. I installed  R of version 3.0.2 which is required for
> Bioconductor version 2.13 but still getting error. I am attaching my error
> file with the email. Kindly help me in this regard.
>
> --
> Anamika
> Pre-doctoral Fellow
> Translational Bioinformatics Group,
> International Centre for Genetic Engineering and Biotechnology,
> Aruna Asaf Ali Marg, New Delhi - 110067
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R 4.0.3 for Windows R CMD check finds 'abort'

[Vincent Carey]

On Mon, Oct 19, 2020 at 1:41 PM Martin Morgan 
wrote:

> Just to respond that I don't have a clear answer for you; I would guess
> that there is a change upstream of your package, and that the NOTE is
> spurious. If this also occurs on a non-Bioconductor Windows machine then it
> would be appropriate to bring this up on another forum, R-devel or
> R-package-devel (https://stat.ethz.ch/mailman/listinfo/r-package-devel),
> especially if the NOTE can be elicited by a trivial example package. I
> would assume that the NOTE is safe to ignore, but...
>

I was able to reproduce the abort notes using R 4.0.3 with current
rcmdcheck run over the limma_3.44.3.tar.gz on a non-bioconductor
windows machine.  I tried dependency walker on limma.dll there but did not
see any interesting data.  The notes occur with
IRanges on the machine I checked.



>
> I think the 'Dependency walker' utility could be used to investigate the
> DLL to identify where this comes from, but I don't have easy access to a
> Windows machine for this type of work.
>
> Martin Morgan
>
> On 10/16/20, 7:00 PM, "Bioc-devel on behalf of Gordon K Smyth" <
> bioc-devel-boun...@r-project.org on behalf of sm...@wehi.edu.au> wrote:
>
> This is more an R question than a Bioconductor question, but I would
> be grateful if the Biocore team or other Bioc developers have any insight.
>
> After upgrading to R 4.0.3 or R 4.1.0-devel, I find that running R CMD
> check under Windows now gives a worrying Note about .o files and 'abort'.
> The same warning occurs for all the packages I maintain that contain source
> code. The Note does not appear for R 4.0.2 or earlier.
>
> An example of the Note is:
>
> START QUOTE
> * checking compiled code ... NOTE
> Note: information on .o files for x64 is not available
> File
> 'c:/Gordon/software/gitbioc/limma.Rcheck/limma/libs/x64/limma.dll':
>   Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>   Found 'exit', possibly from 'exit' (C), 'stop' (Fortran)
>   Found 'printf', possibly from 'printf' (C)
>
> Compiled code should not call entry points which might terminate R nor
> write to stdout/stderr instead of to the console, nor use Fortran I/O
> nor system RNGs. The detected symbols are linked into the code but
> might come from libraries and not actually be called.
> END QUOTE
>
> I am baffled by the Note because my code does not contain any of the
> offending functions (abort, exit or printf) that the Note accuses me of.
> Surprisingly I can't find any recent chatter about this Note on the R-devel
> mailing list. There no mention of it in the Rtools documentation. I have
> also searched the R manual on Writing R Extensions but can't find anything
> that would cause a Windows-specific note.
>
> I see from the build/check reports for Bioconductor 3.12 that I am not
> alone. The same Note appears in the Windows check logs for a very large
> number of Bioconductor packages, for example Biobase:
>
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/Biobase/riesling1-checksrc.html
>
> I am guessing that the same Note now appears in the Windows check log
> for every Bioconductor package that contains any C or Fortran source code.
> The Note does not appear in the Linux or Mac check logs for the same
> packages.
>
> My questions are:
> 1. Does anyone know what is causing this Note.
> 2. Can I fix the note? If not, can I ignore it?
>
> I also wonder whether this Note will cause the CRAN maintainers to not
> accept my package submissions, but that is perhaps a question for another
> forum.
>
> Thanks for any insights
> Gordon
>
> --
> Professor Gordon K Smyth
> Joint Head, Bioinformatics Division
> Walter and Eliza Hall Institute of Medical Research
>
> ___
>
> The information in this email is confidential and intended solely for
> the addressee.
> You must not disclose, forward, print or use it without the permission
> of the sender.
>
> The Walter and Eliza Hall Institute acknowledges the Wurundjeri people
> of the Kulin
> Nation as the traditional owners of the land where our campuses are
> located and
> the continuing connection to country and community.
> ___
>
> [[alternative HTML version deleted]]
>
> ___
> 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Fwd: Orchid ID invalid according to BiocCheck

[Vincent Carey]

forwarding to bioc-devel

-- Forwarded message -
From: Vincent Carey 
Date: Mon, Oct 19, 2020 at 6:33 AM
Subject: Re: [Bioc-devel] Orchid ID invalid according to BiocCheck
To: Manders-2, F.M. 
Cc: Alessandro Lussana via Bioc-devel 


looks like BiocCheck/checks.R:validID <-
grepl("[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}", orcid)

has to change -- do you have time to determine the correct regex for this
and file a PR?



On Mon, Oct 19, 2020 at 6:31 AM Manders-2, F.M. <
f.m.mand...@prinsesmaximacentrum.nl> wrote:

> Yes, the X is correct (https://orcid.org/-0001-6197-347X). I don’t
> know why I have an X there and not a number.
>
>
>
> *From: *Vincent Carey 
> *Date: *Monday, 19 October 2020 at 12:20
> *To: *"Manders-2, F.M." 
> *Cc: *Alessandro Lussana via Bioc-devel 
> *Subject: *Re: [Bioc-devel] Orchid ID invalid according to BiocCheck
>
>
>
>  person("Freek", "Manders", email = "f.m.mand...@prinsesmaximacentrum.nl",
> role = c("aut"),
> comment = c(ORCID = "-0001-6197-347X")),
>
>
>
> is what I see in a current checkout.  is "X" at the end correct?  maybe
> there is an encoding issue?
>
>
>
> On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. <
> f.m.mand...@prinsesmaximacentrum.nl> wrote:
>
> Hi all,
>
> BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID
> ID for Freek Manders").
> However, I see nothing wrong with the ID. It also seems to work well on
> the dev page of my package (MutationalPatterns)
> Clicking on the green ID circle, sends me to my page just fine.
> Is there a mistake in BiocCheck? Should I just ignore this?
>
> With kind regards,
> Freek Manders
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the
> Partners Compliance HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>

-- 
The information in this e-mail is intended only for the person to whom it 
is
addressed. If you believe this e-mail was sent to you in error and the 
e-mail
contains patient information, please contact the Partners Compliance 
HelpLine at
http://www.partners.org/complianceline 
<http://www.partners.org/complianceline> . If the e-mail was sent to you in 
error
but does not contain patient information, please contact the sender 
and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

[Vincent Carey]

looks like BiocCheck/checks.R:validID <-
grepl("[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}", orcid)

has to change -- do you have time to determine the correct regex for this
and file a PR?



On Mon, Oct 19, 2020 at 6:31 AM Manders-2, F.M. <
f.m.mand...@prinsesmaximacentrum.nl> wrote:

> Yes, the X is correct (https://orcid.org/-0001-6197-347X). I don’t
> know why I have an X there and not a number.
>
>
>
> *From: *Vincent Carey 
> *Date: *Monday, 19 October 2020 at 12:20
> *To: *"Manders-2, F.M." 
> *Cc: *Alessandro Lussana via Bioc-devel 
> *Subject: *Re: [Bioc-devel] Orchid ID invalid according to BiocCheck
>
>
>
>  person("Freek", "Manders", email = "f.m.mand...@prinsesmaximacentrum.nl",
> role = c("aut"),
> comment = c(ORCID = "-0001-6197-347X")),
>
>
>
> is what I see in a current checkout.  is "X" at the end correct?  maybe
> there is an encoding issue?
>
>
>
> On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. <
> f.m.mand...@prinsesmaximacentrum.nl> wrote:
>
> Hi all,
>
> BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID
> ID for Freek Manders").
> However, I see nothing wrong with the ID. It also seems to work well on
> the dev page of my package (MutationalPatterns)
> Clicking on the green ID circle, sends me to my page just fine.
> Is there a mistake in BiocCheck? Should I just ignore this?
>
> With kind regards,
> Freek Manders
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the
> Partners Compliance HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>

-- 
The information in this e-mail is intended only for the person to whom it 
is
addressed. If you believe this e-mail was sent to you in error and the 
e-mail
contains patient information, please contact the Partners Compliance 
HelpLine at
http://www.partners.org/complianceline 
<http://www.partners.org/complianceline> . If the e-mail was sent to you in 
error
but does not contain patient information, please contact the sender 
and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

[Vincent Carey]

 person("Freek", "Manders", email = "f.m.mand...@prinsesmaximacentrum.nl",
role = c("aut"),
comment = c(ORCID = "-0001-6197-347X")),

is what I see in a current checkout.  is "X" at the end correct?  maybe
there is an encoding issue?

On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. <
f.m.mand...@prinsesmaximacentrum.nl> wrote:

> Hi all,
>
> BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID
> ID for Freek Manders").
> However, I see nothing wrong with the ID. It also seems to work well on
> the dev page of my package (MutationalPatterns)
> Clicking on the green ID circle, sends me to my page just fine.
> Is there a mistake in BiocCheck? Should I just ignore this?
>
> With kind regards,
> Freek Manders
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Project-wide code of conduct for Bioconductor

[Vincent Carey]

Bioconductor has published a project-wide code of conduct:
http://bioconductor.org/about/code-of-conduct/. We invite all members of
the community to familiarise themselves with it.

The Bioconductor community values

   - an open approach to science that promotes the sharing of ideas, code,
   and expertise
   - collaboration
   - diversity and inclusivity
   - kindness and a welcoming environment
   - community contributions
   - openness in regard to software implementations

In line with these values, Bioconductor is dedicated to providing a
welcoming, supportive, collegial, and harassment-free experience for
community members (users, developers, conference and workshop attendees
etc.), regardless of:

   - identity: gender, gender identity and expression, sexual orientation,
   disability, physical appearance, ethnicity, body size, race, age, religion,
   etc.
   - intellectual position: approaches to data analysis, software
   preferences, coding style, scientific perspective, etc.
   - stage of career

By participating in this community, you agree to abide by the Code of
Conduct, which applies to both in person and virtual events (e.g. talks,
workshops, poster sessions, social activities) and electronic communication
channels (including but not limited to community-bioc Slack, the support
site, online forums and social media communications).

We do not tolerate harassment, intimidation, or bullying of community
members. Sexual language and imagery are not appropriate in presentations,
communications or in online venues, including chats.

Any person/s violating these rules may be sanctioned or expelled
temporarily or permanently from an electronic platform or event at the
discretion of the Code of Conduct committee.
Examples of unacceptable harassment, intimidation, and bullying behavior.

Harassment includes, but is not limited to:

   - Making comments in chats, to an audience or personally, that belittle
   or demean another person
   - Sharing sexual images online
   - Harassing photography or recording
   - Sustained disruption of talks or other events
   - Unwelcome sexual attention
   - Advocating for, or encouraging, any of the above behavior

Intimidation and bullying include, but are not limited to:

   - Aggressive or browbeating behavior
   - Mocking or insulting another person’s intellect, work, perspective, or
   question/comment
   - Making reference to someone’s gender, gender identity and expression,
   sexual orientation, disability, physical appearance, body size, race, age,
   religion, or other personal attributes in the context of a scientific
   discussion
   - Deliberately making someone feel unwelcome

Enforcement

Anyone asked to stop harassing or intimidating behavior are expected to
comply immediately.

If a person/s engage in harassing behavior, the Code of Conduct committee
retains the right to take any action that ensures a welcoming environment
for all community members. This includes warning the alleged offender or
temporary/permanent expulsion from the event and/or electronic platforms
under Bioconductor’s control.

The Code of Conduct committee may take action to redress anything designed
to, or with the clear impact of, disrupting an event or electronic
communication platform or making the environment hostile for any community
member.

We expect everyone in the Bioconductor community to comply with the Code of
Conduct when participating in Bioconductor events and online communication
platforms.
Reporting

If someone makes you or anyone else feel unsafe or unwelcome, please report
it as soon as possible. You can make a report either anonymously or
personally. All reports will be reviewed by the Code of Conduct Committee
and will be kept confidential.

Electronically

You can make an anonymous or non-anonymous report via the following link:
https://tinyurl.com/bioccomplaint. It is a free-form text box that will be
forwarded to the Code of Conduct Committee. Alternatively you can email the
Code of Conduct Committee (code-of-cond...@bioconductor.org). If you are
uncomfortable reporting to the Code of Conduct committee as a group, you
can contact any individual committee member via email or a direct message
on the community-bioc Slack channel.

We can’t follow up an anonymous report with you directly, but we will fully
investigate it and take whatever action is necessary to prevent a
recurrence.

Personal Report (for any Bioconductor events: in-person or virtual)

You can make a personal report to any member of the event Code of Conduct
committee present at an event.

When taking a personal report, we will ensure you are safe and cannot be
overheard. We may involve other event staff to ensure your report is
managed properly. Once safe, we’ll ask you to tell us about what happened.
This can be upsetting, but we’ll handle it as respectfully as possible, and
you can bring someone to support you. You won’t be asked to confront
anyone, and we won’t tell anyone who you are.

Re: [Bioc-devel] MPFE Bioconductor package

[Vincent Carey]

Thanks Jiefei!  I wanted to acknowledge Conrad's comments too -- we will
discuss them as a group in our monthly technical advisory board meeting to
assess adequacy of documentation and support resources for conditions
like these.  Our project must make use of a variety of technologies to meet
the needs and interests of users and developers, and input from the
community
is vital to ensuring that our materials are up-to-date and sufficiently
detailed
to support independent progress through challenging situations.  Community
inputs
that help to remedy shortcomings in our documents are extremely valuable.


On Fri, Sep 18, 2020 at 12:36 PM Jiefei Wang  wrote:

> Hi Conrad,
>
> Glad to hear that you have solved the problem. Sorry for hearing your bad
> experience, I guess it could be better if you can ask your question in a
> git mailing list(If there is one) because it is really not a package
> administrative problem which the Bioconductor core team is responsible for.
> What Nitesh said does not mean you should sort it out for your self, it
> just means you should ask it in a better place, and he forwarded your email
> to here. Bioc mailing list is mostly for package development, so you can
> get two responses for that(Even though we did not correctly understand your
> question). Please do not feel anxious about it, you are welcome to ask for
> help.
>
> Best,
> Jiefei
>
> On Fri, Sep 18, 2020 at 12:46 PM Conrad Burden 
> wrote:
>
> >
> > Hi guys,
> >
> > It seems to be working now.  There is one warning message, which I
> believe
> > is just to tell me that the package had been "deprecated”  (which
> > apparently does not mean what my Oxford English Dictionary tells me it
> > means).
> >
> > Could you please confirm whether I have to do anything else for it to go
> > into the next release?
> >
> > By the way, I should have pointed out from the beginning that my problem
> > was NOT with debugging the R code.  I had that sorted out almost
> > immediately back in April (but thanks for confirming that you came up
> with
> > the same solution Jiefei).  My problem was with working out how to get
> this
> > trivial 1-line change into the bioconductor system.  If one is not
> already
> > familiar with unix, GitHub, ssh keys, repositories and heaven knows what
> > else, and if one doesn’t know the terminology, the on-liine instructions
> > are impossible to follow, assuming, that is, one can find the right web
> > page to start with.  I was somewhat put off by asking further by the
> > sentence "Unfortunately we are not able to devote time towards individual
> > packages”, which I took to mean “go away, stop bothering us, and sort it
> > out for yourself”.
> >
> > cheers, Conrad.
> >
> > A/Prof. Conrad Burden
> > Mathematical Sciences Institute
> > Building 145
> > Australian National University
> >
> > Phone: 61-2-61250730
> > E-mail: conrad.bur...@anu.edu.au 
> > Web page: http://maths.anu.edu.au/people/conrad-burden
> >
> >
> > On 17 Sep 2020, at 8:36 pm, Jiefei Wang  wrote:
> >
> > Hi Conrad,
> >
> > Just a friendly reminder, there is a bug in your package. Here is the
> > build result from the link you provided:
> >
> > ==
> >  --- Error message ---
> >  --- failure: length > 1 in coercion to logical ---
> >
> >  --- call from argument ---
> > columns < 1 || columns > nColumns
> >
> > --- place where the error occurs ---
> > if (any(columns < 1 || columns > nColumns)) {
> > stop("Column indices must be between 1 and ", nColumns,
> > "\n")
> > }
> > ==
> >
> > The symbol `||` only applies the logical OR on the first element of two
> > operands. Since you need the elementwise comparison, you should use the
> > symbol `|` instead.
> >
> > Best,
> > Jiefei
> >
> >
> >
> > On Thu, Sep 17, 2020 at 2:11 PM Conrad Burden 
> > wrote:
> >
> >>
> >> Hi Matt, Nitesh,
> >>
> >> Thanks for replying quickly and for sending the link to the full check
> >> report, which I had not been able to find.
> >>
> >> I think I have worked out what the problem might be.  I have found the
> >> page “Troubleshooting Build Report” which tells me "Changes pushed to
> >> Bioconductor before 4:45 will be reflected in the following day’s build
> >> report that is posted around 1:00 PM EST”, which I assume is US eastern
> >> standard time.
> >>
> >> I pushed my changes (MPFE v1.5.2) to the Bioconductor repository at
> >> approximately 2:30pm Canberra time yesterday, 16 September, which is
> 12:30
> >> am 16 September on the east coast of the US.   It won’t appear in the
> build
> >> report unitl 1:00pm 17 September US time, which is 3:00am 18 September
> in
> >> Canberra.  I’ll check it again tomorrow.  Sorry to put you to all this
> >> trouble.
> >>
> >> - cheers, Conrad.
> >>
> >> A/Prof. Conrad Burden
> >> Mathematical Sciences Institute
> >> Building 145
> >> Australian National University
> >>
> >> Phone: 61-2-61250730
> >> E-mail: 

Re: [Bioc-devel] Best object structure for representing a pairwise genome alignment ?

[Vincent Carey]

Starting from

PairwiseAlignments-class  package:Biostrings   R Documentation

PairwiseAlignments, PairwiseAlignmentsSingleSubject, and
PairwiseAlignmentsSingleSubjectSummary objects

Description:

 The ‘PairwiseAlignments’ class is a container for storing a set of
 pairwise alignments.

 The ‘PairwiseAlignmentsSingleSubject’ class is a container for
 storing a set of pairwise alignments with a single subject.

 The ‘PairwiseAlignmentsSingleSubjectSummary’ class is a container
 for storing the summary of a set of pairwise alignments.

Usage:

 ## Constructors:
 ## When subject is missing, pattern must be of length 2
 ## S4 method for signature 'XString,XString'
 PairwiseAlignments(pattern, subject,
   type = "global", substitutionMatrix = NULL, gapOpening = 0,
gapExtension = 1)
 ## S4 method for signature 'XStringSet,missing'
 PairwiseAlignments(pattern, subject,
   type = "global", substitutionMatrix = NULL, gapOpening = 0,
gapExtension = 1)
 ## S4 method for signature 'character,character'
 PairwiseAlignments(pattern, subject,
   type = "global", substitutionMatrix = NULL, gapOpening = 0,
gapExtension = 1,
   baseClass = "BString")

...

my question would be whether this is a relevant starting place?  Clearly
the focus is not on coordinates, but perhaps a structure that maintains
genomic content and coordinates together would be of use?


On Fri, Sep 18, 2020 at 2:49 AM Charles Plessy 
wrote:

> Dear Bioc developers,
>
> I am currently analysing pairwise genome alignments with Bioconductor,
> and I represent them with a GRanges object of the first genome,
> containing one element by alignment block, and storing the coordinates
> in the other genome in a metadata column containing another GRanges object.
>
> Something like this.
>
> GRanges object with 36582 ranges and 2 metadata columns:
>seqnames  ranges strand | scorequery
> | 
>[1]   S1 162-550  + |   861XSR:909374-909853
>[2]   S1833-3738  + |  7238XSR:910181-913291
>[3]   S1   3769-4212  + |  1165XSR:913510-913953
>[4]   S1   4246-4381  + |   359XSR:914134-914275
>[5]   S1   4532-5990  + |  2977 chr2:6694031-6695569
>...  ... ...... .   ...  ...
>[36578]  S99 17228-17759  - |   793 chr1:2375870-2376379
>[36579]  S99 16417-16935  - |   632 chr1:2376612-2377077
>[36580]  S99 12370-12759  - |   773 chr1:2379949-2380343
>[36581]  S99   5270-5384  - |   295   chr1:843397-843511
>[36582]  S99   1949-3053  - |  2105   chr1:845358-846326
>---
>
> Using "Pairwise genome alignment" as a keyword in a search engine, I
> found that the packages CNEr is doing something similar, although it
> uses a dedicated "GRangePairs" object for the purpose.
>
> Before I start to invest time in either direction, I wanted to check on
> that mailing list if there were other solutions already existing, in
> particularly closer to the core packages ?
>
> Have a nice day,
>
> Charles
>
> --
> Charles Plessy - - ~ ~ ~ ~ ~  ~ ~ ~ ~ ~ - - charles.ple...@oist.jp
> Okinawa  Institute  of  Science  and  Technology  Graduate  University
> Staff scientist in the Luscombe Unit - ~ - https://groups.oist.jp/grsu
> Toots from work - ~ ~~ ~ - https://mastodon.technology/@charles_plessy
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Question about org.Dr.eg.db package

[Vincent Carey]

This should probably be posed to the support site.  What version of the
package are you using?  Where
are you seeing coordinates?  I would expect those to be obtained from the
TxDb package, or perhaps
from AnnotationHub.

> columns(org.Dr.eg.db)

 [1] "ACCNUM"   "ALIAS""ENSEMBL"  "ENSEMBLPROT"
"ENSEMBLTRANS"

 [6] "ENTREZID" "ENZYME"   "EVIDENCE" "EVIDENCEALL"  "GENENAME"


[11] "GO"   "GOALL""IPI"  "ONTOLOGY"
"ONTOLOGYALL"

[16] "PATH" "PFAM" "PMID" "PROSITE"  "REFSEQ"


[21] "SYMBOL"   "UNIGENE"  "UNIPROT"  "ZFIN"


On Thu, Aug 13, 2020 at 2:13 PM Margolin, Gennady (NIH/NICHD) [C] via
Bioc-devel  wrote:

> Hello,
>
> I have a short question – how do I figure the genome version for
> org.Dr.eg.db package? I couldn’t see it in the DESCRIPTION and also it’s
> not in org.Dr.eg_dbInfo() output. It would be nice to know if this is
> danRer11/GRCz11 or some other assembly, as there are coordinates present in
> the DB.
>
> Thank you,
> Gennady
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] non-conformable arrays

[Vincent Carey]

On Sun, Aug 9, 2020 at 6:57 AM Mikhail Dozmorov 
wrote:

> Thanks, Vincent. If I clone the Bioconductor version
> from g...@git.bioconductor.org:packages/HiCcompare, it builds
> without errors. The version from
> https://github.com/dozmorovlab/HiCcompare.git, which supposed to be
> identical, errors as before - rcmdcheck::rcmdcheck() throws the same
>

"supposed to be identical" but no -- I checked out the one you mention
above, reproduced the error you report with R CMD *build* but
note that the versions in DESCRIPTION are different, and, for example

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/MIK/HiCcompare/R$ diff hic_compare.R
~/BIOC_SOURCES/HiCcompare/R/hic_compare.R
99c99
< A.min <- ceiling(mean(A_q10))
---
> A.min <- mean(A_q10) %>% ceiling()

perhaps there is a branch in your lab repo that needs to be checked out?



  Error: processing vignette 'HiCcompare-vignette.Rmd' failed with diagnostics:
>
> non-conformable arrays
> But the vignette builds using the "Knit" button.
>
> I still don't understand what is going on. The MD5 sums for files in both
> repositories are identical, except some in .git folder. I'll use the
> Bioconductor version and we don't need to dig more since this version
> works. Still, very strange situation.
>
> Thanks again,
> Mikhail
>
> On Sat, Aug 8, 2020 at 7:12 AM Vincent Carey 
> wrote:
>
>> Hi Mikhail -- I cannot reproduce your problem.  I think I need more
>> details as to how
>> your error is triggered.  Using rcmdcheck::rcmdcheck within R as shown in
>> this transcript,
>> on the built tar.gz from the current git checkout master branch, I have
>>
>> ── R CMD check results ── HiCcompare
>> 1.11.0 
>> Duration: 3m 11.5s
>>
>> ❯ checking installed package size ... NOTE
>> installed size is  6.2Mb
>> sub-directories of 1Mb or more:
>>   data   5.6Mb
>>
>> ❯ checking R code for possible problems ... NOTE
>>   .adjust_pval : : no visible binding for global variable
>> ‘p.adj’
>>   .adjust_pval : : no visible binding for global variable
>> ‘p.value’
>>   .adjust_pval: no visible binding for global variable ‘p.value’
>>   .adjust_pval: no visible binding for global variable ‘p.adj’
>>   .calc.diff.thresh: no visible global function definition for ‘sd’
>>   .calc.pval: no visible binding for global variable ‘D’
>>   .calc.pval: no visible binding for global variable ‘p.value’
>>   .calc.pval: no visible binding for global variable ‘p.adj’
>>   .calc.pval: no visible binding for global variable ‘adj.M’
>>   .calc.pval: no visible binding for global variable ‘fold.change’
>>   .calc.pval: no visible binding for global variable ‘adj.IF2’
>>   .calc.pval: no visible binding for global variable ‘adj.IF1’
>>   .calc_z2: no visible global function definition for ‘sd’
>>   .calc_z2: no visible binding for global variable ‘Z’
>>   .calc_z2: no visible global function definition for ‘pnorm’
>>   .calc_z2: no visible binding for global variable ‘p.value’
>>   .loess.matrix: no visible binding for global variable ‘adj.IF1’
>>   .loess.matrix: no visible binding for global variable ‘IF1’
>>   .loess.matrix: no visible binding for global variable ‘adj.IF2’
>>   .loess.matrix: no visible binding for global variable ‘IF2’
>>   .loess.matrix: no visible binding for global variable ‘adj.M’
>>   .loess.matrix: no visible binding for global variable ‘A’
>>   .sim.mat: no visible global function definition for ‘head’
>>   .split_cent: no visible binding for global variable
>> ‘centromere_locations’
>>   .split_cent: no visible binding for global variable ‘start1’
>>   .split_cent: no visible binding for global variable ‘start2’
>>   .split_cent: no visible binding for global variable ‘chr1’
>>   .split_cent: no visible binding for global variable ‘chr2’
>>   MA_norm: no visible binding for global variable ‘D’
>>   MA_norm: no visible binding for global variable ‘M’
>>   MA_norm: no visible binding for global variable ‘adj.IF1’
>>   MA_norm: no visible binding for global variable ‘IF1’
>>   MA_norm: no visible binding for global variable ‘adj.IF2’
>>   MA_norm: no visible binding for global variable ‘IF2’
>>   MA_norm: no visible binding for global variable ‘adj.M’
>>   cooler2sparse: no visible binding for global variable ‘chr1’
>>   cooler2sparse: no visible binding for global variable ‘chr2’
>>   cooler2sparse: no visible binding for global variable ‘IF’
>>   create.hic.table: no visible binding for global variable ‘D’
>>   create.hic.table: no visible binding for global variable ‘r

Re: [Bioc-devel] non-conformable arrays

[Vincent Carey]

Hi Mikhail -- I cannot reproduce your problem.  I think I need more details
as to how
your error is triggered.  Using rcmdcheck::rcmdcheck within R as shown in
this transcript,
on the built tar.gz from the current git checkout master branch, I have

── R CMD check results ── HiCcompare 1.11.0

Duration: 3m 11.5s

❯ checking installed package size ... NOTE
installed size is  6.2Mb
sub-directories of 1Mb or more:
  data   5.6Mb

❯ checking R code for possible problems ... NOTE
  .adjust_pval : : no visible binding for global variable
‘p.adj’
  .adjust_pval : : no visible binding for global variable
‘p.value’
  .adjust_pval: no visible binding for global variable ‘p.value’
  .adjust_pval: no visible binding for global variable ‘p.adj’
  .calc.diff.thresh: no visible global function definition for ‘sd’
  .calc.pval: no visible binding for global variable ‘D’
  .calc.pval: no visible binding for global variable ‘p.value’
  .calc.pval: no visible binding for global variable ‘p.adj’
  .calc.pval: no visible binding for global variable ‘adj.M’
  .calc.pval: no visible binding for global variable ‘fold.change’
  .calc.pval: no visible binding for global variable ‘adj.IF2’
  .calc.pval: no visible binding for global variable ‘adj.IF1’
  .calc_z2: no visible global function definition for ‘sd’
  .calc_z2: no visible binding for global variable ‘Z’
  .calc_z2: no visible global function definition for ‘pnorm’
  .calc_z2: no visible binding for global variable ‘p.value’
  .loess.matrix: no visible binding for global variable ‘adj.IF1’
  .loess.matrix: no visible binding for global variable ‘IF1’
  .loess.matrix: no visible binding for global variable ‘adj.IF2’
  .loess.matrix: no visible binding for global variable ‘IF2’
  .loess.matrix: no visible binding for global variable ‘adj.M’
  .loess.matrix: no visible binding for global variable ‘A’
  .sim.mat: no visible global function definition for ‘head’
  .split_cent: no visible binding for global variable
‘centromere_locations’
  .split_cent: no visible binding for global variable ‘start1’
  .split_cent: no visible binding for global variable ‘start2’
  .split_cent: no visible binding for global variable ‘chr1’
  .split_cent: no visible binding for global variable ‘chr2’
  MA_norm: no visible binding for global variable ‘D’
  MA_norm: no visible binding for global variable ‘M’
  MA_norm: no visible binding for global variable ‘adj.IF1’
  MA_norm: no visible binding for global variable ‘IF1’
  MA_norm: no visible binding for global variable ‘adj.IF2’
  MA_norm: no visible binding for global variable ‘IF2’
  MA_norm: no visible binding for global variable ‘adj.M’
  cooler2sparse: no visible binding for global variable ‘chr1’
  cooler2sparse: no visible binding for global variable ‘chr2’
  cooler2sparse: no visible binding for global variable ‘IF’
  create.hic.table: no visible binding for global variable ‘D’
  create.hic.table: no visible binding for global variable ‘region2’
  create.hic.table: no visible binding for global variable ‘region1’
  create.hic.table: no visible binding for global variable ‘IF2’
  create.hic.table: no visible binding for global variable ‘M’
  create.hic.table: no visible binding for global variable ‘IF1’
  create.hic.table: no visible binding for global variable ‘i’
  create.hic.table: no visible binding for global variable ‘j’
  filter_params: no visible binding for global variable ‘M’
  filter_params: no visible binding for global variable ‘IF1’
  filter_params: no visible binding for global variable ‘IF2’
  filter_params: no visible global function definition for ‘axis’
  full2sparse: no visible binding for global variable ‘IF’
  hic_compare : : no visible binding for global variable
‘p.adj’
  hic_simulate: no visible binding for global variable ‘bias.slope’
  hic_simulate: no visible global function definition for ‘na.omit’
  hicpro2bedpe: no visible binding for global variable ‘chr1’
  hicpro2bedpe: no visible binding for global variable ‘chr2’
  manhattan_plot: no visible binding for global variable ‘bp’
  manhattan_plot: no visible binding for global variable ‘count’
  sim.other.methods: no visible binding for global variable ‘adj.IF1’
  sim.other.methods: no visible binding for global variable ‘IF1’
  sim.other.methods: no visible binding for global variable ‘adj.IF2’
  sim.other.methods: no visible binding for global variable ‘IF2’
  sim.other.methods: no visible binding for global variable ‘adj.M’
  sim.other.methods: no visible binding for global variable ‘M’
  sim.other.methods: no visible global function definition for ‘na.omit’
  sim_matrix: no visible binding for global variable ‘bias.slope’
  total_sum: no visible binding for global variable ‘IF2’
  total_sum: no visible binding for global variable ‘M’
  total_sum: no visible binding for global variable ‘IF1’
  total_sum: no visible binding for global variable ‘chr1’
  volcano: no visible binding for global 

Re: [Bioc-devel] non-conformable arrays

[Vincent Carey]

Hi Mikhail -- would you provide the results of sessionInfo() after the
failure?  Thanks

On Fri, Aug 7, 2020 at 7:08 PM Mikhail Dozmorov 
wrote:

> Dear Bioconductor team,
>
> I am trying to update a package we developed, HiCcompare.
> https://bioconductor.org/packages/HiCcompare/. The package has been
> successfully submitted previously. However, now `R CMD check` throws an
> error:
> E> Quitting from lines 426-427 (HiCcompare-vignette.Rmd)
> E> Error: processing vignette 'HiCcompare-vignette.Rmd' failed with
> diagnostics:
> E> non-conformable arrays
> E> --- failed re-building ‘HiCcompare-vignette.Rmd’
>
> Yet, If I knit the vignette manually, it builds. If I execute the code
> manually, it works. If I install the package from Bioconductor, it also
> works.
>
> I'm working with this package using bioconductor/bioconductor_docker:devel.
> But the strange behavior - vignette knits manually but fails in CMD check -
> persists both in Docker container and on local R installation.
>
> Please advise, where to troubleshoot next.
> Thanks,
> Mikhail
>
> ---
> Mikhail Dozmorov, Ph.D., Blick scholar
> Associate Professor, Department of Biostatistics
> Affiliate, Department of Pathology
> Virginia Commonwealth University
> OCS #738, 830 E. Main St, RVA, 23298
> E-mail:  mikhail.dozmo...@vcuhealth.org
> Phone: 804-827-2055
> https://medschool.vcu.edu/expertise/detail.html?id=mdozmorov
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Resource temporarily unavailable error with rtracklayer

[Vincent Carey]

Can you post an example dataset that triggers the error reproducibly?

On Tue, Jul 14, 2020 at 4:44 AM Charles Plessy 
wrote:

> Hello,
>
> a user of the CAGEr package reported an error that occurs when it calls
> the `export.bw` function of rtracklayer:
>
> rsession: 1730343 1730344 doesn't intersect 1892288 1899678, chromId 6
> chromSize 5022195: Resource temporarily unavailable
> Error in isSingleString(path) : UCSC library operation failed
> In addition: Warning message:
> In isSingleString(path) : Internal error ucsc/bbiWrite.c 414
>
> This is triggered by a GRanges object that has 236595 lines and 13304
> seqlevels.  My attempts to bisect the object to find a defective line
> did not succeed; but it seems important that I keep most of the contents
> to trigger the error.  I therefore wonder if the problem is either the
> number of lines or the number of seqlevels.
>
> Not being very familiar with the BigWig format and the internals of
> rtracklayer, I am a bit lost.
>
> Can somebody suggest me a way to solve the problem ?
>
> Have a nice day,
>
> Charles
>
> R version 4.0.2 (2020-06-22)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux bullseye/sid
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
>
> locale:
>   [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
> LC_TIME=en_GB.UTF-8
>   [4] LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8
> LC_MESSAGES=en_GB.UTF-8
>   [7] LC_PAPER=en_GB.UTF-8   LC_NAME=C  LC_ADDRESS=C
>
> [10] LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8
> LC_IDENTIFICATION=C
>
> attached base packages:
> [1] parallel  stats4stats graphics  grDevices utils datasets
>   methods
> [9] base
>
> other attached packages:
>   [1] CAGEr_1.31.3MultiAssayExperiment_1.15.2
>   [3] SummarizedExperiment_1.19.5 DelayedArray_0.15.6
>   [5] matrixStats_0.56.0  Matrix_1.2-18
>   [7] Biobase_2.49.0  GenomicRanges_1.41.5
>   [9] GenomeInfoDb_1.25.8 IRanges_2.23.10
> [11] S4Vectors_0.27.12   BiocGenerics_0.35.4
>
> loaded via a namespace (and not attached):
>   [1] Rcpp_1.0.5   stringdist_0.9.5.5   lattice_0.20-41
>
>   [4] formula.tools_1.7.1  Rsamtools_2.5.3
> Biostrings_2.57.2
>   [7] gtools_3.8.2 digest_0.6.25R6_2.4.1
>
> [10] plyr_1.8.6   ggplot2_3.3.2pillar_1.4.5
>
> [13] zlibbioc_1.35.0  rlang_0.4.7  rstudioapi_0.11
>
> [16] data.table_1.12.8vegan_2.5-6  splines_4.0.2
>
> [19] BiocParallel_1.23.2  RCurl_1.98-1.2   munsell_0.5.0
>
> [22] compiler_4.0.2   rtracklayer_1.49.3   pkgconfig_2.0.3
>
> [25] mgcv_1.8-31  tidyselect_1.1.0 tibble_3.0.2
>
> [28] GenomeInfoDbData_1.2.3   XML_3.99-0.4 reshape_0.8.8
>
> [31] permute_0.9-5crayon_1.3.4 dplyr_1.0.0
>
> [34] GenomicAlignments_1.25.3 MASS_7.3-51.6bitops_1.0-6
>
> [37] grid_4.0.2   nlme_3.1-148 gtable_0.3.0
>
> [40] lifecycle_0.2.0  magrittr_1.5 scales_1.1.1
>
> [43] KernSmooth_2.23-17   stringi_1.4.6som_0.3-5.1
>
> [46] XVector_0.29.3   ellipsis_0.3.1   generics_0.0.2
>
> [49] vctrs_0.3.1  tools_4.0.2  BSgenome_1.57.4
>
> [52] glue_1.4.1   purrr_0.3.4  colorspace_1.4-1
>
> [55] cluster_2.1.0operator.tools_1.6.3 beanplot_1.2
>
> [58] memoise_1.1.0VGAM_1.1-3
>
> --
> Charles Plessy - - ~ ~ ~ ~ ~  ~ ~ ~ ~ ~ - - charles.ple...@oist.jp
> Okinawa  Institute  of  Science  and  Technology  Graduate  University
> Staff scientist in the Luscombe Unit - ~ - https://groups.oist.jp/grsu
> Toots from work - ~ ~~ ~ - https://mastodon.technology/@charles_plessy
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
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)

[Vincent Carey]

here's my sessionInfo() -- we don't even agree on lipidr version.  I
presently don't have enough disk space to work
on both devel and release so I work only on devel branch.  I'll ask you to
look over the different package versions
and see if you can get closer to mine and then fail to generate error on
example(plot_heatmap)  check BiocManager::valid()

> sessionInfo()

R version 4.0.1 beta (2020-05-28 r78607)

Platform: x86_64-apple-darwin17.0 (64-bit)

Running under: macOS Mojave 10.14.6


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] parallel  stats4stats graphics  grDevices utils datasets

[8] methods   base


other attached packages:

 [1] lipidr_2.3.2SummarizedExperiment_1.19.5

 [3] DelayedArray_0.15.4 matrixStats_0.56.0

 [5] Matrix_1.2-18   Biobase_2.49.0

 [7] GenomicRanges_1.41.5GenomeInfoDb_1.25.2

 [9] IRanges_2.23.10 S4Vectors_0.27.12

[11] BiocGenerics_0.35.4 rmarkdown_2.2


loaded via a namespace (and not attached):

 [1] fastcluster_1.1.25 tidyselect_1.1.0   xfun_0.14

 [4] purrr_0.3.4lattice_0.20-41colorspace_1.4-1

 [7] vctrs_0.3.1generics_0.0.2 htmltools_0.4.0

[10] rlang_0.4.6startup_0.14.1 pillar_1.4.4

[13] glue_1.4.1 RColorBrewer_1.1-2 plyr_1.8.6

[16] GenomeInfoDbData_1.2.3 lifecycle_0.2.0zlibbioc_1.35.0

[19] munsell_0.5.0  gtable_0.3.0   htmlwidgets_1.5.1

[22] codetools_0.2-16   evaluate_0.14  knitr_1.28

[25] forcats_0.5.0  iheatmapr_0.4.12   Rcpp_1.0.4.6

[28] scales_1.1.1   limma_3.45.7   jsonlite_1.6.1

[31] XVector_0.29.2 ggplot2_3.3.1  digest_0.6.25

[34] dplyr_1.0.0ropls_1.21.0   grid_4.0.1

[37] tools_4.0.1bitops_1.0-6   magrittr_1.5

[40] RCurl_1.98-1.2 tibble_3.0.1   crayon_1.3.4

[43] tidyr_1.1.0pkgconfig_2.0.3ellipsis_0.3.1

[46] data.table_1.12.8  R6_2.4.1   compiler_4.0.1

On Wed, Jun 17, 2020 at 6:56 AM Ahmed Mohamed 
wrote:

> Thanks Vincent.
>
> I would like to debug the error, but I still cannot reproduce it.
> SessionInfo, below, shows update to date versions! My Travis build also
> works, with Bioc Devel and iheapmapr 0.4.12 (
> https://travis-ci.org/github/ahmohamed/lipidr/jobs/696329028#L2718). What
> am I missing?
>
> > 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   LC_TIME=en_US.UTF-8
>  [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8LC_MESSAGES=C
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C  LC_ADDRESS=C
> [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] parallel  stats4stats graphics  grDevices utils datasets  
> methods
> [9] base
>
> other attached packages:
>  [1] lipidr_2.3.0SummarizedExperiment_1.19.5 
> DelayedArray_0.15.4
>  [4] matrixStats_0.56.0  Matrix_1.2-18   Biobase_2.49.0
>  [7] GenomicRanges_1.41.5GenomeInfoDb_1.25.2 IRanges_2.23.10
> [10] S4Vectors_0.27.12   BiocGenerics_0.35.4 iheatmapr_0.4.12
> [13] BiocManager_1.30.10
>
> loaded via a namespace (and not attached):
>  [1] fastcluster_1.1.25 tidyselect_1.1.0   xfun_0.14
>  [4] purrr_0.3.4lattice_0.20-41colorspace_1.4-1
>  [7] vctrs_0.3.1generics_0.0.2 htmltools_0.5.0
> [10] yaml_2.2.1 rlang_0.4.6pillar_1.4.4
> [13] glue_1.4.1 RColorBrewer_1.1-2 GenomeInfoDbData_1.2.3
> [16] lifecycle_0.2.0plyr_1.8.6 zlibbioc_1.35.0
> [19] munsell_0.5.0  gtable_0.3.0   htmlwidgets_1.5.1
> [22] knitr_1.28 forcats_0.5.0  Rcpp_1.0.4.6
> [25] scales_1.1.1   limma_3.45.7   jsonlite_1.6.1
> [28] XVector_0.29.2 farver_2.0.3   ggplot2_3.3.1
> [31] digest_0.6.25  dplyr_1.0.0ropls_1.21.0
> [34] grid_4.0.0 tools_4.0.0bitops_1.0-6
> [37] magrittr_1.5   RCurl_1.98-1.2 tibble_3.0.1
> [40] ggdendro_0.1-20tidyr_1.1.0crayon_1.3.4
> [43] pkgconfig_2.0.3MASS_7.3-51.5  ellipsis_0.3.1
> [46] data.table_1.12.8  rstu

Re: [Bioc-devel] lipidr: Unable to reproduce error (possibly from S4Vectors)

[Vincent Carey]

I can reproduce the error, which arises from iheatmapr.  Note that

http://bioconductor.org/checkResults/devel/bioc-LATEST/malbec1-R-instpkgs.html

shows that iheatmapr is 0.4.12 and on my system example(iheatmap) fails
with the
error you showed.  In future please provide sessionInfo() result when
reporting a
problem.

on my system, example(iheatmap) dies in an unexported function
main_heatmap.  iheatmapr is an ropensci
package that depends on S4Vectors.  it may only be tested with the release
version.  You
can see at https://travis-ci.org/github/ropensci/iheatmapr/jobs/698340792 that
iheatmapr
is passing its tests.  i don't know how to determine what packages were
used in the tests.

you might want to condition out your example for now.  perhaps you can
debug iheatmapr against
current S4Vectors and suggest the solution to iheatmapr authors


On Wed, Jun 17, 2020 at 1:26 AM Ahmed Mohamed 
wrote:

> Hi all,
>
> My package "lipidr" has been failing checks for a while, giving the error
> below:
>
> Error in .wrap_in_length_one_list_like_object(value, name, x) :
>   failed to coerce 'list(value)' to a IheatmapPlots object of length 1
>
> (Full report here:
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/lipidr/malbec1-checksrc.html
> )
>
> The error seems to originate from S4Vectors package, which lipidr depends
> on (indirectly through SummarizedExperiment). However, I am completely
> unable to reproduce this error. This is what I did:
> - Installed Bioc-devel docker image
> - run the faulty example alone, as well as devtools::check(), both without
> errors.
> - Ran BiocManager::install(update = TRUE) to pick up updates not propagated
> to the docker image
> - I even installed S4Vector from GitHub, just in case the git checkout is
> ahead of Bioc.
>
> Faulty example:
> https://github.com/ahmohamed/lipidr/blob/master/R/plot.R#L345
>
> Any suggestions would be appreciated.
> Thanks.
> Ahmed.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] GenomicScores: irreproducible build error caused by gwascat

[Vincent Carey]

On Fri, Jun 5, 2020 at 10:24 AM Robert Castelo 
wrote:

> hi Vince,
>
> no worries, i've been finally able to reproduce the error in my computer
> and i'm afraid i'm probably using a deprecated dataset from 'gwascat',
> concretely the one that was stored as
>
> gwascat/data/ebicat37.rda
>
> what would be the replacement for the following kind of operation?
>

The best thing to do from a scientific point of view would likely be

curcat = gwascat::makeCurrentGwascat()

then work with that, which will have GRCh38 coordinates.

It is slow to run makeCurrentGwascat.  You might want to serialize what you
need.
I can't place a snapshot in gwascat as I had in the past because the image
compressed
with xz exceeds 5MB.  Any snapshot has to be in AnnotationHub.  I don't
have a
plan for this at the moment.

There is an object called ebicat_2020_04_30 in the data
folder of gwascat on devel branch.  It is a sample of 5 records from
the full
catalog of that date.  You might be able to use that for what you are
doing; I will
be renaming it to clarify that it is a sample.


>
> data(ebicat37)
> eyersids <- unique(subsetByTraits(ebicat37, tr="Eye color")$SNPS)
> eyersids
>  [1] "rs12913832" "rs7173419"  "rs3002288"  "rs12896399" "rs1408799"
>  [6] "rs12520016" "rs288139"   "rs1667394"  "rs4596632"  "rs12203592"
> [11] "rs16891982" "rs1393350"  "rs1847134"
>
> thanks!
>
> robert.
>
> On 05/06/2020 14:06, Vincent Carey wrote:
>
> I am really sorry about the situation with gwascat and will try to
> straighten it out today.
>
> On Fri, Jun 5, 2020 at 6:27 AM Robert Castelo 
> wrote:
>
>> hi,
>>
>> my package GenomicScores is not building, see:
>>
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicScores/malbec1-buildsrc.html
>>
>> 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 (GenomicScores.Rmd)
>> Error: processing vignette 'GenomicScores.Rmd' failed with diagnostics:
>> object 'ebicat37' not found
>> --- failed re-building ‘GenomicScores.Rmd’
>>
>> 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.6lattice_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.1GenomeInfoDb_1.25.1
>> [11] stats4_4.0.0RSQLite_2.2.0
>> [13] httr_1.4.1  ggplot2_3.3.1
>> [15] pillar_1.4.4zlibbioc_1.35.0
>> [17] rlang_0.4.6 GenomicFeatures_1.41.0
>> [19] pro

Re: [Bioc-devel] GenomicScores: irreproducible build error caused by gwascat

[Vincent Carey]

I am really sorry about the situation with gwascat and will try to
straighten it out today.

On Fri, Jun 5, 2020 at 6:27 AM Robert Castelo 
wrote:

> hi,
>
> my package GenomicScores is not building, see:
>
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicScores/malbec1-buildsrc.html
>
> 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 (GenomicScores.Rmd)
> Error: processing vignette 'GenomicScores.Rmd' failed with diagnostics:
> object 'ebicat37' not found
> --- failed re-building ‘GenomicScores.Rmd’
>
> 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.6lattice_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.1GenomeInfoDb_1.25.1
> [11] stats4_4.0.0RSQLite_2.2.0
> [13] httr_1.4.1  ggplot2_3.3.1
> [15] pillar_1.4.4zlibbioc_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.2biomaRt_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.0SummarizedExperiment_1.19.4
> [39] tibble_3.0.1GenomeInfoDbData_1.2.3
> [41] IRanges_2.23.7  matrixStats_0.56.0
> [43] XML_3.99-0.3crayon_1.3.4
> [45] dplyr_1.0.0 dbplyr_1.4.4
> [47] GenomicAlignments_1.25.1bitops_1.0-6
> [49] rappdirs_0.3.1  grid_4.0.0
> [51] gtable_0.3.0lifecycle_0.2.0
> [53] DBI_1.1.0   magrittr_1.5
> [55] scales_1.1.1stringi_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.0GenomicRanges_1.41.3
> [71] memoise_1.1.0
>
>
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] How I hide non-exported function from the manual

[Vincent Carey]

On Wed, Jun 3, 2020 at 11:48 PM stefano  wrote:

> Hello Community,
>
> I am used to document function although hey are not exported
>
>
I suppose you are talking about tidybulk?  I am somewhat mystified by the
behavior
of

%vjcair> R CMD build tidybulk

* checking for file ‘tidybulk/DESCRIPTION’ ... OK

* preparing ‘tidybulk’:

* checking DESCRIPTION meta-information ... OK

* installing the package to process help pages

* building the PDF package manual

Hmm ... looks like a package

Converting Rd files to LaTeX .

Creating pdf output from LaTeX ...


which produces a 147 page manual, and as you note many

non-user-visible symbols are documented in manual.  I've

never seen the "process help pages" phase in any

of my packages, and I don't know why.


I don't have experience with the RdMacros setting in

DESCRIPTION, and the way S3 methods are being handled

in the package leads, I think, to an excess of Rd

files relative to what you have as visible symbols

in the package namespace.


Perhaps some tidyverse experts can comment.


> ```
> #' Get differential transcription information to a tibble using edgeR.
> #'
> #' @import dplyr
> #' @import tidyr
> #' @import tibble
> #' @importFrom magrittr set_colnames
> #' @importFrom stats model.matrix
> #' @importFrom utils installed.packages
> #' @importFrom utils install.packages
> #' @importFrom purrr when
> #'
> #'
> #' @param .data A tibble
> #' @param .formula a formula with no response variable, referring only to
> numeric variables
> #' @param .sample The name of the sample column
> #' @param .transcript The name of the transcript/gene column
> #' @param .abundance The name of the transcript/gene abundance column
> #' @param .contrasts A character vector. See edgeR makeContrasts
> specification for the parameter `contrasts`. If contrasts are not present
> the first covariate is the one the model is tested against (e.g., ~
> factor_of_interest)
> #' @param method A string character. Either "edgeR_quasi_likelihood" (i.e.,
> QLF), "edgeR_likelihood_ratio" (i.e., LRT)
> #' @param significance_threshold A real between 0 and 1
> #' @param minimum_counts A positive integer. Minimum counts required for at
> least some samples.
> #' @param minimum_proportion A real positive number between 0 and 1. It is
> the threshold of proportion of samples for each transcripts/genes that have
> to be characterised by a cmp bigger than the threshold to be included for
> scaling procedure.
> #' @param fill_missing_values A boolean. Whether to fill missing
> sample/transcript values with the median of the transcript. This is rarely
> needed.
> #' @param scaling_method A character string. The scaling method passed to
> the backend function (i.e., edgeR::calcNormFactors;
> "TMM","TMMwsp","RLE","upperquartile")
> #' @param omit_contrast_in_colnames If just one contrast is specified you
> can choose to omit the contrast label in the colnames.
> #'
> #' @return A tibble with edgeR results
> #'
> get_differential_transcript_abundance_bulk <- function
> [...]
> ```
>
> However this leads to 2 problems
>
> 1) The PDF manual includes many function that are not accessible to the
> user. How can I hide documented non-exported function from the manual
> 2) I receive the Biocheck note. "You have  initialised objects".
> Again how can I document an object without initialising it?
>
> Thanks a lot.
>
> Best wishes.
>
> *Stefano *
>
>
>
> Stefano Mangiola | Postdoctoral fellow
>
> Papenfuss Laboratory
>
> The Walter Eliza Hall Institute of Medical Research
>
> +61 (0)466452544
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] How I hide non-exported function from the manual

[Vincent Carey]

hi stefano

what package are you talking about, what is the exact error message you
are concerned about (please transcribe or copy exactly) and what version of
R are you working with?

thank you


On Wed, Jun 3, 2020 at 11:48 PM stefano  wrote:

> Hello Community,
>
> I am used to document function although hey are not exported
>
> ```
> #' Get differential transcription information to a tibble using edgeR.
> #'
> #' @import dplyr
> #' @import tidyr
> #' @import tibble
> #' @importFrom magrittr set_colnames
> #' @importFrom stats model.matrix
> #' @importFrom utils installed.packages
> #' @importFrom utils install.packages
> #' @importFrom purrr when
> #'
> #'
> #' @param .data A tibble
> #' @param .formula a formula with no response variable, referring only to
> numeric variables
> #' @param .sample The name of the sample column
> #' @param .transcript The name of the transcript/gene column
> #' @param .abundance The name of the transcript/gene abundance column
> #' @param .contrasts A character vector. See edgeR makeContrasts
> specification for the parameter `contrasts`. If contrasts are not present
> the first covariate is the one the model is tested against (e.g., ~
> factor_of_interest)
> #' @param method A string character. Either "edgeR_quasi_likelihood" (i.e.,
> QLF), "edgeR_likelihood_ratio" (i.e., LRT)
> #' @param significance_threshold A real between 0 and 1
> #' @param minimum_counts A positive integer. Minimum counts required for at
> least some samples.
> #' @param minimum_proportion A real positive number between 0 and 1. It is
> the threshold of proportion of samples for each transcripts/genes that have
> to be characterised by a cmp bigger than the threshold to be included for
> scaling procedure.
> #' @param fill_missing_values A boolean. Whether to fill missing
> sample/transcript values with the median of the transcript. This is rarely
> needed.
> #' @param scaling_method A character string. The scaling method passed to
> the backend function (i.e., edgeR::calcNormFactors;
> "TMM","TMMwsp","RLE","upperquartile")
> #' @param omit_contrast_in_colnames If just one contrast is specified you
> can choose to omit the contrast label in the colnames.
> #'
> #' @return A tibble with edgeR results
> #'
> get_differential_transcript_abundance_bulk <- function
> [...]
> ```
>
> However this leads to 2 problems
>
> 1) The PDF manual includes many function that are not accessible to the
> user. How can I hide documented non-exported function from the manual
> 2) I receive the Biocheck note. "You have  initialised objects".
> Again how can I document an object without initialising it?
>
> Thanks a lot.
>
> Best wishes.
>
> *Stefano *
>
>
>
> Stefano Mangiola | Postdoctoral fellow
>
> Papenfuss Laboratory
>
> The Walter Eliza Hall Institute of Medical Research
>
> +61 (0)466452544
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] LazyData in DESCRIPTION file

[Vincent Carey]

> My historical impression: I would say that when lazyData was
> introduced,
> >> it seems to me that the intention was widespread use. It seems to
> me that
> >> the tides have turned against lazy data and the official
> recommendation is
> >> to not use it unless you have good reasons.  One disadvantage with
> >> widespread use of lazyData is that the names of these objects have
> to be
> >> accessible somewhere.
> >>
> >> Note: one thing I have realized very belatedly is that the lazyData
> field
> >> is a boolean, the right statements are one of
> >>   lazyData: TRUE
> >>   lazyData: FALSE
> >> For example, I think it has to be all uppercase.
> >>
> >> Best,
> >> Kasper
> >>
> >> On Wed, Apr 29, 2020 at 6:05 PM Vincent Carey <
> st...@channing.harvard.edu>
> >> wrote:
> >>
> >>> I see this is guideline 7 at
> >>> https://bioconductor.org/developers/package-guidelines/
> >>>
> >>> I have used LazyData: TRUE so that [pkgname]::[entity] can be used
> >>> instead
> >>> of data().  The
> >>> claim that it is "rarely a good thing" and slows down package
> loading can
> >>> be weighed against
> >>> convenience.  I am not sure you should use LazyData to avoid a
> >>> documentation warning
> >>> however.  Can you give more details on what package is generating
> the
> >>> warning?
> >>>
> >>> On Wed, Apr 29, 2020 at 5:34 PM Vinh Tran <
> t...@bio.uni-frankfurt.de>
> >>> wrote:
> >>>
> >>> > Dear Bioc members,
> >>> >
> >>> > I have just encountered a warning during the CHECK that some data
> >>> objects
> >>> > are used in the documents but not in code (e.g. “Variables with
> usage
> >>> in
> >>> > documentation object ‘ppTree’ but not in code"). They are the
> demo
> >>> data,
> >>> > that I am using only in the examples for demonstrate the usage
> of some
> >>> > functions. Adding LazyData: True to the DESCRIPTION can solve
> that
> >>> issue,
> >>> > but according to the package guidelines it is not recommended.
> Could
> >>> you
> >>> > please show me what should I do in this case? The demo data is
> only
> >>> about
> >>> > 15 KB at max.
> >>> >
> >>> > Many thanks for your advices!
> >>> >
> >>> > Best regards,
> >>> > Vinh
> >>> >
> >>> > 
> >>> > Dr. Vinh Tran
> >>> >
> >>> > Dept. for Applied Bioinformatics
> >>> > Inst. for Cell Biology and Neuroscience
> >>> > Goethe University Frankfurt
> >>> >
> >>> > Biologicum, Room 3.209
> >>> > Phone +49 (0)69/798-42118
> >>> >
> >>> >
> >>> > [[alternative HTML version deleted]]
> >>> >
> >>> > ___
> >>> > Bioc-devel@r-project.org mailing list
> >>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>> >
> >>>
> >>> --
> >>> The information in this e-mail is intended only for the
> ...{{dropped:18}}
> >>>
> >>> ___
> >>> Bioc-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>
> >>
> >>
> >> --
> >> Best,
> >> Kasper
> >>
> >>
> >>
> >
> > --
> > Best,
> > Kasper
> >
> >
> >
>
> --
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> ___
> 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
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

[Vincent Carey]

Thanks for checking this out.  I am leaning towards readr::read_tsv which
is very explicit about
untoward content

Browse[2]>

debug: tab = readr::read_tsv(tf)

Browse[2]>

*Parsed with column specification:*

*cols(*

*  .default = col_character(),*

*  `DATE ADDED TO CATALOG` = **col_date(format = "")**,*

*  PUBMEDID = **col_double()**,*

*  DATE = **col_date(format = "")**,*

*  UPSTREAM_GENE_DISTANCE = **col_double()**,*

*  DOWNSTREAM_GENE_DISTANCE = **col_double()**,*

*  MERGED = **col_double()**,*

*  SNP_ID_CURRENT = **col_double()**,*

*  INTERGENIC = **col_double()**,*

*  `P-VALUE` = **col_double()**,*

*  PVALUE_MLOG = **col_double()**,*

*  `OR or BETA` = **col_double()*

*)*

*See spec(...) for full column specifications.*

|=| 100%  114
MB

*Warning: 13 parsing failures.*

*  rowcol   expected actual
file*

*21021 SNP_ID_CURRENT no trailing characters  *
'/var/folders/5_/14ld0y7s0vbg_z0g2c9l8v30gr/T//Rtmpi3B4HE/filecb946948e8fb'*

*25725 SNP_ID_CURRENT no trailing characters  d
'/var/folders/5_/14ld0y7s0vbg_z0g2c9l8v30gr/T//Rtmpi3B4HE/filecb946948e8fb'*

*45770 SNP_ID_CURRENT no trailing characters  b
'/var/folders/5_/14ld0y7s0vbg_z0g2c9l8v30gr/T//Rtmpi3B4HE/filecb946948e8fb'*

*54548 SNP_ID_CURRENT no trailing characters  *
'/var/folders/5_/14ld0y7s0vbg_z0g2c9l8v30gr/T//Rtmpi3B4HE/filecb946948e8fb'*

*54594 SNP_ID_CURRENT no trailing characters  *
'/var/folders/5_/14ld0y7s0vbg_z0g2c9l8v30gr/T//Rtmpi3B4HE/filecb946948e8fb'*

*. .. .. ..
...*

*See problems(...) for more details.*

On Thu, Apr 30, 2020 at 2:29 PM Hervé Pagès  wrote:

> 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 <
> st...@channing.harvard.edu>
> > 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

Re: [Bioc-devel] a day in the life of gwascat

[Vincent Carey]

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
> http://www.ebi.ac.uk/gwas/api/search/downloads/alternative has an
> unclosed quote in a field.
>
>  35265 2019-04-10  30804558Grove J 2019-02-25  Nat Genet
> www.ncbi.nlm.nih.gov/pubmed/30804558I   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:/
>   /www.ebi.ac.uk/efo/EFO_0003756GCST007556  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://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
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

[Vincent Carey]

right, line 35265 of
http://www.ebi.ac.uk/gwas/api/search/downloads/alternative has an unclosed
quote in a field.

 35265 2019-04-10  30804558Grove J 2019-02-25  Nat Genet
www.ncbi.nlm.nih.gov/pubmed/30804558I   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:/   /www.ebi.ac.uk/efo/EFO_0003756
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://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] a day in the life of gwascat

[Vincent Carey]

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://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] LazyData in DESCRIPTION file

[Vincent Carey]

I see this is guideline 7 at
https://bioconductor.org/developers/package-guidelines/

I have used LazyData: TRUE so that [pkgname]::[entity] can be used instead
of data().  The
claim that it is "rarely a good thing" and slows down package loading can
be weighed against
convenience.  I am not sure you should use LazyData to avoid a
documentation warning
however.  Can you give more details on what package is generating the
warning?

On Wed, Apr 29, 2020 at 5:34 PM Vinh Tran  wrote:

> Dear Bioc members,
>
> I have just encountered a warning during the CHECK that some data objects
> are used in the documents but not in code (e.g. “Variables with usage in
> documentation object ‘ppTree’ but not in code"). They are the demo data,
> that I am using only in the examples for demonstrate the usage of some
> functions. Adding LazyData: True to the DESCRIPTION can solve that issue,
> but according to the package guidelines it is not recommended. Could you
> please show me what should I do in this case? The demo data is only about
> 15 KB at max.
>
> Many thanks for your advices!
>
> Best regards,
> Vinh
>
> 
> Dr. Vinh Tran
>
> Dept. for Applied Bioinformatics
> Inst. for Cell Biology and Neuroscience
> Goethe University Frankfurt
>
> Biologicum, Room 3.209
> Phone +49 (0)69/798-42118
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Unit tests pass locally but fail on Bioconductor machines

[Vincent Carey]

I will chime in because the error is a bit obscure.  You serialized
ExpressionSet instances for testing.  In the expected_res
in your tests we have


 ..@ .__classVersion__:Formal class 'Versions' [package "Biobase"] with 1
slot

  .. .. ..@ .Data:List of 4

  .. .. .. ..$ : int [1:3] 3 6 1

  .. .. .. ..$ : int [1:3] 2 46 0

  .. .. .. ..$ : int [1:3] 1 3 0

  .. .. .. ..$ : int [1:3] 1 0 0


which formally encodes the version of R with which the ExpressionSet was

created.  The one created in the test on the

build system will have first list element c(4,0,0)


How to get around this for the long run?  One possibility is to create your

S4 instances from serializations of more basic objects as

part of the test process.

On Tue, Apr 7, 2020 at 7:55 AM Shepherd, Lori 
wrote:

> There are many changes to base R hence the switch from 3.6 to 4.0.   I
> would highly suggest using R 4.0.  There is a R-alpha version now available
> for all platforms with the R - 4.0 release schedule for later this month.
> Please use the R-alpha version .
>
> on CRAN.r-project.org you should see a section
> Sources of R alpha and beta releases (daily snapshots, created only in
> time periods before a planned release) with links to R-alpha for linux.
> There is a link here to R-alpha for mac  http://mac.r-project.org/   and
> one here for windows:
> https://cran.rstudio.com/bin/windows/base/rpatched.html
>
> This should allow you to download the most stable R-4.0 alpha before the
> release at the end of the month.
> Hope this helps.
>
>
>
>
> 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
> Christian Holland 
> Sent: Tuesday, April 7, 2020 7:22 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Unit tests pass locally but fail on Bioconductor
> machines
>
> Hi there,
>
> the unit tests (implemented with testthat) of my package (
> https://github.com/saezlab/dorothea )
> run smoothly on local machines (tested for Linux, Windows and macOS).
> However, on the Bioconductor machines (both Linux and Window) a particular
> test fails. The feature that distinguish this particular test from all
> other (that passed without any problems) is the use of the ExpressionSet
> class from the Biobase package. Locally I am using the Biobase version
> 2.46.0.
>
> You can see the build output from Bioconductor here:
> http://bioconductor.org/spb_reports/dorothea_buildreport_20200407063358.html
> <
> http://bioconductor.org/spb_reports/dorothea_buildreport_20200407063358.html
> >
>
> Is it possible that this error is somehow related to the used R Version?
> Locally I am still using 3.6.2 but if I understand correctly the package is
> build and checked on Bioconductor machines with R version 4.0. So far I
> refrained from installing the development version of R4.0 as it crashed
> RStudio for a colleague of mine.
>
> Many thanks for your support.
>
> Christian
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] news on tidybulk?

[Vincent Carey]

I think "header says it all" may be intended ... the question is whether
it is accepted.   since the package seems to be in error state I am not sure
it can move forward at this time

On Tue, Mar 24, 2020 at 8:22 AM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> Is there a question here? Nothing came through in the body of the email?
>
>
> 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 Stefano
> Mangiola 
> Sent: Tuesday, March 24, 2020 7:28 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] news on tidybulk?
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] news on tidybulk?

[Vincent Carey]

I am weak on finding logs, but at
https://github.com/Bioconductor/Contributions/issues?q=is%3Aissue+is%3Aopen+tidybulk
I see the package is in an error state.  Can you fix that?

On Tue, Mar 24, 2020 at 7:31 AM Stefano Mangiola 
wrote:

>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] proper way to define an S4 method for 'plot'

[Vincent Carey]

I just updated my R and I am getting into trouble with MLInterfaces
maintenance.

> BiocManager::install("MLInterfaces")

*Bioconductor version 3.11 (BiocManager 1.30.10), R Under development
(unstable)*

*  (2020-03-15 r77975)*

*Installing package(s) 'MLInterfaces'*

*Warning: unable to access index for repository
https://cran.rstudio.com/bin/macosx/el-capitan/contrib/4.0
:*

*  cannot open URL
'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/4.0/PACKAGES
'*


  There is a binary version available but the source version is later:

 binary source needs_compilation

MLInterfaces 1.67.2 1.67.5 FALSE


*installing the source package ‘MLInterfaces’*


*trying URL
'https://bioconductor.org/packages/3.11/bioc/src/contrib/MLInterfaces_1.67.5.tar.gz
'*

*Content type 'application/x-gzip' length 1071876 bytes (1.0 MB)*

*==*

*downloaded 1.0 MB*


* installing *source* package ‘MLInterfaces’ ...

** using staged installation

** R

** inst

** byte-compile and prepare package for lazy loading

Error in getGeneric(f, TRUE, envir, package) :

  no generic function found for ‘plot’

Calls:  ... namespaceImportFrom -> .mergeImportMethods ->
 -> getGeneric

recover called non-interactively; frames dumped, use debugger() to view

** help

*** installing help indices

** building package indices

** installing vignettes

** testing if installed package can be loaded from temporary location

Error: package or namespace load failed for ‘MLInterfaces’ in getGeneric(f,
TRUE, envir, package):

 no generic function found for ‘plot’


...


> sessionInfo()

R Under development (unstable) (2020-03-15 r77975)

Platform: x86_64-apple-darwin15.6.0 (64-bit)

Running under: macOS Mojave 10.14.6


Matrix products: default

BLAS:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.0.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


other attached packages:

[1] rmarkdown_2.1


loaded via a namespace (and not attached):

 [1] BiocManager_1.30.10 compiler_4.0.0  startup_0.14.0

 [4] tools_4.0.0 htmltools_0.4.0 Rcpp_1.0.3

 [7] codetools_0.2-16knitr_1.28  xfun_0.12

[10] digest_0.6.25   rlang_0.4.5 evaluate_0.14

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Class for differentially expressed genes?

[Vincent Carey]

On Mon, Mar 9, 2020 at 6:58 AM Roman Hillje via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hi all,
>
> I was wondering if there is a class for results of differential gene
> expression analysis. I couldn’t find anything generic. Perhaps it’s too
> similar to a simple data frame, but I like the idea of having a consistent
> format. I would imagine something that holds gene names, statistics (logFC,
> p-value, adjusted p-value), plus optional information, e.g. the percent of
> cells expressing a gene (in the context of scRNA-seq). This could then be
> attached to an SCE object (“metadata" slot) to keep all results together.
> I’m probably making things too complicated and should just use a simple
> data frame but wanted to be sure that I’m not missing any existing
> solution. I’d appreciate if you share your advice. Thank you!
>

IMHO it is always profitable to consider the methods desired before
designing a class.  My sense of how this has
proceeded to date starts with limma: data+design -> lmFit -> eBayes ->
topTable(contrast) ... schematically, this has been
an adequate approach to generating and working with DE statistics for some
time.  For DESeq2 a function called
results() is used to acquire statistics on DE.

There are aspects of asking for and interpreting results DE analyses that
could be made more systematic and
perhaps shared among packages so that users have a more consistent and
informative experience in this
domain ... sketching out the key actions may be the place to start.  Just
my 2c.


> Cheers,
> Roman
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] MRD measurements in Leukemic patients using NGS data in r

[Vincent Carey]

This has been a very interesting and illuminating dialogue but it really
should be moved to
support.bioconductor.org so that a record is available to the general user
community.

The solution here
> library(Homo.sapiens)
Error in library(Homo.sapiens) :
  there is no package called ‘Homo.sapiens’

is BiocManager::install("Homo.sapiens")

On Sun, Mar 8, 2020 at 6:22 AM Mulder, R  wrote:

> Dear Tim,
>
>
> Thanks again for your (quick) reply.
>
>
> I just ran it on my computer and it gave me some results but also several
> errors.
>
>
> The first part went perfect
>
>
> > BamFiles <- BamFileList(lapply(list.files(pattern=".bam$"), BamFile))
> > names(BamFiles) <- sapply(strsplit(list.files(pattern=".bam$"), "\\."),
> `[`, 1)
> > show(BamFiles)
> BamFileList of length 2
> names(2): here were my 2 files named without bam extension
>
> However the second part did give results but also several errors
>
> > library(Homo.sapiens)
> Error in library(Homo.sapiens) :
>   there is no package called ‘Homo.sapiens’
> > gxs <- genes(Homo.sapiens)
> Error in genes(Homo.sapiens) : could not find function "genes"
> > names(gxs)  <- mapIds(Homo.sapiens, names(gxs), "SYMBOL", "ENTREZID")
> Error in mapIds(Homo.sapiens, names(gxs), "SYMBOL", "ENTREZID") :
>   could not find function "mapIds"
> > SomeGenes <- gxs[ c("HRAS", "WT1", "IGF2") ]
> Error: object 'gxs' not found
> >
> > sbparam <- ScanBamParam(which=SomeGenes)
> Error in ScanBamParam(which = SomeGenes) : object 'SomeGenes' not found
> > puparam <- PileupParam(max_depth=1e3, min_nucleotide_depth=5,
> +include_insertions=TRUE, min_minor_allele_depth=1)
> > piles <- lapply(BamFiles, pileup, ScanBamParam=sbparam,
> PileupParam=puparam)
> >
> > filterInvariant <- function(x) {
> + positions <- subset(x, duplicated(pos))$pos
> + subset(x, pos %in% positions)
> + }
> > show(do.call(rbind, lapply(lapply(piles, filterInvariant), head, 2)))
>   seqnames  pos strand nucleotide count
> myfile11 36931671  +  A   251
> myfile1 1 36931671  +  G 2
> myfile2   1 36931673  +  - 1
> myfile2   1 36931673  +  A   253
>
>
> Error in library(Homo.sapiens) :
>   there is no package called ‘Homo.sapiens’
>
> For this error I installed the package BSgenome.Hsapiens.UCSC.hg19 and ran
> it again, but the errors at the next operations remained.
>
> > gxs <- genes(Homo.sapiens)
> Error in genes(Homo.sapiens) : could not find function "genes"
>
> Renaming Homo.sapiens as BSgenome.Hsapiens.UCSC.hg19 did not work. Should
> I look up how this genome is called?
>
>
> > names(gxs)  <- mapIds(Homo.sapiens, names(gxs), "SYMBOL", "ENTREZID")
> Error in mapIds(Homo.sapiens, names(gxs), "SYMBOL", "ENTREZID") :
>   could not find function "mapIds"
>
> Where can I find this function?
>
> > SomeGenes <- gxs[ c("HRAS", "WT1", "IGF2") ]
> Error: object 'gxs' not found
>
> Does this have to do with the fact that IGF2 is not included in my panel?
>
> > sbparam <- ScanBamParam(which=SomeGenes)
> Error in ScanBamParam(which = SomeGenes) : object 'SomeGenes' not found
>
> As a result of the previous error, right?
>
> Interestingly enough, I did get results. Why?
>
>
>
> 
> Van: Tim Triche, Jr. 
> Verzonden: zaterdag 7 maart 2020 22:28
> Aan: Mulder, R
> CC: bioc-devel@r-project.org
> Onderwerp: Re: [Bioc-devel] MRD measurements in Leukemic patients using
> NGS data in r
>
> something like this perhaps?
>
> library(Rsamtools)
> BamFiles <- BamFileList(lapply(list.files(pattern=".bam$"), BamFile))
> names(BamFiles) <- sapply(strsplit(list.files(pattern=".bam$"), "\\."),
> `[`, 1)
> show(BamFiles)
> #BamFileList of length 14
> #names(14): Normal_0813_S19_R1_001 Normal_2013_S18_R1_001 ... REMC_CD19
> REMC_CD3
>
> library(Homo.sapiens)
> gxs <- genes(Homo.sapiens)
> names(gxs)  <- mapIds(Homo.sapiens, names(gxs), "SYMBOL", "ENTREZID")
> SomeGenes <- gxs[ c("HRAS", "WT1", "IGF2") ]
>
> sbparam <- ScanBamParam(which=SomeGenes)
> puparam <- PileupParam(max_depth=1e3, min_nucleotide_depth=5,
>include_insertions=TRUE, min_minor_allele_depth=1)
> piles <- lapply(BamFiles, pileup, ScanBamParam=sbparam,
> PileupParam=puparam)
>
> filterInvariant <- function(x) {
>   positions <- subset(x, duplicated(pos))$pos
>   subset(x, pos %in% positions)
> }
> show(do.call(rbind, lapply(lapply(piles, filterInvariant), head, 2)))
> #   seqnames pos strand nucleotide count
> # Normal_0813_S19_R1_001.43chr11 1979973  -  C 1
> # Normal_0813_S19_R1_001.44chr11 1979973  +  T 1
> # Normal_2013_S18_R1_001.16chr11 1979889  +  T 3
> # Normal_2013_S18_R1_001.17chr11 1979889  -  T 1
> # Normal_2714_S20_R1_001.4 chr11 1979933  +  A 1
> # Normal_2714_S20_R1_001.5 chr11 1979933  -  A 1
> # P01-00020-T06-P-cfDNA.21 

Re: [Bioc-devel] Biostrings: unicode character ("compact ellipsis") in print()/show() output (2nd attempt, rephrased)

[Vincent Carey]

you are not wrong ... thanks for pointing this out

https://github.com/Bioconductor/Biostrings/pull/33



On Sat, Mar 7, 2020 at 2:33 PM Shepherd, Lori 
wrote:

> I could be wrong but I think there is an open issue and PR already
> submitted that might be related.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* Bioc-devel  on behalf of
> Vincent Carey 
> *Sent:* Saturday, March 7, 2020 12:58:57 PM
> *To:* Ulrich Bodenhofer 
> *Cc:* bioc-devel@r-project.org ; Kurt Hornik <
> kurt.hor...@wu.ac.at>
> *Subject:* Re: [Bioc-devel] Biostrings: unicode character ("compact
> ellipsis") in print()/show() output (2nd attempt, rephrased)
>
> I have a feeling that the best way to get action here will be to file an
> issue
> and perhaps a PR at https://github.com/Bioconductor/Biostrings
>
> On Sat, Mar 7, 2020 at 7:12 AM Ulrich Bodenhofer  >
> wrote:
>
> > Dear colleagues,
> >
> > As noted in my previous message, I have encountered problems with the
> > new way of displaying sequences/sequence sets that now use a UTF-8
> > ellipsis character (internally defined as R object 'compact_ellipsis' in
> > the package) when the output is included in a LaTeX document (which
> > happens when printing biological sequences via the 'Biostrings' package
> > inside LaTeX-based Sweave or knitr documents). My question again: Is
> > there any special measure that I can take to counteract this issue?
> > (e.g. like loading \usepackage[xxx]{inputenc} in the vignette, setting
> > an option, or manually refining 'compact_ellipsis') Is there a way that
> > the users can revert to the old-style dots for such cases?
> >
> > As a sidenote: this causes the building of my package 'apcluster' to
> > break on a non-UTF-8 locale
> > (
> >
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/apcluster-00check.html
> ),
> >
> > but leads to warnings also in a UTF-8 locale.
> >
> > Any help is gratefully appreciated, thanks so much in advance!
> >
> > Best regards,
> > Ulrich
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> --
> The information in this e-mail is intended only for the ...{{dropped:18}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> 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.

-- 
The information in this e-mail is intended only for the person to whom it 
is
addressed. If you believe this e-mail was sent to you in error and the 
e-mail
contains patient information, please contact the Partners Compliance 
HelpLine at
http://www.partners.org/complianceline 
<http://www.partners.org/complianceline> . If the e-mail was sent to you in 
error
but does not contain patient information, please contact the sender 
and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Biostrings: unicode character ("compact ellipsis") in print()/show() output (2nd attempt, rephrased)

[Vincent Carey]

I have a feeling that the best way to get action here will be to file an
issue
and perhaps a PR at https://github.com/Bioconductor/Biostrings

On Sat, Mar 7, 2020 at 7:12 AM Ulrich Bodenhofer 
wrote:

> Dear colleagues,
>
> As noted in my previous message, I have encountered problems with the
> new way of displaying sequences/sequence sets that now use a UTF-8
> ellipsis character (internally defined as R object 'compact_ellipsis' in
> the package) when the output is included in a LaTeX document (which
> happens when printing biological sequences via the 'Biostrings' package
> inside LaTeX-based Sweave or knitr documents). My question again: Is
> there any special measure that I can take to counteract this issue?
> (e.g. like loading \usepackage[xxx]{inputenc} in the vignette, setting
> an option, or manually refining 'compact_ellipsis') Is there a way that
> the users can revert to the old-style dots for such cases?
>
> As a sidenote: this causes the building of my package 'apcluster' to
> break on a non-UTF-8 locale
> (
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/apcluster-00check.html),
>
> but leads to warnings also in a UTF-8 locale.
>
> Any help is gratefully appreciated, thanks so much in advance!
>
> Best regards,
> Ulrich
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] how to trace 'Matrix' as package dependency for 'GenomicScores'

[Vincent Carey]

nd to disjoint
> graphs and 1 to identical ones.
>
> from these numbers i can see that, for instance, i'm importing just one
> function call from 'BSgenome' (about 1% of its functionality), while the
> dependency burden of 'BSGenome' overlaps more than 1/3 of the total
> burden of the package. this is to me a good candidate to explore in the
> following two steps.
>
> 2.let's say we want to investigate what function calls are responsible
> for the dependency on "BSgenome"
>
> funCalls2Dep("GenomicScores", "BSgenome", db)
> # A tibble: 1 x 3
> # Groups:   pkg [1]
>pkg  fun n
>   
> 1 BSgenome referenceGenome 4
>
> so i'm using a function or method called "referenceGenome" imported from
> "BSgenome"
>
> 3. we want now to see what lines in our code contain those function
> calls (assuming we're in the source path of the package "GenomicScores"):
>
> lines <- funCalls2Dep("GenomicScores", "BSgenome", db, ".", "R")
> head(lines, 2)
> [[1]]
> R/makeGScoresPackage.R:60:68: warning: BSgenome::referenceGenome
> organism(gsco),
> providerVersion(referenceGenome(gsco))),
>
> ^~~
>
> [[2]]
> R/makeGScoresPackage.R:69:49: warning: BSgenome::referenceGenome
>GENOMEVERSION=providerVersion(referenceGenome(gsco)),
>  ^~~
>
> here i'm using the release version of R because otherwise, as i said
> before, some of the function calls to the 'itdepends' package break.
>
>
> i'd be happy to pull-request this code, with the necessary adaptations,
> wherever the community feels is more appropriate, but i'd say that the
> problem with 'itdepends' and R-devel should be fixed first, and then we
> can decide if this is something we want to incorporate into an API and
> from what package.
>
> cheers,
>
> robert.
>
> On 2/9/20 5:01 PM, Sean Davis wrote:
> > There are some good ideas here that would provide enhancement to
> > BiocPkgTools. I don't have the bandwidth to incorporate right now, but
> > filing issues or a pull request with a skeleton would be helpful to keep
> > track.
> >
> > Sean
> >
> > On Sun, Feb 9, 2020 at 7:31 AM Vincent Carey  >
> > wrote:
> >
> >> On Sat, Feb 8, 2020 at 12:02 PM Martin Morgan 
> >> wrote:
> >>
> >>> I find it quite interesting to identify formal strategies for removing
> >>> dependencies, but also a little outside my domain of expertise. This
> code
> >>>
> >>
> >> It would be nice to collect the ideas in this thread into some
> >> recommendations.  The themes I am thinking of
> >> are "how developers can make their packages robust to loss of external
> >> packages" and "how can the
> >> Bioc ecosystem best deal with departures of packages from itself and
> from
> >> CRAN?"  A good and well-adopted
> >> solution to the first one makes the second one moot.
> >>
> >> Two CRAN-related events I know of that required some effort are
> (temporary)
> >> loss of ashr and (recently)
> >> archiving of Seurat.
> >>
> >>
> >>> library(tools)
> >>> library(dplyr)
> >>>
> >>> ## non-base packages the user requires for GenomicScores
> >>> deps <- package_dependencies("GenomicScores", db, recursive=TRUE)[[1]]
> >>> deps <- intersect(deps, rownames(db))
> >>>
> >>> ## only need the 'universe' of GenomicScores dependencies
> >>> db1 <- db[c("GenomicScores", deps),]
> >>>
> >>> ## sub-graph of packages between each dependency and GenomicScores
> >>> revdeps <- package_dependencies(deps, db1, recursive = TRUE, reverse =
> >>> TRUE)
> >>>
> >>> tibble(
> >>>  package = names(olap),
> >>>  n_remove = lengths(revdeps),
> >>> ) %>%
> >>>  arrange(n_remove)
> >>>
> >>> produces a tibble
> >>>
> >>> # A tibble: 106 x 2
> >>> package   n_remove
> >>> 
> >>>   1 BSgenome 1
> >>>   2 AnnotationHub1
> >>>   3 shinyjs  1
> >>>   4 DT   1
> >>>   5 shinycustomloader1
> >>>   6 data.table   1
> &

Re: [Bioc-devel] how to trace 'Matrix' as package dependency for 'GenomicScores'

[Vincent Carey]

On Sat, Feb 8, 2020 at 12:02 PM Martin Morgan 
wrote:

> I find it quite interesting to identify formal strategies for removing
> dependencies, but also a little outside my domain of expertise. This code
>

It would be nice to collect the ideas in this thread into some
recommendations.  The themes I am thinking of
are "how developers can make their packages robust to loss of external
packages" and "how can the
Bioc ecosystem best deal with departures of packages from itself and from
CRAN?"  A good and well-adopted
solution to the first one makes the second one moot.

Two CRAN-related events I know of that required some effort are (temporary)
loss of ashr and (recently)
archiving of Seurat.


> library(tools)
> library(dplyr)
>
> ## non-base packages the user requires for GenomicScores
> deps <- package_dependencies("GenomicScores", db, recursive=TRUE)[[1]]
> deps <- intersect(deps, rownames(db))
>
> ## only need the 'universe' of GenomicScores dependencies
> db1 <- db[c("GenomicScores", deps),]
>
> ## sub-graph of packages between each dependency and GenomicScores
> revdeps <- package_dependencies(deps, db1, recursive = TRUE, reverse =
> TRUE)
>
> tibble(
> package = names(olap),
> n_remove = lengths(revdeps),
> ) %>%
> arrange(n_remove)
>
> produces a tibble
>
> # A tibble: 106 x 2
>package   n_remove
>
>  1 BSgenome 1
>  2 AnnotationHub1
>  3 shinyjs  1
>  4 DT   1
>  5 shinycustomloader1
>  6 data.table   1
>  7 shinythemes  1
>  8 rtracklayer  2
>  9 BiocFileCache2
> 10 BiocManager  2
> # … with 96 more rows
>
> shows me, via n_remove, that I can remove the dependency on AnnotationHub
> by removing the dependency on just one package (AnnotationHub!), but to
> remove BiocFileCache I'd also have to remove another package
> (AnnotationHub, I'd guess). So this provides some measure of the ease with
> which a package can be removed.
>
> I'd like a 'benefit' column, too -- if I were to remove AnnotationHub, how
> many additional packages would I also be able to remove, because they are
> present only to satisfy the dependency on AnnotationHub? More generally,
> perhaps there is a dependency of AnnotationHub that is only used by
> AnnotationHub and BSgenome. So removing AnnotationHub as a dependency would
> make it easier to remove BSgenome, etc. I guess this is a graph
> optimization problem.
>
> Probably also worth mentioning the itdepends package (
> https://github.com/r-lib/itdepends), which I think tries primarily to
> determine the relationship between package dependencies and lines of code,
> which seems like complementary information.
>
> Martin
>
> On 2/6/20, 12:29 PM, "Robert Castelo"  wrote:
>
> true, i was just searching for the shortest path, we can search for
> all
> simple (i.e., without repeating "vertices") paths and there are up to
> five routes from "GenomicScores" to "Matrix"
>
> igraph::all_simple_paths(igraph::igraph.from.graphNEL(g),
> from="GenomicScores", to="Matrix", mode="out")
> [[1]]
> + 7/117 vertices, named, from 04133ec:
> [1] GenomicScoresBSgenome rtracklayer
> [4] GenomicAlignmentsSummarizedExperiment DelayedArray
> [7] Matrix
>
> [[2]]
> + 6/117 vertices, named, from 04133ec:
> [1] GenomicScoresBSgenome rtracklayer
> [4] GenomicAlignmentsSummarizedExperiment Matrix
>
> [[3]]
> + 6/117 vertices, named, from 04133ec:
> [1] GenomicScores DTcrosstalk ggplot2   mgcv
> [6] Matrix
>
> [[4]]
> + 6/117 vertices, named, from 04133ec:
> [1] GenomicScoresrtracklayer  GenomicAlignments
> [4] SummarizedExperiment DelayedArray Matrix
>
> [[5]]
> + 5/117 vertices, named, from 04133ec:
> [1] GenomicScoresrtracklayer  GenomicAlignments
> [4] SummarizedExperiment Matrix
>
> this is interesting, because it means that if i wanted to get rid of
> the
> "Matrix" dependence i'd need to get rid not only of the "rtracklayer"
> dependence but also of "BSgenome" and "DT".
>
> robert.
>
>
> On 2/6/20 5:41 PM, Martin Morgan wrote:
> > Excellent! I think there are other, independent, paths between your
> immediate dependents...
> >
> > RBGL::sp.between(g, start="DT", finish="Matrix",
> detail=TRUE)[[1]]$path_detail
> > [1] "DT""crosstalk" "ggplot2"   "mgcv"  "Matrix"
> >
> > ??
> >
> > Martin
> >
> > On 2/6/20, 10:47 AM, "Robert Castelo" 
> wrote:
> >
> >  hi Martin,
> >
> >  thanks for hint!! i wasn't aware of
> 'tools::package_dependencies()',
> >  adding a bit of graph sorcery i get the result i was looking
> for:
> >
> >  repos <- BiocManager::repositories()[c(1,5)]
> >  repos
> > 

Re: [Bioc-devel] Compatibility of Bioconductor with tidyverse S3 classes/methods

[Vincent Carey]

On Fri, Feb 7, 2020 at 6:39 PM stefano  wrote:

> Thanks Guys for the discussion (I am learning a lot),
>
> *To Martin:*
>
> Thanks for the tips. I will start to implement those S4 style methods
> https://github.com/stemangiola/ttBulk/issues/7
>
> I would *really *like to be part of Bioconductor community with this
> package, if just this
>
> > " One would expect the vignette and examples to primarily emphasize the
> use of the interoperable (SummmarizedExperiment) version. "
>
> Could become this
>
> > One would expect the vignette and examples to emphasize the use of the
> interoperable (SummmarizedExperiment) version.
>
> I agree with the integration priority of Bioconductor, but this repository
> (and this philosophy) is more than its data structures. There should be
> space for more than one approach to do things, given that the principle are
> respected.
>
> If this is true, I could really spend energies to use methods as you
> suggested and implement the SummarisedExperiment stream. And with the tips
> of the community the link will become stronger and stronger with time and
> versions.
>
>
> *To Vincent*
>
> Thanks a lot for the interest.
>
> *> One thing I feel is missing is an approach to the following question:
> [..] How do I make one that works the way ttBulk's operators work?*
>
> I'm afraid I don't really understand the question. Are you wondering about
> extension of the framework? Or creating a similar framework for other
> applications? Could you please reformulate, maybe giving a concrete
> example?
>

We can take further discussion to the issues on the github repo but I will
briefly respond here.  Consider reduce_dimensions.
You give a small number of method options here -- PCA, MDS, tSNE.  The MDS
option makes its way to stats::cmdscale via limma::plotMDS;
the PCA option uses prcomp.  For any number of reasons, users may want to
select alternate dimension reduction procedures or
tune them in ways not passed up through your interface.  This might involve
modifications to your code to introduce changes, or
one could imagine a protocol for "dropping in" a new operator for ttBulk
pipelines.  My question is to understand how this level
of flexibility might be achieved.

An example of an R package that pursues this is mlr3, see
https://github.com/mlr-org/mlr3learners.template ... a link there is broken
but the full details of contributing new pipeline elements are at
https://mlr3book.mlr-org.com/pipelines.html


> *> Are there patterns there that are preserved across different operators?
> *
>
> A commonality is the use of code for integrating the new calculated
> information (dplyr), validation functions, ..
>
> *> Can they be factored out to improve maintainability?*
>
> Almost surely yes, this is the first version, I hope to see enough
> interest, improve the API upon feedback, and hope for (intellectual and
> practical) contributions from more experts in software engineering.
>
> *> validObject *
>
> Seems a good method, and as far as I tested works for S3 objects as well.
> I will try to implement it. In fact I already added it as issue into Github
> https://github.com/stemangiola/ttBulk/issues/6
>
> At the moment I have a custom validation function
>
> Best wishes.
>
> *Stefano *
>
>
>
> Stefano Mangiola | Postdoctoral fellow
>
> Papenfuss Laboratory
>
> The Walter Eliza Hall Institute of Medical Research
>
> +61 (0)466452544
>
>
> Il giorno sab 8 feb 2020 alle ore 01:54 Vincent Carey <
> st...@channing.harvard.edu> ha scritto:
>
>> This is an interesting discussion and I hope it is ok to continue it a
>> bit.  I found the
>> readme for the ttBulk repo extremely enticing and I am sure many people
>> will want to
>> explore this way of working with genomic data.  I have only a few moments
>> to explore
>> it and did not read the vignette, but it looks to me as if it is mostly
>> recapitulated in the
>> README, which is an excellent overview.
>>
>> One thing I feel is missing is an approach to the following question: I
>> like the
>> idea of a pipe-oriented operator for programming steps in genomic
>> workflows.
>> How do I make one that works the way ttBulk's operators work?  Well, I can
>> have a look at ttBulk:::reduce_dimensions.ttBulk ...
>>
>> It's involved.  Are there patterns there that
>> are preserved across different operators?  Can
>> they be factored out to improve maintainability?
>>
>> One other point before I run
>>
>> It seems to me the operators "require" that certain
>> fields be defined in their tibble operands.
>>
>

Re: [Bioc-devel] Annotation for Lactuca sativa (Lettuce)

[Vincent Carey]

You'll need a current version of R and the AnnotationHub package
installed.  Then

> library(AnnotationHub)

ah *5/39 packages newly attached/loaded, see sessionInfo() for details.*

> ah = AnnotationHub()

*snapshotDate(): 2019-12-26*

> query(ah, "sativa")

AnnotationHub with 7 records

# snapshotDate(): 2019-12-26

# $dataprovider: ftp://ftp.ncbi.nlm.nih.gov/gene/DATA/, Inparanoid8

# $species: Oryza sativa_subsp._japonica, Oryza sativa_Japonica_Group,
Oryza...

# $rdataclass: OrgDb, Inparanoid8Db

# additional mcols(): taxonomyid, genome, description,

#   coordinate_1_based, maintainer, rdatadateadded, preparerclass, tags,

#   rdatapath, sourceurl, sourcetype

# retrieve records with, e.g., 'object[["AH10561"]]'


title

  AH10561 | hom.Oryza_sativa.inp8.sqlite

  AH75771 | org.Camelina_sativa.eg.sqlite

  AH75823 | org.Lactuca_sativa.eg.sqlite

  AH75915 | org.Oryza_sativa_(japonica_cultivar-group).eg.sqlite

  AH75916 | org.Oryza_sativa_Japonica_Group.eg.sqlite

  AH75917 | org.Oryza_sativa_subsp._japonica.eg.sqlite

  AH76047 | org.Cannabis_sativa.eg.sqlite


What then do we have?


> lett = ah[["AH75823"]]

*downloading 1 resources*

*retrieving 1 resource*

*  |==|
100%*


*loading from cache*

*Loading required package: AnnotationDbi*

*Loading required package: stats4*

*Loading required package: Biobase*

*Welcome to Bioconductor*


*Vignettes contain introductory material; view with*

*'browseVignettes()'. To cite Bioconductor, see*

*'citation("Biobase")', and for packages 'citation("pkgname")'.*



*Attaching package: ‘Biobase’*


*The following object is masked from ‘package:AnnotationHub’:*


*cache*


*Loading required package: IRanges*

*Loading required package: S4Vectors*


*Attaching package: ‘S4Vectors’*


*The following object is masked from ‘package:base’:*


*expand.grid*



> lett

OrgDb object:

| DBSCHEMAVERSION: 2.1

| DBSCHEMA: NOSCHEMA_DB

| ORGANISM: Lactuca sativa

| SPECIES: Lactuca sativa

| CENTRALID: GID

| Taxonomy ID: 4236

| Db type: OrgDb

| Supporting package: AnnotationDbi


*Please see: help('select') for usage information*

> keys(lett)[1:10]

 [1] "3772783" "3772784" "3772785" "3772786" "3772787" "3772788" "3772789"

 [8] "3772790" "3772791" "3772792"

> select(lett, keys=.Last.value, columns="GENENAME")

*'select()' returned 1:1 mapping between keys and columns*

   GID   GENENAME

1  3772783   Ycf2

2  3772784   Ycf2

3  3772785   ribosomal protein S4

4  3772786  envelope membrane protein

5  3772787  ribosomal protein S14

6  3772788  photosystem II protein D1

7  3772789 photosystem I P700 chlorophyll a apoprotein A2

8  3772790  ribosomal protein S15

9  3772791   photosystem II protein K

10 3772792  ribosomal protein L20

> columns(lett)

 [1] "ACCNUM"  "ALIAS"   "CHR" "ENTREZID""EVIDENCE"

 [6] "EVIDENCEALL" "GENENAME""GID" "GO"  "GOALL"

[11] "ONTOLOGY""ONTOLOGYALL" "PMID""REFSEQ"  "SYMBOL"

[16] "UNIGENE"

>


Please post any followup questions to support.bioconductor.org



On Mon, Jan 6, 2020 at 11:25 AM Camila Alves  wrote:

> Hello,
>
> I am looking for Lactuca sativa (lettuce) annotation to download but I am
> not finding it. Do you have it available?
>
> Thank you,
> Camila
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] A query about fixing bugs via github

[Vincent Carey]

On Sun, Jan 5, 2020 at 7:50 AM Tang, Wenhao 
wrote:

> Hello,
>
> I am following this instruction to fix bugs:
> http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>
> However, both master and RELEASE_3_10 branches were not updated. For
> master branch, I have the following messages which could be helpful:
>
> $ git commit -m "DEV 1.5.10" .
> [master a358dce] DEV 1.5.10
>  1 file changed, 5 insertions(+), 13 deletions(-)
>
> $ git push upstream master
> Enumerating objects: 7, done.
> Counting objects: 100% (7/7), done.
> Delta compression using up to 12 threads
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 391 bytes | 391.00 KiB/s, done.
> Total 4 (delta 3), reused 0 (delta 0)
> To git.bioconductor.org:packages/bayNorm
>7c57170..a358dce  master -> master
>
> However, this update was not successful as the message "DEV 1.5.10" was
> not appeared in the github website.
>

Is this sorted now?  The git commands shown above don't affect a github
website.  On the other hand
at https://github.com/WT215/bayNorm, which you maintain, I see the tag on
several folders.

In the bioc git repository I see


commit 43af6a11b166dda2a2283bc5b51139b926297751

Merge: e9528c8 a358dce

Author: Wenhao Tang 

Date:   Sun Jan 5 21:16:10 2020 +0800


Merge remote-tracking branch 'upstream/master'


commit a358dce3bf1b3fb7476d1b9cf4bef3622bab0ee1

Author: Wenhao Tang 

Date:   Sun Jan 5 20:34:19 2020 +0800


DEV 1.5.10


which is what you are looking for?



> On my laptop, I am working on the folder, which was obtained via "git
> clone g...@git.bioconductor.org:packages/bayNorm"
>
> Previously, I directly updated packages on master branch via: git add . ;
> git commit . ; and git push
>
> Not sure whether that procedure is a mistake or not.
>
> I appreciate for your help!
>
> Best wishes,
> Wenhao
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] FW: Repetitive variables within multiple function

[Vincent Carey]

in cbaf/R you could have a file cbaf-constants.R (this name is consistent
with the other filenaming in that folder) that includes assignments like the
one I sketched.  Your functions can then use the values defined in this
R program.

Your code would benefit from simplifications of this type ...  but all we
are
doing is avoiding redefinition of L1.characteristics in activities like

cbaf-obtainMultipleStudies.R:existing.L1.charac <-
AvailableDataTypes[,2] %in% L1.characteristics

cbaf-obtainMultipleStudies.R:f.condition <-
(AvailableDataTypes[,2])[existing.L1.charac]


There are opportunities for simplifying and improving trustworthiness

of code like that above that go beyond reducing the repetitive definition

of vectors of constants.  We can take it off list if you would like to

discuss further.




On Tue, Dec 31, 2019 at 10:27 AM Arman Shahrisa 
wrote:

> Thank you very much for your response. I really appreciate it.
>
>
>
> How can I define those vectors in my package? Another R script that
> possesses only
>
> all the vectors? Which also needs documentation. Am I correct?
>
>
>
> Best regards,
>
> Arman
>
>
>
> *From: *Vincent Carey 
> *Sent: *‏سه شنبه,‏ ‏10 ‏دی ‏1398 ‏07:31
> *To: *Arman Shahrisa 
> *Cc: *bioc-devel 
> *Subject: *Re: [Bioc-devel] Repetitive variables within multiple function
>
>
>
>
>
>
>
> On Mon, Dec 30, 2019 at 9:35 PM Arman Shahrisa 
> wrote:
>
> Hi to all,
>
> I’m the maintainer of the package cbaf. The package relies on various
> terms to find
> the cancer studies that possess specific data e.g. RNA-Seq.
>
> These terms are used by three various functions. I was wondering maybe it
> would be
> much better to include them in a separate file such as zzz.R so that every
> function
> could read the same variables. I already use the zzz.R file to print a
> message upon
> package loading on console.
>
> What is the best way to achieve what I’m looking for? I really appreciate
> any suggestions.
>
>
>
> I don't really understand the question.  I see some repetitiveness in
> grepping for "Tumor"
>
> in cbaf/R/*
>
>
>
> cbaf-availableData.R:  "Tumor Samples with mRNA data (RNA Seq V2)",
>
> cbaf-availableData.R:  "Tumors with mRNA data (RNA Seq V2)",
>
> cbaf-availableData.R:  "Tumor Samples with mRNA data (RNA Seq)",
>
> cbaf-availableData.R:  "Tumors with mRNA data (RNA Seq)",
>
> cbaf-availableData.R:microRNA.Seq_terms_L1 <- c("Tumors with microRNA
> data (microRNA-Seq)",
>
> cbaf-availableData.R:   "Tumor Samples with
> microRNA data (microRNA-Seq)"
>
> ...
>
> cbaf-obtainMultipleStudies.R:  c("Tumor Samples with mRNA data
> (RNA Seq V2)",
>
> cbaf-obtainMultipleStudies.R:"Tumors with mRNA data (RNA Seq
> V2)",
>
> cbaf-obtainMultipleStudies.R:"Tumor Samples with mRNA data
> (RNA Seq)",
>
> cbaf-obtainMultipleStudies.R:"Tumors with mRNA data (RNA
> Seq)",
>
>
>
> Is your question about how to avoid repetitive definition of string
> constants in multiple
>
> functions?  There is no need to use zzz.R ... you can define your vectors
> of constants
>
> outside of functions in R code in your package.  The following is found
> inside one of your
>
> functions, and can't be seen by other functions that need the same content.
>
>
>
>   RNA.Seq_terms_L1 <- c("Tumor Samples with mRNA data (RNA Seq V2)",
>
>   "Tumors with mRNA data (RNA Seq V2)", "Samples with mRNA data (RNA
> Seq V2)",
>
>   "Tumor Samples with mRNA data (RNA Seq)", "Tumors with mRNA data
> (RNA Seq)",
>
>   "Samples with mRNA data (RNA Seq)")
>
>
>
>But as long as this is defined outside of a function it will be
> accessible
>
> to any function in your package.  It can be documented and exported like
>
> any other value or function, should this be desired.  If not exported it
> will
>
> be private to code in the package.
>
>
> Best regards,
> Arman
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the
> Partners Compliance HelpLine at
> http://www.pa

Re: [Bioc-devel] Repetitive variables within multiple function

[Vincent Carey]

On Mon, Dec 30, 2019 at 9:35 PM Arman Shahrisa 
wrote:

> Hi to all,
>
> I’m the maintainer of the package cbaf. The package relies on various
> terms to find
> the cancer studies that possess specific data e.g. RNA-Seq.
>
> These terms are used by three various functions. I was wondering maybe it
> would be
> much better to include them in a separate file such as zzz.R so that every
> function
> could read the same variables. I already use the zzz.R file to print a
> message upon
> package loading on console.
>
> What is the best way to achieve what I’m looking for? I really appreciate
> any suggestions.
>

I don't really understand the question.  I see some repetitiveness in
grepping for "Tumor"
in cbaf/R/*

cbaf-availableData.R:  "Tumor Samples with mRNA data (RNA Seq V2)",

cbaf-availableData.R:  "Tumors with mRNA data (RNA Seq V2)",

cbaf-availableData.R:  "Tumor Samples with mRNA data (RNA Seq)",

cbaf-availableData.R:  "Tumors with mRNA data (RNA Seq)",

cbaf-availableData.R:microRNA.Seq_terms_L1 <- c("Tumors with microRNA
data (microRNA-Seq)",

cbaf-availableData.R:   "Tumor Samples with
microRNA data (microRNA-Seq)"

...

cbaf-obtainMultipleStudies.R:  c("Tumor Samples with mRNA data (RNA
Seq V2)",

cbaf-obtainMultipleStudies.R:"Tumors with mRNA data (RNA Seq
V2)",

cbaf-obtainMultipleStudies.R:"Tumor Samples with mRNA data (RNA
Seq)",

cbaf-obtainMultipleStudies.R:"Tumors with mRNA data (RNA Seq)",


Is your question about how to avoid repetitive definition of string
constants in multiple
functions?  There is no need to use zzz.R ... you can define your vectors
of constants
outside of functions in R code in your package.  The following is found
inside one of your
functions, and can't be seen by other functions that need the same content.

  RNA.Seq_terms_L1 <- c("Tumor Samples with mRNA data (RNA Seq V2)",

  "Tumors with mRNA data (RNA Seq V2)", "Samples with mRNA data (RNA
Seq V2)",

  "Tumor Samples with mRNA data (RNA Seq)", "Tumors with mRNA data (RNA
Seq)",

  "Samples with mRNA data (RNA Seq)")


   But as long as this is defined outside of a function it will be
accessible

to any function in your package.  It can be documented and exported like

any other value or function, should this be desired.  If not exported it
will

be private to code in the package.


> Best regards,
> Arman
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] peculiar warning in BiocOncoTK

[Vincent Carey]

On Thu, Dec 19, 2019 at 3:11 PM Martin Morgan 
wrote:

> I'd guess that 'car' is trying to use globalVariables() with saying
> Imports: utils in the DESCRIPTION and / or importFrom(utils,
> globalVariables) in the NAMESPACE?
>

yes -- "without" ... I will contact John Fox.

The error messaging seemed strange, because there are no problems
loading/checking car on its own


> Martin
>
> On 12/19/19, 2:22 PM, "Bioc-devel on behalf of Vincent Carey" <
> bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
> wrote:
>
> I can't get a handle on this apparent issue with 'car' -- there is some
>
> indication of this globalVariables error at
> https://rdrr.io/github/hadley/tibble/f/revdep/problems.md  but I
> don't see
> an explanation.  The pernicious aspect of this, which seems limited
>
> to mac, is that it stops the "possible problems" process, and various
> notes
>
> are not emitted that should be.
>
>
> * checking whether the namespace can be loaded with stated
> dependencies ...
> WARNING
>
> Error in globalVariables(".groups") :
>
>   could not find function "globalVariables"
>
> Error: unable to load R code in package ‘car’
>
> Execution halted
>
>
> A namespace must be able to be loaded with just the base namespace
>
> loaded: otherwise if the namespace gets loaded by a saved object, the
>
> session will be unable to start.
>
>
> Probably some imports need to be declared in the NAMESPACE file.
>
> * checking whether the namespace can be unloaded cleanly ... OK
>
> * checking dependencies in R code ... OK
>
> * checking S3 generic/method consistency ... OK
>
> * checking replacement functions ... OK
>
> * checking foreign function calls ... OK
>
> * checking R code for possible problems ... NOTE
>
> Error in globalVariables(".groups") :
>
>   could not find function "globalVariables"
>
> Error: unable to load R code in package ‘car’
>
> Execution halted
>
>
> R Under development (unstable) (2019-11-01 r77355)
>
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>
> Running under: macOS Mojave 10.14.6
>
>
> Matrix products: default
>
> BLAS:
>
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.0.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
>
>
> other attached packages:
>
> [1] rmarkdown_2.0
>
>
> loaded via a namespace (and not attached):
>
>  [1] Rcpp_1.0.3knitr_1.26magrittr_1.5
> rcmdcheck_1.3.3
>
>  [5] R6_2.4.1  rlang_0.4.2   fansi_0.4.0   tools_4.0.0
>
>  [9] pkgbuild_1.0.6xopen_1.0.0   xfun_0.11 cli_2.0.0
>
> [13] withr_2.1.2   htmltools_0.4.0   digest_0.6.23
>  assertthat_0.2.1
>
> [17] rprojroot_1.3-2   crayon_1.3.4  processx_3.4.1
> startup_0.14.0
>
> [21] callr_3.4.0   ps_1.3.0  codetools_0.2-16  glue_1.3.1
>
> [25] evaluate_0.14 compiler_4.0.0desc_1.2.0
> backports_1.1.5
>
> [29] prettyunits_1.0.2
>
> --
> The information in this e-mail is intended only for the
> ...{{dropped:18}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] peculiar warning in BiocOncoTK

[Vincent Carey]

I can't get a handle on this apparent issue with 'car' -- there is some

indication of this globalVariables error at
https://rdrr.io/github/hadley/tibble/f/revdep/problems.md  but I don't see
an explanation.  The pernicious aspect of this, which seems limited

to mac, is that it stops the "possible problems" process, and various notes

are not emitted that should be.


* checking whether the namespace can be loaded with stated dependencies ...
WARNING

Error in globalVariables(".groups") :

  could not find function "globalVariables"

Error: unable to load R code in package ‘car’

Execution halted


A namespace must be able to be loaded with just the base namespace

loaded: otherwise if the namespace gets loaded by a saved object, the

session will be unable to start.


Probably some imports need to be declared in the NAMESPACE file.

* checking whether the namespace can be unloaded cleanly ... OK

* checking dependencies in R code ... OK

* checking S3 generic/method consistency ... OK

* checking replacement functions ... OK

* checking foreign function calls ... OK

* checking R code for possible problems ... NOTE

Error in globalVariables(".groups") :

  could not find function "globalVariables"

Error: unable to load R code in package ‘car’

Execution halted


R Under development (unstable) (2019-11-01 r77355)

Platform: x86_64-apple-darwin15.6.0 (64-bit)

Running under: macOS Mojave 10.14.6


Matrix products: default

BLAS:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.0.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


other attached packages:

[1] rmarkdown_2.0


loaded via a namespace (and not attached):

 [1] Rcpp_1.0.3knitr_1.26magrittr_1.5  rcmdcheck_1.3.3

 [5] R6_2.4.1  rlang_0.4.2   fansi_0.4.0   tools_4.0.0

 [9] pkgbuild_1.0.6xopen_1.0.0   xfun_0.11 cli_2.0.0

[13] withr_2.1.2   htmltools_0.4.0   digest_0.6.23 assertthat_0.2.1

[17] rprojroot_1.3-2   crayon_1.3.4  processx_3.4.1startup_0.14.0

[21] callr_3.4.0   ps_1.3.0  codetools_0.2-16  glue_1.3.1

[25] evaluate_0.14 compiler_4.0.0desc_1.2.0backports_1.1.5

[29] prettyunits_1.0.2

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] bioctitle issue for Rmd

[Vincent Carey]

On my mac and linux systems I am seeing a new

error.  With the latest checkout of BiocStyle


rmarkdown::render("foo/BiocStyle/vignettes/AuthoringRmdVignettes.Rmd",
BiocStyle::pdf_document())


produced


! Undefined control sequence.

l.56 \bioctitle

   []{Authoring R Markdown vignettes}


Error: Failed to compile AuthoringRmdVignettes.tex. See
https://yihui.org/tinytex/r/#debugging for debugging tips. See
AuthoringRmdVignettes.log for more info.

> sessionInfo()

R Under development (unstable) (2019-12-06 r77536)

Platform: x86_64-pc-linux-gnu (64-bit)

Running under: Debian GNU/Linux 10 (buster)


Matrix products: default

BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.5.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=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] stats graphics  grDevices utils datasets  methods   base


other attached packages:

[1] BiocStyle_2.15.2rmarkdown_2.0   BiocManager_1.30.10


loaded via a namespace (and not attached):

 [1] Rcpp_1.0.3  bookdown_0.16   digest_0.6.23   magrittr_1.5

 [5] evaluate_0.14   rlang_0.4.2 stringi_1.4.3   tools_4.0.0

 [9] stringr_1.4.0   tinytex_0.18xfun_0.11   yaml_2.2.0

[13] compiler_4.0.0  htmltools_0.4.0 knitr_1.26

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] proposal for additional seqlevelsStyle

[Vincent Carey]

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://api.ncbi.nlm.nih.gov/variation/v0/
>
> 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("
> ftp://ftp.ncbi.nih.gov/snp/redesign/latest_release/VCF/GCF_01405.38.gz
> ",
>
> +   genome="GRCh38", param=mypar)
>
>
> > head(rowRanges(nn), 3)
>
> GRanges object with 3 ranges and 5 metadata columns:
>
>seqnamesranges strand | paramRangeIDREF
>
>   |  
>
>   rs1331956057 NC_01.1110  * |   C
>
>   rs1252351580 NC_01.11100036  * |   T
>
>   rs1238523913 NC_01.11100051  * |   T
>
>   ALT  QUAL  FILTER
>
>  
>
>   rs1331956057  T .
>
>   rs1252351580  G .
>
>   rs1238523913  C .
>
>   ---
>
>   seqinfo: 1 sequence from GRCh38 genome; no seqlengths
>
>
> On Fri, Dec 13, 2019 at 11:01 AM Robert Castelo 
> wrote:
>
>> hi Hervé,
>>
>> i didn't know about this new sequence style until Vince posted his
>> message and we briefly talked about it at the European BioC meeting this
>> week in Brussels. however, i didn't know that the style was specific to
>> a particular assembly. i have no use case of this at the mome moment,
>> i.e., i have not encountered myself any annotation or BAM file with
>> chromosome names written that way, so i don't know how pressing this
>> issue is, maybe Vince can tell us how spread such chromosome naming
>> style may become in the near future.
>>
>> naively, i'd think that it would be matter of adding a
>> reference-specific column, i.e., 'GRCh38.p13', 'GRCh37.p13', etc., but i
>> can imagine that maybe the "reference style" concept might not be the
>> appropriate placeholder to map all different chromosome names of all
>> different individual human genomes uploaded to NCBI. maybe we should
>> wait until we have a specific use case .. Vince?
>>
>> robert.
>>
>> On 12/11/19 10:06 PM, Pages, Herve wrote:
>> > Hi Vince, Robert,
>> >
>> > Looks like Vince wants the RefSeq accession e.g. NC_17.11 for chrom
>> > 17 in the GRCh38.
>> >
>> > @Robert: Is this what you're also interested in?
>> >
>> > The problem is that the RefSeq accessions are specific to a particular
>> > assembly (e.g. NC_17.11 for chrom 17 in GRCh38 but NC_17.10 for
>> > the same chrom in GRCh37).
>> >
>> > Currently seqlevelsStyle() doesn't know how to distinguish between
>> > different assemblies of the same organism. Not saying it couldn't but it
>> > would require some thinking and some significant refactoring. It
>> > wouldn't be just a matter of adding a column to
>> > genomeStyles()$Homo_sapiens.
>> >
>> > H.
>> >
>> >
>> > On 12/10/19 14:19, Robert Castelo wrote:
>> >> I second this, and would suggest to name the style as 'GRC' for "Genome
>> >> Reference Consortium".
>> >>
>> >> thanks Vince for bringing this up, being able to easily switch between
>> >> genome styles is great.
>> >>
>> >> if 'paste0()' in R is one of the most influential contributions to
>> >> statistical computing
>> >>
>> >>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__simplystatistics.org_2013_01_31_paste0-2Dis-2Dstatistical-2Dcomputings-2Dmost-2Dinfluential-2Dcontribution-2Dof-2Dthe-2D21st-2Dcentury=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=b0_SIu8orJ7ZcCS3TIodFvGTPibt9R8vFL5Y40YSx3Q=
>> >>
>

[Bioc-devel] proposal for additional seqlevelsStyle

[Vincent Carey]

I raised this issue previously with little response.

I'd propose that we add a column or two to genomeStyles()$Homo_sapiens

> head(genomeStyles()$Homo_sapiens, 2)

  circular auto   sex NCBI UCSC dbSNP Ensembl

1FALSE TRUE FALSE1 chr1   ch1   1

2FALSE TRUE FALSE2 chr2   ch2   2


that includes the values for "NCBI reference sequence names"

See https://www.ncbi.nlm.nih.gov/nuccore/568815581 for one report on chr17,
and

https://www.ncbi.nlm.nih.gov/assembly/GCF_01405.39

for a table that includes the Genbank labels.

Should I just file a PR at https://github.com/Bioconductor/GenomeInfoDb/ after
testing?

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RangedData objects deprecated

[Vincent Carey]

The RangedData objects are still viable with the software you are using,
but trying
to set colnames will trigger an error.  In Bioc 3.11 you won't even be able
to use
the RangedData class at all.  So an intervention is needed now.

The RangedData objects that were serialized or created in your workflow
should
be converted to GRanges or GRangesList as appropriate, using as(...,
"GRanges")

Code that attempts to set the column names can be changed to use
colnames(mcols(...))

The ichorCNA package man pages don't include examples and I see no example
data with the package.

You might get a sense of what needs to be done in the following.

library(GenomicRanges)

ranges <- IRanges(c(1,2,3),c(4,5,6))

filter <- c(1L, 0L, 1L)

score <- c(10L, 2L, NA)


## constructing RangedData instances

## no variables

rd <- RangedData(ranges, filter, vals = score) # will not work at all

   # in Bioc 3.11

gr = as(rd, "GRanges")

colnames(mcols(gr))




On Wed, Dec 4, 2019 at 7:34 PM Brent O'Carrigan <
brent.ocarri...@cruk.cam.ac.uk> wrote:

> Dear Bioc devel team,
>
> Can you advise how to amend the following code to update references to
> RangedData objects?
>
> I’m running the Broad ichorCNA, which had a similar issue described in the
> package internal code, which I gather has been addressed
> https://github.com/broadinstitute/ichorCNA/issues/50
>
> A colleague has written a wrapper script in part of our shared pipeline,
> which I think was under R 3.5.3, and I think the RangedData references in
> this script may need updating  - which I have not been able to do.
>
> Kind regards,
>
> Dr Brent O'Carrigan
> Clinical Research Training Fellow | PhD candidate
> CRUK Cambridge Institute | Caldas Group
> Li Ka Shing Centre, Robinson Way, Cambridge, CB2 0RE
> E: brent.ocarri...@cruk.cam.ac.uk
> | T: (+44) 01223 769500
>
> > source('make.ichor.summary.R')
> data.table 1.12.6 using 10 threads (see ?getDTthreads).  Latest news:
> r-datatable.com
> Loading required package: HMMcopy
> Loading required package: IRanges
> 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 objects are masked from ‘package:data.table’:
>
> first, second
>
> The following object is masked from ‘package:base’:
>
> expand.grid
>
>
> Attaching package: ‘IRanges’
>
> The following object is masked from ‘package:data.table’:
>
> shift
>
> Loading required package: geneplotter
> Loading required package: Biobase
> Welcome to Bioconductor
>
> Vignettes contain introductory material; view with
> 'browseVignettes()'. To cite Bioconductor, see
> 'citation("Biobase")', and for packages 'citation("pkgname")'.
>
> Loading required package: lattice
> Loading required package: annotate
> Loading required package: AnnotationDbi
> Loading required package: XML
> Loading required package: ichorCNA
>
> Attaching package: ‘ichorCNA’
>
> The following object is masked from ‘package:HMMcopy’:
>
> HMMsegment
>
> Loading required package: GenomicRanges
> Loading required package: GenomeInfoDb
> [1] "./ichor/ichor.default/raw/041V10.sorted.dedupped.RDS"
> [1] "Running ichorCNA"
> Error: RangedData objects are deprecated and the colnames setter for
>   RangedData objects is now defunct. Please migrate your code to use
>   GRanges or GRangesList objects instead. See IMPORTANT NOTE in
>   ?RangedData
> In addition: Warning messages:
> 1:   RangedData objects are deprecated. Please migrate your code to use
>   GRanges or GRangesList objects instead. See IMPORTANT NOTE in
>   ?RangedData
> 2:   RangedData objects are deprecated. Please migrate your code to use
>   GRanges or GRangesList objects instead. See IMPORTANT NOTE in
>   ?RangedData
> 3:   RangedData objects are deprecated. Please migrate your code to use
>   GRanges or GRangesList objects instead. See IMPORTANT NOTE in
>   ?RangedData
> 4:   RangedData objects are deprecated. Please migrate your code to use
>   GRanges or GRangesList objects instead. See 

Re: [Bioc-devel] -fopenmp switch issue on mac

[Vincent Carey]

Thanks -- the solution I used was to install the Simon-Urbanek-modified
distribution clang 8.0 from the page noted in my reply.

On Wed, Dec 4, 2019 at 3:10 PM Bunis, Daniel  wrote:

> I was running into the `clang: *error: *unsupported option '-fopenmp’`
> yesterday myself.  I’m not on Sierra, but I fixed it with the top answer on
> this page:
> https://stackoverflow.com/questions/43595457/alternate-compiler-for-installing-r-packages-clang-error-unsupported-option/43943631#43943631?newreg=e3bd1c44b597485f981795398d9432b6.
>
>
> Specifically, I used the solution #3 there to turn of the addition of the
> -fopenmp option:
> 1) Made a folder in my `~/` called .R
> 2) Made a file in ~/.R/Makevars containing:
>
> SHLIB_OPENMP_CFLAGS=
> SHLIB_OPENMP_CXXFLAGS=
>
> Then I was able to install all the packages for which I’d been getting the
> -fopenmp error.
>
> I hope this solution works for you as well!
> -Dan
>
> On Dec 4, 2019, at 8:07 AM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> Are you using the clang 6 (R 3.5) / 7 (R 3.6) / 8 (R 4.0) which Simon
> supplies?
>
> This is for clang 6 with full path
>
> /usr/local/clang6/bin/clang --version
> clang version 6.0.0 (tags/RELEASE_600/final)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /usr/local/clang6/bin
>
> On Wed, Dec 4, 2019 at 11:03 AM Vincent Carey 
> wrote:
>
> When installing packages from source,
>
> I frequently run into this error with
>
>
> %vjcair> clang --version
>
> Apple LLVM version 9.0.0 (clang-900.0.39.2)
>
> Target: x86_64-apple-darwin16.7.0
>
> Thread model: posix
>
> InstalledDir:
>
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
>
> I am still running macos Sierra ... is there a solution within this
> platform?  I have been getting around this by modifying Makevars when
> needed
>
>
>
> * installing *source* package ‘sitmo’ ...
>
> ** package ‘sitmo’ successfully unpacked and MD5 sums checked
>
> ** using staged installation
>
> ** libs
>
> clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I../inst/include/
>
>
> -I'/Library/Frameworks/R.framework/Versions/4.0/Resources/library/Rcpp/include'
> -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> -I/usr/local/include  -fopenmp -fPIC  -Wall -g -O2  -c RcppExports.cpp -o
> RcppExports.o
>
> clang: *error: *unsupported option '-fopenmp'
>
> make: *** [RcppExports.o] Error 1
>
> ERROR: compilation failed for package ‘sitmo’
>
> --
> The information in this e-mail is intended only for th...{{dropped:15}}
>
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=iORugZls2LlYyCAZRB3XLg=basuzE7-VlMupNUhjOlOjq3Z71OZ7WVlqjvCai9jtug=8ndw52WAHTohPcPQItPQQDlzi2GSSFsa48rBNYORZzQ=3Bk4CmiTOaGnnX2gf7KvkUvv3pW8P1ek4otRy5jvrPE=
>
>
>

-- 
The information in this e-mail is intended only for the person to whom it 
is
addressed. If you believe this e-mail was sent to you in error and the 
e-mail
contains patient information, please contact the Partners Compliance 
HelpLine at
http://www.partners.org/complianceline 
<http://www.partners.org/complianceline> . If the e-mail was sent to you in 
error
but does not contain patient information, please contact the sender 
and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] -fopenmp switch issue on mac

[Vincent Carey]

When installing packages from source,

I frequently run into this error with


%vjcair> clang --version

Apple LLVM version 9.0.0 (clang-900.0.39.2)

Target: x86_64-apple-darwin16.7.0

Thread model: posix

InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


I am still running macos Sierra ... is there a solution within this
platform?  I have been getting around this by modifying Makevars when needed



* installing *source* package ‘sitmo’ ...

** package ‘sitmo’ successfully unpacked and MD5 sums checked

** using staged installation

** libs

clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I../inst/include/
-I'/Library/Frameworks/R.framework/Versions/4.0/Resources/library/Rcpp/include'
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
-I/usr/local/include  -fopenmp -fPIC  -Wall -g -O2  -c RcppExports.cpp -o
RcppExports.o

clang: *error: *unsupported option '-fopenmp'

make: *** [RcppExports.o] Error 1

ERROR: compilation failed for package ‘sitmo’

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] ndexr fails on vignette build on windows

[Vincent Carey]

Thanks for this.  I will try with the upcoming curl from github

On Thu, Oct 24, 2019 at 7:21 AM Florian J. Auer <
florian.a...@informatik.uni-augsburg.de> wrote:

> Hi Vincent,
>
> For me the sollution was quite simple: I just put the protocol to the url,
> i.e. replaced www.ndexbio.org with http://www.ndexbio.org.
>
> I guess providing the protocol would be good practice anyways.
>
> In general, the issue was in curl, which should be fixed in the current
> devel release. For more information see also the curl issue:
>
> https://github.com/jeroen/curl/issues/209#issuecomment-542127937
>
> and the discussion in the httr issue:
>
> https://github.com/r-lib/httr/issues/619
>
> It seems, that this issue still exists in windows:
> *jeroen <https://github.com/jeroen> *commented 8 days ago
> <https://github.com/jeroen/curl/issues/209#issuecomment-542758288> •
> edited
>
> On Windows you have to wait for the next release of the r package
>
> https://github.com/jeroen/curl/issues/209#issuecomment-542758288
>
> Greetings
>
> Florian
> Am 23.10.19 um 21:23 schrieb Vincent Carey:
>
> May I ask what is the resolution here?  I have updated curl and httr on my
> windows box and continue
> to see errors unique to windows when requests lack the protocol in the URL.
>
> On Wed, Oct 23, 2019 at 7:28 AM Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
>> Thank you for the update.
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Comprehensive Cancer Center
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>>
>> 
>> From: Florian J. Auer 
>> Sent: Wednesday, October 23, 2019 7:25 AM
>> To: Shepherd, Lori 
>> ; bioc-devel@r-project.org <
>> bioc-devel@r-project.org>
>> Subject: Re: [Bioc-devel] ndexr fails on vignette build on windows
>>
>>
>> Hi Lori,
>>
>> Thanks a lot, that really helped!
>>
>> It seems, that the error is caused by httr, and curl in the end.
>>
>>
>> https://github.com/r-lib/httr/issues/619
>>
>>
>> Greetings
>>
>> Florian
>>
>>
>>
>> Am 09.10.19 um 17:37 schrieb Shepherd, Lori:
>> I did a little digging and here is what I've found...
>>
>>
>> I R CMD Stangle the vignette and then sourced the code:
>>
>>
>> > source("ndexr-vignette.R", echo=TRUE)
>>
>> > ## 
>> eval=FALSE-
>> > ## if (!requireNamespace("BiocManager", quietly=TRUE))
>> > ## instal  [TRUNCATED]
>>
>> > ## 
>> eval=FALSE-
>> > ## ## login to the NDEx server
>> > ## ndexcon = ndex_connect("username",  [TRUNCATED]
>> Error in if (is_http) { : argument is of length zero
>> > traceback()
>> 8: request_perform(req, hu$handle$handle)
>> 7: httr::GET(url = url, config = auth_param) at ndex_helper.r#149
>> 6: ndex_helper_httpResponseHandler(httr::GET(url = url, config =
>> auth_param),
>>log_txt, verbose) at ndex_connect.r#84
>> 5: ndex_connect() at ndexr-vignette.R#24
>> 4: eval(ei, envir)
>> 3: eval(ei, envir)
>> 2: withVisible(eval(ei, envir))
>> 1: source("ndexr-vignette.R", echo = TRUE)
>>
>>
>> If I then did a
>> debug(httr:::request_perform)
>>
>> httr:::request_fetch results in different output on windows than on
>> mac/linux
>>
>>
>>
>> #
>> # on linux and mac
>> #
>>
>> Browse[2]> resp
>> $url
>> [1] "HTTP://www.ndexbio.org/v2/admin/status"<
>> HTTP://www.ndexbio.org/v2/admin/status>
>>
>>
>> #
>> # on windows
>> #
>>
>> Browse[2]> resp
>> $url
>> [1] "www.ndexbio.org/v2/admin/status<
>> http://www.ndexbio.org/v2/admin/status>"
>>
>> This causes the eventual error.
>>
>>
>> You might try to come up with a small reproducible example and report as
>> a bug to httr.
>>
>>
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Comprehensive Cancer Center
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>>
>> 

Re: [Bioc-devel] ndexr fails on vignette build on windows

[Vincent Carey]

May I ask what is the resolution here?  I have updated curl and httr on my
windows box and continue
to see errors unique to windows when requests lack the protocol in the URL.

On Wed, Oct 23, 2019 at 7:28 AM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> Thank you for the update.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Florian J. Auer 
> Sent: Wednesday, October 23, 2019 7:25 AM
> To: Shepherd, Lori ;
> bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] ndexr fails on vignette build on windows
>
>
> Hi Lori,
>
> Thanks a lot, that really helped!
>
> It seems, that the error is caused by httr, and curl in the end.
>
>
> https://github.com/r-lib/httr/issues/619
>
>
> Greetings
>
> Florian
>
>
>
> Am 09.10.19 um 17:37 schrieb Shepherd, Lori:
> I did a little digging and here is what I've found...
>
>
> I R CMD Stangle the vignette and then sourced the code:
>
>
> > source("ndexr-vignette.R", echo=TRUE)
>
> > ## 
> eval=FALSE-
> > ## if (!requireNamespace("BiocManager", quietly=TRUE))
> > ## instal  [TRUNCATED]
>
> > ## 
> eval=FALSE-
> > ## ## login to the NDEx server
> > ## ndexcon = ndex_connect("username",  [TRUNCATED]
> Error in if (is_http) { : argument is of length zero
> > traceback()
> 8: request_perform(req, hu$handle$handle)
> 7: httr::GET(url = url, config = auth_param) at ndex_helper.r#149
> 6: ndex_helper_httpResponseHandler(httr::GET(url = url, config =
> auth_param),
>log_txt, verbose) at ndex_connect.r#84
> 5: ndex_connect() at ndexr-vignette.R#24
> 4: eval(ei, envir)
> 3: eval(ei, envir)
> 2: withVisible(eval(ei, envir))
> 1: source("ndexr-vignette.R", echo = TRUE)
>
>
> If I then did a
> debug(httr:::request_perform)
>
> httr:::request_fetch results in different output on windows than on
> mac/linux
>
>
>
> #
> # on linux and mac
> #
>
> Browse[2]> resp
> $url
> [1] "HTTP://www.ndexbio.org/v2/admin/status"<
> HTTP://www.ndexbio.org/v2/admin/status>
>
>
> #
> # on windows
> #
>
> Browse[2]> resp
> $url
> [1] "www.ndexbio.org/v2/admin/status<
> http://www.ndexbio.org/v2/admin/status>"
>
> This causes the eventual error.
>
>
> You might try to come up with a small reproducible example and report as a
> bug to httr.
>
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  bioc-devel-boun...@r-project.org> on behalf of Florian J. Auer <
> florian.a...@informatik.uni-augsburg.de> florian.a...@informatik.uni-augsburg.de>
> Sent: Thursday, September 26, 2019 7:52 AM
> To: bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: [Bioc-devel] ndexr fails on vignette build on windows
>
> Hi everyone,
>
> my package ndexr produces some errors while building the vignette, but
> only in the Windows build.
>
> In particular, the error message shows:
>
> Quitting from lines 76-78 (ndexr-vignette.Rmd)
> Error: processing vignette 'ndexr-vignette.Rmd' failed with diagnostics:
> argument is of length zero
> --- failed re-building 'ndexr-vignette.Rmd'
>
> Seems like it's occurring in the following lines:
>
> ```{r, echo=FALSE, results='hide', message=FALSE}
> ## login to the NDEx server
> ndexcon = ndex_connect()
> ```
>
> Is there some different behavior in Windows of how the code blocks are
> treated? Or is the error occurring within the code?
>
> Have there been some changes on the build server, since the error only
> occurred recently without any changes in the package?
>
> I'm grateful for any feedback!
>
> Greetings
>
> Florian
>
> --
> Dipl.Bioinf. Florian Auer
> IT Infrastructure for Translational Medical Research
> Faculty of Applied Computer Science
> Faculty of Medicine
> University of Augsburg
> Alter Postweg 101
> 86159 Augsburg
>
> email: florian.a...@informatik.uni-augsburg.de florian.a...@informatik.uni-augsburg.de>
> phone: (+49) 0821- 598 - 3748
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> 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 

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Vincent Carey]

On Wed, Oct 9, 2019 at 6:55 AM Andrzej Oleś  wrote:

> Hi Vince,
>
> I briefly communicated with Martin regarding this issue a few days ago.
> The ImageMagick convert tool called by BiocStyle through a knitr figure
> cropping hook can certainly be improved, as pointed out by Yihui in the in
> the GitHub issue linked by Christian. This is something I will look into.
> However, I don't think that your failing builds are related to BiocStyle. I
> can only second on what Herve has already mentioned here: the observed
> convert messages are picked up as warnings by 'R CMD build' and they don't
> actually cause the build to fail.
>

Thank you Andrzej ... I missed this point.  Because it is a
platform-specific failure (no prob on linux or mac)
I assumed that this event was the problem.  I will look more closely at a
windows build attempt.


>
> Cheers,
> Andrzej
>
> On Wed, Oct 9, 2019 at 12:10 PM Vincent Carey 
> wrote:
>
>> Just wondering whether this has been followed up.  I am still seeing build
>> errors for
>> windows related to this.
>>
>> On Tue, Sep 17, 2019 at 10:20 AM Christian Mertes 
>> wrote:
>>
>> > I just came across this issue on rmarkdown which links the same problem
>> to
>> > BiocStyle.
>> > The post is from Nov 2017.
>> >
>> > https://github.com/rstudio/rmarkdown/issues/1207
>> >
>> > Maybe this helps to understand the underlying problem?
>> >
>> > It was suggested to check this in BiocStyle:
>> >
>> > Have you reported to the authors of BiocStyle? It seems they enabled the
>> > *knitr* hook knitr::hook_pdfcrop unconditionally (i.e. without checking
>> > if ImageMagick has been installed).
>> >
>> > Best,
>> >
>> > Christian
>> > On 9/11/19 5:50 PM, Pages, Herve wrote:
>> >
>> > New to me too. But it seems that knitr suggests magick, which itself has
>> >
>> >SystemRequirements: ImageMagick++: ImageMagick-c++-devel (rpm) or
>> > libmagick++-dev (deb)
>> >
>> > Don't know when this knitr dep on magick was introduced tough... Bummer!
>> >
>> > H.
>> >
>> > On 9/11/19 06:13, Kasper Daniel Hansen wrote:
>> >
>> > Yeah, does this imply that the render operation uses (or tries to use)
>> > ImageMagick? That's news to me, but I am not following this closely.
>> >
>> > On Wed, Sep 11, 2019 at 5:21 AM Pages, Herve > <mailto:hpa...@fredhutch.org> > wrote:
>> >
>> > On 9/11/19 00:50, Vincent Carey wrote:
>> >  > I seem to be running into a similar problem with BiocOncoTK on
>> > windows
>> >  >
>> >  > The build report for tokay1 shows:
>> >  >
>> >  > Loading required package: ontologyIndex
>> >  > Invalid Parameter - /figure-html
>> >  > Warning in shell(paste(c(cmd, args), collapse = " ")) :
>> >  >'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
>> >  > "BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
>> >  > error code 4
>> >  > Invalid Parameter - /figure-html
>> >  >
>> >  > The figure code is introduced with ```{r
>> > lkgbm,fig=TRUE,message=FALSE}
>> >  > ... the 'convert' process is not requested by me
>> >  >
>> >  > Is the fig=TRUE problematic for windows?  It seems unnecessary.
>> >
>> > Not sure what's going on. A few observations:
>> >
>> > a) About 500 software packages use fig=TRUE.
>> >
>> > b) The convert warning is just a warning. The actual error in the
>> case
>> > of BiocOncoTK is:
>> >
>> > Error: processing vignette 'BiocOncoTK.Rmd' failed with
>> diagnostics:
>> > argument is of length zero
>> >
>> > Note that the ndexr vignette also fails with this error on
>> tokay1
>> > only but it doesn't have the convert warning (this vignette does not
>> > use
>> > 'fig' at all). So it's not clear to me that the "argument is of
>> length
>> > zero" error is related to the convert warning.
>> >
>> > c) The devel build report shows the convert warning for 4 other
>> > packages
>> > (CAGEfightR, CATALYST, CTDquerier, specL) but each of them actually
>> > fails with a different error message:
>> >
>> > 

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Vincent Carey]

Just wondering whether this has been followed up.  I am still seeing build
errors for
windows related to this.

On Tue, Sep 17, 2019 at 10:20 AM Christian Mertes  wrote:

> I just came across this issue on rmarkdown which links the same problem to
> BiocStyle.
> The post is from Nov 2017.
>
> https://github.com/rstudio/rmarkdown/issues/1207
>
> Maybe this helps to understand the underlying problem?
>
> It was suggested to check this in BiocStyle:
>
> Have you reported to the authors of BiocStyle? It seems they enabled the
> *knitr* hook knitr::hook_pdfcrop unconditionally (i.e. without checking
> if ImageMagick has been installed).
>
> Best,
>
> Christian
> On 9/11/19 5:50 PM, Pages, Herve wrote:
>
> New to me too. But it seems that knitr suggests magick, which itself has
>
>SystemRequirements: ImageMagick++: ImageMagick-c++-devel (rpm) or
> libmagick++-dev (deb)
>
> Don't know when this knitr dep on magick was introduced tough... Bummer!
>
> H.
>
> On 9/11/19 06:13, Kasper Daniel Hansen wrote:
>
> Yeah, does this imply that the render operation uses (or tries to use)
> ImageMagick? That's news to me, but I am not following this closely.
>
> On Wed, Sep 11, 2019 at 5:21 AM Pages, Herve  <mailto:hpa...@fredhutch.org> > wrote:
>
> On 9/11/19 00:50, Vincent Carey wrote:
>  > I seem to be running into a similar problem with BiocOncoTK on
> windows
>  >
>  > The build report for tokay1 shows:
>  >
>  > Loading required package: ontologyIndex
>  > Invalid Parameter - /figure-html
>  > Warning in shell(paste(c(cmd, args), collapse = " ")) :
>  >'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
>  > "BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
>  > error code 4
>  > Invalid Parameter - /figure-html
>  >
>  > The figure code is introduced with ```{r
> lkgbm,fig=TRUE,message=FALSE}
>  > ... the 'convert' process is not requested by me
>  >
>  > Is the fig=TRUE problematic for windows?  It seems unnecessary.
>
> Not sure what's going on. A few observations:
>
> a) About 500 software packages use fig=TRUE.
>
> b) The convert warning is just a warning. The actual error in the case
> of BiocOncoTK is:
>
> Error: processing vignette 'BiocOncoTK.Rmd' failed with diagnostics:
> argument is of length zero
>
> Note that the ndexr vignette also fails with this error on tokay1
> only but it doesn't have the convert warning (this vignette does not
> use
> 'fig' at all). So it's not clear to me that the "argument is of length
> zero" error is related to the convert warning.
>
> c) The devel build report shows the convert warning for 4 other
> packages
> (CAGEfightR, CATALYST, CTDquerier, specL) but each of them actually
> fails with a different error message:
>
> CAGEfightR:
>   colData(object1) not identical to colData(object2)
>
> CATALYST:
>   no slot of name "reducedDims" for this object of class "daFrame"
>
> CTDquerier:
>   bfcadd() failed; see warnings()
>
> specL:
>   pandoc.exe: Out of memory
>
> These errors don't seem related to the convert warning either.
>
> So I'm wondering: could it be that the convert warning is actually
> common but we generally don't see it because 'R CMD build' doesn't
> report warnings? And that we just happen to see the warning when 'R CMD
> build' fails to build a vignette.
>
> We'll investigate more.
>
> H.
>
>
>  >
>  > On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes
> mailto:mer...@in.tum.de> > wrote:
>  >
>  >> Thanks a lot for the info! So from my understanding we dont use any
>  >> trimming or editing function from ImageMagick directly. I think
> this is
>  >> rather knitr based since we just include png files in the vignette.
>  >>
>  >> I guess it was an hickup since now the error is gone over night.
>  >>
>  >> Best regards,
>  >>
>  >> Christian
>  >>
>  >> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
>  >>> You don't declare any systems requirements for ImageMagick
> (doing so
>  >>> will probably not solve your problem, but you really should).
>  >>>
>  >>> Alternatively you could look into using the tools provided by the
>

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Vincent Carey]

I seem to be running into a similar problem with BiocOncoTK on windows

The build report for tokay1 shows:

Loading required package: ontologyIndex
Invalid Parameter - /figure-html
Warning in shell(paste(c(cmd, args), collapse = " ")) :
  'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
"BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
error code 4
Invalid Parameter - /figure-html

The figure code is introduced with ```{r lkgbm,fig=TRUE,message=FALSE}
... the 'convert' process is not requested by me

Is the fig=TRUE problematic for windows?  It seems unnecessary.


On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes  wrote:

> Thanks a lot for the info! So from my understanding we dont use any
> trimming or editing function from ImageMagick directly. I think this is
> rather knitr based since we just include png files in the vignette.
>
> I guess it was an hickup since now the error is gone over night.
>
> Best regards,
>
> Christian
>
> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
> > You don't declare any systems requirements for ImageMagick (doing so
> > will probably not solve your problem, but you really should).
> >
> > Alternatively you could look into using the tools provided by the
> > magick package, which wraps ImageMagick.
> >
> > But it looks like you're editing PNG files for your vignette. I would
> > really recommend not doing so. It introduces a system dependency which
> > is just going to increase headaches on your end, for (perhaps) no real
> > tangible benefits. If you're trimming PNGs, you should be able to
> > achieve the same effect when using the png device(s) in R, and that
> > will make everything more portable anyway.
> >
> > On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes  > > wrote:
> >
> > Dear BioC team,
> >
> > I just noticed that our package is failing on the bioconductor build
> > system during the build of the vignette on Windows and on MacOS
> > platforms.
> >
> > From the error I would guess its a problem with the installation
> > of the
> > ImageMagick package. Please correct me if Im wrong.
> >
> > It goes through on travis and appveyor. Any suggestions?
> >
> > Here are some links to the build logs:
> >
> > http://bioconductor.riken.jp/checkResults/3.9/bioc-LATEST/OUTRIDER/
> > https://travis-ci.org/gagneurlab/OUTRIDER
> > https://ci.appveyor.com/project/c-mertes/OUTRIDER
> >
> > Best,
> >
> > Christian
> >
> > PS: the error message on the bioc build system:
> >
> >
>  
> ##
> >
>  
> ##
> > ###
> > ### Running command:
> > ###
> > ###   chmod a+r OUTRIDER -R &&
> > C:\Users\biocbuild\bbs-3.9-bioc\R\bin\R.exe CMD build
> > --keep-empty-dirs --no-resave-data OUTRIDER
> > ###
> >
>  
> ##
> >
>  
> ##
> >
> >
> > * checking for file 'OUTRIDER/DESCRIPTION' ... OK
> > * preparing 'OUTRIDER':
> > * checking DESCRIPTION meta-information ... OK
> > * cleaning src
> > * installing the package to build vignettes
> > * creating vignettes ... ERROR
> > --- re-building 'OUTRIDER.Rnw' using knitr
> > Invalid Parameter - /deVsOutlier-1.png"
> > Warning in shell(paste(c(cmd, args), collapse = " ")) :
> >   'convert "figure/deVsOutlier-1.png" -trim
> > "figure/deVsOutlier-1.png"' execution failed with error code 4
> > 229 genes did not passed the filter due to zero counts. This is
> > 22.9% of the genes.
> > Sat Sep 07 01:16:53 2019: SizeFactor estimation ...
> > Sat Sep 07 01:16:53 2019: Controlling for confounders ...
> > Using estimated q with: 23
> > Sat Sep 07 01:16:53 2019: Using the autoencoder implementation for
> > controlling.
> > Sat Sep 07 01:17:52 2019: Used the autoencoder implementation for
> > controlling.
> > Sat Sep 07 01:17:52 2019: P-value calculation ...
> > Sat Sep 07 01:17:52 2019: Zscore calculation ...
> > Invalid Parameter - /quick_guide-1.png"
> > Warning in shell(paste(c(cmd, args), collapse = " ")) :
> >   'convert "figure/quick_guide-1.png" -trim
> > "figure/quick_guide-1.png"' execution failed with error code 4
> > Quitting from lines 222-232 (OUTRIDER.Rnw)
> > Error: processing vignette 'OUTRIDER.Rnw' failed with diagnostics:
> > no lines available in input
> > --- failed re-building 'OUTRIDER.Rnw'
> >
> > SUMMARY: processing the following file failed:
> >   'OUTRIDER.Rnw'
> >
> > Error: Vignette re-building failed.
> > Execution halted
> >
> > --
> >
> > Christian Mertes
> > PhD Student / Lab Administrator
> > Gagneur lab
> >
> > Computational Genomics
> > I12 

Re: [Bioc-devel] Build error due to TensorFlow installation

[Vincent Carey]

how about TF for platforms that support it and C++ for those that don't,
eventually
migrating away from C++ as support grows?   a little messy for the moment
but let's
get some mileage on the TF solution ASAP

On Thu, Sep 5, 2019 at 9:21 AM Dirmeier Simon  wrote:

> Hi Herve,
>
> > All this means that if you replace some old C++ code with TensorFlow
> > then we will need to mark your package as unavailable on Windows and
> > Mac, at least for now. Sorry. I wonder if there was something wrong
> > with this old C++ code. I would recommend that you stick to it if you
> can.
> >
> The code is fine, but still an impractical complexity that doesn't need
> to exist:
>
> 1) It's hard to extend and read for others.
>
> 2) It needs a custom configure.ac.
>
> 3) Extending the package to other models/families is a huge pain, as one
> needs to derive custom coordinate descents (or other optimizers for that
> matter) for each.
>
> On the other side:
>
> 1) TF allowed me to replace like 5000 lines of source code with 100
> lines of R.
>
> 2) TF allows to easily extend with other models with just a few lines.
>
> 3) I don't need a huge test suite.
>
> 4) On GPUs it's a huge speedup.
>
> So, for now I'll revert the changes back on Bioc devel and continue
> development on another branch.
>
> Cheers,
>
> S
>
>
> Am 04.09.19 um 16:53 schrieb Pages, Herve:
> >
> > Hi Simon,
> >
> > On 9/3/19 09:11, Simon Dirmeier wrote:
> >> ...
> >> Do you think it would be possible to install TensorFlow and
> >> TensorFlow-Probability on the builders? I'd assume that many would
> >> profit from that.
> >>
> > As Lori mentioned at the end of her email (see below), we can't make
> > the tensorflow Python module available on our Windows builders at the
> > moment because we need to update Python to Python 3 on these machines
> > first (AFAIK tensorflow is only available for Python 3 on Windows).
> > This is something that we are currently working on.
> >
> > As for the Mac builders, we have tensorflow there but unfortunately
> > it's an old version because recent versions of are broken on El
> > Capitan (this is the Mac OS version that, for various reasons, we are
> > stuck with at the moment). This prevents us from installing the
> > tensorflow_probability module which requires a recent version of
> > tensorflow.
> >
> > The tensorflow and tensorflow_probability modules are available on our
> > Linux builders.
> >
> > All this means that if you replace some old C++ code with TensorFlow
> > then we will need to mark your package as unavailable on Windows and
> > Mac, at least for now. Sorry. I wonder if there was something wrong
> > with this old C++ code. I would recommend that you stick to it if you
> can.
> >
> > Best,
> >
> > H.
> >
> >
> >>> Right now tensorflow is unavailable on our windows server (tokay1)�as
> >>> we have not updated to python 3 (but will be in the near future)� The
> >>> windows error can be ignored for now.
> >>>
> >>>
> >>>
> >>> Lori Shepherd
> >>>
> >>> Bioconductor Core Team
> >>>
> >>> Roswell Park Cancer Institute
> >>>
> >>> Department of Biostatistics & Bioinformatics
> >>>
> >>> Elm & Carlton Streets
> >>>
> >>> Buffalo, New York 14263
> >>>
> >>>
> 
> >>> *From:* Bioc-devel  on behalf of
> >>> Simon Dirmeier
> >>> *Sent:* Monday, September 2, 2019 6:08:45 AM
> >>> *To:*bioc-devel@r-project.org  
> >>> *Subject:* [Bioc-devel] Build error due to TensorFlow installation
> >>> Dear all,
> >>>
> >>> since I replaced some old C++ code with TensorFlow I am getting some
> >>> build errors on merida1 and tokay1 regarding installation (even though
> I
> >>> install TF and TF Probability during /.onLoad/)
> >>>
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_netReg_merida1-2Dbuildsrc.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=wjC8b2uCm0PJgQ1LRO_CTrqNvfGKpEKN0N6QN23Sbd0=
>
> >>>
> >>> Does anyone know how I can fix this or did anyone use TF with
> >>> Bioconductor so far?
> >>>
> >>> Many thanks in advance.
> >>>
> >>> Best,
> >>>
> >>> Simon
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ��� [[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=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Iy8WHNH6twF-8QkJjKa7MOIXm9mYjGg4pBlLb2CGiq8=98vYdk5e2ryxlWN99O68ty2dUHnoE23VPU9TwSF8rPc=
>
> >>>
> >>> 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,
> >>> 

Re: [Bioc-devel] BiocCheck error

[Vincent Carey]

If your package that generates the error is in a github repo, please give
the details.
If it is already in Bioconductor please give the name of the package and
ensure we can
get access to the code that is generating the error.  In general it is very
hard to help unless
we can reproduce the error you report.

On Tue, Aug 20, 2019 at 11:38 AM Zhezhen Wang  wrote:

> Hi I am running BiocCheck on my new package and I get the following error
> message
>
>   *   Checking for deprecated package usage... Warning in readLines(file,
> skipNul = TRUE) : InternetOpenUrl failed: 'The server name or address could
> not be resolved' Error in readLines(file, skipNul = TRUE) : cannot open the
> connection
>
> May I know what this error message means and how I can correct it?
>
> Zhezhen
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Is magrittr "%>%" acceptable in bioc packages?

[Vincent Carey]

On Sat, Aug 17, 2019 at 4:40 AM Venu Thatikonda 
wrote:

> Hi,
>
> As the title says, is %>% acceptable in bioc packages? With BiocCheck, I
> get a WARNING that is "Add non-empty \\value sections to the following man
> pages: man/pipe.Rd".
>

Yes magrittr is acceptable.  The warning says (I think) that you have a man
page for
a topic 'pipe' but did not put a \value section for the man page.  If using
roxygen you
would want to have a @return element in your documentation, to avoid this
warning.


> Is it okay even if this warning appears ? `R CMD check` didn't give
> warnings about it.
>

Try to avoid the warning.  If you have difficulty, report back.


>
> Thank you.
>
> --
> Best regards
> Venu Thatikonda
> https://itsvenu.github.io/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] [ext] Re: Vignettes for a data processing package

[Vincent Carey]

I think we can take this to a one-to-one discussion for now and report back
to bioc-devel.  I have
done a little work with the package and have some comments.

On Mon, Aug 5, 2019 at 1:16 PM Dermot Harnett 
wrote:

> Hi Vincent - thanks, much appreciated.
>
> Here's the current development version of the repository.
>
> https://github.com/ohlerlab/RiboseQC/
>
>
> <https://github.com/ohlerlab/RiboseQC/settings>
>
> On Mon, Aug 5, 2019 at 1:22 PM Vincent Carey 
> wrote:
>
>> Is there an open github repository where this can be examined as a work
>> in progress?  If so please let us know and I and likely others will take a
>> look
>> and make recommendations.
>>
>> On Mon, Aug 5, 2019 at 6:55 AM Dermot Harnett > >
>> wrote:
>>
>> > Hi
>> > I've been put in charge of trying to clean up a package produced in my
>> lab
>> > into bioconductor compatible code.
>> >
>> > The package consists of a a few functions (which process annotation,
>> > process bam files, and then create a html report, respectively). Each of
>> > these functions necessarily take a long time aas they have to traverse a
>> > bam file several times, create lots of plots etc.
>> >
>> > It's proving extremely difficult, even with subsets of the data, to
>> create
>> > a vignette which can be run in the the bioconductor standard 10minutes.
>> > What would you recommend in these circumstances? Is it possible for the
>> > package to have a workflow vignette instead of a standard vignette?
>> >
>> > Best
>> > Dermot Harnett, PhD
>> > Ohler Group
>> > BIMSB, Berlin
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>> --
>> The information in this e-mail is intended only for t...{{dropped:27}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Build error - C stack usage is too close to the limit

[Vincent Carey]

On Thu, Aug 1, 2019 at 10:36 PM Aaron Lun <
infinite.monkeys.with.keyboa...@gmail.com> wrote:

> One possibility is that this is due to a regression in
> SingleCellExperiment, caused by the altexp updates and other
> refactoring. This should be fixed in 1.7.3, you can check this for
> yourself by installing drisso/SingleCellExperiment off GitHub.
>

I can confirm this.  Would it then be appropriate for scMerge to add a
(>= 1.7.3) after its Imports: entry for SingleCellExperiment?


>
> The other moral of the story is to not use serialized high-level
> objects. Serializing basic objects is fine, but the higher up you go,
> the more fragile your code becomes to refactoring. See, for example, the
> scRNAseq data package for how to deliver a SingleCellExperiment to an R
> session without relying on serialized SingleCellExperiments.
>

I have run into this issue also.  It is convenient to serialize a high-level
object.  Breaking it down to its constituents, and assembling it, is
a lot more effort.  scRNAseq:::.create_sce shows how to reassemble for
SingleCellExperiments.

Is this a principle we want to adopt?  Avoid serializing "non-basic"
objects?
updateObject methods should help centralize the effort to managing object
designs and their implementation.

It seems it would be wise to implement this principle for any resource that
might be used by both release and devel ... even in devel we may see more
breaking changes propagating as S4 classes evolve, if objects are
serialized.
Adding validObject tests in tests/ could reduce surprises.  Helping class
maintainers know what packages have serialized fragile objects might be a
task for BiocPkgTools -- but a nontrivial one.  Maybe a BiocDevTools package
would be more appropriate.  And checking hub elements seems relevant too.

Basically, before we commit changes to a class, it should not be too hard
to assess the downstream effects and notify relevant developers.  The
alternative
of banning serialized S4 objects seems too harsh and possibly ambiguous.
On the other hand it may be necessary to ban serialized S4 in the *Hubs?




>
> -A
>
> On 8/1/19 7:14 PM, Kevin Wang wrote:
> > Hi all,
> >
> > I am getting a strange build error message for scMerge (
> http://bioconductor.org/checkResults/devel/bioc-LATEST/scMerge/malbec1-buildsrc.html)
> that reads
> >
> > + "C stack usage is too close to the limit” on Linux and Mac and
> > + "evaluation nested too deeply: infinite recursion” on Windows, when
> building the vignette file “scMerge.Rmd”.
> >
> > However, when I was building the Rmd locally and also on Travis +
> pkgdown under BioC3.10 (
> https://travis-ci.org/SydneyBioX/scMerge/builds/566753523), I had no
> errors. This file has not been edited for 2 months (
> https://github.com/SydneyBioX/scMerge/blob/master/vignettes/scMerge.Rmd).
> >
> > Any help would be appreciated.
> >
> > Thank you
> > Best Wishes
> > Kevin
> >
> > PhD Candidate
> > Faculty of Science, School of Mathematics and Statistics
> > THE UNIVERSITY OF SYDNEY
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BioC packages - profileplyr

[Vincent Carey]

Hi Doug,

I think you've written a method of "[" for class "profileplyr" that is
using certain aspects of the Assays API that
are not guaranteed to be stable.  It would be good to have a simple
reproducible example -- I can run
your vignette and see that certain uses of "$" cause errors but pinpointing
how you have to update your
code would take some work.  My gut feeling is that you do not have to write
as much of a "[" method as
you have ... let RangedSummarizedExperiment infrastructure do everything it
can, and only when one
of your extensions really needs to be fiddled with by "[" do you add that
operation.  Learning how to use
callNextMethod may be helpful.




On Fri, Jul 12, 2019 at 1:51 PM Doug Barrows  wrote:

> Hi,
>
> Our package - profileplyr - is failing on the development branch with an
> error when it tries to subset a RangedSummarizedExperiment object with
> brackets ([ ]). Within our package we build a slightly modified
> RangedSummarizedExperiment object with a few additional slots and features,
> and often will subset this object using the brackets in both the functions
> and in the vignette. When trying to subset (e.g. object[1:10, 1:10]) we get
> the error "Error: $ operator not defined for this S4 class". This is a new
> error, so I wanted to check if this kind of subsetting functionality is no
> longer supported with RangedSummarizedExperiment objects in general, or
> whether this is likely something specific to our package. Any insight you
> may have would be greatly appreciated - thanks!
>
> Bestm
> Doug
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Problems with MACPET package

[Vincent Carey]

It should be possible to get stringdist as a binary package for mac.
provide your sessionInfo().

> BiocManager::install("stringdist")

*Bioconductor version 3.10 (BiocManager 1.30.4), R 3.6.0 Patched
(2019-05-06*

*  r76460)*

*Installing package(s) 'stringdist'*

*trying URL
'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.6/stringdist_0.9.5.2.tgz
'*

*Content type 'application/x-gzip' length 567740 bytes (554 KB)*

*==*

*downloaded 554 KB*

On Fri, Jul 12, 2019 at 10:13 AM Ioannis Vardaxis 
wrote:

> I have changed the S4methods now and the Rcheck is working fine locally on
> my machine.
>
> I cannot run BiocCheck because I cannot install it on my Mac anymore. It
> depends on a package named stringdist, which cannot be installed in my Mac.
> I get an error:
> clang: error: unsupported option '-fopenmp'
>
> However I have pushed the changes to the repository now and we will see if
> the devel version gets fixed.
>
> Best,
> Ioannis
>
>
> > 8. jul. 2019 kl. 11:20 skrev Martin Morgan :
> >
> > Under bioc-devel, I ran
> >
> >  MACPET/vignettes$ R CMD Stangle MACPET.Rmd
> >
> > and then in R
> >
> >  source("MACPET.R", echo = TRUE)
> >
> > where the problem manifests as
> >
> >> summary(MACPET_pintraData,heatmap=TRUE)
> >  Error in .Vector_summary(object, ...) : unused argument (heatmap = TRUE)
> >
> > You have the S4 class
> >
> >> getClass(class(MACPET_pintraData))
> > Class "PIntra" [package "MACPET"]
> >
> > Slots:
> >
> > Name:anchor1   anchor2   regions
>  NAMES
> > Class:   integer   integer   GRanges
> character_OR_NULL
> >
> > Name:elementMetadata  metadata
> > Class: DataFrame  list
> >
> > Extends:
> > Class "GInteractions", directly
> > Class "Vector", by class "GInteractions", distance 2
> > Class "Annotated", by class "GInteractions", distance 3
> > Class "vector_OR_Vector", by class "GInteractions", distance 3
> >
> > that extends 'Vector'.
> >
> > You have an S3 generic summary.PIntra, but I guess recently S4Vectors
> introduced an S4 method summary,Vector-method. Probably the dispatch system
> sees the inherited S4 method before your S3 method, and the solution is to
> change your S3 method to S4. Best practice would do this for all S3 methods
> defined on S4 classes.
> >
> > Martin
> >
> > On 7/8/19, 10:46 AM, "Bioc-devel on behalf of Ioannis Vardaxis" <
> bioc-devel-boun...@r-project.org on behalf of ioannis.varda...@ntnu.no>
> wrote:
> >
> >Hey,
> >
> >My package (MACPET) has been crashing lately. The error I get is from
> the vignette:
> >
> >
> >Error in .Vector_summary(object, ...) : unused argument (heatmap =
> TRUE)
> >Calls:  ... withCallingHandlers -> withVisible -> eval ->
> eval -> summary -> summary
> >Execution halted
> >
> >When I call the summary function which is specified on one of my
> classes.
> >
> >I realised that for some reason all the methods that I had created
> and worked fine for every class, they just don’t work anymore.
> >
> >I have no idea what causes the error..
> >
> >
> >Best,
> >
> >Ioannis
> >
> >   [[alternative HTML version deleted]]
> >
> >___
> >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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Fwd: banocc problems reported in the Multiple platform build/check report for BioC 3.9

[Vincent Carey]

The error reported by the build system is reproducible on my mac running R
CMD check on

banocc_1.8.0.tar.gz


The check error is pretty terse.  I turned your vignette into

an R script using knitr::purl and ran into


> compiled_banocc_model <- rstan::stan_model(model_code =
banocc::banocc_model)

DIAGNOSTIC(S) FROM PARSER:

Info: integer division implicitly rounds to integer. Found int division: (P
* (P - 1)) / 2

 Positive values rounded down, negative values rounded up or down in
platform-dependent way.


*Error in compileCode(f, code, language = language, verbose = verbose) : *

*  Compilation ERROR, function(s)/method(s) not created! In file included
from file15ef4c04043e.cpp:8:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/StanHeaders/include/src/stan/model/model_header.hpp:4:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/StanHeaders/include/stan/math.hpp:4:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/StanHeaders/include/stan/math/rev/mat.hpp:4:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/StanHeaders/include/stan/math/rev/core.hpp:5:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/StanHeaders/include/stan/math/rev/core/build_vari_array.hpp:4:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/StanHeaders/include/stan/math/prim/mat/fun/Eigen.hpp:4:*

*In file included from
/Library/Frameworks/R.framework/Versions/3.6/Resources/l*

*In addition: Warning message:*

*In system(cmd, intern = !verbose) :*

*  running command '/Library/Frameworks/R.framework/Resources/bin/R CMD
SHLIB file15ef4c04043e.cpp 2> file15ef4c04043e.cpp.err.txt' had status 1*

Selection:


I don't know how to interpret this as I don't make much use of rstan.

Even though you have not changed anything in this version of banocc,

other software that you rely on may be changing ... perhaps
https://github.com/stan-dev/rstan/issues/666 is relevant?

On Mon, Jun 24, 2019 at 10:27 PM George Weingart 
wrote:

> Hello !
>
> I am receiving these messages.
>
> We haven't changed anything in the package and all of a sudden we are
> getting errors to the effect that the "vignette build failed"  "because a
> connect error"
>
> I do  not know what causes the error (Since we haven't changed anything in
> the package)  and how to recreate it.
>
> Can you assist solving the issue ?
>
> Thanks!
>
> George Weingart PhD
> Huttenhower Lab
> Harvard School of Pubilc Health
>
>
>
> -- Forwarded message -
> From: 
> Date: Mon, Jun 24, 2019 at 11:36 AM
> Subject: banocc problems reported in the Multiple platform build/check
> report for BioC 3.9
> To: 
>
>
> [This is an automatically generated email. Please don't reply.]
>
> Hi banocc maintainer,
>
> According to the Multiple platform build/check report for BioC 3.9,
> the banocc package has the following problem(s):
>
>   o ERROR for 'R CMD build' on malbec2. See the details here:
>
>
> https://master.bioconductor.org/checkResults/3.9/bioc-LATEST/banocc/malbec2-buildsrc.html
>
> Please take the time to address this by committing and pushing
> changes to your package at git.bioconductor.org
>
> Notes:
>
>   * This was the status of your package at the time this email was sent to
> you.
> Given that the online report is updated daily (in normal conditions)
> you
> could see something different when you visit the URL(s) above,
> especially if
> you do so several days after you received this email.
>
>   * It is possible that the problems reported in this report are false
> positives,
> either because another package (from CRAN or Bioconductor) breaks your
> package (if yours depends on it) or because of a Build System problem.
> If this is the case, then you can ignore this email.
>
>   * Please check the report again 24h after you've committed your changes
> to the
> package and make sure that all the problems have gone.
>
>   * If you have questions about this report or need help with the
> maintenance of your package, please use the Bioc-devel mailing list:
>
>   https://bioconductor.org/help/mailing-list/
>
> (all package maintainers are requested to subscribe to this list)
>
> For immediate notification of package build status, please
> subscribe to your package's RSS feed. Information is at:
>
> https://bioconductor.org/developers/rss-feeds/
>
> Thanks for contributing to the Bioconductor project!
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] normalize_names_replacement_value error with colnames<- on SummarizedExperiment

[Vincent Carey]

remedied by installation of latest S4Vectors/SummarizedExperiment from git

On Wed, Jun 12, 2019 at 10:53 AM Vincent Carey 
wrote:

> my installation of Bioc 3.10 passes valid()
>
>
> > ee = SummarizedExperiment(assay=data.matrix(mtcars))
>
> > ee
>
> class: SummarizedExperiment
>
> dim: 32 11
>
> metadata(0):
>
> assays(1): ''
>
> rownames(32): Mazda RX4 Mazda RX4 Wag ... Maserati Bora Volvo 142E
>
> rowData names(0):
>
> colnames(11): mpg cyl ... gear carb
>
> colData names(0):
>
> > colnames(ee)[1] = "foo"
>
> *Error in get(name, envir = asNamespace(pkg), inherits = FALSE) : *
>
> *  object 'normalize_names_replacement_value' not found*
>
>
> > sessionInfo()
>
> R version 3.6.0 Patched (2019-05-06 r76460)
>
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>
> Running under: macOS Sierra 10.12.6
>
>
> Matrix products: default
>
> BLAS:
> /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib
>
> LAPACK:
> /Library/Frameworks/R.framework/Versions/3.6/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] parallel  stats4stats graphics  grDevices utils datasets
>
> [8] methods   base
>
>
> other attached packages:
>
>  [1] SummarizedExperiment_1.15.1 DelayedArray_0.11.0
>
>  [3] BiocParallel_1.19.0 matrixStats_0.54.0
>
>  [5] Biobase_2.45.0  GenomicRanges_1.37.10
>
>  [7] GenomeInfoDb_1.21.1 IRanges_2.19.9
>
>  [9] S4Vectors_0.23.11   BiocGenerics_0.31.4
>
> [11] rmarkdown_1.13
>
>
> loaded via a namespace (and not attached):
>
>  [1] Rcpp_1.0.1 knitr_1.23 XVector_0.25.0
>
>  [4] zlibbioc_1.31.0lattice_0.20-38tools_3.6.0
>
>  [7] grid_3.6.0 xfun_0.7   htmltools_0.3.6
>
> [10] digest_0.6.19  Matrix_1.2-17  startup_0.12.0
>
> [13] GenomeInfoDbData_1.2.1 BiocManager_1.30.4 bitops_1.0-6
>
> [16] RCurl_1.95-4.12evaluate_0.14  compiler_3.6.0
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] normalize_names_replacement_value error with colnames<- on SummarizedExperiment

[Vincent Carey]

my installation of Bioc 3.10 passes valid()


> ee = SummarizedExperiment(assay=data.matrix(mtcars))

> ee

class: SummarizedExperiment

dim: 32 11

metadata(0):

assays(1): ''

rownames(32): Mazda RX4 Mazda RX4 Wag ... Maserati Bora Volvo 142E

rowData names(0):

colnames(11): mpg cyl ... gear carb

colData names(0):

> colnames(ee)[1] = "foo"

*Error in get(name, envir = asNamespace(pkg), inherits = FALSE) : *

*  object 'normalize_names_replacement_value' not found*


> sessionInfo()

R version 3.6.0 Patched (2019-05-06 r76460)

Platform: x86_64-apple-darwin15.6.0 (64-bit)

Running under: macOS Sierra 10.12.6


Matrix products: default

BLAS:
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib

LAPACK:
/Library/Frameworks/R.framework/Versions/3.6/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] parallel  stats4stats graphics  grDevices utils datasets

[8] methods   base


other attached packages:

 [1] SummarizedExperiment_1.15.1 DelayedArray_0.11.0

 [3] BiocParallel_1.19.0 matrixStats_0.54.0

 [5] Biobase_2.45.0  GenomicRanges_1.37.10

 [7] GenomeInfoDb_1.21.1 IRanges_2.19.9

 [9] S4Vectors_0.23.11   BiocGenerics_0.31.4

[11] rmarkdown_1.13


loaded via a namespace (and not attached):

 [1] Rcpp_1.0.1 knitr_1.23 XVector_0.25.0

 [4] zlibbioc_1.31.0lattice_0.20-38tools_3.6.0

 [7] grid_3.6.0 xfun_0.7   htmltools_0.3.6

[10] digest_0.6.19  Matrix_1.2-17  startup_0.12.0

[13] GenomeInfoDbData_1.2.1 BiocManager_1.30.4 bitops_1.0-6

[16] RCurl_1.95-4.12evaluate_0.14  compiler_3.6.0

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] new error with saved HDF5SummarizedExperiment

[Vincent Carey]

Loading required namespace: HDF5Array
Error in .stop_if_bad_dir(dir, prefix) : directory
  "/home/biocbuild/bbs-3.10-bioc/R/library/BiocSklearn/hdf5/tenx_750"
  does not seem to contain an HDF5-based SummarizedExperiment object
  previously saved with saveHDF5SummarizedExperiment()
Calls:  -> .stop_if_bad_dir
Execution halted

it looks like some things are going on in HDF5Array and SummarizedExperiment
that might lead to new constraints on how these work together ... I don't
see
any high-level commentary in these package NEWS

when I try to recreate using current software but older content

> saveHDF5SummarizedExperiment(se, "tenx_750b")

*Error in assays[[i]] : wrong arguments for subsetting an environment*


Enter a frame number, or 0 to exit


1: saveHDF5SummarizedExperiment(se, "tenx_750b")

2: .write_HDF5SummarizedExperiment(x, rds_path = rds_path, h5_path =
h5_path,

3: .write_h5_assays(x@assays, h5_path, chunkdim, level, verbose)


any hints?

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] warnings with BiocStyle pdf compilation

[Vincent Carey]

On Thu, May 9, 2019 at 5:12 AM Andrzej Oleś  wrote:

> Hi Vince,
>
> thank you for your feedback. If the vignette compiles fine I wouldn't
> worry too much about these warnings.
>

Hi Andrzej -- yes, the compilation seems fine.

Best regards
Vince


>
> The first one "LaTeX Warning: You have requested package
> `/Library/Frameworks/R.framework/Versions/3.6/Resources/library/BiocStyle/resources/tex/Bioconductor',
> but the package provides `Bioconductor'." is related to the nonstandard
> approach of specifying an external LaTeX package by file path rather than
> by referring to a package from the local library by name. I haven't really
> found a way around this, unfortunately.
>
> The remaining warnings could be probably fixed by tweaks to
> Bioconductor.sty, but as far as I can tell they doesn't seem to harm so I
> wouldn't bother to much.
>
> Cheers,
> Andrzej
>
> On Mon, May 6, 2019 at 9:42 PM Vincent Carey 
> wrote:
>
>> *I don't often compile vignettes to pdf ... but a recent attempt led to:*
>>
>>
>> *Warning message:*
>>
>> *LaTeX Warning: You have requested package
>> `/Library/Frameworks/R.framework/Vers*
>>
>> *ions/3.6/Resources/library/BiocStyle/resources/tex/Bioconductor',*
>>
>> *   but the package provides `Bioconductor'.*
>>
>> *Package geometry Warning: Over-specification in `h'-direction.*
>>
>> *`width' (384.1122pt) is ignored.*
>>
>> *Package Fancyhdr Warning: \fancyhead's `E' option without twoside option
>> is use*
>>
>> *less on input line 173. *
>>
>>
>> *Any hints?  Must I update tex?*
>>
>>
>> > sessionInfo()
>>
>> R Under development (unstable) (2019-03-18 r76245)
>>
>> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>>
>> Running under: macOS Sierra 10.12.6
>>
>>
>> Matrix products: default
>>
>> BLAS:
>>
>> /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib
>>
>> LAPACK:
>>
>> /Library/Frameworks/R.framework/Versions/3.6/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
>>
>>
>> other attached packages:
>>
>> [1] BiocStyle_2.12.0 rmarkdown_1.12
>>
>>
>> loaded via a namespace (and not attached):
>>
>>  [1] Rcpp_1.0.1 bookdown_0.9   digest_0.6.18  magrittr_1.5
>>
>>
>>  [5] evaluate_0.13  stringi_1.4.3  startup_0.11.0 tools_3.6.0
>>
>>
>>  [9] stringr_1.4.0  tinytex_0.12   xfun_0.6   yaml_2.2.0
>>
>>
>> [13] compiler_3.6.0 BiocManager_1.30.4 htmltools_0.3.6knitr_1.22
>>
>> --
>> The information in this e-mail is intended only for t...{{dropped:27}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] warnings with BiocStyle pdf compilation

[Vincent Carey]

*I don't often compile vignettes to pdf ... but a recent attempt led to:*


*Warning message:*

*LaTeX Warning: You have requested package
`/Library/Frameworks/R.framework/Vers*

*ions/3.6/Resources/library/BiocStyle/resources/tex/Bioconductor',*

*   but the package provides `Bioconductor'.*

*Package geometry Warning: Over-specification in `h'-direction.*

*`width' (384.1122pt) is ignored.*

*Package Fancyhdr Warning: \fancyhead's `E' option without twoside option
is use*

*less on input line 173. *


*Any hints?  Must I update tex?*


> sessionInfo()

R Under development (unstable) (2019-03-18 r76245)

Platform: x86_64-apple-darwin15.6.0 (64-bit)

Running under: macOS Sierra 10.12.6


Matrix products: default

BLAS:
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib

LAPACK:
/Library/Frameworks/R.framework/Versions/3.6/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


other attached packages:

[1] BiocStyle_2.12.0 rmarkdown_1.12


loaded via a namespace (and not attached):

 [1] Rcpp_1.0.1 bookdown_0.9   digest_0.6.18  magrittr_1.5


 [5] evaluate_0.13  stringi_1.4.3  startup_0.11.0 tools_3.6.0


 [9] stringr_1.4.0  tinytex_0.12   xfun_0.6   yaml_2.2.0


[13] compiler_3.6.0 BiocManager_1.30.4 htmltools_0.3.6knitr_1.22

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db

[Vincent Carey]

Has this situation been rectified?

On Tue, Apr 23, 2019 at 11:40 AM Van Twisk, Daniel <
daniel.vantw...@roswellpark.org> wrote:

> We've made some changes to our annotation generation scripts this release
> and it seems these may have introduced some errors. Thank you for
> identifying this issue and I will try to have some fixes out asap.
>
> 
> From: Bioc-devel  on behalf of James W.
> MacDonald 
> Sent: Tuesday, April 23, 2019 11:03:02 AM
> To: Aaron Lun
> Cc: Bioc-devel
> Subject: Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db
>
> Looks like the ensembl table of the human.db0 package got polluted with
> *Pan
> troglodytes* genes:
>
> > con <- dbConnect(SQLite(),
> "/R-devel/lib64/R/library/human.db0/extdata/chipsrc_human.sqlite")
> > dbGetQuery(con, "select count(*) from ensembl where ensid like
> 'ENSPTR%';")
>   count(*)
> 116207
> > dbGetQuery(con, "select count(*) from ensembl where ensid like 'ENSG%';")
>   count(*)
> 128973
>
> On Mon, Apr 22, 2019 at 11:54 PM Aaron Lun <
> infinite.monkeys.with.keyboa...@gmail.com> wrote:
>
> > Playing around with org.Hs.eg.db 3.8.0. What on earth is ENSPTRG...?
> >
> >  > library(org.Hs.eg.db)
> >  > mapIds(org.Hs.eg.db, key="GCG", keytype="SYMBOL", column="ENSEMBL")
> > 'select()' returned 1:many mapping between keys and columns
> >   GCG
> > "ENSPTRG777"
> >
> > Well, at least it still recovers the right identifier... eventually.
> >
> >  > select(org.Hs.eg.db, key="GCG", keytype="SYMBOL", columns="ENSEMBL")
> > 'select()' returned 1:many mapping between keys and columns
> >SYMBOLENSEMBL
> > 1GCG ENSPTRG777
> > 2GCGENSG0115263
> >
> > The SYMBOL->Entrez ID relational table seems to be okay:
> >
> >  > Y <- toTable(org.Hs.egSYMBOL)
> >  > Y[which(Y[,2]=="GCG"),]
> >   gene_id symbol
> > 21522641GCG
> >
> > So the cause is the Ensembl->Entrez mappings:
> >
> >  > Z <- toTable(org.Hs.egENSEMBL2EG)
> >  > Z[Z[,1]==2641,]
> >   gene_id ensembl_id
> > 30282641 ENSPTRG777
> > 30292641ENSG0115263
> >
> > Googling suggests that ENSPTRG777 is an identifier for some
> > other gene in one of the other monkeys. Hardly "Hs" stuff.
> >
> > Session info (not technically R 3.6, but I didn't think that would have
> > been the cause):
> >
> > > R Under development (unstable) (2019-04-11 r76379)
> > > Platform: x86_64-pc-linux-gnu (64-bit)
> > > Running under: Ubuntu 18.04.2 LTS
> > >
> > > Matrix products: default
> > > BLAS:   /home/luna/Software/R/trunk/lib/libRblas.so
> > > LAPACK: /home/luna/Software/R/trunk/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] org.Hs.eg.db_3.8.0   AnnotationDbi_1.45.1 IRanges_2.17.5
> > > [4] S4Vectors_0.21.23Biobase_2.43.1   BiocGenerics_0.29.2
> > >
> > > loaded via a namespace (and not attached):
> > >  [1] Rcpp_1.0.1  digest_0.6.18   DBI_1.0.0   RSQLite_2.1.1
> > >  [5] blob_1.1.1  bit64_0.9-7 bit_1.1-14  compiler_3.7.0
> > >  [9] pkgconfig_2.0.2 memoise_1.1.0
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] Help with installing netReg

[Vincent Carey]

On Sun, Apr 14, 2019 at 6:30 PM Spencer Brackett <
spbracket...@saintjosephhs.com> wrote:

> Good evening,
>
>  I am having problems with downloading the package used to generate
> regression models on R. The following is the error message I received. I
> tried installing BiocManager instead as suggested, but this too did not
> work. Any ideas?
>
> The downloaded binary packages are in
> C:\Users\Spencer\AppData\Local\Temp\Rtmp8YKVqx\downloaded_packages
> installation path not writeable, unable to update packages: class, cluster,
> codetools, foreign,
>   lattice, MASS, Matrix, mgcv, nlme, rpart, survival
> Warning message:
> 'biocLite' is deprecated.
> Use 'BiocManager::install' instead.
> See help("Deprecated")
>

Dear Spencer

1) this is not an error message but a warning concerning the permission
setup on your computer
2) this mailing list is for package development in bioconductor, but the
question
does not address development, please do not use this list
3) use support.bioconductor.org for questions concerning
installation/BiocManager.  Just point
your browser to support.bioconductor.org, and read the posting guidelines

Thank you


>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Vincent Carey]

On Wed, Mar 27, 2019 at 9:05 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> On Wed, Mar 27, 2019 at 1:06 AM Aaron Lun <
> infinite.monkeys.with.keyboa...@gmail.com> wrote:
>
> > > well, we can't fix this in old branches of Bioc.
> >
> > Sure, but one could say that about breaking changes to any CRAN package.
> > Nothing particularly special about BH on that point.
> >
>
> Indeed, and this has been my position for a number of years. Having said
> that, dynamic linking / headers in my experience increase the chance of
> breaking and it is usually a kind of breakage which requires substantial
> insight to fix (as opposed to say changing the order / naming of arguments
> in an R function, which is really easy to diagnose even if you know nothing
> about the package).
>

Definitely.

I started a channel on slack to continue this discussion.   #containers


>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Vincent Carey]

On Mon, Mar 25, 2019 at 10:57 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> There are no issues with depending on CRAN packages.
>
> But I would advise caution. On one hand it is great that boost gets
> updated regularly. On the other hand, it could lead to incompatibilities
> with RBGL and then you have to update that package rapidly. Also - and this
> is something we could consider addressing - the CRAN imports of Bioc are
> not locked down. By which I mean, you release RBGL in Bioconductor X. After
> release (or perhaps even after next Bioc release) BH is updated in a
> non-backwards compatible way and now the old code is hosed. Having said
> that, so far we have been ignoring it (I think) and the same issue arises
> with Rcpp.
>
> Do you have any idea how often Boost breaks compatibility?  I would
> strongly advise to download the last couple of BH releases and test with
> RBGL. While kind of irrelevant in some sense, it will give you an idea of
> how fast Boost / BH evolves.
>

These are good points.  In this particular case I believe that Boost Graph
Library evolves very slowly and
backwards compatibility is not endangered.  It is an early component of
Boost.  On the other hand, BH has
no obligation to provide the graph (BGL) headers, and I believe that in
early incarnations of BH, some headers
needed for RBGL were not there.  So there are maintenance vulnerabilities
to this approach, but I think it is better
if we stick with the maintained BH as long as this works.  Should this
approach fail (and your scenario of
CRAN package changes breaking bioc must be kept in mind) we can go back to
tarball distribution if necessary.


>
> On Mon, Mar 25, 2019 at 8:03 AM Martin Morgan 
> wrote:
>
>> ...also Bioconductor knows all about CRAN -- see the repositories
>> returned by
>>
>> > BiocManager::repositories()
>>BioCsoft
>>"https://bioconductor.org/packages/3.9/bioc;
>> BioCann
>> "https://bioconductor.org/packages/3.9/data/annotation;
>> BioCexp
>> "https://bioconductor.org/packages/3.9/data/experiment;
>>   BioCworkflows
>>   "https://bioconductor.org/packages/3.9/workflows;
>>CRAN
>>  "https://cran.rstudio.com;
>> >
>>
>> On 3/25/19, 7:42 AM, "Martin Morgan"  wrote:
>>
>> I think the usual incantation in configure files is ${R_HOME}/bin/R
>> ... R_HOME is the path to R set by the command that starts to build or
>> install the package, whereas Rscript is found on the search path.
>>
>> Martin
>>
>> On 3/25/19, 7:33 AM, "Bioc-devel on behalf of Vincent Carey" <
>> bioc-devel-boun...@r-project.org on behalf of st...@channing.harvard.edu>
>> wrote:
>>
>> The error on linux for 3.9:
>>
>>
>> ##
>>
>> ##
>> ###
>> ### Running command:
>> ###
>> ###   /home/biocbuild/bbs-3.9-bioc/R/bin/R CMD INSTALL RBGL
>> ###
>>
>> ##
>>
>> ##
>>
>>
>> * installing to library ‘/home/biocbuild/bbs-3.9-bioc/R/library’
>> * installing *source* package ‘RBGL’ ...
>> ** using staged installation
>> checking R package BH ... no
>> configure: error: R package BH not found.
>> ERROR: configuration failed for package ‘RBGL’
>> * removing ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’
>> * restoring previous ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’
>>
>> Note that BiocParallel also uses BH and succeeds
>>
>> configure: creating ./config.status
>> config.status: creating src/Makevars
>> ** libs
>> g++ -std=gnu++11 -I"/home/biocbuild/bbs-3.9-bioc/R/include"
>> -DNDEBUG
>> -I"/home/biocbuild/bbs-3.9-bioc/R/library/BH/include"
>> -I/usr/local/include  -fpic  -g -O2  -Wall -c ipcmutex.cpp -o
>> ipcmutex.o
>> In file included from
>>
>> /home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/ra

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Vincent Carey]

The error on linux for 3.9:

##
##
###
### Running command:
###
###   /home/biocbuild/bbs-3.9-bioc/R/bin/R CMD INSTALL RBGL
###
##
##


* installing to library ‘/home/biocbuild/bbs-3.9-bioc/R/library’
* installing *source* package ‘RBGL’ ...
** using staged installation
checking R package BH ... no
configure: error: R package BH not found.
ERROR: configuration failed for package ‘RBGL’
* removing ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’
* restoring previous ‘/home/biocbuild/bbs-3.9-bioc/R/library/RBGL’

Note that BiocParallel also uses BH and succeeds

configure: creating ./config.status
config.status: creating src/Makevars
** libs
g++ -std=gnu++11 -I"/home/biocbuild/bbs-3.9-bioc/R/include" -DNDEBUG
-I"/home/biocbuild/bbs-3.9-bioc/R/library/BH/include"
-I/usr/local/include  -fpic  -g -O2  -Wall -c ipcmutex.cpp -o
ipcmutex.o
In file included from
/home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/integer_log2.hpp:19:0,
 from
/home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/large_arithmetic.hpp:19,
 from
/home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/const_mod.hpp:23,
 from
/home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/detail/seed_impl.hpp:26,
 from
/home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/random/mersenne_twister.hpp:30,
 from
/home/biocbuild/bbs-3.9-bioc/R/library/BH/include/boost/uuid/random_generator.hpp:17,

So could it be an issue with the configure script?


On Mon, Mar 25, 2019 at 7:22 AM Samuela Pollack 
wrote:

> Dear Bioconductor,
>
> The devel version of package RBGL is flunking build.
>
> This package has been modified to include header files in the CRAN
> package 'BH' instead of using a local tarball of the header files. We
> consider this an improvement because the 'BH' maintainers update their
> package every time a new version of boost is released, but rebuilding
> the included tarball is unreliable.
>
> Is it possible to request inclusion of a CRAN package dependency in a
> Bioconductor package? If not, how would Bioconductor recommend we handle
> this?
>
> (Full disclosure: the BH package has all the header files for all of
> boost. This is a lot more disk space then we need, because we only need
> the BGL.)
>
> thanks,
>
> - Sam
>
>
>
> On 3/22/19 7:28 AM, Morgan, Martin wrote:
> >  External Email - Use Caution
> >
> > Thanks for the explanation and exemplary detective work. Will you push
> these changes to the release and devel branches of RBGL? I've given you
> permissions... Martin
> >
> > On 3/22/19, 5:15 AM, "Samuela Pollack" 
> wrote:
> >
> >  We have a temporary fix which we believe will alleviate the
> difficulty.
> >
> >  The only routine in RBGL that does not compile under the LLVM-9.0
> system
> >  is the routine that implements betweenness connectivity clustering.
> This
> >  seems to be a rarely-used routine, so we have temporarily removed it
> >  from RBGL and put in a message explaining how users may replace it
> easily.
> >
> >  I have contacted Professor Jeremy Siek at in Bloomington to discuss
> how
> >  best to proceed. It is possible this will have to be fixed in BGL,
> >  probably not in time for boost 1.70.
> >
> >  For clarity: the incompatibility is not in clang. The
> incompatibility is
> >  in the llvm c++ standard library. Mac users who build with clang
> will be
> >  fine, as long as they don't link in the llvm C++ stdlib, which most
> >  wouldn't think to do and Apple does not encourage.
> >
> >  We hope this will be sufficient for now.
> >
> >  - Sam
> >
> >
> >  On 3/22/19 4:18 AM, Morgan, Martin wrote:
> >  >  External Email - Use Caution
> >  >
> >  > What's the status for RBGL?
> >  >
> >  > Thanks, Martin
> >  >
> >  > On 3/22/19, 3:57 AM, "Prof Brian Ripley" 
> wrote:
> >  >
> >  >  clang 8.0.0 is now released, and these fail there too (and
> break about
> >  >  50 CRAN packages which depend on them).
> >  >
> >  >  Reminder: this is with clang's native libc++, as documented
> at
> >  >
> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x86_64-fedora-clang
> >  >
> >  >  We really need fixes in both 3.8 and 3.9.
> >  >
> >  >  BDR
> >  >
> >  >  On 28/02/2019 18:52, Prof Brian Ripley wrote:
> >  >  > These packages fail to install with clang 8.0.0rc3, which
> is supposed to
> >  >  > be near-final (it is overdue for release).  (AFAIR they
> did install with
> >  >  > rc1.)  

Re: [Bioc-devel] What is Bioconductor's position on allowing users to create files in the working directory without an explicit path definition in the filename

[Vincent Carey]

Guidelines on this topic do not seem to be present in our web
site; there is a link to Wickham's guide but I don't see that it
confronts the topic.  I will make some unofficial and possibly
wrong remarks.

Suppose my function has to create a file "foo.txt".  If I do it
in the working folder, I might destroy a user's cherished file.
So I should check to see if the filename I need is already in use.
If it is, I need to do something graceful.

That's a lot of complexity that may never actually be used.  Can
we avoid it completely?  Here are a few ways to avoid it:

1) Don't create files, just create objects and leave the serialization
task to the user.  You can provide helper functions and documentation but
the details of target location of the serialization are left to the user.

2) If you create a file, use R's tempfile/tempdir discipline to avoid
the need for checking for clobber.  If the content needs to persist the
user should direct this, again with helpers as needed.

3) If you create a file that should persist, use BiocFileCache as that
addresses the location problem and has an added benefit of obligatory
metadata binding.  This is an underused strategy and more pedagogy
is surely in order.  If the user "cannot find" what has been made, there
is a systematic approach available that involves querying the cache.  Your
documentation will supply all relevant details.

On Fri, Mar 22, 2019 at 11:38 AM Koustav Pal  wrote:

> Hello,
>
> My package HiCBricks was submitted and accepted under the previous 3.8
> release of Bioconductor.
>
> At the time, during package review, my reviewer had expressed reservations
> towards my package creating
> files in the current working directory.
>
>
> [REQUIRED] CreateLego() creates HDF5 files in the current directory if no
> path is given in the Output.Filename argument. This may clutter the working
> directory and it would be better to have the files saved to a temporary
> file
> (or directory) using tempfile() (or tempdir()).
>
>
> This was with regards to the main output files that were being created by
> my package.
> I clarified the specific point in question with my reviewer.
>
>
> The idea behind this package is to create a HDF file for storing
> high-resolution Hi-C (can be as large as a user wants) data and keep it as
> a persistent copy which the user can access later without having to reload
> the file. Therefore, I am a bit averse towards creating a tempfile or
> tempdir. Using a temporary file would go against this idea and would
> probably result in the user not having access to the file later. I have
> incorporated a control statement which will issue a warning regarding file
> creation inside the current working directory. Is that ok?
>
>
> Finally, my reviewer suggested that I make use of the BiocFileCache
> package to create files.
>
>
> The changes so far look good. I understand that tempfile() isn't a great
> solution for your package, so may I recommend that you store your data
> using the BiocFileCache package
> https://bioconductor.org/packages/release/bioc/html/BiocFileCache.html <
> https://bioconductor.org/packages/release/bioc/html/BiocFileCache.html>
> as opposed to automatically saving the file in a local directory. Once this
> change is made, I should be able to accept the package.
>
> I interpreted this as the reviewer expressing reservation towards files
> being created in the
> current working directory without the user's explicit requirement.
> Therefore, I made a working
> implementation of BiocFileCache within my package, which works perfectly
> fine.
>
> Yet, users are now facing troubles when having to locate files that they
> may have created in the current
> working directory using the traditional method of var = “something.txt”,
> because these files were created in
> the BiocFileCache cache during file creation. All the confusion and issue
> stems from this being a non-traditional
> method of keeping track of files and folders.
>
> What is Bioconductor’s position regarding this issue?
>
> Can users create files using Bioconductor packages in the current working
> directory without an explicit path definition in the filename?
>
> Or did I misinterpret the reviewer’s position and this is only a
> requirement when the package is being build by the builder?
>
>
> Koustav Pal,
> Post-Doctoral Fellow in Genome Architecture,
> Computational Genomics Group,
> IFOM - The FIRC Institute of Molecular Oncology,
> Via Adamello 16,
> 20139 Milano, Italy.
> Phone: +393441130157
> E-mail: koustav@ifom.eu
>
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Question about package dependency

[Vincent Carey]

put ggplot2 in Suggests:

see 1.1.3 of https://cran.r-project.org/doc/manuals/r-release/R-exts.html

The ‘Suggests’ field uses the same syntax as ‘Depends’ and lists packages
that are not necessarily needed. This includes packages used only in
examples, tests or vignettes (see Writing package vignettes
),
and packages loaded in the body of functions. E.g., suppose an example11
 from
package *foo* uses a dataset from package *bar*. Then it is not necessary
to have *bar* use *foo* unless one wants to execute all the
examples/tests/vignettes: it is useful to have *bar*, but not necessary.
Version requirements can be specified but should be checked by the code
which uses the package.

On Tue, Feb 19, 2019 at 10:02 AM Xu Ren  wrote:

> Hi everyone,
>
> I'm developing a Bioconductor package and I have a question about package
> dependency. The functions in my package do not depend on ggplot2 but I used
> ggplot2 to do some visualization in the package vignette. I'm wondering if
> I should import ggplot2 in the DESCRIPTION file. If ggplot2 is not
> imported, R CMD check will produce a note:
>
>
> * checking tests ...
>
>   Running ‘testthat.R’
>
>  OK
>
> * checking for unstated dependencies in vignettes ... NOTE
>
> 'library' or 'require' call not declared from: ‘ggplot2’
>
> * checking package vignettes in ‘inst/doc’ ... OK
>
> * checking running R code from vignettes ...
>
> If ggplot2 is imported, since it is used only in the vignette, and none of
> the function in my package depend on ggplot2, R CMD check generates another
> note:
>
> * checking loading without being on the library search path ... OK
>
> * checking dependencies in R code ... NOTE
>
> Namespace in Imports field not imported from: ‘ggplot2’
>
>   All declared Imports should be used.
>
> * checking S3 generic/method consistency ... OK
>
> * checking replacement functions ... OK
>
>
>
> So I'm wondering if ggplot2 should be imported in this case. Thank you!
>
> Sincerely,
> Xu Ren
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Questions about some checks in the latest BiocCheck

[Vincent Carey]

Can you provide the repo for your package in development?  These BiocCheck
issues are important and
should be resolved at your end.  We can give some advice on how to get
better results with BiocCheck.

On Wed, Nov 28, 2018 at 10:34 AM Casper Peters  wrote:

> So in the package I'm developing, I have a few specific use cases that
> make BiocCheck not so happy.
>
>
>
> 1:
>
>
> ```
>
> * WARNING: Avoid class()== or class()!= ; use is() or !is()
>
> ```
>
> So my first problem arises with checking the classes of objects. I want
> the interface to be such that I can allow for case insensitivity and/or
> allow the object to be NULL in some specific cases. This is easier with
> using `class()` explicitly (especially in the case of case sensitivity).
>
>
>
> 2:
>
>
> ```
>
>  * ERROR: At least 80% of man pages documenting exported objects
>   must have runnable examples. The following pages do not:
> ```
>
> The second problem arises because of some of my exported functions. I made
> parser+download functions for the Fantom5 data, as this was not available
> anywhere inside a package yet. Because of the download being big/taking too
> long, I want to avoid running the checks in R CMD check. For this I added
> \dontrun{} at the examples, resulting in BiocCheck not liking this.
>
>
> Other than that I just have some small notes that I still need to take
> care of, but with these I am not sure what to do.
>
> Thanks in advance,
>
> -Casper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BioC 3.8 build Error

[Vincent Carey]

I also attempted to replicate and I found that one of your serialized data
elements (eveLocus)
was a GRanges that needed updateObject

However I would like to raise a question about this:

if(!require("BSgenome.Dmelanogaster.UCSC.dm3", character.only = TRUE)){

if (!requireNamespace("BiocManager", quietly=TRUE))

install.packages("BiocManager")

BiocManager::install("BSgenome.Dmelanogaster.UCSC.dm3")

}

library(BSgenome.Dmelanogaster.UCSC.dm3)


I think that installing packages in vignettes should be

avoided.  You can put BSgenome.Dmelanogaster.UCSC.dm3 in

Suggests.


On Wed, Oct 17, 2018 at 11:12 AM, Martin, Patrick C N 
wrote:

> Hi Lori,
>
>
> Thank you very much! That seemed to have done the trick. At least now I
> can replicate the error.
>
>
> Thank you for your help.
>
>
>
> Kind Regards
>
>
>
> Patrick Martin
>
> 
> From: Shepherd, Lori 
> Sent: 17 October 2018 15:54:04
> To: Martin, Patrick C N; bioc-devel@r-project.org
> Subject: Re: BioC 3.8 build Error
>
>
> I am able to reproduce this ERROR on a local copy of the ChIPanalyser
>  cloned from git.bioconductor.org  (version 1.3.5)
>
>
>
> Please make sure all package and associated package are updated.
> BiocInstaller is being deprecated so I suggest using BiocManager to update
> the packages
>
>
>
> install.packages("BiocManager")
>
> library(BiocManager)
>
> install(version="3.8")
>
> This should indicate if there are any additional packages that are
> out-of-date
>
>
>
> From the looks of your sessionInfo  you have a mixture of release and
> devel versions of packages so the above should suggest which packages need
> to be updated.  Once you update all versions of the packages, please see if
> you can replicate the ERROR.
>
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Martin,
> Patrick C N 
> Sent: Wednesday, October 17, 2018 10:40:34 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] BioC 3.8 build Error
>
> To whom it may concern,
>
>
> It has recently come to my attention that my package ( ChIPanalyser1.3.2
> on BioC 3.8) generates a build error.
>
>
> However, I cannot seem to replicate that error on my local machine. The
> version of the package that I have pushed towards both github
> (patrickCNMartin/ChIPanalyser) and to bioconductor passes both R CMD build
> and R CMD check on my local machine.
>
>
> I suspected that my R version could be outdated ( I was running R3.4.1)
> however even after updating to R3.5.1 and updating all relevant packages, I
> still cannot replicate the error. ChIPanalyser still passes through Build
> and Check.
>
>
> I also tested ChIPanalyser1.3.1 that is available on the devel branch to
> see if that one would build on my local machine and it does (also passes R
> CMD check ).
>
>
> Here is my sessionInfo()
>
>
> R version 3.5.1 (2018-07-02)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.1 LTS
>
> Matrix products: default
> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
>
> locale:
>  [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
>  [5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
>  [7] LC_PAPER=en_GB.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] parallel  stats4stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
> [1] GenomicRanges_1.32.7 GenomeInfoDb_1.16.0  IRanges_2.14.12
> [4] S4Vectors_0.18.3 BiocGenerics_0.26.0  BiocInstaller_1.30.0
>
> loaded via a namespace (and not attached):
> [1] zlibbioc_1.26.0compiler_3.5.1 XVector_0.20.0
> [4] tools_3.5.1GenomeInfoDbData_1.1.0 RCurl_1.95-4.11
> [7] bitops_1.0-6
>
>
>
> I am currently out of ideas on how to replicate and fix the build error.
>
>
> Thank you for your help.
>
>
>
> Kind Regards
>
>
>
>
> Patrick Martin
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> 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] a pattern to be avoided? mcols(x)$y <- z

[Vincent Carey]

The following comes up in use of Fdb.InfiniumMethylation.hg19::getPlatform


debug: mcols(GR)$channel <- Rle(as.factor(mcols(GR)$channel450))

Browse[3]> system.time(uu <- Rle(as.factor(mcols(GR)$channel450)))

   user  system elapsed

  0.020   0.003   0.022

Browse[3]> system.time(mcols(GR)$channel <-
Rle(as.factor(mcols(GR)$channel450)))

   user  system elapsed

 47.263   0.067  47.373

Browse[3]> GR$channel[1]

factor-Rle of length 1 with 1 run

  Lengths:1

  Values : Both

Levels(3): Both Grn Red

Browse[3]> system.time(GR$channel <- Rle(as.factor(mcols(GR)$channel450)))

   user  system elapsed

  0.058   0.006   0.065


Presumably the mcols()$<- copies/rewrites a lot of data needlessly?

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Error: file larger than 5 Mb.

[Vincent Carey]

your annotation hub is out of date.  run hub = AnnotationHub() and try again

On Wed, Sep 26, 2018 at 3:48 PM, Bohdan Khomtchouk 
wrote:

> Martin, I don't see it unfortunately:
>
> > query(hub, "Mus_musculus.GRCm38.93.chr.gtf")
> AnnotationHub with 0 records
> # snapshotDate(): 2018-04-30
>
> But perhaps it needs to be added to AnnotationHub, because I see other
> .chr.gtf files that go up to 86 (while I'm using 93 in this original post):
>
> > query(hub, c("GTF", "Mus musculus", ".chr.gtf"))
> AnnotationHub with 112 records
> # snapshotDate(): 2018-04-30
> # $dataprovider: Ensembl
> # $species: Mus musculus
> # $rdataclass: GRanges
> # additional mcols(): taxonomyid, genome, description,
> #   coordinate_1_based, maintainer, rdatadateadded, preparerclass,
> #   tags, rdatapath, sourceurl, sourcetype
> # retrieve records with, e.g., 'object[["AH50868"]]'
>
> title
>   AH50868 | Mus_musculus.GRCm38.84.chr.gtf
>   AH51038 | Mus_musculus.GRCm38.85.chr.gtf
>   AH51979 | Mus_musculus.GRCm38.86.chr.gtf
>   AH51983 | Mus_musculus_129s1svimj.129S1_SvImJ_v1.86.chr.gtf
>   AH51986 | Mus_musculus_aj.A_J_v1.86.chr.gtf
>   ...   ...
>   AH61202 | Mus_musculus_lpj.LP_J_v1.92.chr.gtf
>   AH61205 | Mus_musculus_nodshiltj.NOD_ShiLtJ_v1.92.chr.gtf
>   AH61208 | Mus_musculus_nzohlltj.NZO_HlLtJ_v1.92.chr.gtf
>   AH61211 | Mus_musculus_pwkphj.PWK_PhJ_v1.92.chr.gtf
>   AH61214 | Mus_musculus_wsbeij.WSB_EiJ_v1.92.chr.gtf
>
> So it looks like "AH51979 | Mus_musculus.GRCm38.86.chr.gtf" is the latest
> one available in AnnotationHub right now.
>
>
> On Tue, Sep 25, 2018 at 10:35 PM Martin Morgan 
> wrote:
>
>> Good news, the file is in AnnotationHub and can be used from there.
>> There is a download cost the first time but not subsequently.
>>
>> library(AnnotationHub)
>> hub = AnnotationHub()
>> query(hub, "Mus_musculus.GRCm38.93.chr.gtf.gz")
>>
>> ## note 'AH' number, then...
>> gtf = hub[["AH63797"]]
>>
>> Need the path rather than the imported path? use cache(hub["AH63797"])
>> instead.
>>
>> Martin
>>
>> On 09/25/2018 09:59 PM, Bohdan Khomtchouk wrote:
>> > To generate mouse.rda, I used:
>> >
>> > library(rtracklayer)
>> > mouse <- readGFF("
>> > ftp://ftp.ensembl.org/pub/release-93/gtf/mus_musculus/
>> Mus_musculus.GRCm38.93.chr.gtf.gz
>> > ")
>> >
>> > And then I saved the object as mouse.rda
>> >
>> >
>> > On Tue, Sep 25, 2018 at 6:33 PM Bohdan Khomtchouk <
>> khomtchouk...@gmail.com>
>> > wrote:
>> >
>> >> Here it is:
>> >> https://github.com/Bohdan-Khomtchouk/geneXtendeR/blob/
>> master/data/mouse.rda
>> >>
>> >>
>> >> On Tue, Sep 25, 2018 at 6:23 PM Vincent Carey <
>> st...@channing.harvard.edu>
>> >> wrote:
>> >>
>> >>> (resending with reply all -- please reply to this one)
>> >>>
>> >>> Can you say some more about the content of the file?  Perhaps it can
>> be
>> >>> placed in ExperimentHub.  "mouse.rda" is not very descriptive.  is it
>> >>> in your github repo?
>> >>>
>> >>>
>> >>> On Tue, Sep 25, 2018 at 6:25 PM, Bohdan Khomtchouk <
>> >>> khomtchouk...@gmail.com> wrote:
>> >>>
>> >>>> I need to include an important .rda file in the /data folder of my
>> >>>> Bioconductor package.  However, this .rda file exceeds 5 Mb in
>> size.  Do
>> >>>> I
>> >>>> have any other options besides for deleting it?
>> >>>>
>> >>>> bohdankhomtchouk$ git push origin master
>> >>>>
>> >>>> Counting objects: 65, done.
>> >>>>
>> >>>> Delta compression using up to 8 threads.
>> >>>>
>> >>>> Compressing objects: 100% (65/65), done.
>> >>>>
>> >>>> Writing objects: 100% (65/65), 13.79 MiB | 7.62 MiB/s, done.
>> >>>>
>> >>>> Total 65 (delta 30), reused 0 (delta 0)
>> >>>>
>> >>>> remote: Error: file larger than 5 Mb.
>> >>>>
>> >>>> remote:
>> >>>>
>> >>>> remote: File name: 'data/mouse.rda'
>> >>>>
>> >>>> remote: File size: 12.9 Mb
>> >>>>
&

Re: [Bioc-devel] Error: file larger than 5 Mb.

[Vincent Carey]

(resending with reply all -- please reply to this one)

Can you say some more about the content of the file?  Perhaps it can be
placed in ExperimentHub.  "mouse.rda" is not very descriptive.  is it
in your github repo?


On Tue, Sep 25, 2018 at 6:25 PM, Bohdan Khomtchouk 
wrote:

> I need to include an important .rda file in the /data folder of my
> Bioconductor package.  However, this .rda file exceeds 5 Mb in size.  Do I
> have any other options besides for deleting it?
>
> bohdankhomtchouk$ git push origin master
>
> Counting objects: 65, done.
>
> Delta compression using up to 8 threads.
>
> Compressing objects: 100% (65/65), done.
>
> Writing objects: 100% (65/65), 13.79 MiB | 7.62 MiB/s, done.
>
> Total 65 (delta 30), reused 0 (delta 0)
>
> remote: Error: file larger than 5 Mb.
>
> remote:
>
> remote: File name: 'data/mouse.rda'
>
> remote: File size: 12.9 Mb
>
> remote:
>
> remote: Please see Biocondcutor guidelines
>
> remote: https://bioconductor.org/developers/package-guidelines/
>
> remote:
>
> To git.bioconductor.org:packages/geneXtendeR
>
>  ! [remote rejected] master -> master (pre-receive hook declined)
>
> error: failed to push some refs to 'g...@git.bioconductor.org:
> packages/geneXtendeR'
>
> --
> Bohdan Khomtchouk, Ph.D.
> AHA Postdoctoral Fellow, Gozani & Assimes Labs
> Department of Biology & Department of Medicine
> Division of Cardiovascular Medicine
> Stanford University
> Stanford, CA 94305
> https://profiles.stanford.edu/bohdan-khomtchouk
>
>
> CONFIDENTIALITY NOTICE: Information contained in this me...{{dropped:9}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Question

[Vincent Carey]

On Sat, Aug 18, 2018 at 12:17 PM, Ghiwa Khalil  wrote:

> Hello,
>
> We are writing a package with 2 main functions, one of these functions
> requires kent utils to be installed.
>
> Since kent utils is supported by only specific operating systems, is it
> recommended to have it in an R package?
>
> If we remove this function then our package will only be based on one
> function, we are not sure if it is clever to submit a package with one
> function. We were thinking to keep the function based on kent utils and
> consider it as an option for users able to use it.
>
>
> Any thoughts on this issue?
>

It is best to have packages that run on all platforms.  The number of
functions
in a package is not an important determinant of usefulness.

What exactly do you require from the "kent utils"?  Have you checked
rtracklayer
for relevant functionality?

You would get best guidance if you identified a github repo where your
package is being developed.  If you are concerned about exposure, you can
invite a developer as a confidential evaluator/consultant.  I would be
willing
to play this role if necessary.

Sincerely,
Vincent Carey

>
>
> Thank you.
>
>  Regards
>
> [[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

Re: [Bioc-devel] Question about package development

[Vincent Carey]

As Lori has noted Bioconductor users have access to many chain files
through AnnotationHub -- please
let us know if these are not sufficient for your needs.

>  library(AnnotationHub)
> ah = AnnotationHub()

> query(ah, "chain")

AnnotationHub with 1513 records

# snapshotDate(): 2018-08-01

# $dataprovider: UCSC

# $species: Homo sapiens, Mus musculus, Bos taurus, Pan troglodytes, Danio
r...

# $rdataclass: ChainFile, GRanges

# additional mcols(): taxonomyid, genome, description,

#   coordinate_1_based, maintainer, rdatadateadded, preparerclass, tags,

#   rdatapath, sourceurl, sourcetype

# retrieve records with, e.g., 'object[["AH5097"]]'


title

  AH5097  | Primate Chain/Net

  AH5098  | Placental Chain/Net

  AH5099  | Vertebrate Chain/Net

  AH5126  | Self Chain

  AH5229  | Chimp Chain/Net

  ...   ...

  AH15215 | sacCer3ToSacCer2.over.chain.gz

  AH15216 | sacCer2ToSacCer1.over.chain.gz

  AH15217 | sacCer2ToSacCer3.over.chain.gz

  AH15218 | sacCer1ToSacCer2.over.chain.gz

  AH15219 | sacCer1ToSacCer3.over.chain.gz


On Fri, Aug 3, 2018 at 4:23 AM, Ghiwa Khalil  wrote:

> To whom it may concern,
>
>
> I am Ghiwa a research assistant at Dr.Pierre Khoeuiry bioinformatic's lab
> at the American University of Beirut.
>
>
> We are currently building our package and we have a question, we hope you
> can help us with.
>
>
> While writing the documentation for the function(.Rd file) the examples
> section is mandatory, but our function uses
>
> chrom.sizes and chain files which should be user provided.
>
> How can we address this while writing the example? Should we include a
> chrom.sizes file and a chain file in the inst folder
> to allow the example to run? And the disadvantage of that would be that
> the package would be large since the chain file is a large file.
>
> Any recommendations?
>
> Thank you.
> Regards,
> Ghiwa
>
>
> [[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

Re: [Bioc-devel] Fwd: Vignette warnings/errors

[Vincent Carey]

add something like this

vignette: >

  %\VignetteIndexEntry{[your index entry]}

  %\VignetteEngine{knitr::rmarkdown}

  %\VignetteEncoding{UTF-8}

to your vignette YAML ... see 1.4.2 of
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-package-vignettes

On Fri, May 11, 2018 at 1:47 PM, Kenneth Condon 
wrote:

> I forgot to add the YAML header of my .rmd file.
>
> ---
> title: "User Guide"
> author: "Kenneth Condon"
> date: "`r Sys.Date()`"
> output:
> html_document:
> number_sections: true
> theme: cerulean
> highlight: default
> toc: TRUE
> toc_depth: 3
> toc_float:
> collapsed: TRUE
> smooth_scroll: FALSE
> ---
>
> Regards,
> Kenneth
>
> -- Forwarded message --
> From: Kenneth Condon 
> Date: Fri, May 11, 2018 at 6:37 PM
> Subject: Vignette warnings/errors
> To: bioc-devel 
>
>
> Hi all,
>
> I'm hoping to submit my package soon. But I am having issues with the
> vignette.
>
> R CMD check results0 errors | 1 warning  | 0 noteschecking files in
> ‘vignettes’ ... WARNING
> Files in the 'vignettes' directory but no files in 'inst/doc':
>   ‘UserGuide.Rmd’, ‘UserGuide.html’, ‘images/benchmark.png’,
> ‘images/workflow.png’
> Files named as vignettes but with no recognized vignette engine:
>‘vignettes/UserGuide.Rmd’
> (Is a VignetteBuilder field missing?)
>
>
> BiocCheck FAILED.$error
> [1] "VignetteBuilder listed in DESCRIPTION but not found as
> VignetteEngine in any vignettes:"
>
>
>
> My DESCRIPTION contains:
> RoxygenNote: 6.0.1
> Suggests: knitr,
> rmarkdown,
> testthat
> VignetteBuilder: knitr
>
> My directory tree looks as follows (note there is no inst/doc/ folder):
> data/
> man/
> R/
> tests/testthat/
> vignettes/images/
>
> Contents of vignettes/:
> images/benchmark.png
>
> images/workflow.png
>
> UserGuide.Rmd # created with use_vignette('UserGuide', pkg =
> myNewPackageName)
> Userguide.html # created successfully with knitr button in Rstudio
>
>
> Can someone instruct me what I am missing?
>
> Regards,
> Kenneth
>
> [[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

Re: [Bioc-devel] Package download when using functions from affy and oligo

[Vincent Carey]

How about a google drive?  This problem of autodownloading should be
addressed directly.
These facilities are still important but their maintenance is clearly a
lower priority as the
technologies handled have diminished use in the field.  I think we should
be able to team up and remove autoinstallation elements of these packages,
and
perhaps improve general maintainability -- Joris, can you pick
one, make a github repo that we can collaborate on revising, and then
we can start?  It will involve a deprecation process.

On Sat, May 5, 2018 at 10:54 AM, Joris Meys  wrote:

> Thank you for the answer.
>
> I was trying to create a reproducible example before I vented maybe a bit
> too much in my previous mail.
>
> I managed to get closer to the problem and it is related to data that was
> corrupted at download. I can send you a reproducible example that bombs R,
> but I will have to send the specific data files as well. How do I send them
> best?
>
> Cheers
> Joris
>
> On Sat, 5 May 2018, 00:09 James W. MacDonald,  wrote:
>
> > I think there are multiple complaints here, so I'll take them one at a
> > time.
> >
> > On Fri, May 4, 2018 at 3:56 PM, Obenchain, Valerie <
> > valerie.obench...@roswellpark.org> wrote:
> >
> >> Joris,
> >>
> >> Sorry I don't have much to offer here. I've cc'd the authors of oligo
> and
> >> affy who may have some insight.
> >>
> >> Valerie
> >>
> >>
> >> On 05/02/2018 11:35 AM, Joris Meys wrote:
> >>
> >> Dear,
> >>
> >> I've noticed that using certain functions in affy and oligo (eg
> >> oligo::read.celfiles and affy::bg.correct) start with downloading
> another
> >> package and end with either R crashing or a warning that -after
> >> installation succeeded- the package is not available.
> >
> >
> > This is true for oligo, and perhaps a bit annoying. If you don't have the
> > package installed already, it gets the package, installs it, and then
> says
> > it's not available. This is an easy enough fix.
> >
> >
> > After which using
> >> some functions of both packages still crash R.
> >>
> >
> > I don't know what to do with that. What functions?
> >
> >
> >>
> >> The warning I get when trying oligo::read.celfiles() on a single CEL
> file
> >> right after installing it about the pd.hugene.1.0.st.v1 package. The
> even
> >> more annoying thing is that on my machine it insists on building from
> >> source, whereas on another Windows machine without Rtools, it downloads
> a
> >> binary.
> >>
> >
> > That is an options setting that gets changed when you install Rtools. The
> > 'pkgType' option gets set to 'both' because you can now install both
> kinds.
> > And in install.packages it ends up getting switched from 'both' to
> > 'source'. I haven't dug any further into that because I am not sure I see
> > why it's a problem. In the end there isn't a difference between
> installing
> > a source or a binary pdInfoPackage, and trying to get it to 'do the right
> > thing' might have some unforeseen consequences that I would rather not
> have
> > to worry about. This is really an 'if it ain't broke, don't fix it'
> > scenario, IMO.
> >
> >
> >
> >>
> >> Reason it frustrates the heck out of me, is that both affy and oligo
> >> crashed the R session in different ways. During installation of a
> package,
> >> during use of a function, and at different points when comparing my
> >> machine
> >> with the one of our students. The culprit seems to be in one of the
> >> underlying packages, but I wasn't even able to detect which package is
> the
> >> culprit, let alone which function crashes everything.
> >>
> >
> > I understand your frustration, but that's not enough to go on. I have
> > never, in like 18 years, had either oligo or affy randomly segfault on
> me.
> > I understand that it is happening for you, but unless you can come up
> with
> > a reproducible example, it's not possible for anybody to help.
> >
> >
> >>
> >> Is there a way around this so I can ensure that at least I have the same
> >> setup as they have and I can try to come up with a reproducible example
> to
> >> report this critical bug?
> >>
> >
> > Again, I am not sure what to do with that. I am not sure what 'a way
> > around this' pertains to, and ensuring you have the same setup as 'they
> > have' seems to be something only you can accomplish. Is there some reason
> > you cannot ensure that you have the same setup on two different
> computers?
> >
> > Best,
> >
> > Jim
> >
> >
> >>
> >> Thank you in advance
> >> Joris
> >>
> >>
> >>
> >>
> >>
> >> 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

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

[Vincent Carey]

yes, the [] is a habit i need to break.  ok, we'll get by.

On Wed, Apr 18, 2018 at 3:09 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

>
>
> On 04/18/2018 02:45 PM, Vincent Carey wrote:
>
>>
>>
>> On Mon, Apr 9, 2018 at 11:23 AM, Martin Morgan <
>> martin.mor...@roswellpark.org <mailto:martin.mor...@roswellpark.org>>
>> wrote:
>>
>>
>>
>> On 04/09/2018 10:51 AM, Ramon Diaz-Uriarte wrote:
>>
>>
>> Dear Martin,
>>
>> On Fri, 06-April-2018, at 18:59:00, Martin Morgan
>> <martin.mor...@roswellpark.org
>> <mailto:martin.mor...@roswellpark.org>> wrote:
>>
>> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>>
>> I have recently faced a similar warning.
>> This is when a link to a help page of another package is
>> broken (there is
>> not such help page). Although those could be false
>> positives:
>> mclapply help page does exists in parallel package.
>> as.MAList does exists in devel limma
>>
>>
>> when \link-ing to another package, from RShowDoc("R-exts")
>> section 2.5
>> the [] has to name the html help page, not the name of the
>> function. For
>> instance, `mclapply` is documented on a man page called
>> mcdummies.Rd
>> (!), so '\link[parallel:mcdummies]{nearest} would presumably
>> not
>>
>>
>> I am confused here: as far as I can tell, there is an
>> mclapply.html file:
>>
>> http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/m
>> clapply.html
>> <http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/
>> mclapply.html>
>>
>> In addition, when I use the \link[parallel:mcdummies] I get a
>> warning when
>> testing under Linux.
>>
>>
>> yeah, this is a pretty good one. If you look at
>>
>> https://github.com/wch/r-source/tree/trunk/src/library/parallel/man
>> <https://github.com/wch/r-source/tree/trunk/src/library/parallel/man>
>>
>> you'll see that there are different man pages for different
>> operating systems. On windows there is mcdummies, on unix mclapply &
>> friends. This seems like a bad idea (users comparing notes to work
>> through a problem get different help pages!). I don't really know
>> how to link explicitly to these in a conditional manner.
>>
>>
>> Does this mean that to cross-reference to MArrayLM-class, I need to find
>> limma source and
>> determine that the topic is covered in marraylm.Rd and use
>> \link[limma:marraylm]{MArrayLM-class} for
>> the cross-reference?  I don't see how this is good -- are the page names
>> programmatically accessible
>> to developers who want to cross-reference?  here's the grep result:
>>
>> marraylm.Rd:\alias{MArrayLM-class}
>>
>
> I agree that this is a bad idea.
>
> I think the first solution is not to use \link[pkg]{foo} when it is not
> needed, which Writing R Extensions (https://cran.r-project.org/do
> c/manuals/r-release/R-exts.html#Cross_002dreferences) says
>
>   "These are rarely needed, perhaps to refer to not-yet-installed packages
> (but there the HTML help system will resolve the link at run time) or in
> the normally undesirable event that more than one package offers help on a
> topic"
>
> Packages you depend / import and even suggest will be installed by the
> build system, so the only need is when two or more packages define the same
> topic.
>
> But even then, when faced with a WARNING, and even Bioc core team members
> or reviewers for new packages hassling you about correcting WARNINGs, I
> personally would trade off sanity for perfection and stick with
> \link[limma]{MArrayLM-class} -- there is a WARNING, but the warning says
> that it's going to treat MArrayLM-class as a topic (alias) and it'll get
> resolved correctly.
>
> Also, for what it's worth, the opinion expressed in
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html
> #Cross_002dreferences is that the fact that these WARNINGs are often
> Windows-specific is more likely that the linux check is wrong (i.e., the
> WARNING should also be generated there). I will try to investigate that
> further.
>
> Martin
>
>
>
>>
>> And in general it seems highly fragile to link to the name of the
>>  

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

[Vincent Carey]

On Mon, Apr 9, 2018 at 11:23 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

>
>
> On 04/09/2018 10:51 AM, Ramon Diaz-Uriarte wrote:
>
>>
>> Dear Martin,
>>
>> On Fri, 06-April-2018, at 18:59:00, Martin Morgan <
>> martin.mor...@roswellpark.org> wrote:
>>
>>> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>>>
>>>> I have recently faced a similar warning.
>>>> This is when a link to a help page of another package is broken (there
>>>> is
>>>> not such help page). Although those could be false positives:
>>>> mclapply help page does exists in parallel package.
>>>> as.MAList does exists in devel limma
>>>>
>>>
>>> when \link-ing to another package, from RShowDoc("R-exts") section 2.5
>>> the [] has to name the html help page, not the name of the function. For
>>> instance, `mclapply` is documented on a man page called mcdummies.Rd
>>> (!), so '\link[parallel:mcdummies]{nearest} would presumably not
>>>
>>
>> I am confused here: as far as I can tell, there is an mclapply.html file:
>>
>> http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html
>>
>> In addition, when I use the \link[parallel:mcdummies] I get a warning when
>> testing under Linux.
>>
>
> yeah, this is a pretty good one. If you look at
>
>   https://github.com/wch/r-source/tree/trunk/src/library/parallel/man
>
> you'll see that there are different man pages for different operating
> systems. On windows there is mcdummies, on unix mclapply & friends. This
> seems like a bad idea (users comparing notes to work through a problem get
> different help pages!). I don't really know how to link explicitly to these
> in a conditional manner.
>

Does this mean that to cross-reference to MArrayLM-class, I need to find
limma source and
determine that the topic is covered in marraylm.Rd and use
\link[limma:marraylm]{MArrayLM-class} for
the cross-reference?  I don't see how this is good -- are the page names
programmatically accessible
to developers who want to cross-reference?  here's the grep result:

marraylm.Rd:\alias{MArrayLM-class}


>
> And in general it seems highly fragile to link to the name of the help
> page, rather than to the alias. I'd treat the 'warning' as (maybe bad)
> advice, rather than a requirement.
>
> On rereading section 2.5, I think \link[pkg]{foo} should work too (if there
>> is a foo.html file.)
>>
>
> it does (but on windows there is no mclapply.html). But also on windows
> the '...treated as a topic' part of the warning actually indicates that R
> has figured out where it should link, so you get the warning but also a
> working link.
>
> Nevertheless, section 2.5 indicates that \link[pkg]{foo} and
>> \link[pkg:bar]{foo} are rarely needed, so I'll try to remove them (except
>> in those cases, covered in section 2.5, where "more than one package
>> offers
>> help on a topic")
>>
>
> yes the first pass should also be the simplest -- no fancy markup unless
> necessary.
>
> Martin
>
>
>
>>
>> generate the warning. Similarly \link[limma:asmalist]{as.MAList}.
>>>
>>> There are several things that still need exploration.
>>>
>>> - platform-specific (I have a vague understanding that Windows is
>>> special, but that might be outdated... [at least in this context...])
>>>
>>>
>> I am only getting the warnings under Windows (which lead me to think it
>> was
>> windows misbehaving).
>>
>>
>> - recent. I have to admit to changing the text of the warning with this
>>> commit
>>>
>>>
>>> https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11e
>>> e2440fbde891cba524e
>>>
>>> but what I was intending to do was to change what it says, from the
>>> warning in release ('missing file link') to what it says, correctly, in
>>> devel 'file link ... does not exist and so has been treated as a topic'.
>>> The old text appears in release, and the new in devel, as anticipated.
>>> If I messed up somehow please let me know...
>>>
>>> - even with the warning, the link isn't broken in the dynamic help
>>> system (it might have been broken prior to my commit...).
>>>
>>
>> OK, thanks.
>>
>> Best,
>>
>>
>> R.
>>
>>
>>
>>> Martin
>>>
>>>
>>>> HTH
>>>>
>>>> On 6 April 2018 at 16:35, Vincent Carey <st...@channing.harvard.edu>
>>>> w

Re: [Bioc-devel] problem with class definitions between S4Vectors and RNeXML in using Summarized Experiment

[Vincent Carey]

But Annotated is defined in S4Vectors and RNeXML; the latter is not a
Bioconductor package.

The likelihood of collisions among class names defined in different
packages seems pretty high
as S4 adoption grows.  So requiring a systematic approach to disambiguating
class references seems inevitable.


On Sat, Apr 14, 2018 at 4:05 AM, Hervé Pagès <hpa...@fredhutch.org> wrote:

> How about renaming Annotated? Isn't having 2 classes around with the
> same name fundamentally a bad situation? No amount of workarounds will
> change that.
>
> H.
>
>
> On 04/12/2018 04:06 PM, Michael Lawrence wrote:
>
>> Yea, good idea, I was thinking of supporting :: in class names and
>> parsing them out. In code is better.  Maybe %::%? It wouldn't have to
>> get a class object (for one thing, a class might not exist), because
>> the methods package supports a 'package' attribute on the character
>> vector, abstracted by packageSlot().
>>
>>
>>
>> On Thu, Apr 12, 2018 at 3:26 PM, Vincent Carey
>> <st...@channing.harvard.edu> wrote:
>>
>>> If we need to disambiguate class references, perhaps an operator
>>>
>>> could help?  Along the lines of base::"::" ...
>>>
>>>
>>> "%c%" <- function(package,class) {
>>>
>>> pk = as.character(substitute(package))
>>>
>>> cl = as.character(substitute(class))
>>>
>>> getClass(cl, where=getNamespace(pk))
>>>
>>> }
>>>
>>>
>>> Biobase %c% ExpressionSet  # a classRepresentation instance
>>>
>>>
>>> is(1:5, Biobase %c% ExpressionSet)  # FALSE
>>>
>>>
>>> is(Biobase::ExpressionSet(), "ExpressionSet")  # TRUE
>>>
>>>
>>> is(Biobase::ExpressionSet(),  Biobase %c% ExpressionSet) # TRUE
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 12, 2018 at 3:57 PM, Michael Lawrence
>>> <lawrence.mich...@gene.com> wrote:
>>>
>>>>
>>>> Hi Davide,
>>>>
>>>> We can get this fixed soon, but I was hoping to hear e.g. Herve's
>>>> opinion first if he has one.
>>>>
>>>> Michael
>>>>
>>>> On Thu, Apr 12, 2018 at 12:53 PM, Davide Risso <dar2...@med.cornell.edu
>>>> >
>>>> wrote:
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Thanks for looking into this.
>>>>>
>>>>> Can you or someone with push permission to S4Vectors implement the
>>>>> workaround that you mentioned?
>>>>>
>>>>> Happy to create a pull request on Github if that helps.
>>>>>
>>>>> We’re trying to solve this to fix the clusterExperiment package build
>>>>> on
>>>>> Bioc-devel.
>>>>>
>>>>> Thanks,
>>>>> Davide
>>>>>
>>>>>
>>>>> On Apr 12, 2018, at 1:27 PM, Michael Lawrence
>>>>> <lawrence.mich...@gene.com>
>>>>> wrote:
>>>>>
>>>>> Yea it's basically
>>>>>
>>>>> library(S4Vectors)
>>>>> library(RNeXML)
>>>>> is(1:5, "Annotated")
>>>>> # Found more than one class "Annotated" in cache; using the first,
>>>>> from namespace 'S4Vectors'
>>>>> # Also defined by ‘RNeXML’
>>>>> # [1] FALSE
>>>>>
>>>>> But can be worked around:
>>>>>
>>>>> is(1:5, getClass("Annotated", where=getNamespace("S4Vectors"))
>>>>>
>>>>> # [1] FALSE
>>>>>
>>>>> Of course, using class objects instead of class names in every call to
>>>>> is() is not very palatable, but that's how it's done in all other
>>>>> languages, as far as I know.
>>>>>
>>>>> There is an inconsistency between new() and is() when resolving the
>>>>> class name. new() looks into the calling package's namespace, while
>>>>> is() looks at the package for the class of the 'object'. The new()
>>>>> approach seems sensible for that function, since packages should be
>>>>> abstracting the construction of their objects with constructors. The
>>>>> is() approach is broken though, because it's easy to imagine cases
>>>>> like where some foreign object is passed to a function, and the
>>&

Re: [Bioc-devel] problem with class definitions between S4Vectors and RNeXML in using Summarized Experiment

[Vincent Carey]

If we need to disambiguate class references, perhaps an operator

could help?  Along the lines of base::"::" ...


"%c%" <- function(package,class) {

   pk = as.character(substitute(package))

   cl = as.character(substitute(class))

   getClass(cl, where=getNamespace(pk))

}


Biobase %c% ExpressionSet  # a classRepresentation instance


is(1:5, Biobase %c% ExpressionSet)  # FALSE

is(Biobase::ExpressionSet(), "ExpressionSet")  # TRUE


is(Biobase::ExpressionSet(),  Biobase %c% ExpressionSet) # TRUE






On Thu, Apr 12, 2018 at 3:57 PM, Michael Lawrence  wrote:

> Hi Davide,
>
> We can get this fixed soon, but I was hoping to hear e.g. Herve's
> opinion first if he has one.
>
> Michael
>
> On Thu, Apr 12, 2018 at 12:53 PM, Davide Risso 
> wrote:
> > Hi Michael,
> >
> > Thanks for looking into this.
> >
> > Can you or someone with push permission to S4Vectors implement the
> > workaround that you mentioned?
> >
> > Happy to create a pull request on Github if that helps.
> >
> > We’re trying to solve this to fix the clusterExperiment package build on
> > Bioc-devel.
> >
> > Thanks,
> > Davide
> >
> >
> > On Apr 12, 2018, at 1:27 PM, Michael Lawrence  >
> > wrote:
> >
> > Yea it's basically
> >
> > library(S4Vectors)
> > library(RNeXML)
> > is(1:5, "Annotated")
> > # Found more than one class "Annotated" in cache; using the first,
> > from namespace 'S4Vectors'
> > # Also defined by ‘RNeXML’
> > # [1] FALSE
> >
> > But can be worked around:
> >
> > is(1:5, getClass("Annotated", where=getNamespace("S4Vectors"))
> >
> > # [1] FALSE
> >
> > Of course, using class objects instead of class names in every call to
> > is() is not very palatable, but that's how it's done in all other
> > languages, as far as I know.
> >
> > There is an inconsistency between new() and is() when resolving the
> > class name. new() looks into the calling package's namespace, while
> > is() looks at the package for the class of the 'object'. The new()
> > approach seems sensible for that function, since packages should be
> > abstracting the construction of their objects with constructors. The
> > is() approach is broken though, because it's easy to imagine cases
> > like where some foreign object is passed to a function, and the
> > function checks the type with is().
> >
> > I can change is() to use the calling package as the fallback, so
> > DataFrame(1:5) no longer produces a message. But calling it from
> > another package, or global env, will still break, just like new(). How
> > does that sound?
> >
> > On the other hand, maybe we should be more careful with calls to is()
> > and use class objects. That's a good workaround in this case, anyway,
> > since I probably can't get the change into R before release.
> >
> > Michael
> >
> >
> > On Thu, Apr 12, 2018 at 9:03 AM, Aaron Lun  wrote:
> >
> > Well, it's not really SingleCellExperiment's problem, either.
> >
> > library(S4Vectors)
> > DataFrame(1:5) # Silent, okay.
> > library(RNeXML)
> > DataFrame(1:5) # Prints out the message
> > ## Found more than one class "Annotated" in cache; using the first,
> > from namespace 'S4Vectors'
> > ## Also defined by ‘RNeXML’
> >
> > Session information attached below.
> >
> > -Aaron
> >
> > sessionInfo()
> >
> > R Under development (unstable) (2018-03-26 r74466)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 16.04.4 LTS
> >
> > Matrix products: default
> > BLAS: /home/cri.camres.org/lun01/Software/R/trunk/lib/libRblas.so
> > LAPACK: /home/cri.camres.org/lun01/Software/R/trunk/lib/libRlapack.so
> >
> > locale:
> > [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
> > [3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
> > [5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
> > [7] LC_PAPER=en_GB.UTF-8   LC_NAME=C
> > [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] parallel  stats4stats graphics  grDevices
> > utils datasets
> > [8] methods   base
> >
> > other attached packages:
> > [1] RNeXML_2.0.8ape_5.1 S4Vectors_0.17.41
> > [4] BiocGenerics_0.25.3
> >
> > loaded via a namespace (and not attached):
> > [1] Rcpp_0.12.16compiler_3.6.0  pillar_1.2.1
> > [4] plyr_1.8.4  bindr_0.1.1 iterators_1.0.9
> > [7] tools_3.6.0 uuid_0.1-2  jsonlite_1.5
> > [10] tibble_1.4.2nlme_3.1-137lattice_0.20-35
> > [13] pkgconfig_2.0.1 rlang_0.2.0 foreach_1.4.4
> > [16] crul_0.5.2  curl_3.2bindrcpp_0.2.2
> > [19] httr_1.3.1  stringr_1.3.0   dplyr_0.7.4
> > [22] xml2_1.2.0  grid_3.6.0  reshape_0.8.7
> > [25] glue_1.2.0  data.table_1.10.4-3 R6_2.2.2
> > [28] XML_3.98-1.10   purrr_0.2.4 reshape2_1.4.3
> > [31] tidyr_0.8.0 magrittr_1.5codetools_0.2-15
> > [34] 

Re: [Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

[Vincent Carey]

Thanks Paul.  Package works.  Browser visualizations look really nice.

I tried to run your unit tests and they
use a function called "printf".  Setting printf = sprintf allowed the tests
to all run to completion.

The following vignette chunk is problematic ... maybe you meant eval=FALSE,
echo=TRUE to show what the
user needs to do?

```{r createLoad, echo=TRUE, echo=FALSE, results='hide'}

igv <- IGV()

setBrowserWindowTitle(igv, "MEF2C")

setGenome(igv, "hg19")

```


It does seem to me that you would need to avoid running

the browser in tests and vignette and examples.  Using

if (interactive()) can help with vignette and examples.

The unit testing of such a package should I think focus

on verifying that the essential data manipulations succeed,

without requiring browser communication.  But others in the

group will have more authoritative remarks on this.


I don't know whether the methods sketched in


https://stackoverflow.com/questions/15509231/unit-testing-node-js-and-websockets-socket-io


could be used in this task, to go beyond checking the basic

R manipulations.


On Mon, Apr 9, 2018 at 8:15 PM, Paul Shannon <pshan...@systemsbiology.org>
wrote:

> Hi Vince,
>
> My dumb mistake, sorry.  Now fixed, version 0.99.9,
> https://github.com/paul-shannon/IGV
>
> I’m looking forward to hearing your suggestions.
>
>  - Paul
>
>
>
> > On Apr 9, 2018, at 4:49 PM, Vincent Carey <st...@channing.harvard.edu>
> wrote:
> >
> > Hi Paul -- I am trying to build your vignette but it has
> >
> > load("~/s/work/priceLab/AD/tbl.gwas.level_1.RData")
> >
> > I think it should be possible to get your package through
> > check, but I would like to get the vignette built and
> > check out the tests before commenting further.
> >
> >
> > On Mon, Apr 9, 2018 at 1:52 PM, Paul Shannon <
> paul.thurmond.shan...@gmail.com> wrote:
> > > "Once your package builds and checks without errors or (avoidable)
> warnings, a Bioconductor team member will provide a technical review of
> your package. Other Bioconductor developers and users with domain expertise
> are encouraged to provide additional community commentary. Reviewers will
> add comments to the issue you created.”
> >
> > I don’t believe my submission, IGV, quite fits the mold.  As best I can
> tell, no web browser can be summoned on any of the architectures by IGV
> during build or check.  So the package build always times out.  And so,
> according to the guideline quoted above, it will never be reviewed!
> >
> > IGV is a BrowserViz version >=2 subclass; BrowserViz was recently
> uprev’d in devel.  Like RCyjs, IGV's raison d’être is the provision of R
> access to interactive graphics in your web browser, in this case to Jim
> Robinson’s igv.js.
> >
> > My analysis may be incorrect.  Can this matter receive a little
> attention, despite the bioc submission guideline quoted above, in hopes
> that the package can move forward?
> >
> > Thank you,
> >
> >  - Paul
> > ___
> > 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

Re: [Bioc-devel] new package IGV needs web browsers on the build machines to pass build & check

[Vincent Carey]

Hi Paul -- I am trying to build your vignette but it has

load("~/s/work/priceLab/AD/tbl.gwas.level_1.RData")


I think it should be possible to get your package through

check, but I would like to get the vignette built and

check out the tests before commenting further.


On Mon, Apr 9, 2018 at 1:52 PM, Paul Shannon <
paul.thurmond.shan...@gmail.com> wrote:

> > "Once your package builds and checks without errors or (avoidable)
> warnings, a Bioconductor team member will provide a technical review of
> your package. Other Bioconductor developers and users with domain expertise
> are encouraged to provide additional community commentary. Reviewers will
> add comments to the issue you created.”
>
> I don’t believe my submission, IGV, quite fits the mold.  As best I can
> tell, no web browser can be summoned on any of the architectures by IGV
> during build or check.  So the package build always times out.  And so,
> according to the guideline quoted above, it will never be reviewed!
>
> IGV is a BrowserViz version >=2 subclass; BrowserViz was recently uprev’d
> in devel.  Like RCyjs, IGV's raison d’être is the provision of R access to
> interactive graphics in your web browser, in this case to Jim Robinson’s
> igv.js.
>
> My analysis may be incorrect.  Can this matter receive a little attention,
> despite the bioc submission guideline quoted above, in hopes that the
> package can move forward?
>
> Thank you,
>
>  - Paul
> ___
> 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

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

[Vincent Carey]

ive seen this too apropos bigrquery on windows

On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte 
wrote:

>
> Dear All,
>
> Two packages I maintain are showing, in Windows, a warning during check
> with messages like
>
> Rd warning:
> C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/OncoSimulR/man/oncoSimulIndiv.Rd:570:
> file link 'mclapply' in package 'parallel' does not exist and so has been
> treated as a topic
>
> or
>
> Rd warning:
> C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45:
> file link 'as.MAList' in package 'limma' does not exist and so has been
> treated as a topic
>
>
>
> that I cannot reproduce under Linux and that I think are false
> positives. Is there a way to avoid this warning? As far as I can tell,
> those links really exist.
>
> Best,
>
>
> R.
>
> --
> Ramon Diaz-Uriarte
> Department of Biochemistry, Lab B-25
> Facultad de Medicina
> Universidad Autónoma de Madrid
> Arzobispo Morcillo, 4
> 28029 Madrid
> Spain
>
> Phone: +34-91-497-2412
>
> Email: rdia...@gmail.com
>ramon.d...@iib.uam.es
>
> http://ligarto.org/rdiaz
>
> ___
> 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