Re: [Bioc-devel] Request to Add an Additional Developer to CRISPRseek on Bioconductor

Thanks Lori! I will sign up for both as you suggested. Lmk if you need anything from my end. Best, --Kai From: Zhu, Lihua (Julie) Sent: Wednesday, November 27, 2024 8:25:25 AM To: Kern, Lori ; bioc-devel@r-project.org ; Hu, Kai Subject: Re: Request to Add an A

Re: [Bioc-devel] Request to Add an Additional Developer to CRISPRseek on Bioconductor

Thank you very much for your help, Lori! Best regards, Julie From: Kern, Lori Sent: Wednesday, November 27, 2024 7:51 AM To: bioc-devel@r-project.org ; Hu, Kai ; Zhu, Lihua (Julie) Subject: Re: Request to Add an Additional Developer to CRISPRseek on Bioconduct

Re: [Bioc-devel] Request to Add an Additional Developer to CRISPRseek on Bioconductor

We can assist with this request. We will need to set up a BiocCredentials account for Dr. Kai Hu. I will be in touch off mailing list to continue this process. It will be recommended that the additional maintainer also sign up for the bioc-devel mailing list and support site with appropriate w

Re: [Bioc-devel] Request un-deprecation of bioconductor package TnT

Thank you for fixing the package. TnT has been undeprecated in 3.19 and will reappear in devel 3.20. Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 ___

Re: [Bioc-devel] Request to be added as Maintainer for SingleCellSignalR Package

Dear Jean-Philippe, There are some examples on the mailing list how this has gone in the past. For example this one: https://stat.ethz.ch/pipermail/bioc-devel/2021-May/018105.html Usually the current maintainer asks for it with the new maintainer in copy (or vice-versa and the previous maintainer

Re: [Bioc-devel] Request to Retire COHCAP Bioconductor Package

Hi Lori, Thank you very much for your help. As long as it won't be a problem that I don't think my COH e-mail address will not be able to receive messages after 4/30, then I agree to direct removal. I believe this is what has been discussed with Yate-Ching and Xiwei, in terms of the general t

Re: [Bioc-devel] Request to Retire COHCAP Bioconductor Package

We normally like to do a full round of a package in a deprecation state before removal completely (so deprecated in Bioc 3.19 and removed in Bioc 3.20) but since there are no reverse dependencies, I don't think this should be an issue to directly remove from 3.19 without deprecation. Please con

Re: [Bioc-devel] Request to add maintainers for diffHic

Do Hannah and Gordon already have BiocCredentials accounts? If so please let me know the email or userid. If not I can create them and Hannah and Gordon should let me know which email they would like for access and if they have a github id they would like associated with the account. Cheers,

Re: [Bioc-devel] Request for undeprecation for exomePeak2

exomePeak2 was never deprecated. You can push to the devel branch to also fix the package in devel and then it will be available https://bioconductor.org/checkResults/devel/bioc-LATEST/exomePeak2/ Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Departm

Re: [Bioc-devel] Request to reverse package deprecation (and support pushing changes)

Responded to the slack message as well but so it is documented on the mailing list. If the package was deprecated, yes you must request undeprecation here. The package was failing for over 6 months without updates or efforts to fix. We will only undeprecate once the package is building cleanl

Re: [Bioc-devel] Request for undeprecation of motifbreakR

Please also make sure that an active email is in the maintainer field of the DESCRIPTION; this is the email we use for communication. Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffa

Re: [Bioc-devel] Request for undeprecation of motifbreakR

Thank you. Yes we can undeprecate the package. Please remember to also push your changes to RELEASE_3_17 branch as the package is also failing there. Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlt

Re: [Bioc-devel] Request for advice on ANCOMBC package error messages in Linux platform

You have this in line 1093-1094 ```{r} samp_frac = out$samp_frac And yet it appears that there is no 'out' object ever generated. There is an 'output' object, that perhaps you meant to use? Also, the vignette building is skipped for Windows and MacOS, which is why it is passing check on those

Re: [Bioc-devel] Request GWAS.BAYES to be un-deprecated

Since the package is building cleanly in devel, we will undeprecate the package. Thank you for your contiued contributions to Bioconductor. Cheers, Lori Shepherd Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Stre

Re: [Bioc-devel] Request access to EGSEA123

I believe you should have access now. Let us know if you do not. 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 be

Re: [Bioc-devel] Request package deprecation

Gives me some nostalgia because I think simpleaffy was the first Bioconductor package I used! Il gio 27 ago 2020, 1:46 PM Shepherd, Lori ha scritto: > Thank you for letting us know. I will begin the deprecation process for > the package. Thank you for your contributions. > > > Lori Shepherd > >

Re: [Bioc-devel] Request package deprecation

Thank you for letting us know. I will begin the deprecation process for the package. Thank you for your contributions. Lori Shepherd Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 _

Re: [Bioc-devel] request

, Ashwath ; Bioc-devel@r-project.org Subject: Re: [Bioc-devel] request Please view the nightly build report http://bioconductor.org/checkResults/devel/bioc-LATEST/CSSQ/ compare the time that your package had a 'snapshot' taken for the build to start Snapshot Date: 2020-05-29 16:51:41 -040

Re: [Bioc-devel] request

Please view the nightly build report http://bioconductor.org/checkResults/devel/bioc-LATEST/CSSQ/ compare the time that your package had a 'snapshot' taken for the build to start Snapshot Date: 2020-05-29 16:51:41 -0400 (Fri, 29 May 2020) and commit hash and date of the last commit included in

Re: [Bioc-devel] request

Hello all, I am the maintainer for CSSQ (https://bioconductor.org/packages/release/bioc/html/CSSQ.html). I had made some changes (Re authorship and email addresses) to the package last night. I made sure to push them to both the master and RELEASE_3_11 branches and confirmed the changes by

Re: [Bioc-devel] Request to undeprecate MANOR

Yes we will undeprecated the MANOR package. Are you working on the ERROR's in the devel report? These cannot be ignored. Lori Shepherd Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 1

Re: [Bioc-devel] Request R code this paper

Hi Joris, I think that it's a spam email. I've gotten a similar if not the same version directly already. Best, Leo On Tue, Jan 7, 2020 at 10:48 AM Joris Meys wrote: > Dear, > > you mailed the developers mailing list of Bioconductor, i.e. the list for > people who develop packages for the Bioc

Re: [Bioc-devel] Request R code this paper

Dear, you mailed the developers mailing list of Bioconductor, i.e. the list for people who develop packages for the Bioconductor suite. Please mail the authors of the paper instead. If you know the package they used, the source code of each package can be found on the bioconductor website. Kin

Re: [Bioc-devel] Request to un-deprecate a package

Hi, “biocLite" will stay deprecated for R version 3.5.2. Please note that the issue is not with “biocLite" but with “mmnet". “mmnet” has been deprecated for R-3.5.z and is defunct for R-3.6.z. There are other workaround solutions to this, where you may install the package from the tarball (ht

Re: [Bioc-devel] Request upstream pull --force of sanitized master branch

Thanks for fixing this Nitesh and Sam! I wrote that R check and forgot that it depended on the Gencode url. I had to fix this too for recount https://github.com/leekgroup/recount/commit/056e81c326143e3748b452988ac15a6bed3b035e. Best, Leo On Mon, Nov 5, 2018 at 3:14 PM Turaga, Nitesh wrote: > >

Re: [Bioc-devel] Request upstream pull --force of sanitized master branch

Hi Sam, I fixed the RELEASE_3_8 branch as well. There was a minor discrepancy in the commit history for RELEASE_3_8 though, (which I fixed in git.bioconductor.org/packages/bumphunter) so you should resync RELEASE_3_8 in rafalab/bumphunter. The commit history on rafalab/bumphunter:RELEASE_3_8

Re: [Bioc-devel] Request upstream pull --force of sanitized master branch

Hi Nitesh, I have fixed the commit history for rafalab/bumphunter RELEASE_3_8 branch, and request synchronization with Bioconductor RELEASE_3_8. We need this, because bumphunter is not building on RELEASE_3_8, due to an obsolete URL in one of the tests. thanks, - Sam On 11/5/18 7:56 AM, T

Re: [Bioc-devel] Request upstream pull --force of sanitized master branch

Hi Sam, I have updated your “master” branch on git.bioconductor.com to reflect what you have on GitHub, at https://github.com/rafalab/bumphunter. You will not get the duplicate commit error when you push to the master branch anymore. However, RELEASE_3_8 still has duplicate commits in the his

Re: [Bioc-devel] Request the change of the email of the maintainer

Hi Sohrab, If you still have access to the old email you can change this yourself. Activate your account here with the old email: https://git.bioconductor.org/BiocCredentials Once activated you can login. Then got to --> user profile --> update email. If you don't have access to sohrab.sar..

Re: [Bioc-devel] Request for comment metagenomeFeatures package

Thanks, Martin. I agree using AnnotationHub to manage the db resources is a better option than how it is currently setup. A pull request would be much appreciated. On Tue, Aug 4, 2015 at 3:14 PM Vincent Carey wrote: > On Tue, Aug 4, 2015 at 3:00 PM, Martin Morgan > wrote: > >> On 08/04/2015 0

Re: [Bioc-devel] Request for comment metagenomeFeatures package

On Tue, Aug 4, 2015 at 3:00 PM, Martin Morgan wrote: > On 08/04/2015 06:43 AM, Nathan Olson wrote: > >> We are starting to work on an infrastructure for annotation of 16S >> metagenomic >> sequencing datasets and would like your comments and/or contributions. >> Below are >> links to two github r

Re: [Bioc-devel] Request for comment metagenomeFeatures package

On 08/04/2015 06:43 AM, Nathan Olson wrote: We are starting to work on an infrastructure for annotation of 16S metagenomic sequencing datasets and would like your comments and/or contributions. Below are links to two github repositories: metagenomeFeatures and greengenes13.5MgDb. The metagenomeFe

Re: [Bioc-devel] Request for comment metagenomeFeatures package

Thanks Vince, I think we just fixed that: https://github.com/HCBravoLab/greengenes13.5MgDb/issues/1#issuecomment-127649449 Cheers, Hector On Tue, Aug 4, 2015 at 10:45 AM, Vincent Carey wrote: > very interesting development, we have several folks who will take a look. > > FYI > > %vjcair> R CMD

Re: [Bioc-devel] Request for comment metagenomeFeatures package

very interesting development, we have several folks who will take a look. FYI %vjcair> R CMD INSTALL greeng*b Bioconductor version 3.2 (BiocInstaller 1.19.9), ?biocLite for help Loading required package: digest Loading required package: tools Loading required package: utils Loading required

Re: [Bioc-devel] request for more notices about build issues

That would be great. On Tue, Apr 14, 2015 at 2:48 PM, Michael Love wrote: > works for me. Thanks Dan. > > On Tue, Apr 14, 2015 at 2:34 PM, Dan Tenenbaum > wrote: > > > > > > - Original Message - > >> From: "Michael Love" > >> To: bioc-devel@r-project.org > >> Sent: Wednesday, April 8,

Re: [Bioc-devel] request for more notices about build issues

works for me. Thanks Dan. On Tue, Apr 14, 2015 at 2:34 PM, Dan Tenenbaum wrote: > > > - Original Message - >> From: "Michael Love" >> To: bioc-devel@r-project.org >> Sent: Wednesday, April 8, 2015 11:03:02 AM >> Subject: [Bioc-devel] request for more notices about build issues >> >> dear

Re: [Bioc-devel] request for more notices about build issues

- Original Message - > From: "Michael Love" > To: bioc-devel@r-project.org > Sent: Wednesday, April 8, 2015 11:03:02 AM > Subject: [Bioc-devel] request for more notices about build issues > > dear core Bioc-ers, > > It would be nice to have more devel mailing list notices about large >

Re: [Bioc-devel] request for more notices about build issues

Is this a use case for a "graphical" build report that displays the build status on a graph/DAG? http://www.bioconductor.org/packages/release/bioc/vignettes/pkgDepTools/inst/doc/pkgDepTools.pdf pkgDepTools, combined with a computable build report (a downloadable version of the current build repor

Re: [Bioc-devel] request for more notices about build issues

- Original Message - > From: "Michael Love" > To: bioc-devel@r-project.org > Sent: Wednesday, April 8, 2015 11:03:02 AM > Subject: [Bioc-devel] request for more notices about build issues > > dear core Bioc-ers, > > It would be nice to have more devel mailing list notices about large >

Re: [Bioc-devel] request to create BSgenome Bos_taurus_UMD3.1.1

On 03/29/2015 12:31 AM, Byungkuk Min wrote: I appreciate your effort, but I'm having trouble to download it. > source("http://bioconductor.org/biocLite.R";) > biocLite("BSgenome.Btaurus.UCSC.bosTau8") Warning message: package ‘BSgenome.Btaurus.UCSC.bosTau8’ is not available (for R version 3.

Re: [Bioc-devel] request to create BSgenome Bos_taurus_UMD3.1.1

So I went ahead and did BSgenome.Btaurus.UCSC.bosTau8. It should become available via biocLite() in the next couple of hours (in BioC devel only). H. On 03/26/2015 12:54 AM, Hervé Pagès wrote: Hi Byungkuk, On 03/25/2015 10:17 PM, Byungkuk Min wrote: Dear Dr.Pages, I've been trying to build a

Re: [Bioc-devel] request to create BSgenome Bos_taurus_UMD3.1.1

Hi Byungkuk, On 03/25/2015 10:17 PM, Byungkuk Min wrote: Dear Dr.Pages, I've been trying to build a BSgenome for Bos_taurus_UMD3.1.1 from NCBI . But I'm getting the same error message... library(BSgenome) forgeBSgenomeDataPkg("/PATH/TO/ge

Re: [Bioc-devel] request: high-level seqlevel utilities

Hi, With the convenience that seqnamesStyles offers now, having to specify the chromosome name notation manually would feel like a step back. In terms of subsetting genomic ranges, I normally think of four major groups of interest: - Toplevel/standard: 1,..22,X,Y,MT - Autosomes: 1,..,22 - A

Re: [Bioc-devel] request: high-level seqlevel utilities

The dropSeqlevels approach for the autosomes is acceptable in terms of readability, but it means the code needs to know the seqname style (chrX rather than just X). On Fri, Dec 27, 2013 at 1:49 PM, Valerie Obenchain wrote: > I think the idea was to avoid the proliferation of small, specialized >

Re: [Bioc-devel] request: high-level seqlevel utilities

I think the idea was to avoid the proliferation of small, specialized functions. library(TxDb.Hsapiens.UCSC.hg19.knownGene) gr <- transcripts(TxDb.Hsapiens.UCSC.hg19.knownGene) ## autosomes std <- keepStandardChromosomes(gr, "Homo sapiens", "UCSC") dropSeqlevels(std, c("chrX", "chrY")) ## allo

Re: [Bioc-devel] request: high-level seqlevel utilities

Hi Sonali, Thank you for this much requested addition to the GenomicRanges API! I would like to second Michael Lawrence's assertion that keepAutosomes() is more straightforward and harder to misunderstand or misuse than a special case of keep/dropSeqlevels. (If the author of a function has tr

Re: [Bioc-devel] request: high-level seqlevel utilities

Michael, Since there is no universal seqnameStyle defined for various objects and they do not internally store the seqnameStyle and species information, we decided to ask the user for all 3 arguments. Marc is aware of these issues and my code. Regarding the dependency of GenomicRanges on Anno

Re: [Bioc-devel] request: high-level seqlevel utilities

I guess you mean dropSeqlevels, not keepSeqlevels? That should work. But your function needs some tweaking, I think. The function should just take the seqnameStyle from the object. There's no need to require the user to specify it, and then check for consistency. I would like to be able to just cal

Re: [Bioc-devel] request: high-level seqlevel utilities

Hi Michael, We decided to come up with one function called keepStandardChromosomes() which is a wrapper for both the functions suggested by you (i.e., keepPrimaryChromosomes() and keepAutosomes() ) Here is an example: library(AnnotationDbi) library(GenomicRanges) txdb <- loadDb(system.file("ext

Re: [Bioc-devel] request: high-level seqlevel utilities

Awesome -- how about keepAutosomes? On Tue, Dec 24, 2013 at 1:11 PM, Arora, Sonali wrote: > Hi everyone, > > We are pleased to announce that we have added a new function called > keepStandardChromosomes() to GenomicRanges(1.15.18) - devel branch. > > This function allows a user to subset a g

Re: [Bioc-devel] request: high-level seqlevel utilities

Hi everyone, We are pleased to announce that we have added a new function called keepStandardChromosomes() to GenomicRanges(1.15.18) - devel branch. This function allows a user to subset a given object (containing a seqinfo class) to retain only the primary chromosomes and the autosomes. Plea

Re: [Bioc-devel] request: high-level seqlevel utilities

Awesome, thanks, Sonali. And welcome to the team. Michael On Mon, Dec 16, 2013 at 10:38 AM, Arora, Sonali wrote: > Hi Michael, > > That is an extremely interesting question. We have a couple of ideas and > are beginning to work on it. > We hope to come up with something soon. > > Thanks, > Son

Re: [Bioc-devel] request: high-level seqlevel utilities

Hi Michael, That is an extremely interesting question. We have a couple of ideas and are beginning to work on it. We hope to come up with something soon. Thanks, Sonali. On 12/16/2013 6:14 AM, Michael Lawrence wrote: should be stored with the Seqinfo. It could be imputed (along with the is

Re: [Bioc-devel] request: high-level seqlevel utilities

On Mon, Dec 16, 2013 at 5:00 AM, Julian Gehring wrote: > Hi Michael, > > I would second your request. In a package I'll submitting soon, I have a > work-around for this by defining a set of functions like 'hsAutosomes', > 'hsAllosomes' etc. that return the respective set of human chromosome > nam

Re: [Bioc-devel] request: high-level seqlevel utilities

Hi Michael, I would second your request. In a package I'll submitting soon, I have a work-around for this by defining a set of functions like 'hsAutosomes', 'hsAllosomes' etc. that return the respective set of human chromosome names. Perhaps on could incorporate this in the 'seqinfo' class,

Re: [Bioc-devel] request: high-level seqlevel utilities

Is this being taken into consideration by anyone? Will it be worked on? Thanks, Michael On Thu, Dec 12, 2013 at 1:36 PM, Michael Lawrence wrote: > We've found that analysts often need to restrict seqlevels to certain > pre-defined sets of chromsomes. Given the variability across organisms, it

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Laurent, On 04/22/2013 12:55 PM, Laurent Gatto wrote: Dear all, Recently, there was a discussion about generics conventions and the possibility of defining normalize in BiocGenerics. I believe that the consensus was to implement the latter in Bioc 2.13: [ ... ] On 21 February 2013 20:16, H

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Dear all, Recently, there was a discussion about generics conventions and the possibility of defining normalize in BiocGenerics. I believe that the consensus was to implement the latter in Bioc 2.13: [ ... ] On 21 February 2013 20:16, Hervé Pagès wrote: > If we agree on this, I'll add it to our

Re: [Bioc-devel] request: timings

On Sat, Mar 16, 2013 at 9:21 PM, Kasper Daniel Hansen wrote: > Is it possible to get _R_CHECK_TIMINGS_=0 set in the build system when > R CMD check is being run? Not super important, but convenient and it > should be easy to add. Done. This will be effective in tomorrow's build report. Dan >

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Wolfgang, On 02/21/2013 01:23 PM, Wolfgang Huber wrote: Hi Herve I have absolutely no objections against 'normalize' in BiocGenerics, I think it is a good idea. OK, thanks! However, the concept of a 'universal namespace' and that no package can mask symbols defined in other packages I

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Herve I have absolutely no objections against 'normalize' in BiocGenerics, I think it is a good idea. However, the concept of a 'universal namespace' and that no package can mask symbols defined in other packages I find objectionable. There is no 'redefining' of functions as you suggest bel

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Laurent, Robert, and others, On 02/20/2013 01:33 PM, Laurent Gautier wrote: On 2013-02-20 22:02, Hervé Pagès wrote: Hi Robert, Nice to hear from you! I'm just a little bit worried that if we put normalize() in BiocGenerics without at the same time have a "take it or leave it" policy, then

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

On 2013-02-20 22:02, Hervé Pagès wrote: Hi Robert, Nice to hear from you! I'm just a little bit worried that if we put normalize() in BiocGenerics without at the same time have a "take it or leave it" policy, then most of the authors of the 10 packages are likely going to ignore that there is n

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

On 02/20/2013 01:02 PM, Hervé Pagès wrote: ... Furthermore, the good citizens that modify their package to use the normalize() in BiocGenerics will be in a situation worth than before because, from an end user point of view, their normalize() function (which is now a method attached to BiocGeneri

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Robert, Nice to hear from you! I'm just a little bit worried that if we put normalize() in BiocGenerics without at the same time have a "take it or leave it" policy, then most of the authors of the 10 packages are likely going to ignore that there is now a new normalize() in BiocGenerics. The

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

my 2c worth On Wed, Feb 20, 2013 at 10:45 AM, Hervé Pagès wrote: > Hi, > > I agree with Laurent that we can't really play the semantic and concept > police. It's the responsibility of package authors to decide whether > it's appropriate or not to call "normalization" that particular > transformat

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Dear all, Looking at the alphabetical list of functions/methods in BioGenerics I have the feeling that all functions are really generic, i.e. general, with the exception of function 'annotation' which in my opinion should be part of BioBase as method for one or more of the BioBase classes. T

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Laurent, LEo there is a clash between two concepts, which seem difficult & messy to reconcile, and all I wanted to do with my initial post was to spur an explicit discussion and awareness of this, rather than just doing it implicitly. Not yet sure if that is going to be productive. 1. packa

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi, I agree with Laurent that we can't really play the semantic and concept police. It's the responsibility of package authors to decide whether it's appropriate or not to call "normalization" that particular transformation they're implementing. However I hope that we all agree on the following

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

On 2013-02-20 17:32, Schalkwyk, Leonard wrote: Is this not just an indication that normalize is now a poor choice of a function name? If the package authors called the functions "normalize", this means either: 1- at least some of the package authors have named a function performing an action

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Is this not just an indication that normalize is now a poor choice of a function name? LEo On 20 Feb 2013, at 16:14, Wolfgang Huber wrote: > Hi > > is it clear that all these different functions (methods) share similar > semantics and enough (conceptually) of their interface? > > Wouldn't

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi is it clear that all these different functions (methods) share similar semantics and enough (conceptually) of their interface? Wouldn't the implication be that preemptively every possible string of characters should already be defined as a generic function in BiocGenerics? Best wish

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

On 19 February 2013 22:44, Hervé Pagès wrote: > Hi Laurent, and maintainers of packages with a normalize() function, > > > On 02/15/2013 04:28 AM, Laurent Gatto wrote: >> >> A quick (and incomplete) manual search using >> http://search.bioconductor.jp/ suggest the following usage of >> normalize:

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi, I have no objection and I am willing to support this generic in the package codelink. I agree that it is better to wait for the next release cycle so that we maintainers have enough time to make the changes. Thank you, Diego On Wed, Feb 20, 2013 at 7:44 AM, Hervé Pagès wrote: > Hi Laurent,

Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics

Hi Laurent, and maintainers of packages with a normalize() function, On 02/15/2013 04:28 AM, Laurent Gatto wrote: A quick (and incomplete) manual search using http://search.bioconductor.jp/ suggest the following usage of normalize: As a function: xps::normalize codelink::normalize EBImage::norm