Re: [Bioc-devel] rtracklayer::import (v 1.53.1) fails on xz-compressed files.

Hi Charles, Thanks for reaching out. Please ensure that you have built R with xz (lzma) support. If this does not resolve your problem, please post on support.bioconductor.org. Michael On Thu, Sep 2, 2021 at 2:54 PM Charles Plessy wrote: > > Hello > > on my R 4.1.0 system, rtracklayer version 1

[Bioc-devel] rtracklayer::import (v 1.53.1) fails on xz-compressed files.

Hello on my R 4.1.0 system, rtracklayer version 1.53.1 refuses to load XZ-compressed GFF files, throwing the error "has unsupported type: xzfile". As the function's manual page states that xz-compressed files are handled transparently, I suppose it is a bug? Have a ncie day, Charles Plessy --

Re: [Bioc-devel] rtracklayer::import.bed(genome = Seqinfo)

Hi Aditya, This is probably best asked on the support site. When you post there, please include your sessionInfo(). Thanks, Michael On Tue, Oct 22, 2019 at 9:50 AM Bhagwat, Aditya wrote: > > Dear Michael, > > Sorry for my incomplete email - the send button got hit too fast. Better this > time.

[Bioc-devel] rtracklayer::import.bed(genome = Seqinfo)

Dear Michael, Sorry for my incomplete email - the send button got hit too fast. Better this time. rtracklayer::import.bed mentions the argument "genome" to be either a genome identifier (like 'mm10') or a Seqinfo object. I notice that the second option does not work on my BED file (in attach).

Re: [Bioc-devel] rtracklayer::import.bw error situation when there's repeated input ranges in the "selection", leads to S4Vectors

Sorry about that. I bumped the version and ported to release. On Thu, Aug 22, 2019 at 7:50 AM Leonardo Collado Torres wrote: > > Hi Michael, > > That was using rtracklayer 1.45.3. However I see at > https://github.com/lawremi/rtracklayer/commit/90d4209eae05ae2a4af550072c35cada662b4c89 > that you

Re: [Bioc-devel] rtracklayer::import.bw error situation when there's repeated input ranges in the "selection", leads to S4Vectors

Hi Michael, That was using rtracklayer 1.45.3. However I see at https://github.com/lawremi/rtracklayer/commit/90d4209eae05ae2a4af550072c35cada662b4c89 that you made a recent change. If I use the GitHub version, it all works =) > result <- rtracklayer::import(sampleFile, + selection = regs, +

Re: [Bioc-devel] rtracklayer::import.bw error situation when there's repeated input ranges in the "selection", leads to S4Vectors

Sorry, please try 1.45.3. If that works then I'll push it over to release. On Wed, Aug 21, 2019 at 11:48 AM Leonardo Collado Torres wrote: > > Dear Bioc-devel, > > In BioC 3.9 and 3.10 I've noticed some errors on recount which today I > finally traced. It looks like the internals of > rtracklayer

[Bioc-devel] rtracklayer::import.bw error situation when there's repeated input ranges in the "selection", leads to S4Vectors

Dear Bioc-devel, In BioC 3.9 and 3.10 I've noticed some errors on recount which today I finally traced. It looks like the internals of rtracklayer::import.bw() changed (or mabye S4Vectors:::normarg_names) in such a way that if you specify as input to rtracklayer::import() the "selection" argument

Re: [Bioc-devel] rtracklayer::import() fails when genome parameter is used

Hello, After reverting to the release version of GenomeInfoDb (1.10.2) the error disappears. In my defense, disaster is overstating it a bit, especially given the context. GenomeInfoDb::Seqinfo() has been failing because of changes to the NCBI servers (and still continues to fail). The devel v

Re: [Bioc-devel] rtracklayer::import() fails when genome parameter is used

On 02/06/2017 10:13 AM, Raymond Cavalcante wrote: Oops, I got so caught up in the setting up the code I forgot to say what the error was: Error in match.arg(pruning.mode) : 'arg' should be one of “error”, “coarse”, “fine”, “tidy” you have a mixture of 'release' (even-numbered y in x.y.z) an

Re: [Bioc-devel] rtracklayer::import() fails when genome parameter is used

Oops, I got so caught up in the setting up the code I forgot to say what the error was: Error in match.arg(pruning.mode) : 'arg' should be one of “error”, “coarse”, “fine”, “tidy” Thanks again, Raymond > On Feb 6, 2017, at 10:10 AM, Raymond Cavalcante wrote: > > Hello, > > Perhaps this is

[Bioc-devel] rtracklayer::import() fails when genome parameter is used

Hello, Perhaps this is related to problems in GenomeInfoDb::Seqinfo() and NCBI server file structure changes, but rtracklayer::import() is failing when I specify a genome. See below for example code. Thanks, Raymond Cavalcante library(annotatr) # These fail file = system.file('extdata', 'tes

Re: [Bioc-devel] rtracklayer

Michael Lawrence Sent: Thursday, January 26, 2017 1:36:31 PM To: Kathleen Klein Cc: bioc-devel@r-project.org Subject: Re: [Bioc-devel] rtracklayer Hi, We're working on resolving the issue. Sorry for the trouble. Michael On Thu, Jan 26, 2017 at 9:25 AM, Kathleen Klein < kathleen.kl..

Re: [Bioc-devel] rtracklayer

Hi, We're working on resolving the issue. Sorry for the trouble. Michael On Thu, Jan 26, 2017 at 9:25 AM, Kathleen Klein < kathleen.kl...@mail.mcgill.ca> wrote: > A number of packages are failing in the recent build of R-devel due to > rtracklayer. > Any news on a fix for rtracklayer? > I am ge

[Bioc-devel] rtracklayer

A number of packages are failing in the recent build of R-devel due to rtracklayer. Any news on a fix for rtracklayer? I am getting the following error when R is trying to load the rtracklayer.so file unable to load shared object rtracklayer.so: undefined symbol: append_string_to_CharAEAE Kath

Re: [Bioc-devel] rtracklayer: BigWigFIle on Windows

I've never tested it, and reports up until now have been negative. It would help to know the error message (if any) and characteristics of the systems that work or don't work. Given that it works in some circumstances, it sounds like we could make it work more reliably. Michael On Thu, Sep 17, 20

Re: [Bioc-devel] rtracklayer: BigWigFIle on Windows

Thanks. While fetching data over the internet is pretty nice, for me there is a big difference between being able to read local BigWig files and not being able to read anything at all. Wrt. your answer I am a bit unclear whether you expect it to work on a machine local file on Windows. Best, Kas

Re: [Bioc-devel] rtracklayer: BigWigFIle on Windows

I would say that it's unsupported, and surprising that it actually worked for you. It would require some non-trivial engineering to get it fully working on Windows. For example, to access data via HTTP, one would need to implement or integrate an HTTP client based on Windows sockets, as well as abs

[Bioc-devel] rtracklayer: BigWigFIle on Windows

In the man page for trackLayer::BigWigFile it says "These functions do not work on Windows". Despite this statement, which seems to have been around for a while, I and several of my students seems to be able to execute something like import(bwFile, which = my.gr, as = "Rle") on Windows on a BigW

Re: [Bioc-devel] rtracklayer bug?

I will add "..." to the httpGet call. On Tue, Jun 30, 2015 at 10:10 AM, Marc Carlson wrote: > Hi Arne, > > So this time when I look at the bioc-devel email list, I don't see a record > for this last name (or this email). In fact the only way I could be sure it > was you was that your post was th

Re: [Bioc-devel] rtracklayer bug?

Hi Arne, So this time when I look at the bioc-devel email list, I don't see a record for this last name (or this email). In fact the only way I could be sure it was you was that your post was the same... ;) If you want to post from gmail, then you will need to subscribe the gmail address to

Re: [Bioc-devel] rtracklayer::import( as = 'NumericList' ) doesn't work with more than 1 range

Thank you Valerie for the bug fix and Michael for the explanation! Cheers, Leo On Wed, May 20, 2015 at 2:28 PM, Michael Lawrence wrote: > I guess I would say that the summary stuff is sort of an estimate that is > useful for e.g. visualization, rather than an exact quantification. > > On Wed, Ma

Re: [Bioc-devel] rtracklayer::import( as = 'NumericList' ) doesn't work with more than 1 range

I guess I would say that the summary stuff is sort of an estimate that is useful for e.g. visualization, rather than an exact quantification. On Wed, May 20, 2015 at 10:56 AM, Valerie Obenchain wrote: > Hi Leo, > > Thanks for reporting the bug with import. The problem was in how the > length of

Re: [Bioc-devel] rtracklayer::import( as = 'NumericList' ) doesn't work with more than 1 range

Hi Leo, Thanks for reporting the bug with import. The problem was in how the length of the output was computed. This has been fixed in both release (1.28.3) and devel (1.29.6). I'll let Michael answer the summary() question. Valerie On 05/19/2015 12:10 PM, Leonardo Collado Torres wrote: H

[Bioc-devel] rtracklayer::import( as = 'NumericList' ) doesn't work with more than 1 range

Hi, While playing around with importing BigWig files I found that import.bw() fails when you use a `which` or `selection` that has more than one range and you specify `as = 'NumericList'`. The code and output are available at https://gist.github.com/lcolladotor/a0eafc335a2738de42f6. From the BigWi

Re: [Bioc-devel] rtracklayer: Export to bigwig with unused seqlevels

Hi Michael, Thanks, works all fine now. Best wishes Julian On 28/03/14 22:05, Michael Lawrence wrote: > Thanks, should be resolved in 1.23.20 (devel). > > > On Fri, Mar 28, 2014 at 8:09 AM, Julian Gehring > wrote: > > Hi, > > Exporting a GRanges objec

Re: [Bioc-devel] rtracklayer: Export to bigwig with unused seqlevels

Thanks, should be resolved in 1.23.20 (devel). On Fri, Mar 28, 2014 at 8:09 AM, Julian Gehring wrote: > Hi, > > Exporting a GRanges object to the 'bigwig' format with rtracklayer fails > if not all seqlevels are used: > > #+BEGIN_SRC R > library(rtracklayer) > library(GenomicRanges) > > ##

[Bioc-devel] rtracklayer: Export to bigwig with unused seqlevels

Hi, Exporting a GRanges object to the 'bigwig' format with rtracklayer fails if not all seqlevels are used: #+BEGIN_SRC R library(rtracklayer) library(GenomicRanges) ## example data example(GRanges) lg = reduce(unstrand(longGR)) lg$score = 1:6 ## full one works export(lg, tempfi

Re: [Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

This makes sense. Thanks for the fast answer and for this really nice package. Best, Laurent 2013/10/9 Michael Lawrence > It's not feasible to download an entire genome's worth of mappability data > using rtracklayer and the underlying table browser interface. UCSC has > limits in place that

Re: [Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

Currently it looks for the message that UCSC inserts (or used to insert?) when truncating. count.fields is another idea. On Wed, Oct 9, 2013 at 10:35 AM, Kasper Daniel Hansen < kasperdanielhan...@gmail.com> wrote: > Perhaps instead of doing the try() it would be more specific to check > whether

Re: [Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

Perhaps instead of doing the try() it would be more specific to check whether the first non-comment line has the same number of fields as the last line using utils::count.fields. This is what seems to kill us (and leaves the scary possibility of the connection terminating right after a \n). Kaspe

Re: [Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

I recently added an attempt to detect incompleteness but obviously it is not very robust. So I'll give up and add the try(). On Wed, Oct 9, 2013 at 10:16 AM, Kasper Daniel Hansen < kasperdanielhan...@gmail.com> wrote: > (I recently had the same problem downloading dbSnp) > > It would be an impro

Re: [Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

(I recently had the same problem downloading dbSnp) It would be an improvement if the parsing of the download data was inside a try() statement, with a good error message about USCS possibly truncating the record. Also, perhaps mention truncation in the vignette (or make it more visible, if it is

Re: [Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

It's not feasible to download an entire genome's worth of mappability data using rtracklayer and the underlying table browser interface. UCSC has limits in place that truncate the response. rtracklayer has little way of knowing whether the user is requesting too many records. Just download the mapp

[Bioc-devel] rtracklayer: problem with formatting the output of ucscTableQuery

Hi everyone, I'm trying to use the ucscTableQuery function from the rtracklayer package to download a mapability table from the ucsc genome browser. Everything works fine if I restrict the query to a small range, but I get an error message when querying the entire genome (at the moment where I co

Re: [Bioc-devel] rtracklayer Export BED itemRgb Annotation

Thanks, I've clarified the docs, and an integer matrix of color codes is now supported. On Thu, Jul 18, 2013 at 1:00 AM, Dario Strbenac wrote: > The documentation says that itemRgb must be "a character vector of hex > color codes, as returned by col2rgb". However, the return value of col2rgb > i

[Bioc-devel] rtracklayer Export BED itemRgb Annotation

The documentation says that itemRgb must be "a character vector of hex color codes, as returned by col2rgb". However, the return value of col2rgb is "An integer matrix with three or four rows". -- Dario Strbenac PhD Student University of Sydney Camperdown NSW

Re: [Bioc-devel] rtracklayer import Error

Thanks for letting me know, will be fixed in devel. For now, you can just attach Biostrings, of course. Michael On Sun, Jul 14, 2013 at 11:00 PM, Dario Strbenac wrote: > Hello, > > The import function depends on a function in Biostrings that is not > imported. > > > library(rtracklayer) > > im

[Bioc-devel] rtracklayer import Error

Hello, The import function depends on a function in Biostrings that is not imported. > library(rtracklayer) > import("E:\\Dario\\scaffolds.fasta") Error in get(paste("read", match.arg(type), "StringSet", sep = "")) : object 'readDNAStringSet' not found > sessionInfo() R version 3.0.1 (2013-05

Re: [Bioc-devel] rtracklayer BUG: `export(x, path, index=TRUE)` appears not to close filehandle on tabix files produced

Hi Malcolm, I am not sure why this is happening. I haven't been able to reproduce it on my system (which I think has a limit of 1024, so I had to increase your test case to exceed that). Does this happen when calling bgzip + indexTabix on a file 256 times? That would help to eliminate the complica

[Bioc-devel] rtracklayer BUG: `export(x, path, index=TRUE)` appears not to close filehandle on tabix files produced

rtracklayer developers (Michael/Vincent/Robert), I find that tabix indexed exporting too many bed files causes an error. The session following my signature reproduces the error. It provides sessionInfo() details prior to the code causing the error because sessionInfo() FAILS with 'too many op