[Bioc-devel] SummarizedExperiment, differing assay dimnames
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 those of the SummarizedExperiment. Currently, it appears if there are no dimnames on the incoming matrix, withDimnames=FALSE allows assignment (without this arg we get an error), but with mismatched dimnames, withDimnames=FALSE gives an error. Also, the help file should probably be updated, as it seems the argument is not actually ignored for the setter. Unless this functionality above was unintended? withDimnames: A ‘logical(1)’, indicating whether dimnames should be applied to extracted assay elements (this argument is ignored for the setter ‘assays-’). Setting ‘withDimnames=FALSE’ increases the speed and memory efficiency with which assays are extracted. best, Mike ~ (se - SummarizedExperiment(matrix(1:6, ncol=2, dimnames=list(1:3,1:2)), colData=DataFrame(x=1:2))) class: SummarizedExperiment dim: 3 2 exptData(0): assays(1): '' rownames(3): 1 2 3 rowRanges metadata column names(0): colnames: NULL colData names(1): x assays(se)[[test]] - matrix(7:12, ncol=2) Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements Calls: assays- - assays- # error because the incoming matrix doesn't have the same dimnames assays(se, withDimnames=FALSE)[[test]] - matrix(7:12, ncol=2) # no error, as expected because withDimnames=FALSE assays(se)[[test]] - matrix(7:12, ncol=2, dimnames=list(4:6,3:4)) Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements Calls: assays- - assays- # again, mismatched dimnames, so error assays(se, withDimnames=FALSE)[[test]] - matrix(7:12, ncol=2, dimnames=list(4:6,3:4)) Error in `assays-`(`*tmp*`, withDimnames = FALSE, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements Calls: assays- - assays- # error despite asking withDimnames=FALSE sessionInfo() R Under development (unstable) (2015-01-19 r67547) Platform: x86_64-unknown-linux-gnu (64-bit) Running under: Ubuntu 14.04.2 LTS locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats4parallel stats graphics grDevices datasets utils methods [9] base other attached packages: [1] GenomicRanges_1.19.50 GenomeInfoDb_1.3.16 IRanges_2.1.43 [4] S4Vectors_0.5.22 BiocGenerics_0.13.10 RUnit_0.4.28 [7] devtools_1.7.0knitr_1.9 BiocInstaller_1.17.7 loaded via a namespace (and not attached): [1] evaluate_0.5.5 formatR_1.0stringr_0.6.2 tools_3.2.0XVector_0.7.4 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] SummarizedExperiment, differing assay dimnames
On Fri, Apr 3, 2015 at 7:32 AM, Michael Love michaelisaiahl...@gmail.com 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 can build without error :) 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 those of the SummarizedExperiment. Currently, it appears if there are no dimnames on the incoming matrix, withDimnames=FALSE allows assignment (without this arg we get an error), but with mismatched dimnames, withDimnames=FALSE gives an error. Also, the help file should probably be updated, as it seems the argument is not actually ignored for the setter. Unless this functionality above was unintended? withDimnames: A ‘logical(1)’, indicating whether dimnames should be applied to extracted assay elements (this argument is ignored for the setter ‘assays-’). Setting ‘withDimnames=FALSE’ increases the speed and memory efficiency with which assays are extracted. best, Mike ~ (se - SummarizedExperiment(matrix(1:6, ncol=2, dimnames=list(1:3,1:2)), colData=DataFrame(x=1:2))) class: SummarizedExperiment dim: 3 2 exptData(0): assays(1): '' rownames(3): 1 2 3 rowRanges metadata column names(0): colnames: NULL colData names(1): x assays(se)[[test]] - matrix(7:12, ncol=2) Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements Calls: assays- - assays- # error because the incoming matrix doesn't have the same dimnames assays(se, withDimnames=FALSE)[[test]] - matrix(7:12, ncol=2) # no error, as expected because withDimnames=FALSE assays(se)[[test]] - matrix(7:12, ncol=2, dimnames=list(4:6,3:4)) Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements Calls: assays- - assays- # again, mismatched dimnames, so error assays(se, withDimnames=FALSE)[[test]] - matrix(7:12, ncol=2, dimnames=list(4:6,3:4)) Error in `assays-`(`*tmp*`, withDimnames = FALSE, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements Calls: assays- - assays- # error despite asking withDimnames=FALSE sessionInfo() R Under development (unstable) (2015-01-19 r67547) Platform: x86_64-unknown-linux-gnu (64-bit) Running under: Ubuntu 14.04.2 LTS locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats4parallel stats graphics grDevices datasets utils methods [9] base other attached packages: [1] GenomicRanges_1.19.50 GenomeInfoDb_1.3.16 IRanges_2.1.43 [4] S4Vectors_0.5.22 BiocGenerics_0.13.10 RUnit_0.4.28 [7] devtools_1.7.0knitr_1.9 BiocInstaller_1.17.7 loaded via a namespace (and not attached): [1] evaluate_0.5.5 formatR_1.0stringr_0.6.2 tools_3.2.0XVector_0.7.4 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Build error for DESeq2 dev causing error in other package builds
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 dealing with the dimnames of a DESeqDataSet object. The error message in my package reads: Error in `assays-`(`*tmp*`, value = S4 object of class structure(SimpleList, package = S4Vectors)) : 'dimnames' differ between assay elements and seems to occur when calling the DESeq function (right after the gene-wise dispersion estimates message is printed). I know that today is the deadline for fixing errors prior to release, so the time-frame is somewhat short to fix errors. To ensure that my package isn't withheld from release, should I retrograde to the last stable version of DESeq2 rather than using dev? Thanks for your help, Andrea Here is some code + sessionInfo that illustrate the error: library(HTSFilter) library(DESeq2) library(Biobase) data(sultan) conds - pData(sultan)$cell.line dds - DESeqDataSetFromMatrix(countData = exprs(sultan), +colData = data.frame(cell.line = conds), +design = ~ cell.line) dds - DESeq(dds) estimating size factors estimating dispersions gene-wise dispersion estimates Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements sessionInfo() R version 3.2.0 beta (2015-04-01 r68134) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64 (build 7601) Service Pack 1 locale: [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 [4] LC_NUMERIC=C LC_TIME=French_France.1252 attached base packages: [1] stats4parallel stats graphics grDevices utils datasets methods base other attached packages: [1] DESeq2_1.7.46 RcppArmadillo_0.4.650.1.1 Rcpp_0.11.5 GenomicRanges_1.19.50 [5] GenomeInfoDb_1.3.16 IRanges_2.1.43 S4Vectors_0.5.22 HTSFilter_1.7.0 [9] Biobase_2.27.3BiocGenerics_0.13.10 loaded via a namespace (and not attached): [1] RColorBrewer_1.1-2futile.logger_1.4 plyr_1.8.1 XVector_0.7.4 tools_3.2.0 [6] futile.options_1.0.0 rpart_4.1-9 digest_0.6.8 annotate_1.45.4 RSQLite_1.0.0 [11] gtable_0.1.2 lattice_0.20-31 DBI_0.3.1 proto_0.3-10 DESeq_1.19.0 [16] cluster_2.0.1 genefilter_1.49.2 stringr_0.6.2 locfit_1.5-9.1nnet_7.3-9 [21] grid_3.2.0AnnotationDbi_1.29.20 XML_3.98-1.1 survival_2.38-1 BiocParallel_1.1.21 [26] foreign_0.8-61latticeExtra_0.6-26 Formula_1.2-0 limma_3.23.11 geneplotter_1.45.0 [31] ggplot2_1.0.1 reshape2_1.4.1 lambda.r_1.1.7 edgeR_3.9.14 Hmisc_3.15-0 [36] MASS_7.3-40 scales_0.2.4 splines_3.2.0 colorspace_1.2-6 xtable_1.7-4 [41] acepack_1.3-3.3 munsell_0.4.2 [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Build error for DESeq2 dev causing error in other package builds
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 to ensure dimnames are consistent for every set. So either way everything should be resolved today. best Mike On Fri, Apr 3, 2015 at 7:37 AM, Andrea Rau andrea@jouy.inra.fr 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 from a recent change in the DESeq2 code dealing with the dimnames of a DESeqDataSet object. The error message in my package reads: Error in `assays-`(`*tmp*`, value = S4 object of class structure(SimpleList, package = S4Vectors)) : 'dimnames' differ between assay elements and seems to occur when calling the DESeq function (right after the gene-wise dispersion estimates message is printed). I know that today is the deadline for fixing errors prior to release, so the time-frame is somewhat short to fix errors. To ensure that my package isn't withheld from release, should I retrograde to the last stable version of DESeq2 rather than using dev? Thanks for your help, Andrea Here is some code + sessionInfo that illustrate the error: library(HTSFilter) library(DESeq2) library(Biobase) data(sultan) conds - pData(sultan)$cell.line dds - DESeqDataSetFromMatrix(countData = exprs(sultan), +colData = data.frame(cell.line = conds), +design = ~ cell.line) dds - DESeq(dds) estimating size factors estimating dispersions gene-wise dispersion estimates Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements sessionInfo() R version 3.2.0 beta (2015-04-01 r68134) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64 (build 7601) Service Pack 1 locale: [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 [4] LC_NUMERIC=C LC_TIME=French_France.1252 attached base packages: [1] stats4parallel stats graphics grDevices utils datasets methods base other attached packages: [1] DESeq2_1.7.46 RcppArmadillo_0.4.650.1.1 Rcpp_0.11.5 GenomicRanges_1.19.50 [5] GenomeInfoDb_1.3.16 IRanges_2.1.43S4Vectors_0.5.22 HTSFilter_1.7.0 [9] Biobase_2.27.3BiocGenerics_0.13.10 loaded via a namespace (and not attached): [1] RColorBrewer_1.1-2futile.logger_1.4 plyr_1.8.1 XVector_0.7.4 tools_3.2.0 [6] futile.options_1.0.0 rpart_4.1-9 digest_0.6.8 annotate_1.45.4 RSQLite_1.0.0 [11] gtable_0.1.2 lattice_0.20-31 DBI_0.3.1 proto_0.3-10 DESeq_1.19.0 [16] cluster_2.0.1 genefilter_1.49.2 stringr_0.6.2 locfit_1.5-9.1nnet_7.3-9 [21] grid_3.2.0AnnotationDbi_1.29.20 XML_3.98-1.1 survival_2.38-1 BiocParallel_1.1.21 [26] foreign_0.8-61latticeExtra_0.6-26 Formula_1.2-0 limma_3.23.11 geneplotter_1.45.0 [31] ggplot2_1.0.1 reshape2_1.4.1lambda.r_1.1.7 edgeR_3.9.14 Hmisc_3.15-0 [36] MASS_7.3-40 scales_0.2.4 splines_3.2.0 colorspace_1.2-6 xtable_1.7-4 [41] acepack_1.3-3.3 munsell_0.4.2 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Build error for DESeq2 dev causing error in other package builds
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 from a recent change in the DESeq2 code dealing with the dimnames of a DESeqDataSet object. The error message in my package reads: Error in `assays-`(`*tmp*`, value = S4 object of class structure(SimpleList, package = S4Vectors)) : 'dimnames' differ between assay elements I broke assays-,SummarizedExperiment,*-method in GenomicRanges 1.19.50. it has been fixed and problems should clear up in the next build report. The (incorrect) error about 'dimnames differ between assay elements', seen in ./DESeq2/zin2-buildsrc.html ./BiocGenerics/zin2-checksrc.html ./HTSFilter/zin2-buildsrc.html ./VariantAnnotation/zin2-checksrc.html ./bsseq/zin2-buildsrc.html ./AllelicImbalance/zin2-buildsrc.html ./TCC/zin2-buildsrc.html ./gage/zin2-buildsrc.html ./ReportingTools/zin2-checksrc.html ./MLSeq/zin2-buildsrc.html ./systemPipeR/zin2-buildsrc.html ./DiffBind/zin2-buildsrc.html ./SGSeq/zin2-buildsrc.html ./VariantFiltering/zin2-buildsrc.html ./rgsepd/zin2-buildsrc.html will not appear. Off-list, Michael Love asked me what exactly does get checked. The row- and column names of each incoming assay need either to be NULL, or to match the current row and column names of the SummarizedExperiment. For instance the following example(SummarizedExperiment) ## ... assays(se2) = assays(se2) # incoming dimnames assays(se2) = assays(se2, withDimnames=FALSE) # no incoming dimnames m = assays(se2)[[counts]]; rownames(m) = NULL assays(se2)[[counts]] = m # no rownames assays(se2)[[1]] = assays(se2)[[1]][, c(2:6, 1)]# out-of-order columns Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : current and replacement dimnames() differ It doesn't seem safe to allow the dimnames to mismatch, even though earlier versions allowed this. The documentation page has assays(x, ..., withDimnames=TRUE) - value but says withDimnames: A 'logical(1)', indicating whether dimnames should be applied to extracted assay elements (this argument is ignored for the setter 'assays-'). Setting 'withDimnames=FALSE' increases the speed and memory efficiency with which assays are extracted. which may make one wonder why withDimnames=TRUE appears in the signature for assays-. The reason involves complex assignments like names(assays(se2)) = foo versus names(assays(se2, withDimanames=FALSE)) = bar The second version is more efficient than the first, avoiding copying dimnames. The reason for the efficiency is a little complicated. assays() in these expressions acts as both getter and setter. The signature of the setter assays- needs to be able to 'pass through' the withDimnames argument to the getter, even if it has no effect on the setter itself. I have updated the documentation to clarify this, inasmuch as I am able. assayNames(se2) = foo hides the complex assignment complexity for this common use case. Probably the default should be FALSE for the setter, but symmetry and the complexity of the update scenario made me hesitant to do so. Presumably handling of dimnames will be simplified in the next release cycle, when dimnames are stored redundantly on all assay elements. Sorry for the confusion from my flawed commits in version 1.19.50. Martin and seems to occur when calling the DESeq function (right after the gene-wise dispersion estimates message is printed). I know that today is the deadline for fixing errors prior to release, so the time-frame is somewhat short to fix errors. To ensure that my package isn't withheld from release, should I retrograde to the last stable version of DESeq2 rather than using dev? Thanks for your help, Andrea Here is some code + sessionInfo that illustrate the error: library(HTSFilter) library(DESeq2) library(Biobase) data(sultan) conds - pData(sultan)$cell.line dds - DESeqDataSetFromMatrix(countData = exprs(sultan), +colData = data.frame(cell.line = conds), +design = ~ cell.line) dds - DESeq(dds) estimating size factors estimating dispersions gene-wise dispersion estimates Error in `assays-`(`*tmp*`, value = S4 object of class SimpleList) : 'dimnames' differ between assay elements sessionInfo() R version 3.2.0 beta (2015-04-01 r68134) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64 (build 7601) Service Pack 1 locale: [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 [4] LC_NUMERIC=C LC_TIME=French_France.1252 attached base packages: [1] stats4parallel stats graphics grDevices utils datasets methods base other attached
Re: [Bioc-devel] BrowserViz
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 websockets as minimal, simple, fast and flexible, whereas you see them quite differently. I would like to understand your views on this; I could be overlooking somce important and maybe costly complicating features, perhaps because of my fondness for other simplifying features. I was just referring to potential complexity. If one attempted to reimplement the useful features of HTTP (like caching), complexity would be introduced into application code, while you really want that complexity in the protocol implementation. HTTP seems most appropriate for when the server is acting as the data model. Outside of that, I see the benefits of web sockets. I think you missed my question about RPC. Also, any thoughts as to more formalism around the payload? We obviously have complex data structures, and it would be nice to communicate semantics somehow to the web browser. For example, could there be some convention for representing a SummarizedExperiment? Could a payload contain the equivalent of a media type that an R/JS library could understand to marshal objects? Could there be some way to query for the types of payload a command supports? I've seen stuff like WAMP, but they seem to lack the ability to declare high-level types. Maybe that's just out of style? More below... I look forward to hearing back from you. - Paul On Apr 3, 2015, at 1:45 PM, Michael Lawrence lawrence.mich...@gene.com wrote: 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 the browser. But what if the R session is headless, or if there is no need for commands in R to affect the browser? Then the web socket layer brings mostly unneeded complexity. I see websockets (like TCP sockets) as musch simpler than HTTP. No headers, no explicit server and explicit client (once the connection is open). Could you explain the complexity you see? An interesting comparison to BrowserViz is not shiny but OpenCPU. It's purely HTTP-based and still manages to maintain state (not sure how efficiently). I guess one advantage of web sockets is that one can program imperatively instead of declaratively on the server, i.e., the server can send a command to show a popup in response to some event, instead of returning a declaration that the popup should be shown. Exactly! So essentially web sockets are more natural for implementing server-side controllers (think MVC), instead of just the data model, but man, it's a shame to lose the features of HTTP. I'll confess: I set out to -shed- the features of HTTP. Isn't it a protocol designed for serving up web pages on demand? Not for fast, lighweight peer-to-peer communications? Ultimately, I think we want web apps that are easy to develop and maintain, and run equally well from either a useR's session or a remote client communicating to a dedicated, headless server. Is the generality of websockets worth the complexity? As an aside, it would seem relatively straight-forward to implement a simple bi-directional RPC mechanism between R and JS using the standard protocol (i.e., hide details like the callback). Does that sound reasonable? I was also a bit surprised about the need to copy/paste the JS boilerplate. Certainly there must be javascript frameworks with a more elegant solution to extensibility. You are correct on this, and I only need to correct the vignette, written many weeks ago. I now provide BrowserViz.jx, a simple Javascript module. It is used by both BrowserVizDemo and RCyjs. Sorry to have sent out an obsolete vignette. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Bioconductor Newsletter - April 2015
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
[Bioc-devel] BrowserViz
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 the browser. But what if the R session is headless, or if there is no need for commands in R to affect the browser? Then the web socket layer brings mostly unneeded complexity. An interesting comparison to BrowserViz is not shiny but OpenCPU. It's purely HTTP-based and still manages to maintain state (not sure how efficiently). I guess one advantage of web sockets is that one can program imperatively instead of declaratively on the server, i.e., the server can send a command to show a popup in response to some event, instead of returning a declaration that the popup should be shown. So essentially web sockets are more natural for implementing server-side controllers (think MVC), instead of just the data model, but man, it's a shame to lose the features of HTTP. Ultimately, I think we want web apps that are easy to develop and maintain, and run equally well from either a useR's session or a remote client communicating to a dedicated, headless server. Is the generality of websockets worth the complexity? As an aside, it would seem relatively straight-forward to implement a simple bi-directional RPC mechanism between R and JS using the standard protocol (i.e., hide details like the callback). Does that sound reasonable? I was also a bit surprised about the need to copy/paste the JS boilerplate. Certainly there must be javascript frameworks with a more elegant solution to extensibility. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BrowserViz: curious but needs a small tweak to run example
Forgot to add bioc-devel
On Fri, Apr 3, 2015 at 4:55 PM, Leonardo Collado Torres
lcoll...@jhu.edu 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 version 0.99.26 is passing all the checks in Linux/Mac OS
X but I got errors as shown below.
library(BrowserViz)
Loading required package: httpuv
Loading required package: jsonlite
Attaching package: ‘jsonlite’
The following object is masked from ‘package:utils’:
View
Attaching package: ‘BrowserViz’
The following object is masked from ‘package:jsonlite’:
toJSON
bv - BrowserViz(4000:4024)
Error: file.exists(browserFile) is not TRUE
traceback()
3: stop(sprintf(ngettext(length(r), %s is not TRUE, %s are not all TRUE),
ch), call. = FALSE, domain = NA)
2: stopifnot(file.exists(browserFile))
1: BrowserViz(4000:4024)
devtools::session_info()
Session
info
setting value
version R Under development (unstable) (2014-11-01 r66923)
system x86_64, darwin10.8.0
ui AQUA
language (EN)
collate en_US.UTF-8
tz America/New_York
Packages
package * version date source
BiocGenerics 0.13.11 2015-04-03 Bioconductor
BrowserViz * 0.99.26 2015-04-01 Bioconductor
devtools 1.6.1 2014-10-07 CRAN (R 3.2.0)
httpuv * 1.3.2 2014-10-23 CRAN (R 3.2.0)
jsonlite * 0.9.13 2014-10-21 CRAN (R 3.2.0)
Rcpp 0.11.5 2015-03-06 CRAN (R 3.2.0)
rstudioapi 0.2 2014-12-31 CRAN (R 3.2.0)
I can see that BrowserViz() by default uses browserFile = NA.
args(BrowserViz)
function (portRange, host = localhost, title = BrowserViz,
quiet = TRUE, browserFile = NA)
NULL
The man page states: defaults to NA, which is interpreted as an
instruction to use viz.html in the inst directory of this package.
Looking at the code I noticed that BrowserViz() starts with:
if (is.na(browserFile))
browserFile - browserVizBrowserFile
which is not working. However with
system.file('scripts', 'viz.html', package = 'BrowserViz')
[1]
/Library/Frameworks/R.framework/Versions/3.2/Resources/library/BrowserViz/scripts/viz.html
I can get it to work. See:
f - system.file('scripts', 'viz.html', package = 'BrowserViz')
bv - BrowserViz(4000:4024, browserFile = f)
Cheers,
Leo
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
