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, perh
I wonder if raw only means "raw after line return munging"? can you attach
the file that gets downloaded via email? (off list is fine)
On Fri, Jun 17, 2016 at 1:44 PM, Leonardo Collado Torres
wrote:
> Hi,
>
> I'm trying to figure out what is going wrong with an error that pops
> up on Windows o
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 wi
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
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
exper
hi,
the performance of snpsByOverlaps() in terms of time and memory
consumption is quite poor and i wonder whether there is some bug in the
code. here's one example:
library(GenomicRanges)
library(SNPlocs.Hsapiens.dbSNP144.GRCh37)
snps <- SNPlocs.Hsapiens.dbSNP144.GRCh37
gr <- GRanges(seqna
Hi Mike,
We went down to just a single build per week (Saturday I think) for
experiment data packages.
Here are the last commits I see in the devel branch:
r3785 | m.jiang | 2016-06-03 12:29:00 -0700 (Fri, 03 Jun 2016) | 1
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 found that contain call
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:
> > Thanks for that - for some reason it doe
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 environment after each
> Bioc
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, Tho
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 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 found that contain calls to granges() with 2 unnamed arguments.
Sorry for the trouble.
H.
On 06/16/2016 11:
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
:refs/remotes/
I set-up the git mirror for my PanVizGenerator package while it was still only
in devel. After the latest release there is no tracking of the release branch,
and thus no way to push bug fixes for release. Is there any vetted way of
updating/reinstalling the git-mirrors?
running
bash update_rem
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/
16 matches
Mail list logo