The JS side of Epiviz defines classes for GRanges and SummarizedExperiment
type objects, with epivizr defining how json is created to transfer it. In
principle it should be straightforward to incorporate to projects like
these (the JS src is part of the epivizr package for example).
In Epiviz/Epiv
The high-level type issue is sort of discussed here:
http://chimera.labs.oreilly.com/books/123000545/ch17.html#_subprotocol_negotiation
What about extending your protocol so that the payload consists of two
fields:
content-type and content, where the content-type adheres to the media type
spec
On Fri, Apr 3, 2015 at 2:00 PM, Paul Shannon <
paul.thurmond.shan...@gmail.com> wrote:
> Hi Michael,
>
> Great to get your response, comments and questions. Answers attempted
> below.
>
> I think our overriding difference lies in our contrasting experience of
> complexity. I have come to see web
Forgot to add bioc-devel
On Fri, Apr 3, 2015 at 4:55 PM, Leonardo Collado Torres
wrote:
> Hi,
>
> From the April newsletter I got curious about BrowserViz but I
> couldn't run the simple example as-is. From
> http://bioconductor.org/checkResults/devel/bioc-LATEST/BrowserViz/ I
> can see that vers
Thanks to Val's excellent newsletter, I've had my first glance at
BrowserViz. I'm glad to see something that is more flexible and low-level
than e.g. shiny.
I'm curious about the motivation behind web sockets. I guess any
application with an R-driven web UI actually has two UIs: the R console and
Now available at http://bioconductor.org/help/newsletters/2015_April/
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
On 04/03/2015 04:37 AM, Andrea Rau wrote:
Hello,
I am the maintainer of a Bioconductor package called 'HTSFilter' that
imports DESeq2. On today's build report, I see that my package (as well
as DESeq2 and all of the other packages that import it) is showing an
error message which seems to arise
hi Andrea,
I sent out an email to bioc-devel at the same time as you :)
https://stat.ethz.ch/pipermail/bioc-devel/2015-April/007269.html
I think this might be fixed already, but I didn't have time to try out
GenomicRanges 1.19.51 yet.
I will try soon, and if this doesn't fix it, I have a hack t
Hello,
I am the maintainer of a Bioconductor package called 'HTSFilter' that
imports DESeq2. On today's build report, I see that my package (as well
as DESeq2 and all of the other packages that import it) is showing an
error message which seems to arise from a recent change in the DESeq2
code
On Fri, Apr 3, 2015 at 7:32 AM, Michael Love
wrote:
> hi Martin,
>
> I noticed with GenomicRanges 1.19.51, a new, or newly functional,
> check on dimnames differing between assays.
ah, I'm still using 1.19.50, maybe that's the issue. But I'd still
like to hear what the new behavior will be so I c
hi Martin,
I noticed with GenomicRanges 1.19.51, a new, or newly functional,
check on dimnames differing between assays.
It might be convenient to add an option that assays() will take an
incoming matrix without error no matter what, even if the dimnames on
the incoming matrix are not the same as
11 matches
Mail list logo
