Re: [Bioc-devel] providerVersion error with BSgenome genomes
Finally, I found this which might be a suitable option:
metadata(BSgenome.Dmelanogaster.UCSC.dm3)$genome
>"dm3"
But happy to hear about alternatives.
Best,
Diego
On Sat, Jul 18, 2020 at 12:56 AM Diego Diez wrote:
>
> I found that the providerVersion method has been deprecated (see
> commit log below). Is there an official way to obtain that information
> now? I could do unique(genome(dm3)) but not sure if this is the best
> approach.
>
> Diego
>
> commit f99ceb5d17ca6dcf886600bf1fbf5d7c398de75c
> Author: Hervé Pagès
> Date: Fri Jun 26 18:49:17 2020 -0700
>
> A couple of changes to GenomeDescription objects
>
> - The GenomeDescription() constructor looses its 'provider_version'
> argument.
> - The providerVersion() accessor is now deprecated.
>
> On Sat, Jul 18, 2020 at 12:46 AM Diego Diez wrote:
> >
> > To add more information, this is what I get for
> > showMethods("providerVersion") using Bioc 3.11:
> >
> > >showMethods("providerVersion")
> > Function: providerVersion (package GenomeInfoDb)
> > x="BSgenome"
> > (inherited from: x="GenomeDescription")
> > x="GenomeDescription"
> > x="GFFFile"
> > x="SNPlocs"
> > x="XtraSNPlocs"
> >
> > But with Bioc devel I get:
> >
> > showMethods("providerVersion")
> > Function: providerVersion (package GenomeInfoDb)
> > x="GenomeDescription"
> > x="GFFFile"
> > x="SNPlocs"
> > x="XtraSNPlocs"
> >
> > So it seems providerVersion has lost the BSgenome method. Is this an
> > intentional change or something that needs to be fixed?
> >
> > Thank you.
> > Diego
> >
> > On Thu, Jul 16, 2020 at 2:38 PM Diego Diez wrote:
> > >
> > > Dear all,
> > >
> > > I am finding an error when running the following code:
> > >
> > > > library(BSgenome.Dmelanogaster.UCSC.dm3)
> > > Loading required package: BSgenome
> > > Loading required package: GenomeInfoDb
> > > Loading required package: GenomicRanges
> > > Loading required package: rtracklayer
> > >
> > > > dm3 <- BSgenome.Dmelanogaster.UCSC.dm3
> > > > providerVersion(dm3)
> > > Error in (function (classes, fdef, mtable) :
> > > unable to find an inherited method for function ‘providerVersion’
> > > for signature ‘"BSgenome"’
> > >
> > > > BiocManager::version()
> > > [1] ‘3.12’
> > >
> > >
> > > I am expecting to get "dm3" with this genome. What would be the proper
> > > way to do this?
> > >
> > > Thank you.
> > >
> > > Best,
> > >
> > > Diego
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] providerVersion error with BSgenome genomes
I found that the providerVersion method has been deprecated (see
commit log below). Is there an official way to obtain that information
now? I could do unique(genome(dm3)) but not sure if this is the best
approach.
Diego
commit f99ceb5d17ca6dcf886600bf1fbf5d7c398de75c
Author: Hervé Pagès
Date: Fri Jun 26 18:49:17 2020 -0700
A couple of changes to GenomeDescription objects
- The GenomeDescription() constructor looses its 'provider_version'
argument.
- The providerVersion() accessor is now deprecated.
On Sat, Jul 18, 2020 at 12:46 AM Diego Diez wrote:
>
> To add more information, this is what I get for
> showMethods("providerVersion") using Bioc 3.11:
>
> >showMethods("providerVersion")
> Function: providerVersion (package GenomeInfoDb)
> x="BSgenome"
> (inherited from: x="GenomeDescription")
> x="GenomeDescription"
> x="GFFFile"
> x="SNPlocs"
> x="XtraSNPlocs"
>
> But with Bioc devel I get:
>
> showMethods("providerVersion")
> Function: providerVersion (package GenomeInfoDb)
> x="GenomeDescription"
> x="GFFFile"
> x="SNPlocs"
> x="XtraSNPlocs"
>
> So it seems providerVersion has lost the BSgenome method. Is this an
> intentional change or something that needs to be fixed?
>
> Thank you.
> Diego
>
> On Thu, Jul 16, 2020 at 2:38 PM Diego Diez wrote:
> >
> > Dear all,
> >
> > I am finding an error when running the following code:
> >
> > > library(BSgenome.Dmelanogaster.UCSC.dm3)
> > Loading required package: BSgenome
> > Loading required package: GenomeInfoDb
> > Loading required package: GenomicRanges
> > Loading required package: rtracklayer
> >
> > > dm3 <- BSgenome.Dmelanogaster.UCSC.dm3
> > > providerVersion(dm3)
> > Error in (function (classes, fdef, mtable) :
> > unable to find an inherited method for function ‘providerVersion’
> > for signature ‘"BSgenome"’
> >
> > > BiocManager::version()
> > [1] ‘3.12’
> >
> >
> > I am expecting to get "dm3" with this genome. What would be the proper
> > way to do this?
> >
> > Thank you.
> >
> > Best,
> >
> > Diego
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] providerVersion error with BSgenome genomes
To add more information, this is what I get for
showMethods("providerVersion") using Bioc 3.11:
>showMethods("providerVersion")
Function: providerVersion (package GenomeInfoDb)
x="BSgenome"
(inherited from: x="GenomeDescription")
x="GenomeDescription"
x="GFFFile"
x="SNPlocs"
x="XtraSNPlocs"
But with Bioc devel I get:
showMethods("providerVersion")
Function: providerVersion (package GenomeInfoDb)
x="GenomeDescription"
x="GFFFile"
x="SNPlocs"
x="XtraSNPlocs"
So it seems providerVersion has lost the BSgenome method. Is this an
intentional change or something that needs to be fixed?
Thank you.
Diego
On Thu, Jul 16, 2020 at 2:38 PM Diego Diez wrote:
>
> Dear all,
>
> I am finding an error when running the following code:
>
> > library(BSgenome.Dmelanogaster.UCSC.dm3)
> Loading required package: BSgenome
> Loading required package: GenomeInfoDb
> Loading required package: GenomicRanges
> Loading required package: rtracklayer
>
> > dm3 <- BSgenome.Dmelanogaster.UCSC.dm3
> > providerVersion(dm3)
> Error in (function (classes, fdef, mtable) :
> unable to find an inherited method for function ‘providerVersion’
> for signature ‘"BSgenome"’
>
> > BiocManager::version()
> [1] ‘3.12’
>
>
> I am expecting to get "dm3" with this genome. What would be the proper
> way to do this?
>
> Thank you.
>
> Best,
>
> Diego
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] providerVersion error with BSgenome genomes
Dear all, I am finding an error when running the following code: > library(BSgenome.Dmelanogaster.UCSC.dm3) Loading required package: BSgenome Loading required package: GenomeInfoDb Loading required package: GenomicRanges Loading required package: rtracklayer > dm3 <- BSgenome.Dmelanogaster.UCSC.dm3 > providerVersion(dm3) Error in (function (classes, fdef, mtable) : unable to find an inherited method for function ‘providerVersion’ for signature ‘"BSgenome"’ > BiocManager::version() [1] ‘3.12’ I am expecting to get "dm3" with this genome. What would be the proper way to do this? Thank you. Best, Diego ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Bioconductor git server beta testing begins now.
Hi Nitesh, Thank you for the explanation. Now everything is clear. Best, Diego On Mon, Jul 10, 2017 at 10:55 PM, Turaga, Nitesh wrote: > Hi Diego, > > This is a good question. > > Please note, that when you do a 'git clone¹, you are getting the commit > history of every branch, and master(trunk) locally. Git stores the log of > the commit history(trees, commits and blobs) locally in the .git/object > directory. > > When you checkout an svn branch, you are checking out 1 specific branch, > i.e, trunk or RELEASE_X_Y. It also needs to connect to the server to get > the commit history of your files. > > These are fundamental differences in the way these version control systems > work, and this difference is expected. > > Best, > > Nitesh > > > >>Dear all, >> >>Great to know that the git transition is moving forward. I tested >>cloning (https) several packages and I noticed a significant >>difference in the repository size between svn and git. Two examples >>showing the output (svn/git) of du -k: >> >>Biobase: 4968 / 8720 >>limma: 6284 / 20296 >> >>Looking briefly at the .git folder inside the repositories it seems >>the .pack file inside .git/objects/pack takes most of the overweight. >>I wonder if this is expected? >> >>Thank you. >> >>Diego >> >>PS: commands used to obtain the repositories: >> >>git clone https://git.bioconductor.org/packages/limma >>svn co https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/limma >>--username readonly >> >>On Fri, Jul 7, 2017 at 9:42 PM, Turaga, Nitesh >> wrote: >>> Dear Maintainers, >>> >>> For those of you who have submitted your public github id instead of >>>your >>> public SSH key, please make sure that the link >>> `www.github.com/.keys` is valid and shows your SSH key. >>> >>> If that is not valid, we are not able to add your SSH key to the >>> bioconductor server. >>> >>> Thanks, >>> >>> Nitesh >>> >>> >Dear Maintainers > >As announced earlier this year, Bioconductor is moving version control >systems from SVN to Git. > >The plan > > >- Software, experiment data, and workflow packages will be maintained > as git repositories created to capture the full commit history of > each package. (the commit history of the 'data_store' portion of > data experiment packages will unfortunately not carry forward to > git). > >- Read-only (user) access for each package is available via https, > e.g., > > git clone >https://git.bioconductor.org/packages/SummarizedExperiment > >- Read-write (developer) access for each package is available via ssh, >e.g., > > git clone g...@git.bioconductor.org:packages/SummarizedExperiment > > Developers MUST SHARE public key(s) with Bioconductor. The process > for this during the beta phase is outlined below. > >- The build system and other core infrastructure will use > git.bioconductor.org as the canonical source after the transition. > >- Developers may wish to independently clone and maintain github or > other repositories to support their package. Developers are > responsible for pushing changes from these cloned repositories to > the canonical source. > >- https://github.com/Bioconductor-mirror will be removed after the > transition. > >Beta testers > > >We are starting Beta testing now. We encourage as many people as >possible to become beta-testers, either as users (via git clone >https://...) or maintainers (via git clone git@...). > >All software, data experiment, and workflow packages are available at > > (read-only) git clone >https://git.bioconductor.org/packages/ > (read / write) git clone >g...@git.bioconductor.org:packages/ > >These are STATIC SNAPSHOTS of SVN. Developers are encouraged to commit >to these repositories, but the commits are not propagated to svn and >will be lost at the end of the beta phase. > >For maintainers, Bioconductor needs your SSH public key. We have >prepared a Google form for this > >https://goo.gl/forms/eg36vcBkIUjfZfLe2 > >The form requires your Bioconductor provided SVN username, and your >Github user name (to retrieve your public keys from >https://github.com/.keys) OR SSH key. Currently, the >form is processed on an approximately daily basis, so there is a delay >between credential submission and developer access. > >(IMPORTANT) As a beta tester, we ask that you work through the >'scenarios' at > >https://github.com/Bioconductor/bioc_git_transition/tree/master/doc > >Package authors and maintainers, please take the extra measure to >check that your package history is complete to July 4th, i.e commit >history, >files, folders and all Bioconductor components. > >If you are new to Git or Github, there are learning
Re: [Bioc-devel] Bioconductor git server beta testing begins now.
Dear all, Great to know that the git transition is moving forward. I tested cloning (https) several packages and I noticed a significant difference in the repository size between svn and git. Two examples showing the output (svn/git) of du -k: Biobase: 4968 / 8720 limma: 6284 / 20296 Looking briefly at the .git folder inside the repositories it seems the .pack file inside .git/objects/pack takes most of the overweight. I wonder if this is expected? Thank you. Diego PS: commands used to obtain the repositories: git clone https://git.bioconductor.org/packages/limma svn co https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/limma --username readonly On Fri, Jul 7, 2017 at 9:42 PM, Turaga, Nitesh wrote: > Dear Maintainers, > > For those of you who have submitted your public github id instead of your > public SSH key, please make sure that the link > `www.github.com/.keys` is valid and shows your SSH key. > > If that is not valid, we are not able to add your SSH key to the > bioconductor server. > > Thanks, > > Nitesh > > >>>Dear Maintainers >>> >>>As announced earlier this year, Bioconductor is moving version control >>>systems from SVN to Git. >>> >>>The plan >>> >>> >>>- Software, experiment data, and workflow packages will be maintained >>> as git repositories created to capture the full commit history of >>> each package. (the commit history of the 'data_store' portion of >>> data experiment packages will unfortunately not carry forward to >>> git). >>> >>>- Read-only (user) access for each package is available via https, >>> e.g., >>> >>> git clone >>>https://git.bioconductor.org/packages/SummarizedExperiment >>> >>>- Read-write (developer) access for each package is available via ssh, >>>e.g., >>> >>> git clone g...@git.bioconductor.org:packages/SummarizedExperiment >>> >>> Developers MUST SHARE public key(s) with Bioconductor. The process >>> for this during the beta phase is outlined below. >>> >>>- The build system and other core infrastructure will use >>> git.bioconductor.org as the canonical source after the transition. >>> >>>- Developers may wish to independently clone and maintain github or >>> other repositories to support their package. Developers are >>> responsible for pushing changes from these cloned repositories to >>> the canonical source. >>> >>>- https://github.com/Bioconductor-mirror will be removed after the >>> transition. >>> >>>Beta testers >>> >>> >>>We are starting Beta testing now. We encourage as many people as >>>possible to become beta-testers, either as users (via git clone >>>https://...) or maintainers (via git clone git@...). >>> >>>All software, data experiment, and workflow packages are available at >>> >>> (read-only) git clone >>>https://git.bioconductor.org/packages/ >>> (read / write) git clone >>>g...@git.bioconductor.org:packages/ >>> >>>These are STATIC SNAPSHOTS of SVN. Developers are encouraged to commit >>>to these repositories, but the commits are not propagated to svn and >>>will be lost at the end of the beta phase. >>> >>>For maintainers, Bioconductor needs your SSH public key. We have >>>prepared a Google form for this >>> >>>https://goo.gl/forms/eg36vcBkIUjfZfLe2 >>> >>>The form requires your Bioconductor provided SVN username, and your >>>Github user name (to retrieve your public keys from >>>https://github.com/.keys) OR SSH key. Currently, the >>>form is processed on an approximately daily basis, so there is a delay >>>between credential submission and developer access. >>> >>>(IMPORTANT) As a beta tester, we ask that you work through the >>>'scenarios' at >>> >>>https://github.com/Bioconductor/bioc_git_transition/tree/master/doc >>> >>>Package authors and maintainers, please take the extra measure to >>>check that your package history is complete to July 4th, i.e commit >>>history, >>>files, folders and all Bioconductor components. >>> >>>If you are new to Git or Github, there are learning materials online >>>https://try.github.io >>> >>>We encourage pull-requests on documentation. Please post other >>>beta-test feedback from the experience with the new git server to this >>>mailing list. >>> >>>Transition >>>-- >>> >>>Important Dates: >>> >>>Transition: on date T, tentatively July 31st. >>> >>>Until July 30th 2017: >>> >>>Beta testing phase. >>> >>> >>>July 26th 2017: >>> >>>Developer day demo session on Bioconductor's GIT transition/usage >>>going forward. (30-45 mins) Be sure to attend if you are at >>>Bioc2017, Boston. Slides will be made public. >>> >>>T - 2: Final SVN snapshot of data experiment packages >>> >>>No more SVN commits to Data Experiment packages. >>> >>>T: Day of transition. >>> >>>All SVN commits to software, experiment data, and workflow >>>repositories are stopped, forever. >>> >>> Git repositories are updated to most recent svn version on day T. >>>(We estimate that this will take about 6 hours; no
Re: [Bioc-devel] recent changes in ggplot2 break some packages
Hi Ramon, My experience with this issue is that it requires reinstalling the depending packages from source (but not ggplot2 itself). Alternatively, this should be fixed (I think) once all dependent packages are rebuilt with the newest ggplot2 installed. See this related post in the ggtree package issue tracker: https://github.com/GuangchuangYu/ggtree/issues/91 Best, Diego On Mon, Nov 14, 2016 at 7:50 PM, Ramon Diaz-Uriarte wrote: > Dear All, > > At least some packages (partial list in links below) are failing checks in > both release and devel; the error logs for Linux, Windows, and Mac all show > > > "Error: processing vignette 'OncoSimulR.Rmd' failed with diagnostics: > [GeomTextRepel/PositionQuasirandom/etc] was built with an incompatible > version of ggproto. Please reinstall the package that provides this > extension." > > > A partial list for devel: > http://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/malbec2-buildsrc.html > http://bioconductor.org/checkResults/devel/bioc-LATEST/cytofkit/malbec2-buildsrc.html > http://bioconductor.org/checkResults/devel/bioc-LATEST/maftools/malbec2-buildsrc.html > http://bioconductor.org/checkResults/devel/bioc-LATEST/MoonlightR/malbec2-buildsrc.html > http://bioconductor.org/checkResults/devel/bioc-LATEST/pcaExplorer/malbec2-buildsrc.html > http://bioconductor.org/checkResults/devel/bioc-LATEST/scater/malbec2-buildsrc.html > > > > For release: > http://bioconductor.org/checkResults/release/bioc-LATEST/OncoSimulR/malbec1-buildsrc.html > http://bioconductor.org/checkResults/release/bioc-LATEST/cytofkit/malbec1-buildsrc.html > etc > > > This seems related to very recent changes in ggplot2 (and other people have > reported similar problems in oter forums). It is fixed reinstalling ggplot2 > and the other package that depends on it (e.g., ggrepel)[1]. > > Should we just wait for ggplot2 and ggrepel to be reinstalled in the build > machines? How often do these happen? > > > Best, > > > R. > > > [1] And, at least for the package I maintain, OncoSimulR, there are no > issues with R-devel in my local machines or with Travis > (https://travis-ci.org/rdiaz02/OncoSimul), or Appveyor > (https://ci.appveyor.com/project/rdiaz02/OncoSimul). > > > > > -- > 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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BioC 3.2 branch created
Nice addition, thank you. Just want to note that now the 3.1 page says "April 17, 2005". Thats a long time ago! I guess it means "April 17, 2015". Diego On Sat, Oct 17, 2015 at 3:30 AM, Hervé Pagès wrote: > On 10/16/2015 10:52 AM, Dan Tenenbaum wrote: >> >> >> >> - Original Message - >>> >>> From: "Hervé Pagès" >>> To: "Dan Tenenbaum" , "Levi Waldron" >>> >>> Cc: "bioc-devel" >>> Sent: Friday, October 16, 2015 10:07:03 AM >>> Subject: Re: [Bioc-devel] BioC 3.2 branch created >>> >>> Hi Dan, >>> >>> Thanks for making that change. Would be great to have this for the >>> previous releases too. One often lands on an announcement page >>> directly >>> from Google and has no easy way to tell when that release happened. >>> >> >> Just committed the change, it should show up son. Looks like we used to do >> this and then stopped at some point. > > > Great. Thanks Dan! > > H. > > >> Dan >> >> >>> Thanks, >>> H. >>> >>> >>> On 10/16/2015 08:45 AM, Dan Tenenbaum wrote: Done, the change should appear within 20 minutes. Thanks for the suggestion. Dan - Original Message - > > From: "Levi Waldron" > To: "bioc-devel" > Sent: Friday, October 16, 2015 8:23:17 AM > Subject: Re: [Bioc-devel] BioC 3.2 branch created > > Just a small suggestion, it might be helpful to put a date on > https://www.bioconductor.org/news/bioc_3_2_release/ - currently > it's > not > obvious when you land on that page when the announcement was made, > or > that > this is the current release version. > > Thanks core team for your hard work in getting another release out > on > schedule! > > > > On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum > > wrote: > >> >> The BioC 3.2 branch is now ready. >> >> Remember, you always have access to 2 versions of your package: >> the "release" and the "devel" versions. >> >> Right now the "release" version of your package (which is not >> officially released yet but will be tomorrow if >> everything goes well) is in the 3.2 branch and accessible at: >> >> >> https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/ >> >> >> Only bug fixes and documentation improvements should go here. >> >> As always the "devel" version of your package is at: >> >> >> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/ >> >> Similarly for experiment packages, where your package is >> available >> in >> devel at >> >> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/ >> >> The release branch of it is in: >> >> >> https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/ >> >> >> >> Normal development of your package can now resume here. >> >> Please let us know if you have any questions. >> >> >> Thanks! >> >> Dan >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > > > -- > Levi Waldron > Assistant Professor of Biostatistics > City University of New York School of Public Health, Hunter > College > 2180 3rd Ave Rm 538 > New York NY 10035-4003 > phone: 212-396-7747 > www.waldronlab.org > > [[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 >>> >>> -- >>> Hervé Pagès >>> >>> Program in Computational Biology >>> Division of Public Health Sciences >>> Fred Hutchinson Cancer Research Center >>> 1100 Fairview Ave. N, M1-B514 >>> P.O. Box 19024 >>> Seattle, WA 98109-1024 >>> >>> E-mail: hpa...@fredhutch.org >>> Phone: (206) 667-5791 >>> Fax:(206) 667-1319 >>> > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Problem with the git mirror when committing to SVN
Thanks Jesper for your reply. I am afraid however thats what I did before (see the details of my original message). The real problem is the file .Rbuildignore which causes a rebase that then finds the conflict in DESCRIPTION (and other files as I fix that one; I guess it is trying to go too far in the past). Whatever the reason is, it has happened to me several times now and it gets worse as the number of cycles of git rebase --continue/--skip increases. Last time it lead to me missing correctly editing one of the files which broke my package in svn. Diego On Fri, Sep 18, 2015 at 5:13 PM, Jesper Gådin wrote: > Hi Diego, > > I had the same problem some days ago. Can't tell if this is the right way to > solve the problem, but it worked, and this is what I did, > 1) modified the file under conflict, in your case DESCRIPTION. > 2) git rebase --continue > 3) git rebase --skip > > #This is the selected output from my bash history > 2192 git checkout devel > 2193 git svn rebase > 2194 git merge > 2195 git merge master --log > 2196 git svn dcommit --add-author-from > 2197 ls > 2198 git status > 2199 vim DESCRIPTION > 2200 git status > 2201 git add DESCRIPTION > 2202 git status > 2203 git commit -m"DESCRIPTION conflict change" > 2204 git status > 2205 git rebase --continue > 2206 git rebase --skip > 2207 git status > 2208 vim inst/CITATION > 2209 git status > 2210 vim DESCRIPTION > 2211 git status > 2212 git add * > 2213 git status > 2214 git rebase --continue > 2215 git rebase --skip > 2216 git status > 2217 git svn dcommit --add-author-from > 2218 git status > > /Jesper > > On Fri, Sep 18, 2015 at 9:46 AM, Diego Diez wrote: >> >> Dear all, >> >> I am now having a similar issue (see bellow) with my other package >> rTRM and so would like to bring the attention to this thread again. >> Anyone using git mirrors experiencing something similar and/or knowing >> how to fix it? Thank you very much in advance. >> >> Best, >> Diego >> >> On Tue, Sep 8, 2015 at 3:08 PM, Diego Diez wrote: >> > Dear all, >> > >> > I am having some problem with the git mirror and I would appreciate >> > some light into how could it be solved. >> > >> > I have forked my package "codelink" in github and work on a local copy >> > in my computer. I used the information in >> > http://www.bioconductor.org/developers/how-to/git-mirrors/ to set up >> > the remotes, currently (output of git remote -v): >> > >> > bioc https://github.com/Bioconductor-mirror/codelink.git (fetch) >> > bioc https://github.com/Bioconductor-mirror/codelink.git (push) >> > origin https://github.com/ddiez/codelink (fetch) >> > origin https://github.com/ddiez/codelink (push) >> > >> > Usually I follow this workflow: >> > >> > 1. Work on local/master. >> > 2. Push to origin/master when satisfied. >> > (Submit to SVN when ready) >> > 3. Checkout local/devel >> > 4. Update any changes in SVN (git svn rebase) >> > 5. Merge local/master >> > 6. Commit to SVN (git svn dcommit) >> > 7. Merge changes in devel (SVN commit) back to master (git checkout >> > master; git merge devel) >> > >> > Recently I have found an error during "git svn dcommit" then git tries >> > to do a rebase. Then is when some sort of nightmare begins where older >> > versions of files that I changed before begin to pop up. I go through >> > several cycles of git rebase --continue or --skip where I need to fix >> > the different conflicts. This process has messed up my recent commit >> > log. Anyway, on trying to learn from this I can confirm that if >> > instead of committing the changes through git I checkout a clean SVN >> > copy, move the altered files there and commit no error shows. Then the >> > mirror will synchronize and I can update master from devel and I am >> > all done. But this is of course not optimal. I have tried now to >> > submit changes to two files (NEWS and DESCRIPTION) and got the same >> > problem (show the error message below-- seems to be related to >> > .Rbuildignore already in SVN- after this I did git rebase --abort). My >> > questions: >> > >> > How can I fix this without going through the fruitless git rebase >> > --continue/--skip as I did before? >> > >> > Why this happened and how can I prevent it to happen again? >> > >> > Thank you very much for any help. >
Re: [Bioc-devel] Problem with the git mirror when committing to SVN
Dear all, I am now having a similar issue (see bellow) with my other package rTRM and so would like to bring the attention to this thread again. Anyone using git mirrors experiencing something similar and/or knowing how to fix it? Thank you very much in advance. Best, Diego On Tue, Sep 8, 2015 at 3:08 PM, Diego Diez wrote: > Dear all, > > I am having some problem with the git mirror and I would appreciate > some light into how could it be solved. > > I have forked my package "codelink" in github and work on a local copy > in my computer. I used the information in > http://www.bioconductor.org/developers/how-to/git-mirrors/ to set up > the remotes, currently (output of git remote -v): > > bioc https://github.com/Bioconductor-mirror/codelink.git (fetch) > bioc https://github.com/Bioconductor-mirror/codelink.git (push) > origin https://github.com/ddiez/codelink (fetch) > origin https://github.com/ddiez/codelink (push) > > Usually I follow this workflow: > > 1. Work on local/master. > 2. Push to origin/master when satisfied. > (Submit to SVN when ready) > 3. Checkout local/devel > 4. Update any changes in SVN (git svn rebase) > 5. Merge local/master > 6. Commit to SVN (git svn dcommit) > 7. Merge changes in devel (SVN commit) back to master (git checkout > master; git merge devel) > > Recently I have found an error during "git svn dcommit" then git tries > to do a rebase. Then is when some sort of nightmare begins where older > versions of files that I changed before begin to pop up. I go through > several cycles of git rebase --continue or --skip where I need to fix > the different conflicts. This process has messed up my recent commit > log. Anyway, on trying to learn from this I can confirm that if > instead of committing the changes through git I checkout a clean SVN > copy, move the altered files there and commit no error shows. Then the > mirror will synchronize and I can update master from devel and I am > all done. But this is of course not optimal. I have tried now to > submit changes to two files (NEWS and DESCRIPTION) and got the same > problem (show the error message below-- seems to be related to > .Rbuildignore already in SVN- after this I did git rebase --abort). My > questions: > > How can I fix this without going through the fruitless git rebase > --continue/--skip as I did before? > > Why this happened and how can I prevent it to happen again? > > Thank you very much for any help. > > Diego > > $ git svn dcommit --add-author-from > Committing to > https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codelink > ... > > ERROR from SVN: > RA layer file already exists: File '.Rbuildignore' already exists > W: de6ada9e216e1e0f0829855b4c22b533131cd162 and > refs/remotes/git-svn-devel differ, using rebase: > :100644 100644 2ea5d2ac8a7f79a4133b1151c399f8900cf0f0fd > 47b488122aa8a9f9bc71d6e31f87809afce6131d M DESCRIPTION > :04 04 899c7951d0d3e88ee0b73f54506a6f85ea710e92 > 50f453b70afb84a5fac5d01875c70652352f368f M inst > First, rewinding head to replay your work on top of it... > Applying: Added project files. > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > No changes -- Patch already applied. > Applying: - added URL and BugReports information. > Using index info to reconstruct a base tree... > M DESCRIPTION > :11: trailing whitespace. > BugReports: https://github.com/ddiez/codelink/issues > warning: 1 line adds whitespace errors. > Falling back to patching base and 3-way merge... > Auto-merging DESCRIPTION > CONFLICT (content): Merge conflict in DESCRIPTION > Failed to merge in the changes. > Patch failed at 0002 - added URL and BugReports information. > The copy of the patch that failed is found in: >/Users/diez/projects/R/codelink/codelink/.git/rebase-apply/patch > > When you have resolved this problem, run "git rebase --continue". > If you prefer to skip this patch, run "git rebase --skip" instead. > To check out the original branch and stop rebasing, run "git rebase --abort". > > rebase refs/remotes/git-svn-devel: command returned error: 1 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Problem with the git mirror when committing to SVN
Dear all, I am having some problem with the git mirror and I would appreciate some light into how could it be solved. I have forked my package "codelink" in github and work on a local copy in my computer. I used the information in http://www.bioconductor.org/developers/how-to/git-mirrors/ to set up the remotes, currently (output of git remote -v): bioc https://github.com/Bioconductor-mirror/codelink.git (fetch) bioc https://github.com/Bioconductor-mirror/codelink.git (push) origin https://github.com/ddiez/codelink (fetch) origin https://github.com/ddiez/codelink (push) Usually I follow this workflow: 1. Work on local/master. 2. Push to origin/master when satisfied. (Submit to SVN when ready) 3. Checkout local/devel 4. Update any changes in SVN (git svn rebase) 5. Merge local/master 6. Commit to SVN (git svn dcommit) 7. Merge changes in devel (SVN commit) back to master (git checkout master; git merge devel) Recently I have found an error during "git svn dcommit" then git tries to do a rebase. Then is when some sort of nightmare begins where older versions of files that I changed before begin to pop up. I go through several cycles of git rebase --continue or --skip where I need to fix the different conflicts. This process has messed up my recent commit log. Anyway, on trying to learn from this I can confirm that if instead of committing the changes through git I checkout a clean SVN copy, move the altered files there and commit no error shows. Then the mirror will synchronize and I can update master from devel and I am all done. But this is of course not optimal. I have tried now to submit changes to two files (NEWS and DESCRIPTION) and got the same problem (show the error message below-- seems to be related to .Rbuildignore already in SVN- after this I did git rebase --abort). My questions: How can I fix this without going through the fruitless git rebase --continue/--skip as I did before? Why this happened and how can I prevent it to happen again? Thank you very much for any help. Diego $ git svn dcommit --add-author-from Committing to https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codelink ... ERROR from SVN: RA layer file already exists: File '.Rbuildignore' already exists W: de6ada9e216e1e0f0829855b4c22b533131cd162 and refs/remotes/git-svn-devel differ, using rebase: :100644 100644 2ea5d2ac8a7f79a4133b1151c399f8900cf0f0fd 47b488122aa8a9f9bc71d6e31f87809afce6131d M DESCRIPTION :04 04 899c7951d0d3e88ee0b73f54506a6f85ea710e92 50f453b70afb84a5fac5d01875c70652352f368f M inst First, rewinding head to replay your work on top of it... Applying: Added project files. Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: - added URL and BugReports information. Using index info to reconstruct a base tree... M DESCRIPTION :11: trailing whitespace. BugReports: https://github.com/ddiez/codelink/issues warning: 1 line adds whitespace errors. Falling back to patching base and 3-way merge... Auto-merging DESCRIPTION CONFLICT (content): Merge conflict in DESCRIPTION Failed to merge in the changes. Patch failed at 0002 - added URL and BugReports information. The copy of the patch that failed is found in: /Users/diez/projects/R/codelink/codelink/.git/rebase-apply/patch When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". rebase refs/remotes/git-svn-devel: command returned error: 1 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Bioconductor packages for R-3.1.0 beta on OSX 10.9
Hi Dan,
On Fri, Apr 4, 2014 at 11:05 PM, Dan Tenenbaum wrote:
> Hi Diego,
>
> - Original Message -
>> From: "Diego Diez"
>> To: "bioc-devel"
>> Sent: Friday, April 4, 2014 12:44:20 AM
>> Subject: [Bioc-devel] Bioconductor packages for R-3.1.0 beta on OSX 10.9
>>
>> Dear all,
>>
>> sorry if double posting this. I sent it two days ago using a
>> different
>> email not registered at bioc-devel and it seems (as for the archives)
>> it has not reached destination.
>>
>> FYI, it seems the OSX build R 3.1.0 beta has split into snowleopard
>> and mavericks builds:
>>
>> http://r.research.att.com
>>
>> When installing the later and trying to install Bioconductor I get
>> the
>> following:
>>
>> > source("http://bioconductor.org/biocLite.R";)
>> Warning: unable to access index for repository
>> http://www.bioconductor.org/packages/2.14/bioc/bin/macosx/mavericks/contrib/3.1
>>
>>package 'BiocInstaller' is available as a source package but not
>>as a binary
>>
>> 'biocLite.R' failed to install 'BiocInstaller', use
>> 'install.packages("BiocInstaller",
>> repos="http://www.bioconductor.org/packages/2.14/bioc";)'
>> Warning message:
>> package 'BiocInstaller' is not available (for R version 3.1.0 beta)
>>
>>
>> then did the following:
>>
>>
>> > install.packages("BiocInstaller",
>> +
>> repos="http://www.bioconductor.org/packages/2.14/bioc",type="source";)
>> trying URL
>> 'http://www.bioconductor.org/packages/2.14/bioc/src/contrib/BiocInstaller_1.13.3.tar.gz'
>> Content type 'application/x-gzip' length 14183 bytes (13 Kb)
>> opened URL
>> ==
>> downloaded 13 Kb
>>
>> * installing *source* package 'BiocInstaller' ...
>> ** R
>> ** inst
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** testing if installed package can be loaded
>> Bioconductor version 2.14 (BiocInstaller 1.13.3), ?biocLite for help
>> * DONE (BiocInstaller)
>>
>> The downloaded source packages are in
>> '/private/var/folders/dm/96krztk175d19vx9rcsgd2qcgn/T/RtmpMt3iRo/downloaded_packages'
>>
>>
>> and after that did:
>>
>> > biocLite()
>> Error: 'no packages in repository (no internet connection?)' while
>> trying
>> http://bioconductor.org/packages/2.14/bioc
>>
>> which failed, presumably because the new repository structure is not
>> yet supported?
>
>
> Yes, it's not yet supported. We just ordered some Mavericks machines
> yesterday which we'll use to build BioC against the new R binary for
> Mavericks. We'll announce on the Bioconductor and Bioc-devel mailing lists
> when these builds are ready.
>
> Until then, you can run the R binary built on Snow Leopard. It will work fine
> on Mavericks and you'll be able to download binary BioC packages.
>
Thank you. Also saw your other email sent to the list. What is the
advantage then of having a mavericks build? I guess the problem is
that Xcode 5 builds are not backward compatible.
>>
>> this did not work either:
>>
>> > biocLite(type="source")
>>
>
> That's puzzling. What about installing an individual package from source with
> biocLite()?
Did not work either.
> biocLite("Biobase",type="source")
Error: 'no packages in repository (no internet connection?)' while trying
http://bioconductor.org/packages/2.14/bioc
here include the output of traceback:
> traceback()
11: stop(.msg(...), call. = call.)
10: .stop("'%s' while trying %s", conditionMessage(err), repos, call. = FALSE)
9: value[[3L]](cond)
8: tryCatchOne(expr, names, parentenv, handlers[[1L]])
7: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatch({
.contribUrl(repos)
}, error = function(err) {
version <- getRversion()
currentVersion <- sprintf("%d.%d", version$major, version$minor)
lowerVersion <- .lowerRVersionString(version)
oldRepos <- sub(currentVersion, lowerVersion, repos)
if (oldRepos == repos)
.stop("'%s' while trying %s", conditionMessage(err),
repos, call. = FALSE)
.message("'%s' while trying %s, trying %s", conditionMessage(err),
r
[Bioc-devel] Bioconductor packages for R-3.1.0 beta on OSX 10.9
Dear all,
sorry if double posting this. I sent it two days ago using a different
email not registered at bioc-devel and it seems (as for the archives)
it has not reached destination.
FYI, it seems the OSX build R 3.1.0 beta has split into snowleopard
and mavericks builds:
http://r.research.att.com
When installing the later and trying to install Bioconductor I get the
following:
> source("http://bioconductor.org/biocLite.R";)
Warning: unable to access index for repository
http://www.bioconductor.org/packages/2.14/bioc/bin/macosx/mavericks/contrib/3.1
package 'BiocInstaller' is available as a source package but not as a binary
'biocLite.R' failed to install 'BiocInstaller', use
'install.packages("BiocInstaller",
repos="http://www.bioconductor.org/packages/2.14/bioc";)'
Warning message:
package 'BiocInstaller' is not available (for R version 3.1.0 beta)
then did the following:
> install.packages("BiocInstaller",
+ repos="http://www.bioconductor.org/packages/2.14/bioc",type="source";)
trying URL
'http://www.bioconductor.org/packages/2.14/bioc/src/contrib/BiocInstaller_1.13.3.tar.gz'
Content type 'application/x-gzip' length 14183 bytes (13 Kb)
opened URL
==
downloaded 13 Kb
* installing *source* package 'BiocInstaller' ...
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
Bioconductor version 2.14 (BiocInstaller 1.13.3), ?biocLite for help
* DONE (BiocInstaller)
The downloaded source packages are in
'/private/var/folders/dm/96krztk175d19vx9rcsgd2qcgn/T/RtmpMt3iRo/downloaded_packages'
and after that did:
> biocLite()
Error: 'no packages in repository (no internet connection?)' while trying
http://bioconductor.org/packages/2.14/bioc
which failed, presumably because the new repository structure is not
yet supported?
this did not work either:
> biocLite(type="source")
Best,
Diego
> sessionInfo()
R version 3.1.0 beta (2014-03-31 r65343)
Platform: x86_64-apple-darwin13.1.0 (64-bit)
locale:
[1] C/UTF-8/C/C/C/C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] BiocInstaller_1.13.3
loaded via a namespace (and not attached):
[1] tools_3.1.0
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] shiny, Bioconductor, and reproducible research
Hi, I have been following this conversation with a lot of interest. I have an R package with a shiny interface to another package recently accepted in bioc-devel (rTRM). I was planning to submit it soon, as the package is finished. So my question is, should I hold the submission off until the questions in this topic are decided or on the contrary submit and adapt the package later accordingly? If asked about which I prefer, submit it now would be my choice. One thing to consider is that from the R package developer point of view, it probably only makes sense to implement methods for unit test/etc that do not require the use/knowledge of other language that is not R. For example, for me one of the main motivations to use shiny was the fact that I could avoid having to compute things in Javascript- just could use only R. Maybe it was not implied otherwise in the thread-just wanted to stress this point. At any rate, any solution that is R-founded I will be more than willing to follow. However, I am completely ignorant at this moment about how to implement unit testing for my shiny package. One additional comment. In the package I will submit all the code for the shiny application resides in the inst/ directory (including the ui.R and server.R files, but also images, html and data files). In R/ there is only a runTRM() function that in turns calls to runApp() with the correct path. This may not be optimal so any other suggestions on this regard are welcome. Best wishes, Diego On Tue, Jul 30, 2013 at 6:46 AM, Dan Tenenbaum wrote: > Hi Winston, > > > > On Mon, Jul 29, 2013 at 2:39 PM, Winston Chang wrote: >> Hi everyone - >> >> Great to hear from you all on your thoughts about Shiny. I've tried to >> answer some of Dan's questions below... >> >> 1) Testing shiny apps Typically, bioconductor packages have man page examples, vignettes, and (sometimes) unit tests, so when we build the packages every day on our build system, the code in all of these is evaluated and we have some idea of whether the package is working as it's supposed to. I'm not clear on how to do similar testing of a shiny application. Since launching a shiny app takes away the R console (until the app is closed), shiny apps should probably not be launched in example or test code (unless interactive() is TRUE). Do the shiny folks (or anyone else) have thoughts on testing shiny apps? >> >> >> With regard to testing, we have unit tests for various components, and we're >> working on end-to-end tests using Selenium. >> >> We do have some unit tests in inst/tests/, but they are entirely on the R >> side - they don't test interaction with the browser. We have some other >> tests in inst/tests-js/, which exercise the client (Javascript) side, but >> they don't test interaction with the server. >> >> Of course it's important to have tests for client-server communication. >> We're also in the process of setting up some end-to-end tests using >> Selenium, but that's just in the beginning stages right now. Hopefully in >> the future we'll have more to say about these kinds of tests. >> >> > > My feeling (and I could be wrong) is that Bioconductor package > developers will be more concerned with testing the basic logic of > shiny apps, and that therefore testing only in R would be sufficient > for the most part. For example, if you could simulate a slider in a > unit test by just changing a reactive value, it would not be necessary > to make sure it works in the deployed context (with browser and > server). > > Of course those kinds of tests are also important, but to an extent > they just ensure that shiny itself works, and so they are more the > province of the shiny developers. > > >> 2) Reproducible research Reproducible research is really important in our community, but shiny apps are sort of a black box as far as reproducibility is concerned. If shiny apps are "read-only" (that is, if they are just used to view an object) then this is not really a problem. But shiny has the ability now to change objects back in your R session, so we need to be able to track what is done inside the shiny app. shiny apps can return some sort of object that tells you what was done in the shiny session (insofar as it modifies any objects in the users's session) and this object can provide a way to reproduce those steps without the shiny app. So maybe the object would consist of lines of code. This means that if there is a shiny app, the package author must also provide ways to do the same transformations on objects without shiny. >> >> >> If the goal is to allow the same transformations in a Shiny app and in a >> regular R session, this certainly is possible. You could, for example, have >> a bunch of inputs in a Shiny app that map directly to arguments in a >> function call, and save those arguments so that
Re: [Bioc-devel] biocLite should warn when called from a non-current R version
Hi
however unlike an iphone Bioconductor is only (as far as I know)
supported for the current release. We all do our best to help users
when they find problems and in most cases when I have suggested they
upgrade they have done so- solving their problems. If they were more
aware of being using an unsupported outdated version of Bioconductor
then they will- at least- have the opportunity of making a reasoned
decision- maybe even upgrade before asking. Indeed people having
legitimate reasons to run an outdated version do understand they are
running an outdated version and so will ignore those messages. As for
getting a message/warning when updating packages, now it is not a
clean, message-free process already. Adding useful information will
not make it significantly cluttered in my opinion. I agree with those
that think the shortest and the most explicit the best. My suggestion:
"NOTE: You are running an outdated (unsupported) version of
Bioconductor {show versions}. Consider upgrading your system to get
all the new features and bug fixes. Please take a look at {URL} for
details."
or similar. And include details about the implications (methods,
possible incompatibilities, etc) of doing so in the URL.
All the best,
Diego
On Fri, Jun 21, 2013 at 12:21 AM, Wolfgang Huber wrote:
> Hi,
> there is benefit in having newest versions, but I think we shouldn't get
> carried away, and find Martin's suggestion reasonable. I don't want to be
> told to go get an iPhone 5 every time I update an app on my iPhone 4 - even
> if that same app would work much better there. People may have legitimate
> reasons to run an 'old' R, and we are not the version police.
>
> Simon, I very much sympathise with your frustration about thoughtless or
> ignorant user questions, and I suppose you hope that this proposed change
> will provide a quick fix. I would have said something different above if I
> shared that hope, but I am not sure it would make much difference to them in
> practice: many would not follow that message even it were in ALL CAPS ALL
> ACROSS THEIR SCREEN. And at the same time shouting at people who know what
> they're doing is not a desirable approach.
>
> Best wishes
> Wolfgang
>
> On Jun 20, 2013, at 9:03 am, Simon Anders wrote:
>
>> Hi Martin
>>
>> good to see that Herve agrees with me, and I reiterate my point, because I
>> consider this issue very important.
>>
>> The average user does _not_ expect that a function like 'biocLite', which
>> has the express purpose of downloading and installing packages, does not
>> pull the newest package. I know that to you, as an an experienced Bioc
>> person, this has become second nature, but believe me: It is unusual and
>> very surprising for anybody used to other systems.
>>
>> The message hence has to very clearly and unambiguously state the following
>> fact: "The biocLite function will NOT install the most recent released
>> versions of Bioconductor packages."
>>
>> I insist that this should be mentioned in this direct manner. Your
>> formulation may imply it to the careful reader but not to a user in a hurry.
>> Merely mentioning that there are newer versions will _not_ bring across the
>> point that calling the biocLite installation script will not install these!
>>
>> I really do not see the problem with saying clearly that biocLite will not
>> pull the newest version. Is this something we are ashamed of and don't want
>> to admit straight out?
>>
>> And I frankly see no need to warn users already in this message that updates
>> can break existing workflows. Everybody who has ever used any software knows
>> this.
>>
>> Simon
>>
>> ___
>> 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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] biocLite should warn when called from a non-current R version
Hi
I second improving the awareness of users about new Bioc releases and
also personally do not mind loud messages while I am
installing/upgrading packages, even if it is each time I source/run
biocLite(). Indeed for old releases that I maintain for old projects
very rarely have to install a new package.
Cheers,
Diego
On Thu, Jun 20, 2013 at 3:50 PM, Martin Morgan wrote:
> On 06/19/2013 11:17 PM, Hervé Pagès wrote:
>>
>> Martin,
>>
>> Just to make sure we are on the same page, we are talking about
>> the message we get when we source http://bioconductor.org/biocLite.R
>> (as Simon suggested), not the message we get when loading the
>> BiocInstaller package and/or everytime we use biocLite().
>>
>> So it's a one time thing. IMO it can be loud. If people miss it, they
>> won't see it again...
>
>
> yes we're talking about the same thing. I suspect most people still
> source("http://bioconductor.org/biocLite.R";); biocLite() rather than
> BiocInstaller::biocLite() (that's what most of the documentation says, after
> all, and it's not an incorrect way of updating...), so it's not really a
> one-time thing. Certainly
>
> Bioconductor version 2.12 now available, see
> http://bioconductor.org/install
>
> is a reasonable and more direct alternative.
>
>
>>
>> Almost any app those days (not only smart phone apps, but apps in
>> general) will notify the user when a new version of the app is
>> available. The wording is almost always the same (something like
>> "a new version of the software is available") and everybody knows
>> that this means less features, more bugs, a more restrictive
>> license, more memory requirements, etc... ;-)
>>
>> H.
>>
>> On 06/19/2013 10:50 PM, Martin Morgan wrote:
>>>
>>> On 06/19/2013 09:15 PM, Hervé Pagès wrote:
Hi Martin,
On 06/19/2013 05:21 PM, Martin Morgan wrote:
>
> On 06/19/2013 03:01 PM, Simon Anders wrote:
>>
>> Hi
>>
>> On 19/06/13 23:44, Martin Morgan wrote:
>>>
>>> As a message (not warning or error), how about
>>>
>>>New features are available in Bioconductor version 2.12, R version
>>> 3.0.1.
>>>See http://bioconductor.org/install
>>>
>>> and if the instructions / dire consequences at
>>> http://bioconductor.org/install are not sufficient then we can update
>>> that
>>
>>
>> I see Laurent's point, but this message would not be helpful. The fact
>> that
>> biocLite.R does not pull the newest package version available is
>> unusual,
>> surprising, and a policy rather unique to Bioconductor. Hence it is
>> something
>> that even an otherwise computer-savvy user will appreciate being
>> warned about.
>> The fact that updating a system can break things, however, is common.
>> Furthermore, any user attempting to update his R version will nearly
>> automatically discover that his old R does not disappear if he does
>> not actively
>> delete it.
>>
>> So, what about removing the advice to update but leaving in the
>> warning:
>>
>> "Warning: The biocLite function will NOT install the most recent
>> release
>> versions of Bioconductor packages because you are not using a current
>> R version.
>> Please see http://... for more information."
>
>
> I moved a little on the wording
>
> New features require Bioconductor version 2.12, R version 3.0.1; your
> versions are 2.11 and 2.15.3. See http://bioconductor.org/install.
I think people want to make sure they're using the latest version.
Using the latest version of course means new features, bug fixes, speed
improvements, changes in the API, a new shinny color scheme, etc...
If you really want to keep this message as short and discrete as
possible (I wonder why you'd want that), then I think it's important
to mention those 3 words: new version available.
From the above message I can guess that this means I won't be
installing the latest version but why not be straightforward and just
say it? Also I'm not totally sure those new features are ready yet,
>>>
>>>
>>> Thanks Herve for your comments. I tried 'your out-of-date versions
>>> are...' and similar, but to me that (also flagging this as a 'warning')
>>> sounded too heavy-handed; there are good reasons (e.g., consistency) why
>>> one might want to stick with an out-of-date version. Also I used
>>> 'available' (hence the trifecta 'new', 'version', 'available') initially
>>> (also 'Bioconductor version 2.12 now available, see...', I think this
>>> would be a reasonable alternative to the current message), but 'require'
>>> seemed to be more forceful and to address Simon's concern (without
>>> saying 'n.b. to users of DESeq, estimateDispersions requires
>>> Bioconductor version...' ;) that users mistakenly expect new features to
>>> exist in old releases.
>>>
>>> It's easy to make changes to the message, so keep
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, 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::normalize >> diffGeneAnalysis::normalize >> >> Defining a generic and methods: >> oligo::normalize >> flowCore::normalize >> MSnbase::normalize >> isobar::normalize >> >> and >> >> several normalize\.[*+] functions >> >> Would it be reasonable to add a normalize generic definition to >> BiocGenerics? The generic definitions in the above packages differ, >> however. > > > Sounds good to me. > > However, since the various normalize() functions have different > signatures, we need to agree on what the signature of the generic > in BiocGenerics should be. > > Here is a summary of the situation: > > ** xps package: normalize() is an ordinary function with the > following arg list: > >normalize(xps.data, filename=character(0), filedir=getwd(), > tmpdir="", update=FALSE, select="all", method="mean", > option="transcript:all", logbase="0", exonlevel="", > refindex=0, refmethod="mean", params=list(0.02, 0), > add.data=TRUE, verbose=TRUE) > > The package also defines normalize.constant(), normalize.lowess(), > normalize.quantiles(), normalize.supsmu(), which are also ordinary > functions (not S3 methods), and have similar but slightly > different arg lists. > > ** codelink package: Ordinary function with the following args: > >normalize(object, method="quantiles", log.it=TRUE, > preserve=FALSE, weights=NULL, verbose=FALSE) > > ** EBImage package: Ordinary function with the following args: > >normalize(x, separate=TRUE, ft=c(0, 1)) > > ** diffGeneAnalysis package: Ordinary function with the following > args: > >normalize(rawdata, numSlides, ctrl, expm, ctrlbg=0.30, > expmbg=0.30) > > ** deepSNV package: S4 generic with the following args: > >normalize(test, control, ...) > > ** isobar package: S4 generic with the following args: > >normalize(x, f=median, target="intensity", exclude.protein=NULL, > use.protein=NULL, f.doapply=TRUE, log=TRUE, > channels=NULL, na.rm=FALSE, per.file=TRUE, ...) > > ** affy package: S4 generic with the following args: > >normalize(object, ...) > > ** flowCore package: S4 generic with the following args: > >normalize(data, x, ...) > > ** MSnbase package: S4 generic with the following args: > >normalize(object, method, ...) > > ** oligo package: S4 generic with the following args: > >normalize(object, method=normalizationMethods(), > copy=TRUE, subset=NULL, > target='core', verbose=TRUE, ...) > > So it looks like the greatest common factor is normalize(x, ...). > Not too surprising for a generic that covers such a wide range of > related but slightly different concepts / algorithms. > > One technical difficulty though is that, even though almost all these > functions seem to take an S4 object as their 1st arg, some of them > don't: > > (a) For EBImage::normalize(), 'x' can be an ordinary array in > addition to an Image object. > > (b) For diffGeneAnalysis::normalize(), 'rawdata' is an ordinary > matrix. > > (c) For deepSNV::normalize(), 'test' can be an ordinary matrix > in addition to a deepSNV object. > > (d) For oligo::normalize(), 'object' can be an ordinary matrix > in addition to a FeatureSet object. > > So how can we disambiguate when the first arg is an ordinary matrix? > IMO normalize() should fail in that case i.e. no package should define > methods for ordinary arrays or matrices. Not ideal but better than the > current situation where what is returned depends on which package was > loaded last. > > I could put normalize(x, ...) in BiocGenerics if nobody objects, but > that's all. I don't have time to fix the 10 packages that this change > will affect. However, I'd rather wait the beginning of the Bioc 2.13 > devel cycle (April) for such a change. For some packages like > diffGeneAnalysis (which doesn't use S4 at all), that will probably > require a significant amount of changes since it will need to pass > the data to normalize in an S4 container instead of an ordinary matrix. > > Comments and suggestions are welcome. > > Thanks, > > H. > >> >> Best wishes, >> >> Laurent >> >> ___ >> Bioc-devel@r-project.
