Re: [Bioc-devel] isActiveSeq deprecated
Makes sense. Thanks. I'll update my code. Florian From: Marc Carlson mcarl...@fhcrc.orgmailto:mcarl...@fhcrc.org Date: Friday, September 13, 2013 7:38 PM To: Florian Hahne florian.ha...@novartis.commailto:florian.ha...@novartis.com Cc: bioc-devel@r-project.orgmailto:bioc-devel@r-project.org bioc-devel@r-project.orgmailto:bioc-devel@r-project.org Subject: Re: isActiveSeq deprecated Hi Florian, Yes we are trying to make things more uniform. seqlevels() lets you rename as well as deactivate chromosomes you want to ignore, so it was really redundant with isActiveSeq(). So we are moving away from isActiveSeq() just so that users have less to learn about. The reason why isActiveSeq was different from seqlevels was just because it was born for a TranscriptDb (which is based on an annotation database) instead of being born on a GRanges object. So seqlevels was the more general tool. Marc On 09/13/2013 07:24 AM, Hahne, Florian wrote: Hi Marc, I saw these warnings in Gviz, but they stem from GenomicFeatures Warning messages: 1: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 2: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 3: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 4: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 5: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 6: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). So has the whole idea of active chromosomes in the data base been dropped? I could not find anything in the change notes. Do I get it right that you can now do seqlevels(txdb, force=TRUE) - chr1 if you just want the first chromosome to be active? Florian [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] IRanges: 'extractROWS' fails for 'RangedData'
Hi, It seems the issue has been resolved with the latest bioc build. Best wishes Julian On 09/15/2013 04:01 PM, Julian Gehring wrote: Hi, calling 'head' or 'tail' on a 'RangedData' objects fail with the lastest builds (R: 2013-09-14 r63932, IRanges: 1.19.35). The cause seems to be that there is no 'extractROWS' method that can be found for the signature 'RangedData'. As an example, see: ''' library(IRanges) ## generate the data ranges - IRanges(c(1,2,3),c(4,5,6)) rd = RangedData(ranges) ## this fails head(rd) ''' The last command returns: Error in (function (classes, fdef, mtable) : unable to find an inherited method for function ‘extractROWS’ for signature ‘RangedData’ Best wishes Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] plot methylation figure for end analysis
I agree that the profile or metagene plot is useful and widely applied. Creating such a plot consists of several steps, including: - quantifying and accumulating signal around sites of interest - normalization - visualization The qProfile() function in QuasR was designed to do the quantification/accumulation, which is not straightforward to implement efficiently and could use a lot of memory. This leaves it to the user to choose an appropriate approach for the normalization (if at all necessary) and gives full flexibility for plotting. qProfile returns a list of vectors, so normalization and plotting are not very complex (as shown in the example mentioned by Tim, in the QuasR vignette in section 6.1.6 Create a genomic pro le for a set of regions using qProfile). I would be interested to know your opinions - are these still too complex, so that a plot method would be of high value? Michael On 13.09.2013 07:21, bach le wrote: Many thanks. I've checked BSmooth but it seems not to be what I mentioned. As Tim said, this kind of figures are used quite often to illustrate the difference between groups of objects. Yet till now it seems that there has not been any offer from BioC (afa I may know). It would be great if someone can help to implement it. Cheers, On Fri, Sep 13, 2013 at 3:56 AM, Tim Triche, Jr. tim.tri...@gmail.comwrote: Bsmooth/bsseq (and QuasR, as well) are great for manipulating and analyzing BSseq data, but there's something in this email that I've never really found a great solution for, and that is so-called profile or metagene plots (the latter is a confusing bit of terminology, given that it is re-used for linear combinations of gene effects in expression studies). Suppose you wanted to look at the distribution of H3K4me3 or H3K27me3 ChIP-seq density relative to the start of (or exon/intron junctions within, or enhancers whose activity was linked to, ...) transcribed vs. silent genes across a genome. Suppose you also wanted to look at methylation proportions relative to the same positions (again, the idea here is to take a bunch of landmarks and plot a summary statistic describing the behavior of some measurement relative to those landmarks, across the genome). An example of such a plot is on page 23 of the QuasR user's manual. For clarity, here's a link: https://dl.dropboxusercontent.com/u/12962689/profile.png This seems like something that is so incredibly common it ought to be a generic function within BioC somewhere, but I've never found a really easy way to do it. If I want to plot a density matrix mat[x,y] for alhl x and all y, I can call image(mat) or persp(mat) and that's that. Is there something like this within biocGenerics of which I've remained completely ignorant, or... ? If it isn't a generic somewhere, I think I may have to implement one. On Thu, Sep 12, 2013 at 1:32 AM, Alex Gutteridge al...@ruggedtextile.com wrote: On 12.09.2013 08:25, Gia [guest] wrote: Hi, I would like to ask if anyone experienced with creating figures from BS-Seq methylation data for end analysis of genes (or any genomic features), like what was presented in the following link: http://www.nature.com/ng/**journal/v39/n1/fig_tab/ng1929_**F4.html http://www.nature.com/ng/journal/v39/n1/fig_tab/ng1929_F4.html It would be appreciate if you can show how to create this kind of figures using any Bioconductor packages. Cheers, -- output of sessionInfo(): None -- Sent via the guest posting facility at bioconductor.org. __**_ Bioconductor mailing list bioconduc...@r-project.org https://stat.ethz.ch/mailman/**listinfo/bioconductor https://stat.ethz.ch/mailman/listinfo/bioconductor Search the archives: http://news.gmane.org/gmane.**science.biology.informatics.**conductor http://news.gmane.org/gmane.science.biology.informatics.conductor I've only skimmed through that paper but that figure isn't showing BS-Seq data as far as I can see - it's showing the results of an array / IP based approach to methylation quantitation. BSmooth is one of the best packages I've found for manipulating BS-Seq data. If you get your data in there you could derive analogous statistics (i.e. methylation levels) pretty easily. Then any of the base plotting functions will give you similar graphs. -- Alex Gutteridge __**_ Bioconductor mailing list bioconduc...@r-project.org https://stat.ethz.ch/mailman/**listinfo/bioconductor https://stat.ethz.ch/mailman/listinfo/bioconductor Search the archives: http://news.gmane.org/gmane.** science.biology.informatics.**conductor http://news.gmane.org/gmane.science.biology.informatics.conductor -- *He that would live in peace and at ease, * *Must not speak all he knows, nor judge all he sees.* * * Benjamin Franklin, Poor Richard's Almanackhttp://archive.org/details/poorrichardsalma00franrich
Re: [Bioc-devel] isActiveSeq deprecated
Hey Marc, I think your move towards seqlevels is not quite working yet: samplefile - system.file(extdata, UCSC_knownGene_sample.sqlite, package=GenomicFeatures) txdb - loadDb(samplefile) ## This works fine fiveUTRsByTranscript(txdb) ## This breaks seqlevels(txdb, force=TRUE) - chr6 fiveUTRsByTranscript(txdb) Error in relist(x, f) : shape of 'skeleton' is not compatible with 'NROW(flesh)' Deep in the guts of this you are trying to build a GRanges object with NAs as seqlevels, and it doesn't really like that. Florian sessionInfo() R version 3.0.1 RC (2013-05-12 r62736) Platform: i386-apple-darwin12.3.0/i386 (32-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] parallel grid stats graphics grDevices utils datasets [8] methods base other attached packages: [1] GenomicFeatures_1.13.37 AnnotationDbi_1.23.23 Biobase_2.21.7 [4] GenomicRanges_1.13.43 XVector_0.1.4 IRanges_1.19.36 [7] BiocGenerics_0.7.5 Gviz_1.5.11 BiocInstaller_1.11.4 loaded via a namespace (and not attached): [1] biomaRt_2.17.2 Biostrings_2.29.18 biovizBase_1.9.2 [4] bitops_1.0-6BSgenome_1.29.1 cluster_1.14.4 [7] colorspace_1.2-2DBI_0.2-7 dichromat_2.0-0 [10] Hmisc_3.12-2labeling_0.2lattice_0.20-23 [13] munsell_0.4.2 plyr_1.8RColorBrewer_1.0-5 [16] RCurl_1.95-4.1 rpart_4.1-3 Rsamtools_1.13.39 [19] RSQLite_0.11.4 rtracklayer_1.21.11 scales_0.2.3 [22] stats4_3.0.1stringr_0.6.2 tools_3.0.1 [25] XML_3.98-1.1zlibbioc_1.7.0 From: Marc Carlson mcarl...@fhcrc.orgmailto:mcarl...@fhcrc.org Date: Friday, September 13, 2013 7:38 PM To: Florian Hahne florian.ha...@novartis.commailto:florian.ha...@novartis.com Cc: bioc-devel@r-project.orgmailto:bioc-devel@r-project.org bioc-devel@r-project.orgmailto:bioc-devel@r-project.org Subject: Re: isActiveSeq deprecated Hi Florian, Yes we are trying to make things more uniform. seqlevels() lets you rename as well as deactivate chromosomes you want to ignore, so it was really redundant with isActiveSeq(). So we are moving away from isActiveSeq() just so that users have less to learn about. The reason why isActiveSeq was different from seqlevels was just because it was born for a TranscriptDb (which is based on an annotation database) instead of being born on a GRanges object. So seqlevels was the more general tool. Marc On 09/13/2013 07:24 AM, Hahne, Florian wrote: Hi Marc, I saw these warnings in Gviz, but they stem from GenomicFeatures Warning messages: 1: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 2: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 3: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 4: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 5: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 6: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). So has the whole idea of active chromosomes in the data base been dropped? I could not find anything in the change notes. Do I get it right that you can now do seqlevels(txdb, force=TRUE) - chr1 if you just want the first chromosome to be active? Florian [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] isActiveSeq deprecated
Thanks Florian, I just checked in a fix for this. Please let me know if you find any other quirks. Marc On 09/16/2013 05:33 AM, Hahne, Florian wrote: Hey Marc, I think your move towards seqlevels is not quite working yet: samplefile - system.file(extdata, UCSC_knownGene_sample.sqlite, package=GenomicFeatures) txdb - loadDb(samplefile) ## This works fine fiveUTRsByTranscript(txdb) ## This breaks seqlevels(txdb, force=TRUE) - chr6 fiveUTRsByTranscript(txdb) Error in relist(x, f) : shape of 'skeleton' is not compatible with 'NROW(flesh)' Deep in the guts of this you are trying to build a GRanges object with NAs as seqlevels, and it doesn't really like that. Florian sessionInfo() R version 3.0.1 RC (2013-05-12 r62736) Platform: i386-apple-darwin12.3.0/i386 (32-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] parallel grid stats graphics grDevices utils datasets [8] methods base other attached packages: [1] GenomicFeatures_1.13.37 AnnotationDbi_1.23.23 Biobase_2.21.7 [4] GenomicRanges_1.13.43 XVector_0.1.4 IRanges_1.19.36 [7] BiocGenerics_0.7.5 Gviz_1.5.11 BiocInstaller_1.11.4 loaded via a namespace (and not attached): [1] biomaRt_2.17.2 Biostrings_2.29.18 biovizBase_1.9.2 [4] bitops_1.0-6BSgenome_1.29.1 cluster_1.14.4 [7] colorspace_1.2-2DBI_0.2-7 dichromat_2.0-0 [10] Hmisc_3.12-2labeling_0.2 lattice_0.20-23 [13] munsell_0.4.2 plyr_1.8 RColorBrewer_1.0-5 [16] RCurl_1.95-4.1 rpart_4.1-3 Rsamtools_1.13.39 [19] RSQLite_0.11.4 rtracklayer_1.21.11 scales_0.2.3 [22] stats4_3.0.1stringr_0.6.2 tools_3.0.1 [25] XML_3.98-1.1zlibbioc_1.7.0 From: Marc Carlson mcarl...@fhcrc.org mailto:mcarl...@fhcrc.org Date: Friday, September 13, 2013 7:38 PM To: Florian Hahne florian.ha...@novartis.com mailto:florian.ha...@novartis.com Cc: bioc-devel@r-project.org mailto:bioc-devel@r-project.org bioc-devel@r-project.org mailto:bioc-devel@r-project.org Subject: Re: isActiveSeq deprecated Hi Florian, Yes we are trying to make things more uniform. seqlevels() lets you rename as well as deactivate chromosomes you want to ignore, so it was really redundant with isActiveSeq(). So we are moving away from isActiveSeq() just so that users have less to learn about. The reason why isActiveSeq was different from seqlevels was just because it was born for a TranscriptDb (which is based on an annotation database) instead of being born on a GRanges object. So seqlevels was the more general tool. Marc On 09/13/2013 07:24 AM, Hahne, Florian wrote: Hi Marc, I saw these warnings in Gviz, but they stem from GenomicFeatures Warning messages: 1: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 2: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 3: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 4: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 5: 'isActiveSeq' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). 6: 'isActiveSeq-' is deprecated. Use 'seqlevels' instead. See help(Deprecated) and help(GenomicFeatures-deprecated). So has the whole idea of active chromosomes in the data base been dropped? I could not find anything in the change notes. Do I get it right that you can now do seqlevels(txdb, force=TRUE) - chr1 if you just want the first chromosome to be active? Florian [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] R-version
On 09/15/2013 07:12 AM, Wolfgang Huber wrote: Dear Julian thanks. Since this has come up here and elsewhere, and since the next Bioc release is coming up, let's remind ourselves that we should make development against 3.0.1 Patched (2013-09-03 r63824) -- Good Sport. Martin - should this be noted on http://www.bioconductor.org/developers/release-schedule ? Not sure what relevance this has in practice, but it seems wise to eliminate unnecessary variables. Thanks, the release notes have been updated. A short post to Bioc-devel with some additional pertinent information is forthcoming. Martin Best wishes Wolfgang On Sep 15, 2013, at 4:01 pm, Julian Gehring julian.gehr...@embl.de wrote: Hi, calling 'head' or 'tail' on a 'RangedData' objects fail with the lastest builds (R: 2013-09-14 r63932, IRanges: 1.19.35). The cause seems to be that there is no 'extractROWS' method that can be found for the signature 'RangedData'. As an example, see: ''' library(IRanges) ## generate the data ranges - IRanges(c(1,2,3),c(4,5,6)) rd = RangedData(ranges) ## this fails head(rd) ''' The last command returns: Error in (function (classes, fdef, mtable) : unable to find an inherited method for function ‘extractROWS’ for signature ‘RangedData’ Best wishes Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] R and Bioconductor versions for the forthcoming release
Bioconductor developers: The Bioc release schedule is available http://bioconductor.org/developers/release-schedule/ A reminder that version 2.13 of Bioconductor will be released on October 15, and will work with R-3.0.2. Package authors should be testing the Bioc 'devel' version of their package with R-3.0.2 pre-release. R-3.0.2 is scheduled for release on September 25. The lack of synchrony between R and Bioc releases introduces a wrinkle. Users of R-3.0.2 (including the pre-release, which became available earlier today) using install.packages() (rather than the recommended biocLite()) will be directed toward Bioconductor 2.13 packages, so will be getting a preview of the Bioconductor release scheduled for October 15. Unfortunately, the scheduling requirements of our own release cycle (including building annotation packages and providing fair warning for new package contributors) did not allow us to move the Bioconductor release forward. The chosen solution seemed least disruptive of the available options. R-3.0.2 allows for an environment variable to influence the version of Bioconductor in use, from the R NEWS file: • The default ‘version’ of Bioconductor for its packages has been changed to the upcoming 2.13, but this can be set by the environment variable R_BIOC_VERSION, e.g. in file Renviron.site. Martin Morgan, Bioconductor -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] declaring package dependencies
On Sep 16, 2013, at 01:46 PM, Brian Rowe wrote: That reminds me: I once made a suggestion on how to automate some of the CRAN deployment process, but it was shot down as not being useful to them. I do recall a quote that was along the lines of as long as you don't need help, do whatever you want, so one thought is to just set up a build server that does the building across the three versions of R, checks dependencies, rebuilds when release, patch, or devel are updated, etc. This would ease the burden on package maintainers and would just happen to make the CRAN folks' lives easier by catching a lot of bad builds. A proof of concept on AWS connecting to github or rforge could probably be finished on a six-pack. Speak up if anyone thinks this would be useful. Yes useful. But that includes a package build system (which is what breaks on R-Forge). If you could do that on a six-pack then could you fix R-Forge on a three-pack first please? The R-Forge build system is itself an open source package on R-Forge. Anyone can look at it, understand it and change it to be more stable. That build system is here : https://r-forge.r-project.org/R/?group_id=34 (I only know this because Stefan told me once. So I suspect others don't know either, or it hasn't sunk in that we're pushing on an open door.) Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
Ben Bolker wrote : Do you happen to remember what the technical difficulty was? From memory I think it was that CRAN maintainers didn't have access to Uwe's winbuilder machine. But often when I get OK from winbuilder R-devel I don't want it to go to CRAN yet. So procedures and software would have to be put in place to handle that (unclear) logic which I didn't propose anything for or offer any code to do. So time and effort to decide and time and effort to implement. Just a guess. And maybe some packages don't run on Windows, so what about those? It's all those edge cases that really take the time. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FOSS licence with BuildVignettes: false
On 16.09.2013 01:04, Ben Bolker wrote: Uwe Ligges ligges at statistik.tu-dortmund.de writes: Setting BuildVignettes: false is fine if it is possible to build the vignettes, and the latter is checked in CRAN incoming checks (but not the daily checks). Uwe Ligges Hmmm. I was told by the CRAN maintainers on Aug 7 that CRAN FOSS licence with BuildVignettes: false is not a false positive, CRAN is fixable, and is mentioned at CRAN http://cran.r-project.org/doc/manuals/r-devel/R-exts.html# CRANThe-DESCRIPTION-file as not to be used in an FOSS package. (I had said in my previous e-mail to CRAN that all NOTEs were false positives, minor or not fixable.) Admittedly this e-mail nowhere said explicitly you must fix this or we will not accept it for CRAN, but that was certainly the impression I got. TFM says R-exts [BuildVignettes: false] should only be used exceptionally, for R-exts example if the PDFs include large figures which are not part of the R-exts package sources (and hence only in packages which do not have an R-exts Open Source license). So either I'm confused (always a possibility!) or it seems there are some inconsistencies here ... Yes, and I could see really rare circumstances where vignette building takes a long time and the maintainer decides not to build vignettes as part of the daily checks. If there were no possible (but typically rather rare) exceptions, this would be at least a Warning. Best, Uwe Ligges On 15.09.2013 22:13, Viechtbauer Wolfgang (STAT) wrote: Dear All, I have been checking the metafor package against R-devel. R CMD check --as-cran metafor yields one note: FOSS licence with BuildVignettes: false Yes, I have 'BuildVignettes: FALSE' in my DESCRIPTION file. I see at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS: Tue, 25 Jun 2013 CHANGES IN R-devel UTILITIES 'R CMD check --as-cran' warns about a false value of the 'DESCRIPTION' field 'BuildVignettes' for Open Source packages, and ignores it (as an Open Source package needs to have complete sources for its vignettes). My questions are: 1) Is this going to be an issue if I submit a new version of the metafor package to CRAN right now? 2) And if the answer to 1 is Not right now: Is this going to become an issue in the future? In other words, is it the goal to only allow packages with BuildVignettes=true if they have an FOSS license at some point in the future? Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 09/15/2013 11:09 AM, Matthew Dowle wrote: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. Right, but Please _do not_ upload BioConductor packages or CRAN packages. from the winbuilder page. Göran winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13-09-16 3:59 AM, Göran Broström wrote: On 09/15/2013 11:09 AM, Matthew Dowle wrote: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. Right, but Please _do not_ upload BioConductor packages or CRAN packages. from the winbuilder page. From the context, that message is about packages that are already on CRAN without Windows binaries already built. Duncan Murdoch Göran winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13-09-15 9:58 PM, Yihui Xie wrote: I've been watching this thread closely and trying not to chime in, because as Brian Rowe mentioned about CRAN's mysterious absence in a previous reply. It's no mystery that they don't discuss CRAN policies on this list. That's been stated many times. I don't expect that to change because users on this list make stupid jokes about it. Duncan Murdoch CRAN is like a ghost in r-devel (or any other mailing lists) -- everybody is discussing about it, and nobody has ever seen it. Perhaps one day useRs will realize that the rings of Saturn are actually composed of the lost discussions about CRAN. (Just kidding. No offence. I swear I appreciate the great work of CRAN, and rep(thank you, CRAN, 1e6).) Although this discussion may also contribute to the rings of Saturn, I want to emphasize one final point: requests from package authors do not necessarily mean more work for CRAN. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Sep 15, 2013 at 6:11 PM, Ben Bolker bbol...@gmail.com wrote: Matthew Dowle mdowle at mdowle.plus.com writes: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew I was planning to write a careful e-mail to CRAN suggesting essentially this, and I may yet do so, but for now I'll just chime in and +1 this. Yihui Xie made a very similar suggestion sometime last year (I think). It would seem so much easier for everyone, package maintainers *and* CRAN maintainers, to have an automatic filter of this sort, and I can't figure out any downside other than needing slightly more computer power (which surely must be a reasonable tradeoff for fewer human resources!), *if* having the auto-filter made people sloppier about checking before submitting. Do you happen to remember what the technical difficulty was? If I were a CRAN maintainer (thank goodness I'm not!), overcoming it would be one of my top priorities ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Patch: fix segfault from empty raster
Hi, A colleague recently came across an R crash, which I can boil down to the following, running under Rgui on Windows 7: library(ggplot2) ggplot(data.frame(x=1, y=1, z=4.7), aes(x, y, z=z)) + stat_summary2d() This reliably causes a segmentation fault. sessionInfo() below. What's happening is that (for reasons which I'll discuss with the ggplot2 developers) the 'colorbar' guide is being built with a zero-size source raster. In L_raster() (grid.c), this raster is not a nativeRaster, so we do image = (unsigned int*) R_alloc(n, sizeof(unsigned int)); with n = 0, and R_alloc() gives us a NULL pointer. The display of this raster requests interpolation, so we end up in R_GE_rasterInterpolate(), where 'sraster' is NULL, and chaos ensues as it tries to read source pixels. It seems to me that it doesn't make sense to display an empty raster, so I inserted a check in L_raster(). A proof-of-concept patch is attached. With this patch, R gives an error message instead of a segfault. Does this seem a sensible change? If so, could something like it be incorporated? Thanks, Ben. - - - - 8 - - - - sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_Ireland.1252 LC_CTYPE=English_Ireland.1252 [3] LC_MONETARY=English_Ireland.1252 LC_NUMERIC=C [5] LC_TIME=English_Ireland.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] ggplot2_0.9.3.1 loaded via a namespace (and not attached): [1] colorspace_1.2-2 compiler_3.0.1 dichromat_2.0-0digest_0.6.3 [5] grid_3.0.1 gtable_0.1.2 labeling_0.2 MASS_7.3-26 [9] munsell_0.4plyr_1.8 proto_0.3-10 RColorBrewer_1.0-5 [13] reshape2_1.2.2 scales_0.2.3 stringr_0.6.2 tools_3.0.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 09/16/2013 12:38 PM, Duncan Murdoch wrote: On 13-09-16 3:59 AM, Göran Broström wrote: On 09/15/2013 11:09 AM, Matthew Dowle wrote: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. Right, but Please _do not_ upload BioConductor packages or CRAN packages. from the winbuilder page. From the context, that message is about packages that are already on CRAN without Windows binaries already built. Maybe, but that is not what the page says. Anyway, may I use this facility to check new versions of my CRAN packages or not? Göran Duncan Murdoch Göran winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
I haven't used rforge, but I will look check out the scripts. The reason it would be a six-pack of work is that there are generic build systems that handle most of this work. What they don't do is act as a repository, so rforge could remain that while separating out the build process. On Sep 16, 2013, at 4:58 AM, Matthew Dowle mdo...@mdowle.plus.com wrote: On Sep 16, 2013, at 01:46 PM, Brian Rowe wrote: That reminds me: I once made a suggestion on how to automate some of the CRAN deployment process, but it was shot down as not being useful to them. I do recall a quote that was along the lines of as long as you don't need help, do whatever you want, so one thought is to just set up a build server that does the building across the three versions of R, checks dependencies, rebuilds when release, patch, or devel are updated, etc. This would ease the burden on package maintainers and would just happen to make the CRAN folks' lives easier by catching a lot of bad builds. A proof of concept on AWS connecting to github or rforge could probably be finished on a six-pack. Speak up if anyone thinks this would be useful. Yes useful. But that includes a package build system (which is what breaks on R-Forge). If you could do that on a six-pack then could you fix R-Forge on a three-pack first please? The R-Forge build system is itself an open source package on R-Forge. Anyone can look at it, understand it and change it to be more stable. That build system is here : https://r-forge.r-project.org/R/?group_id=34 (I only know this because Stefan told me once. So I suspect others don't know either, or it hasn't sunk in that we're pushing on an open door.) Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 16.09.2013 13:52, Göran Broström wrote: On 09/16/2013 12:38 PM, Duncan Murdoch wrote: On 13-09-16 3:59 AM, Göran Broström wrote: On 09/15/2013 11:09 AM, Matthew Dowle wrote: I'm a little surprised by this thread. I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and that's been pretty informative in the past : http://developer.r-project.org/RSSfeeds.html Mainly though, I submit to winbuilder before submitting to CRAN, as the CRAN policies advise. Right, but Please _do not_ upload BioConductor packages or CRAN packages. from the winbuilder page. From the context, that message is about packages that are already on CRAN without Windows binaries already built. Maybe, but that is not what the page says. Anyway, may I use this facility to check new versions of my CRAN packages or not? Yes, before submission, but not if the version is on CRAN already (i.e. if the version became a CRAN package). Best, Uwe Ligges Göran Duncan Murdoch Göran winbuilder's R-devel seems to be built daily, saving me the time. Since I don't have Windows it kills two birds with one stone. It has caught many problems for me before submitting to CRAN and I can't remember it ever not responding in a reasonable time. http://win-builder.r-project.org/upload.aspx I've suggested before that winbuilder could be the mechanism to submit to CRAN rather than an ftp upload to incoming. Only if winbuilder passed OK on R-devel could it then go to a human. But iirc there was a technical difficulty preventing this. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rcpp modules
Dear all,
my apologies for posting here instead of rcpp-devel (registration for
which did not seem to work). I try to use a Rcpp module outside a
package using the following code which should work according to posts on
this list/rcpp-devel.
library('Rcpp');
dlr = dyn.load('build/libtestlib.so');
mod = Module('testclass', PACKAGE = dlr);
cl = new(mod$testclass);
This results in the error message:
Failed to initialize module pointer: Error in
FUN(_rcpp_module_boot_testclass[[1L]], ...): no such symbol
_rcpp_module_boot_testclass in package
/home/pingu/src/2013-rcpp-test/rcpptest/build/libtestlib.so
Passing the PACKAGE argument above reportedly should solve this error
but does not seem to do so in my setup. Any suggestion appreciated. The
mentioned symbol exists in the shared object file which is linked agains
libR and libRcpp. Both a build with R CMD SHLIB and/or standard cmake
gives the same result.
Environment:
Linux
R 3.0.1
Rcpp_0.10.4
Freshly compiled from source.
Thanks in advance,
Stefan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcpp modules
On 16 September 2013 at 16:12, Stefan Boehringer wrote: | my apologies for posting here instead of rcpp-devel (registration for | which did not seem to work). It is using the standard Python mailman software, as do lots of other lists. Your From: field _must_ match you registration. That is the sole requirement. | I try to use a Rcpp module outside a Please post Rcpp questions on rcpp-devel. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] helping R-forge build
(subject changed from Re: [Rd] declaring package dependencies ) ... Yes useful. But that includes a package build system (which is what breaks on R-Forge). If you could do that on a six-pack then could you fix R-Forge on a three-pack first please? The R-Forge build system is itself an open source package on R-Forge. Anyone can look at it, understand it and change it to be more stable. That build system is here : https://r-forge.r-project.org/R/?group_id=34 (I only know this because Stefan told me once. So I suspect others don't know either, or it hasn't sunk in that we're pushing on an open door.) Matthew Open code is necessary, but to debug one needs access to logs, etc, to see where it is breaking. Do you know how to find that information? (And, BTW, there are also tools to help automatically build R and test packages at http://automater.r-forge.r-project.org/ .) Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] helping R-forge build
On 16/09/13 16:11, Paul Gilbert wrote: (subject changed from Re: [Rd] declaring package dependencies ) ... Yes useful. But that includes a package build system (which is what breaks on R-Forge). If you could do that on a six-pack then could you fix R-Forge on a three-pack first please? The R-Forge build system is itself an open source package on R-Forge. Anyone can look at it, understand it and change it to be more stable. That build system is here : https://r-forge.r-project.org/R/?group_id=34 (I only know this because Stefan told me once. So I suspect others don't know either, or it hasn't sunk in that we're pushing on an open door.) Matthew Open code is necessary, but to debug one needs access to logs, etc, to see where it is breaking. Do you know how to find that information? There's a link at the bottom of the R-Forge page to : http://download.r-forge.r-project.org/STATUS I don't know if that's enough but it's a start maybe. I've copied Stefan in case there are more logs somewhere else. (And, BTW, there are also tools to help automatically build R and test packages at http://automater.r-forge.r-project.org/ .) automater looks good! What's the next step? Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FOSS licence with BuildVignettes: false
On 13-09-16 05:19 AM, Uwe Ligges wrote: ... Yes, and I could see really rare circumstances where vignette building takes a long time and the maintainer decides not to build vignettes as part of the daily checks. ... I thought 'BuildVignettes: FALSE' only turns of assembling the pdf, all the code is still run. I don't think that would affect the time very much. Am I wrong (again)? Paul Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a fast table() for the 1D case
Any chance some improvements can be made on table()?
table() is probably one of the most used R functions when working
interactively. Unfortunately it can be incredibly slow, especially
on a logical vector where a simple sum() is hundred times faster
(I actually got into the habit of using sum() instead of table()).
The table1D() proposal below doesn't go as far as using sum() on a
logical vector but it already provides significant speedups for most
use cases.
Thanks,
H.
On 08/09/2013 01:19 AM, Hervé Pagès wrote:
Hi,
table1D() below can be up to 60x faster than base::table() for the 1D
case. Here are the detailed speedups compared to base::table().
o With a logical vector of length 5M: 11x faster
(or more if 'useNA=always')
o With factor/integer/numeric/character of length 1M and 9 levels
(or 9 distinct values for non-factors):
- factor: 60x faster
- integer/numeric vector: 12x faster
- character vector: 2.4x faster
o With factor/integer/numeric/character of length 1M and no
duplicates:
- factor: 5x faster
- integer vector: 2x faster
- numeric vector:1.7x faster
- character vector: no significant speedup
Would be great if this improvement could make it into base::table().
Thanks,
H.
## A fast table() implementation for the 1D case (replacing the '...'
## arg with 'x' and omitting the 'dnn' and 'deparse.level' arguments
## which are unrelated to performance).
table1D - function(x, exclude = if (useNA == no) c(NA, NaN),
useNA = c(no, ifany, always))
{
if (!missing(exclude) is.null(exclude)) {
useNA - always
} else {
useNA - match.arg(useNA)
}
if (useNA == always !missing(exclude))
exclude - setdiff(exclude, NA)
if (is.factor(x)) {
x2 - levels(x)
append_NA - (useNA == always ||
useNA == ifany any(is.na(x)))
!any(is.na(x2))
if (append_NA) {
x2 - c(x2, NA)
x - factor(x, levels=x2, exclude=NULL)
}
t2 - tabulate(x, nbins=length(x2))
if (!is.null(exclude)) {
keep_idx - which(!(x2 %in% exclude))
x2 - x2[keep_idx]
t2 - t2[keep_idx]
}
} else {
xx - match(x, x)
t - tabulate(xx, nbins=length(xx))
keep_idx - which(t != 0L)
x2 - x[keep_idx]
t2 - t[keep_idx]
if (!is.null(exclude)) {
exclude - as.vector(exclude, typeof(x))
keep_idx - which(!(x2 %in% exclude))
x2 - x2[keep_idx]
t2 - t2[keep_idx]
}
oo - order(x2)
x2 - x2[oo]
t2 - t2[oo]
append_NA - useNA == always !any(is.na(x2))
if (append_NA) {
x2 - c(x2, NA)
t2 - c(t2, 0L)
}
}
ans - array(t2)
dimnames(ans) - list(as.character(x2))
names(dimnames(ans)) - x # always set to 'x'
class(ans) - table
ans
}
table1D() also fixes some issues with base::table() that can be exposed
by running the tests below.
test_table - function(FUN_NAME)
{
FUN - match.fun(FUN_NAME)
.make_target - function(target_names, target_data)
{
ans - array(target_data)
dimnames(ans) - list(as.character(target_names))
names(dimnames(ans)) - x
class(ans) - table
ans
}
.check_identical - function(target, current, varname, extra_args)
{
if (identical(target, current))
return()
if (extra_args != )
extra_args - paste0(, , extra_args)
cat(unexpected result for ', FUN_NAME,
(x=, varname, extra_args, )'\n, sep=)
}
.test_exclude - function(x, varname, target_names0, target_data0,
exclude)
{
extra_args - paste0(exclude=, deparse(exclude))
current - FUN(x=x, exclude=exclude)
target_names - target_names0
target_data - target_data0
if (is.null(exclude)) {
if (!any(is.na(target_names))) {
target_names - c(target_names, NA)
target_data - c(target_data, 0L)
}
} else {
if (!is.factor(x)) {
exclude - as.vector(exclude, typeof(x))
} else if (!any(is.na(levels(x {
exclude - union(exclude, NA)
}
exclude_idx - match(exclude, target_names, nomatch=0L)
if (any(exclude_idx != 0L)) {
target_names - target_names[-exclude_idx]
target_data - target_data[-exclude_idx]
}
}
target - .make_target(target_names, target_data)
.check_identical(target,
[Rd] strange behavior for RcmdrPlugin.qual
Hello! Over the weekend, I updated my RcmdrPlugin.qual package. It works fine on a 64 bit Windows machine but not a 32 bit. This is very strange. The new menu with all of the Quality Control stuff does not appear. Have any of you run into this sort of thing before, please? Thanks, Sincerely, Erin Erin M. Hodgess, Ph.D. Associate Professor Department of Computer and Mathematical Sciences University of Houston - Downtown mailto: hodge...@uhd.edumailto:hodge...@uhd.edu [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior for RcmdrPlugin.qual
Dear Erin, I noticed that your RcmdrPlugin.qual package declares qcc under Suggests, and thus qcc isn't necessarily installed along with the plug-in. The menu file for your plug-in requires the presence of qcc to install most of the menu items under the Quality Control menu. I installed your plug-in via install.packages() on a 64-bit Windows 8 machine, with R 3.0-1 and Rcmdr 2.0-0. When I first loaded the plug-in, both in 64-bit and 32-bit Windows, most of the items under the Quality Control menu didn't appear, because qcc wasn't installed. The menu itself, along with a couple of items, did appear, and so this may not be the same problem as you described. Also, I don't have a 32-bit machine but, as I said, saw identical behaviour under 32- and 64-bit R on a 64-bit machine. I hope this helps, John On Tue, 17 Sep 2013 00:06:09 + Hodgess, Erin hodge...@uhd.edu wrote: Hello! Over the weekend, I updated my RcmdrPlugin.qual package. It works fine on a 64 bit Windows machine but not a 32 bit. This is very strange. The new menu with all of the Quality Control stuff does not appear. Have any of you run into this sort of thing before, please? Thanks, Sincerely, Erin Erin M. Hodgess, Ph.D. Associate Professor Department of Computer and Mathematical Sciences University of Houston - Downtown mailto: hodge...@uhd.edumailto:hodge...@uhd.edu [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel John Fox McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] JDK not registered
Given: $JAVA_HOME=~/jdk1.7.0_40 $R_SHELL=/bin/sh $PATH=$R_HOME/bin:$JAVA_HOME/bin:... which jar -- ~/jdk1.7.0_40/bin/jar which javac -- ~/jdk1.7.0_40/bin/javac which javah -- ~/jdk1.7.0_40/bin/javah which java -- '', even though there is one in $JAVA_HOME/bin whereis java -- java: /bin/java /usr/bin/java /sbin/java /usr/sbin/java /lib/java /usr/lib/java /usr/local/bin/java /usr/share/java obviously missing the 1.7.0_40 version in $JAVA_HOME/bin as well as the 1.5 version in /usr/bin If I push into the Rserve package directory and run ./configure, I get: ... checking Java support in R... present: interpreter : '' archiver: '' compiler: '' header prep.: '' cpp flags : '' java libs : '' configure: error: Java Development Kit (JDK) is missing or not registered. Of course that may be because I have not yet successfully completed a make of R if I run R CMD javareconf -e I get: Java interpreter : /home1/optimal1/jdk1.7.0_40/jre/bin/java (why not the one in the jdk/bin?) Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Error occurred during initialization of VM Could not reserve enough space for object heap *** Java interpreter doesn't work properly. I have found that $JAVA_HOME/bin/java (and the one in the jre/bin directory) each complain Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. but, if I define: alias java='$JAVA_HOME/bin/java -Xmx668m -XX:MaxPermSize=128m' I can run java in SSH, though R CMD javareconf -e still fails to initialize the VM. What can I do to get javareconf to run java with those memory limits? -- View this message in context: http://r.789695.n4.nabble.com/R-build-issues-tp4676149p4676286.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
