Re: [Bioc-devel] [GenomicFeatures] no pkgName found. makeTxDbPackage() called after txdb created from GFF3 file
Hi Malcolm, In general I have found ensembl to be really great and I expect that their gtf files are probably fine. Usually the exon rank is the 1st thing you will see left out when a gtf file is cutting corners, and you are correct that they seem to be including that. I ran the one for Homo sapiens though makeTranscriptDbFromGFF() and everything appears to be in working order. I wanted to warn Tengfei about this because I worry that most people will be surprised to learn that the gtf file format comes with fewer guarantees about the data included than they might have expected. I also mentioned it because I noticed that his function call to makeTranscriptDbFromGFF() did not specify an exonRankAttributeName, which strongly implies to me that maybe that his file might not have had that information present. The assumption was that if he had that information, he would have supplied that argument so that he could make use of it. But another possibility is that Tengfei just didn't need that information at all, in which case this will all just be another (possibly unwarranted) public service message. If that is the case, I apologise for the noise. Marc On 02/08/2013 06:19 PM, Cook, Malcolm wrote: .Hi Tengfei, . .Yes that looks like an oversight. Thanks for reporting that! I will .extend makeTxDbPackage so that it's more accommodating of these newer .transcriptDbs. If you want to help me out, you could call saveDb() on .your gmax189 object and send me the .sqlite file that you save it to. . .Also, if you have any alternate options for importing your data (other .than using GFF or GTF): I think you probably should consider it. The .file specifications for these filetypes are missing key details and so .you can very easily get a legal GFF or GTF file that is actually .missing important details from it's contents. For example, they can .commonly lack information about the order of the exons for a given .transcript, which can render them difficult (or impossible) to use for .transcript work. But for these specifications, that information is .optional. Marco, do you have any comment on ensembl GTF (which has exon order) in this regard? Thanks, Malcolm . . . Marc . . . .On 02/06/2013 09:46 PM, Tengfei Yin wrote: . Dear all, . . I am trying to build a txdb object from gff3 for soybean data and try to . make it a package. Code used like this . . gmax189- makeTranscriptDbFromGFF(~/Gmax_189_gene_exons.gff3, . format = gff3, species = Glycine max, . dataSource = http://www.phytozome.org/;) . makeTxDbPackage(txdb = gmax189, . version = 0.9.1, . maintainer = Tengfei Yin, . author = Tengfei Yin, . destDir=., . license=Artistic-2.0) . . Error message: . Error in gsub(_, , pkgName) : .error in evaluating the argument 'x' in selecting a method for function . 'gsub': Error: object 'pkgName' not found . . . Looks like my dataSource should be either BioMart or UCSC, otherwise no . pkgname will be produced in function .makePackageName? . . Or should I build annotation package in some other ways? . . Thanks a lot . . Tengfei . . my sessionInfo . . sessionInfo() . R Under development (unstable) (2013-01-21 r61728) . Platform: x86_64-unknown-linux-gnu (64-bit) . . locale: . [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C . [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 . [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 . [7] LC_PAPER=C LC_NAME=C . [9] LC_ADDRESS=C LC_TELEPHONE=C . [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C . . attached base packages: . [1] parallel stats graphics grDevices utils datasets methods . [8] base . . other attached packages: . [1] GenomicFeatures_1.11.8 AnnotationDbi_1.21.10 Biobase_2.19.2 . [4] GenomicRanges_1.11.28 IRanges_1.17.31BiocGenerics_0.5.6 . . loaded via a namespace (and not attached): . [1] biomaRt_2.15.0 Biostrings_2.27.10 bitops_1.0-5 . BSgenome_1.27.1 . [5] DBI_0.2-5 RCurl_1.95-3 Rsamtools_1.11.15 . RSQLite_0.11.2 . [9] rtracklayer_1.19.9 stats4_3.0.0 tools_3.0.0XML_3.95-0.1 . . [13] zlibbioc_1.5.0 . . . .___ .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
[Bioc-devel] bug tracker (was Fwd: Reminder: Your Atlassian OnDemand account bioc-internal will be deactivated soon)
Hi, Seems like there was some kind of billing snafu and the people that we pay for our internal bug tracker did not receive our payment. They are going to shut down the tracker on Monday. I'm trying to resolve this but wanted to send a warning...any bugs you filed in the tracker may become inaccessible. So you might want to copy the information before that happens. I know we are not 'officially' using the tracker but some of you may still want this information. Thanks, Dan -- Forwarded message -- From: Atlassian Kitty sa...@atlassian.com Date: Sat, Feb 9, 2013 at 11:33 AM Subject: Reminder: Your Atlassian OnDemand account bioc-internal will be deactivated soon Hi Dan Tenenbaum, I would like to inform you that your Atlassian OnDemand account - bioc-internal on atlassian.net is due to be deactivated on 11-Feb-2013. If you wish to continue using Atlassian OnDemand, please renew your account via the My Atlassian portal: https://my.atlassian.com/products?sen=2176972 If you do not renew before 11-Feb-2013, you will no longer have access to your instance and your data will be deleted shortly after. Please get in touch if you have any difficulties. You can reach us via any of the details below. Cheers, Kitty, The Atlassian Email Robot http://www.atlassian.com/kitty -- Browse, try, buy, on the new Atlassian Marketplace http://marketplace.atlassian.com http://www.atlassian.com sa...@atlassian.com +1 415 701 1110 (San Francisco, USA) +61 2 9262 1443 (Sydney, Australia) +31 20 796 0060 (Amsterdam, Netherlands) ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] bug tracker (was Fwd: Reminder: Your Atlassian OnDemand account bioc-internal will be deactivated soon)
My apologies, this email was not meant to go to this list. Dan On Sat, Feb 9, 2013 at 9:30 PM, Dan Tenenbaum dtene...@fhcrc.org wrote: Hi, Seems like there was some kind of billing snafu and the people that we pay for our internal bug tracker did not receive our payment. They are going to shut down the tracker on Monday. I'm trying to resolve this but wanted to send a warning...any bugs you filed in the tracker may become inaccessible. So you might want to copy the information before that happens. I know we are not 'officially' using the tracker but some of you may still want this information. Thanks, Dan -- Forwarded message -- From: Atlassian Kitty sa...@atlassian.com Date: Sat, Feb 9, 2013 at 11:33 AM Subject: Reminder: Your Atlassian OnDemand account bioc-internal will be deactivated soon Hi Dan Tenenbaum, I would like to inform you that your Atlassian OnDemand account - bioc-internal on atlassian.net is due to be deactivated on 11-Feb-2013. If you wish to continue using Atlassian OnDemand, please renew your account via the My Atlassian portal: https://my.atlassian.com/products?sen=2176972 If you do not renew before 11-Feb-2013, you will no longer have access to your instance and your data will be deleted shortly after. Please get in touch if you have any difficulties. You can reach us via any of the details below. Cheers, Kitty, The Atlassian Email Robot http://www.atlassian.com/kitty -- Browse, try, buy, on the new Atlassian Marketplace http://marketplace.atlassian.com http://www.atlassian.com sa...@atlassian.com +1 415 701 1110 (San Francisco, USA) +61 2 9262 1443 (Sydney, Australia) +31 20 796 0060 (Amsterdam, Netherlands) ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Arguments passing through dot-dot-dot lose ability to check for missing()?
This seems related also. Using match.call to capture ... arguments returns
odd results for missing arguments. Compare against another method of
capturing ... expressions:
capture_subst - function(...) eval(substitute(alist(...)))
capture_match - function(...) match.call(expand.dots=FALSE)$...
f1 - function(..., capture) {
capture(...)
}
f1(x=1, q=, capture=capture_subst)
f1(x=1, q=, capture=capture_match)
On Wed, Jan 23, 2013 at 3:08 PM, Peter Meilstrup
peter.meilst...@gmail.comwrote:
Hi R-devel. Is the following behavior in g1() and h1() expected? It seems
to make ... arguments work slightly differently from named arguments.
#missing() has the property that it looks up the chain
#for example, z can be missing in f3 even if
#that argument did have a name (y) in f2
f1 - function(x, ...) {
cat(In f1, missing(x) is , missing(x), \n)
f2(x, ...)
}
f2 - function(y, ...) {
cat(In f2, missing(y) is , missing(y), \n)
f3(y, ...)
}
f3 - function(z, ...) {
cat(in f3, missing(z) is , missing(z), \n)
}
f1( , 2) #all TRUE
#does this also work with ... arguments? It seems to lose track.
g1 - function(...) {
cat(In g1, missing(..1) is , missing(..1), \n)
g2(...)
}
g2 - function(...) {
cat(In g2, missing(..1) is , missing(..1), \n)
g3(...)
}
g3 - function(...) {
cat(in g3, missing(..1) is , missing(..1), \n)
}
g1( , 2) #TRUE, TRUE, FALSE ?!
# we can also elicit this lossiness without looking at the virtual ..n
# symbols:
h1 - function(x, ...) {
cat(in h1, missing(x) is , missing(x), \n)
h2(x, ...)
}
hh1 - function(...)
h2(...)
h2 - function(...)
h3(...)
h3 - function(z, ...)
cat(in h3, missing(z) is , missing(z), \n)
h3( , 1) #missing in h3
h2( , 1) #missing in h3
h1( , 1) #missing in h1 but NOT h3
hh1( , 1) #also not missing in h3
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trouble with accentuated characters in \title tag in Rd file
Dear R-devel-list, Since I had no answer on the R-help-list (http://permalink.gmane.org/gmane.comp.lang.r.general/284539) I try to present my trouble on the R-devel-list. I am sure in the past (one year ago) to succeed in putting accentuated characters in the \title tag in a .Rd file. Recently, creating a package, I have NA in the title function instead of the text containing the accentuated character. Could you please tell me what I missed in the understanding of package documentation creation ? Except the title, all works fine. Best regards Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Regression stars
Thanks for bringing this up, Frank. Since many of us are educators, I'd like to suggest a bolder approach. Discontinue even offering the stars as an option. Sadly, we can't stop reporting p-values, as the world expects them, but does R need to cater to that attitude by offering star display? For that matter, why not have R report confidence intervals as a default? Many years ago, I wrote a short textbook on stat, and included a substantial section on the dangers of significance testing. All three internal reviewers liked it, but the funny part is that all three said, I agree with this, but no one else will. :-) Norm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trouble with accentuated characters in \title tag in Rd file
See Writing R Extensions: Since R version 2.12.0 markup has been supported in the text, but use of characters other than English text and punctuation (e.g., ‘’) may limit portability. So the answer is: Don't do that. Best, Uwe Ligges On 09.02.2013 19:27, LaurentRdevel wrote: Dear R-devel-list, Since I had no answer on the R-help-list (http://permalink.gmane.org/gmane.comp.lang.r.general/284539) I try to present my trouble on the R-devel-list. I am sure in the past (one year ago) to succeed in putting accentuated characters in the \title tag in a .Rd file. Recently, creating a package, I have NA in the title function instead of the text containing the accentuated character. Could you please tell me what I missed in the understanding of package documentation creation ? Except the title, all works fine. Best regards Laurent __ 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] Regression stars
Changing the default for show.signif.stars should be sufficient to ensure that, if people are going to get themselves into trouble, they will have to do it on purpose. It's just a visual cue; removing it will not remove the underlying issue, namely blind acceptance of unlikely null models and distributions. For any complex problem, there is a solution that is simple, elegant, and wrong. As grants and careers can depend on these magic numbers, Upton Sinclair might save everyone some trouble... It is difficult to get a man to understand something, when his salary depends upon his not understanding. stringsAsFactors, however, is responsible for an endless stream of mildly irritating misunderstandings, and defaulting that to FALSE would be very nice. Just my $0.02. Defaults are one of the most powerful forces in the universe. Also, I liked your book. On Sat, Feb 9, 2013 at 10:48 AM, Norm Matloff matl...@cs.ucdavis.eduwrote: Thanks for bringing this up, Frank. Since many of us are educators, I'd like to suggest a bolder approach. Discontinue even offering the stars as an option. Sadly, we can't stop reporting p-values, as the world expects them, but does R need to cater to that attitude by offering star display? For that matter, why not have R report confidence intervals as a default? Many years ago, I wrote a short textbook on stat, and included a substantial section on the dangers of significance testing. All three internal reviewers liked it, but the funny part is that all three said, I agree with this, but no one else will. :-) Norm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- *A model is a lie that helps you see the truth.* * * Howard Skipperhttp://cancerres.aacrjournals.org/content/31/9/1173.full.pdf [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Regression stars
To clarify, I favor changing the defaults for stringsAsFactors and show.signif.stars to FALSE in R-3.0.0, and view any attempt to remove either functionality as a seemingly simple but fundamentally misguided idea. This is just my opinion, of course. The change could easily be accompanied by a startup notice or release notes indicating that the changes have been made, and can be reverted to past behavior if the user so desires. Perhaps more users will investigate the various settings, as a happy side effect. My thanks to everyone who spends time supporting and working on R-core. On Sat, Feb 9, 2013 at 12:44 PM, Tim Triche, Jr. tim.tri...@gmail.comwrote: Changing the default for show.signif.stars should be sufficient to ensure that, if people are going to get themselves into trouble, they will have to do it on purpose. It's just a visual cue; removing it will not remove the underlying issue, namely blind acceptance of unlikely null models and distributions. For any complex problem, there is a solution that is simple, elegant, and wrong. As grants and careers can depend on these magic numbers, Upton Sinclair might save everyone some trouble... It is difficult to get a man to understand something, when his salary depends upon his not understanding. stringsAsFactors, however, is responsible for an endless stream of mildly irritating misunderstandings, and defaulting that to FALSE would be very nice. Just my $0.02. Defaults are one of the most powerful forces in the universe. Also, I liked your book. On Sat, Feb 9, 2013 at 10:48 AM, Norm Matloff matl...@cs.ucdavis.eduwrote: Thanks for bringing this up, Frank. Since many of us are educators, I'd like to suggest a bolder approach. Discontinue even offering the stars as an option. Sadly, we can't stop reporting p-values, as the world expects them, but does R need to cater to that attitude by offering star display? For that matter, why not have R report confidence intervals as a default? Many years ago, I wrote a short textbook on stat, and included a substantial section on the dangers of significance testing. All three internal reviewers liked it, but the funny part is that all three said, I agree with this, but no one else will. :-) Norm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- *A model is a lie that helps you see the truth.* * * Howard Skipperhttp://cancerres.aacrjournals.org/content/31/9/1173.full.pdf -- *A model is a lie that helps you see the truth.* * * Howard Skipperhttp://cancerres.aacrjournals.org/content/31/9/1173.full.pdf [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Regression stars
I appreciate Tim's comments. I myself have a social science paper coming out soon in which I felt forced to use p-values, given their ubiquity. However, I also told readers of the paper that confidence intervals are much more informative and I do provide them. As I said earlier, there is no avoiding that, and R needs to report p-values for that reason. Instead, the question is what to do about the stars; I proposed eliminating them altogether. Star-crazed users know how to determine them themselves from the p-values, but deleting them from R would send a message. I did say my proposal was bold, which really meant I was suggesting that R do SOMETHING to send that message, not necessarily star elimination. One such something would be the proposal I made, which would be to add confidence intervals to the output. This too could be just an option, but again offering that option would send a message. Indeed, I would suggest that the help page explain that confidence intervals are more informative. (The help page could make a similar statement regarding the stars.) When I pitch R to people, I say that in addition to the large function and library base and the nice graphics capabilities, R is above all Statistically Correct--it's written by statisticians who know what they are doing, rather than some programmer simply implementing a formula from a textbook. I know that a lot of people feel this is one of R's biggest strengths. Given that, one might argue that R should do what it can to help users engage in good statistical practice. I think this was Frank's point. Norm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
