Re: [Bioc-devel] Windows-only issue with downloading a Rdata file and loading it with R

Hi, I get the same error while hosting the data somewhere else or when using RawGit's url. That is: > library('downloader') > download(' http://www.biostat.jhsph.edu/~lcollado/recount/metadata_clean_sra.Rdata', destfile = 'test2.Rdata') > load('tes2t.Rdata') Error: ReadItem: unknown type 50,

[Bioc-devel] Windows-only issue with downloading a Rdata file and loading it with R

Hi, I'm trying to figure out what is going wrong with an error that pops up on Windows only. It's currently the only error for a package that I recently submitted to Bioc. The function is fairly simple: it downloads a Rdata file from the web and loads it. If I try to download and load the file

Re: [Bioc-devel] poor performance of snpsByOverlaps()

I think you can get relevant information rapidly from the dbsnp vcf. You would acquire ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606/VCF/00-common_all.vcf.gz ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606/VCF/00-common_all.vcf.gz.tbi and wrap in a TabixFile > tf class: TabixFile

Re: [Bioc-devel] outdated data package in development branch

Valerie At the time when I posted the question, it was still 2.9.1 and definitely wasn't built for more than two weeks. Anyway, it is now updated. Thanks, Mike On 06/17/2016 09:32 AM, Obenchain, Valerie wrote: Hi Mike, We went down to just a single build per week (Saturday I think) for

Re: [Bioc-devel] New argument 'use.names' in granges() function

Thanks Hervé. Leonard On Fri, Jun 17, 2016 at 2:11 AM, Hervé Pagès wrote: > Done in SGSeq 1.6.3 (release) and 1.7.4 (devel). > > Also done in SomaticSignatures 2.8.4 (release) and 2.9.4 (devel). > > I scanned the entire Rpacks folder and those are the only 2 packages > I

Re: [Bioc-devel] Update git-mirrors

If you have committed and pushed everything to GitHub, there will be nothing lost by my solution. Just a few minutes of re-cloning. On Fri, Jun 17, 2016 at 10:02 AM, Elena Grassi wrote: > On Fri, Jun 17, 2016 at 2:50 PM, Thomas Lin Pedersen > wrote: >

Re: [Bioc-devel] Update git-mirrors

On Fri, Jun 17, 2016 at 2:50 PM, Thomas Lin Pedersen wrote: > Thanks for that - for some reason it doesn’t create a local release-3.3 > branch that can be synced to svn? Anyway, I think it’s fair to say that there > need to be some convenient way to update ones git

Re: [Bioc-devel] Update git-mirrors

What I do, which is not ideal, is to delete my git checkout; re-clone it from GitHub and run update_remotes. It is likely these things will change substantially before next release, so I don't think anyone should spend time fixing this right now. Best, Kasper On Fri, Jun 17, 2016 at 8:50 AM,

Re: [Bioc-devel] Update git-mirrors

Thanks for that - for some reason it doesn’t create a local release-3.3 branch that can be synced to svn? Anyway, I think it’s fair to say that there need to be some convenient way to update ones git environment after each Bioconductor release… > On 17 Jun 2016, at 10:58, Elena Grassi

Re: [Bioc-devel] New argument 'use.names' in granges() function

Done in SGSeq 1.6.3 (release) and 1.7.4 (devel). Also done in SomaticSignatures 2.8.4 (release) and 2.9.4 (devel). I scanned the entire Rpacks folder and those are the only 2 packages I found that contain calls to granges() with 2 unnamed arguments. Sorry for the trouble. H. On 06/16/2016

Re: [Bioc-devel] Update git-mirrors

I manually added the tracking of the release branch picking some piece of code from update_remotes.sh: $ git config --add svn-remote.release-3.3.url https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_3/madman/Rpacks/PACKAGENAME $ git config --add svn-remote.release-3.3.fetch

Re: [Bioc-devel] SVN and GitHub mirror out-of-sync

On Montag, 18. April 2016 08:10:12 CEST Dan Tenenbaum wrote: > Should be caught up now. > Dan hi, i have the same problem with destiny: the newest commits appear in the SVN but not github (DESCRIPTION has 1.3.3 vs. 1.3.0) SVN: https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/destiny/

Re: [Bioc-devel] New argument 'use.names' in granges() function

Hi Leonard, I really like having 'use.names' before 'use.mcols'. Sorry for breaking SGSeq, I'll fix it. FWIW I think it's good practice to always name this kind of arguments. Not the first argument 'x' or the first 2 arguments 'x' and 'y' of a unary or binary function, but the toggles that