Re: [Rd] ALTREP string methods for substr and nchar

2019-12-19 Thread Gabriel Becker
Hi Jim,

Thanks for posting this. Honestly the methods list I initially proposed
years ago and the one Luke eventually put in which had some of what I had
said and a bunch of new stuff, was pretty heavily focused on numeric values
(exclusively so, in my case, I think).

I agree that there is a lot of space to beef up how AltStrings behave. I
agree that nchar and substring also make a lot of sense. Perhaps nzchar as
well.

There are some other things that might be good as well. In particularly
Michael Lawrence and I have talked about things like AltStrings that *know* all
their elements have the same encoding in the same way that numeric,
integer, or nwo logical ALTREP vectors can know they don't have any NAs.
The suspicion being that this would make certain expensive (I think)
encoding checks and possibly conversions, much cheaper. I'm far from an
expert on encodings and the the costs/difficulties therein, but the concept
seems pretty straightforward and reasonable to me.

I hope to get back to the matching logic and get that hooked in  (I did a
bunch of work on it sometime ago but it ended up having problems at the
time, so it either never went in or it did go in but luke had to pull it
back out, I don't recall which). When(/if) that does happen I'd suspect
that matching would be another one that we'd want AltStrings to have first
class support for.

Regexes in general are probably another big area, since I'd think it would
be nice to not need to wrap and unrwap  the elements when the underlying
library doesn't want them wrapped as CHARSXPs anyway...

Another area that is more fraught, but my intuition suggests might be
really nice, is pasting. A paste(x,collapse="bla") method would be easily
achievable and potentially useful. paste(x,y, z) where x is an ALTREP with
a paste method could also be nice, potentially returning the same type of
AltString representation of the concatenation. If there were both paste
before and paste after then it would be possible to potentially support
arbitrary pastes, though things would get complicated (perhaps fatally so?)
if more than one argument was an AltString.

Overall, though I agree. it is looking like I'll have some time shortly to
get back to some R things I've been wanting to do so I'll put a proposal
for some string altmethods together and see what people (mostly Luke, tbh)
think.

Best,
~G

On Thu, Dec 19, 2019 at 11:39 AM Jim Hester 
wrote:

> A useful extension of ALTREP is having two new string methods which
> return the number of characters of a given string element and to
> return a substring of an element.
>
> Having these methods would allow retrieving these values without
> needing to create a CHARSXP for the full element data, which could
> potentially be costly for long elements.
>
> For example say you have an ALTREP altstring vector where each element
> holds the sequence of a single chromosome, it would be useful to query
> the lengths of each chromosome and retrieve the first 100 characters
> etc. without having to put the whole chromosome in memory. I realize
> there are tools in Bioconductor to handle this particular case, but it
> seems the general case would be perfect for ALTREP.
>
> Jim
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Bioc-devel] peculiar warning in BiocOncoTK

2019-12-19 Thread 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


Re: [Bioc-devel] Trigger a new build after version bump

2019-12-19 Thread Martin Morgan
It seems like in your vignette you are trying to install your own package. But 
if you needed to install the package, then the vignette wouldn't be available 
to install it from... ;) In this code chunk

```{r results='hide',message=FALSE,warning=FALSE}
if (!requireNamespace("BiocManager", quietly = TRUE))
install.packages("BiocManager", repos = "http://cran.us.r-project.org;)
BiocManager::install("OmicsLonDA")
```

Change the options to

```{r, eval = FALSE}

Martin

On 12/19/19, 2:22 PM, "Bioc-devel on behalf of Ahmed Metwally" 
 wrote:

Hi,


The built is has been done on the updates I pushed. Here you see that the 
release version has been bumped to 1.2.1 instead of 1.2.0 and dev version has 
been bumped to 1.3.3 instead of 1.3.0.

However, I still see the same error as before. Here is the OS built results 
for the release branch: 
http://bioconductor.org/checkResults/release/bioc-LATEST/OmicsLonDA/merida1-buildsrc.html

Command output


##

##
###
### Running command:
###
###   /Library/Frameworks/R.framework/Versions/Current/Resources/bin/R CMD 
build --keep-empty-dirs --no-resave-data OmicsLonDA
###

##

##


* checking for file �OmicsLonDA/DESCRIPTION� ... OK
* preparing �OmicsLonDA�:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building �OmicsLonDA.Rmd� using rmarkdown
Bioconductor version 3.10 (BiocManager 1.30.10), R 3.6.2 (2019-12-12)
Installing package(s) 'OmicsLonDA'
trying URL 
'https://bioconductor.org/packages/3.10/bioc/bin/macosx/el-capitan/contrib/3.6/OmicsLonDA_1.2.0.tgz'
Content type 'application/x-gzip' length 5219591 bytes (5.0 MB)

In the above snippet, it says "trying URL 
'https://bioconductor.org/packages/3.10/bioc/bin/macosx/el-capitan/contrib/3.6/OmicsLonDA_1.2.0.tgz'
"

v1.2.0 is the old version. The new version is 1.2.1. Should I update 
anything to make sure BioC checks the new version "1.2.1"?

Thanks,

From: Bioc-devel  on behalf of Ahmed 
Metwally 
Sent: Tuesday, December 17, 2019 4:58 AM
To: Shepherd, Lori 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Trigger a new build after version bump

Great! Thank you, Lori

Ahmed A. Metwally
Sent from iPhone

On Dec 17, 2019, at 4:21 AM, Shepherd, Lori 
mailto:lori.sheph...@roswellpark.org>> wrote:

Jakob is correct.   To expand a bit more:
The results will not be present on today's build report but should be there 
on tomorrows.   We do a git pull around 4:45 PM EST for the daily builds.  If 
commits are made after that (which it seems like in this case) it would be on 
the following days.
For What Its worth I do see your changes on 
git.bioconductor.org so you were able to push them 
correctly.

Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Ahmed Metwally mailto:ametw...@stanford.edu>>
Sent: Tuesday, December 17, 2019 2:49 AM
To: Jakob Theorell 
mailto:jakob.theor...@ndcn.ox.ac.uk>>; 
bioc-devel@r-project.org 
mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] Trigger a new build after version bump

Hi Jakob,

Thanks for your explanation. I was looking for any statement about how long 
should I wait but couldn't find any. I pushed the updates around 6 hours ago. 
I'll wait for 24-48h as you suggested and will check back.

Best,

From: Jakob Theorell 
mailto:jakob.theor...@ndcn.ox.ac.uk>>
Sent: Monday, December 16, 2019 10:35 PM
To: Ahmed Metwally mailto:ametw...@stanford.edu>>; 
bioc-devel@r-project.org 
mailto:bioc-devel@r-project.org>>
Subject: Re: Trigger a new build after version bump

Dear Ahmed,
I am not in the core team, but I still wonder: how long have you waited 
since you pushed? During the review process you get an immediate update of the 
package upon push with a version bump, but with accepted packages it takes 
24-48 hours for the changes to trickle through to the build report. And you 
have to go in and check the build reports yourself on the BioConductor sites 

Re: [Bioc-devel] peculiar warning in BiocOncoTK

2019-12-19 Thread Martin Morgan
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?

Martin

On 12/19/19, 2:22 PM, "Bioc-devel on behalf of Vincent Carey" 
 
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.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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Rd] ALTREP string methods for substr and nchar

2019-12-19 Thread Jim Hester
A useful extension of ALTREP is having two new string methods which
return the number of characters of a given string element and to
return a substring of an element.

Having these methods would allow retrieving these values without
needing to create a CHARSXP for the full element data, which could
potentially be costly for long elements.

For example say you have an ALTREP altstring vector where each element
holds the sequence of a single chromosome, it would be useful to query
the lengths of each chromosome and retrieve the first 100 characters
etc. without having to put the whole chromosome in memory. I realize
there are tools in Bioconductor to handle this particular case, but it
seems the general case would be perfect for ALTREP.

Jim

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Bioc-devel] peculiar warning in BiocOncoTK

2019-12-19 Thread 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


Re: [Bioc-devel] Trigger a new build after version bump

2019-12-19 Thread Ahmed Metwally
Hi,


The built is has been done on the updates I pushed. Here you see that the 
release version has been bumped to 1.2.1 instead of 1.2.0 and dev version has 
been bumped to 1.3.3 instead of 1.3.0.

However, I still see the same error as before. Here is the OS built results for 
the release branch: 
http://bioconductor.org/checkResults/release/bioc-LATEST/OmicsLonDA/merida1-buildsrc.html

Command output

##
##
###
### Running command:
###
###   /Library/Frameworks/R.framework/Versions/Current/Resources/bin/R CMD 
build --keep-empty-dirs --no-resave-data OmicsLonDA
###
##
##


* checking for file �OmicsLonDA/DESCRIPTION� ... OK
* preparing �OmicsLonDA�:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building �OmicsLonDA.Rmd� using rmarkdown
Bioconductor version 3.10 (BiocManager 1.30.10), R 3.6.2 (2019-12-12)
Installing package(s) 'OmicsLonDA'
trying URL 
'https://bioconductor.org/packages/3.10/bioc/bin/macosx/el-capitan/contrib/3.6/OmicsLonDA_1.2.0.tgz'
Content type 'application/x-gzip' length 5219591 bytes (5.0 MB)

In the above snippet, it says "trying URL 
'https://bioconductor.org/packages/3.10/bioc/bin/macosx/el-capitan/contrib/3.6/OmicsLonDA_1.2.0.tgz'
"

v1.2.0 is the old version. The new version is 1.2.1. Should I update anything 
to make sure BioC checks the new version "1.2.1"?

Thanks,

From: Bioc-devel  on behalf of Ahmed Metwally 

Sent: Tuesday, December 17, 2019 4:58 AM
To: Shepherd, Lori 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Trigger a new build after version bump

Great! Thank you, Lori

Ahmed A. Metwally
Sent from iPhone

On Dec 17, 2019, at 4:21 AM, Shepherd, Lori 
mailto:lori.sheph...@roswellpark.org>> wrote:

Jakob is correct.   To expand a bit more:
The results will not be present on today's build report but should be there on 
tomorrows.   We do a git pull around 4:45 PM EST for the daily builds.  If 
commits are made after that (which it seems like in this case) it would be on 
the following days.
For What Its worth I do see your changes on 
git.bioconductor.org so you were able to push them 
correctly.

Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Ahmed Metwally mailto:ametw...@stanford.edu>>
Sent: Tuesday, December 17, 2019 2:49 AM
To: Jakob Theorell 
mailto:jakob.theor...@ndcn.ox.ac.uk>>; 
bioc-devel@r-project.org 
mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] Trigger a new build after version bump

Hi Jakob,

Thanks for your explanation. I was looking for any statement about how long 
should I wait but couldn't find any. I pushed the updates around 6 hours ago. 
I'll wait for 24-48h as you suggested and will check back.

Best,

From: Jakob Theorell 
mailto:jakob.theor...@ndcn.ox.ac.uk>>
Sent: Monday, December 16, 2019 10:35 PM
To: Ahmed Metwally mailto:ametw...@stanford.edu>>; 
bioc-devel@r-project.org 
mailto:bioc-devel@r-project.org>>
Subject: Re: Trigger a new build after version bump

Dear Ahmed,
I am not in the core team, but I still wonder: how long have you waited since 
you pushed? During the review process you get an immediate update of the 
package upon push with a version bump, but with accepted packages it takes 
24-48 hours for the changes to trickle through to the build report. And you 
have to go in and check the build reports yourself on the BioConductor sites 
related to the release and devel branches.
Best regards
Jakob Theorell, MD/PhD
Autoimmune Neurology Group
Nuffield Department of Clinical Neurosciences
University of Oxford


From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Ahmed Metwally mailto:ametw...@stanford.edu>>
Sent: 17 December 2019 02:34
To: bioc-devel@r-project.org 
mailto:bioc-devel@r-project.org>>
Subject: [Bioc-devel] Trigger a new build after version bump

Dear Bioc devel team,

OmicsLonDA package is failing to build on release and devel branches:
http://bioconductor.org/checkResults/release/bioc-LATEST/OmicsLonDA/
http://bioconductor.org/checkResults/devel/bioc-LATEST/OmicsLonDA/


I have fixed the issue and pushed the changes to RELEASE_3_10, and dev-master 
branch. I bumped the package version on the RELEASE_3_10 to v1.2.1 instead of 

Re: [Bioc-devel] Final List of Deprecated Packages for Bioc3.10

2019-12-19 Thread Turaga, Nitesh
Hi Ludwig,

Thank you for volunteering to take over as maintainer for PathNet and 
PathNetData. 

You should now have access to both packages as the maintainer. They should show 
up on the build machine tomorrow. 

You should port your fix(s) to the build machine for the PathNet package when 
you can and see if it is fixed on the devel builder.


Best regards,

 Nitesh 

> On Dec 4, 2019, at 1:54 PM, Shepherd, Lori  
> wrote:
> 
> We will start the process and be in touch off the bioc mailing list.
> 
> We would require you officially take over as maintainer as all bioconductor 
> packages require an active maintainer.  PathNet was failing and we reached 
> out (several times) and deemed the package orphaned as we never heard back 
> from the currently listed maintainer.
> 
> Cheers,
> 
> 
> Lori Shepherd
> 
> Bioconductor Core Team
> 
> Roswell Park Comprehensive Cancer Center
> 
> Department of Biostatistics & Bioinformatics
> 
> Elm & Carlton Streets
> 
> Buffalo, New York 14263
> 
> 
> From: Ludwig Geistlinger 
> Sent: Wednesday, December 4, 2019 1:32 PM
> To: Shepherd, Lori ; bioc-devel@r-project.org 
> 
> Subject: Re: Final List of Deprecated Packages for Bioc3.10
> 
> 
> Yes, I could do that if needed.
> 
> 
> From: Shepherd, Lori 
> Sent: Wednesday, December 4, 2019 1:28 PM
> To: Ludwig Geistlinger; bioc-devel@r-project.org
> Subject: Re: Final List of Deprecated Packages for Bioc3.10
> 
> ***ATTENTION: This email came from an external source. Do not open 
> attachments or click on links from unknown senders or unexpected emails.***
> 
> Are you volunteering to permanently take over as maintainer of this package?
> 
> 
> 
> Lori Shepherd
> 
> Bioconductor Core Team
> 
> Roswell Park Comprehensive Cancer Center
> 
> Department of Biostatistics & Bioinformatics
> 
> Elm & Carlton Streets
> 
> Buffalo, New York 14263
> 
> 
> From: Ludwig Geistlinger 
> Sent: Wednesday, December 4, 2019 1:22 PM
> To: Shepherd, Lori ; bioc-devel@r-project.org 
> 
> Subject: Re: Final List of Deprecated Packages for Bioc3.10
> 
> Hi Lori,
> 
> Is it possible to undeprecate the "PathNet" package?
> I just checked, the problem is a failing unit test, causing the otherwise 
> well working package to fail R CMD check.
> 
> I fixed this here on a local clone of 
> https://git.bioconductor.org/packages/PathNet
>  and could push these minor changes if granted access.
> 
> The PathNet package implements a solid network-based enrichment method and 
> the corresponding paper has some 50 citations - it would thus be unfortunate 
> to see it gone.
> 
> Thanks,
> Ludwig
> 
> 
> 
> From: Bioc-devel  on behalf of Shepherd, 
> Lori 
> Sent: Monday, October 7, 2019 9:41 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Final List of Deprecated Packages for Bioc3.10
> 
> The Bioconductor Team is continuing to identify packages that will be 
> deprecated in the next release to allow for the Bioconductor community to 
> respond accordingly.
> 
> The final list for the 3.10 release is as follows:
> 
> Maintainer requested deprecation:
> 
> Software:
> 
> SNPchip
> GenomeGraphs
> HTSanalyzeR
> Rchemcpp
> charm
> Pbase
> 
> 
> Experiment Data Package:
> 
> charmData
> 
> 
> 
> Unresponsive/not-maintained packages:
> 
> Software:
> 
> dSimer
> flipflop
> exomePeak
> CNPBayes
> brainImageR
> plateCore
> rHVDM
> SEPA
> condcomp
> PathNet
> scone
> birte
> mlm4omics
> RnaSeqSampleSize
> 
> 
> Experiment Data Package:
> 
> facopy.annot
> allenpvc
> 
> 
> Renaming The package CAMTHC is marked for deprecation. This package has been 
> renamed to debCAM
> 
> 
> 
> The following Annotation Packages have been user requested deprecated:
> 
> MafDb.gnomADex.r2.0.1.GRCh38
> MafDb.gnomAD.r2.0.1.GRCh38
> MafDb.gnomADex.r2.0.1.hs37d5
> MafDb.gnomAD.r2.0.1.hs37d5
> They are replaced with
> 
> MafDb.gnomADex.r2.1.GRCh38
> MafDb.gnomAD.r2.1.GRCh38
> MafDb.gnomADex.r2.1.hs37d5
> MafDb.gnomAD.r2.1.hs37d5
> 
> 
> The Bioconductor team will continue to send emails out to packages that have 
> been broken across all platforms for an extended period of time as those are 
> packages that are up for immediate deprecation if not corrected in a timely 
> fashion. Packages that are ERRORing and not fixed before the October 30th 
> 3.10 release will immediately be marked as deprecated in devel 3.11.
> 
> Thank you
> 
> 
> Lori Shepherd
> 
> Bioconductor Core Team
> 
> Roswell Park Comprehensive Cancer Center
> 
> Department of Biostatistics & Bioinformatics
> 
> Elm & Carlton Streets
> 
> Buffalo, New York 14263
> 
> 
> This email message may contain legally 

Re: [Bioc-devel] Question regarding pruning release of large files

2019-12-19 Thread Turaga, Nitesh
Hi Saskia,

Mike is correct, you cannot force push to the Bioconductor git repo. 

If you point me to the GitHub location, and you are confident that you want 
your repo overwritten, let me know I'll force push it for you.

Best,

Nitesh 


> On Dec 19, 2019, at 8:49 AM, Mike Smith  wrote:
> 
> Hi Saskia,
> 
> There's some documentation on this at
> https://bioconductor.org/developers/how-to/git/remove-large-data/
> 
> I guess the most pertinent part is "The Bioconductor git server does not
> allow -f or to force push to the git.bioconductor.org location. Please
> email bioc-devel@r-project.org explaining the package has been cleaned for
> large data files and needs to be reset.".  Seems like you've done the
> emailing part, so I'm sure someone will be in touch soon.
> 
> Mike
> 
> On Thu, 19 Dec 2019 at 05:20, Saskia Freytag <
> saskia.frey...@perkins.uwa.edu.au> wrote:
> 
>> Hi,
>> 
>> I stupidly added and tracked some large files in my package repo at the
>> start. I have since deleted these files and would like to permanently
>> remove them form my GitHub history. I have been able to this locally.
>> However when I try to do ‘git push upstream RELEASE_3_10’, it asks me to
>> fetch first. This results in the history being restored. I have tried to do
>> ‘git push —force’, but this results in an error. Is there any way to delete
>> the history of these files from the upstream?
>> 
>> Cheers,
>> 
>> Saskia
>> ___
>> 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



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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Bioconductor Developers Forum - Thursday 19th December

2019-12-19 Thread Mike Smith
Dear all,

Just a reminder that this is happening today.

It appears I am resolutely wishing for summer time still - the intended
time is 09:00 PST/ 12:00 EST / 18:00 CET

Best wishes,
Mike

On Mon, 16 Dec 2019 at 15:49, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 19th
> December at 09:00 PDT/ 12:00 EDT / 18:00 CEST
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> If you have any specific topics you'd like to raise please let me know or
> post in #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] Question regarding pruning release of large files

2019-12-19 Thread Mike Smith
Hi Saskia,

There's some documentation on this at
https://bioconductor.org/developers/how-to/git/remove-large-data/

I guess the most pertinent part is "The Bioconductor git server does not
allow -f or to force push to the git.bioconductor.org location. Please
email bioc-devel@r-project.org explaining the package has been cleaned for
large data files and needs to be reset.".  Seems like you've done the
emailing part, so I'm sure someone will be in touch soon.

Mike

On Thu, 19 Dec 2019 at 05:20, Saskia Freytag <
saskia.frey...@perkins.uwa.edu.au> wrote:

> Hi,
>
> I stupidly added and tracked some large files in my package repo at the
> start. I have since deleted these files and would like to permanently
> remove them form my GitHub history. I have been able to this locally.
> However when I try to do ‘git push upstream RELEASE_3_10’, it asks me to
> fetch first. This results in the history being restored. I have tried to do
> ‘git push —force’, but this results in an error. Is there any way to delete
> the history of these files from the upstream?
>
> Cheers,
>
> Saskia
> ___
> 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: [Rd] head/tail breaking change

2019-12-19 Thread Martin Maechler
> Jan Gorecki 
> on Thu, 19 Dec 2019 11:49:11 +0530 writes:

> Thank you Gabriel,
> I agree that new behaviour makes much more sense. Just wanted to confirm
> before resolving compatibility of my unit tests.
> Best,
> Jan

Indeed, Gabe's explanation is right-on-spot:  With the
generalization of head() / tail(), we really found it undesirable to
stay "internally inconsistent".

We do have to grab the chance for not-quite-back-compatible
improvements -- when the costs look comparably small --  for R 4.0.0.

Martin

> On Wed 18 Dec, 2019, 10:46 PM Gabriel Becker,  
wrote:

>> Jan,
>> 
>> That is an intentional change as you can see in the documentation for
>> head/tail in R-devel. Last time I discussed it with Martin, this behavior
>> was desired and thus is unlikely to change unless "our" (ie his) mind 
does.
>> 
>> The hope is that the new behavior is actually what people would want 
(note
>> it already behaves this way for data.frames and for matrices, which are 
now
>> explicitly array objects with 2 dimensions as well as classed as 
matrices,
>> so its more consistent now, and more reasonable for the object).
>> 
>> Best,
>> ~G
>> 
>> On Wed, Dec 18, 2019 at 2:44 AM Jan Gorecki  wrote:
>> 
>>> Hi R-devel community,
>>> 
>>> I am aware of changes in R-devel in head/tail methods but I was not
>>> expecting that to be a breaking change.
>>> 
>>> # R 3.6.1
>>> ar = array(1:27, c(3,3,3))
>>> tail(ar, 1)
>>> #[1] 27
>>> 
>>> The current output of R-devel is something that I would expect from a
>>> 
>>> tail(ar, c(1, Inf, Inf))
>>> 
>>> or
>>> 
>>> tail(ar, c(1, NA, NA))
>>> 
>>> calls.
>>> Is it going to stay like this or there are plans to mitigate this
>>> breaking change?
>>> 
>>> # R-devel 2019-12-17 r77592
>>> ar = array(1:27, c(3,3,3))
>>> tail(ar, 1)
>>> #, , 1
>>> #
>>> # [,1] [,2] [,3]
>>> #[3,]369
>>> #
>>> #, , 2
>>> #
>>> # [,1] [,2] [,3]
>>> #[3,]   12   15   18
>>> #
>>> #, , 3
>>> #
>>> # [,1] [,2] [,3]
>>> #[3,]   21   24   27
>>> 
>>> Best,
>>> Jan Gorecki
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 

> [[alternative HTML version deleted]]

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel