Re: [Bioc-devel] Use of SummerisedExperiments or MultiAssayExperiments of many many Dataframes/ nested List objects

[James W. MacDonald]

I think the last sentence of your email answers your question? You don't
know how to do this, primarily because you seem not to know anything about
SE or MAE objects, and you need to learn about the latter in order to do
the former. So I would recommend reading up about (probably) MAE objects
and figuring out how your existing data would fit into that framework.

On Fri, Jan 31, 2020 at 8:31 AM Krutik Patel (PGR) 
wrote:

> Hello Bioc-Devel,
>
> This will be a long winded question and I apologise for that, I just want
> to be thorough.
>
> I recently submitted a package onto bioconductor for review, and received
> a response to have SummerisedExperiments or MultiAssayExperiments as the
> standard format for my package. I looked into the usage of SE/ MAE and do
> think they are very useful. I just find it difficult to envision the usage
> of these objects in my package. Namely, because I do not use sequencing
> data and so I do not have any phenoData.
>
> The input to my package is deferentially expressed data from microRNA and
> mRNA data, and I feel like that should stay as data frames to make it
> easier for users to use. From these data frames, many other data frames and
> nested lists are created. I will give a short demonstration of how my
> package functions below and I would appreciate it if any user could
> demonstrate to me how to incorporate SE's or MAE's.
>
> # This will load test data
> > miR <- mm_miR
> > mRNA <- mm_mRNA
> # Visualise the data
> > head(miR [1:5, 1:5])
>
>  D1.Log2FC D1.adjPValD2.Log2FC   D2.adjPVal  D3.Log2FC
> mmu-let-7b-3p -0.008006934 0.97706031 -0.008296431 0.9503666129 -0.1153951
> mmu-let-7c-5p  0.299802302 0.30094186  0.511083040 0.0489321072  0.4663393
> mmu-let-7d-3p  0.430125310 0.06476131  0.483677350 0.0228474958  0.4301441
> mmu-let-7e-3p  0.417901606 0.06543412  0.448677130 0.0301945611  0.3051121
> mmu-let-7e-5p  0.637167321 0.01010895  0.984529549 0.0001462246  0.8917273
>
> > head(mRNA [1:5, 1:5])
>
>  D1.Log2FC   D1.adjPVal  D2.Log2FC   D2.adjPVal D3.Log2FC
> A2m   1.336002 0.4627700063  4.0470385 0.0114355180  3.688919
> AA986860 -1.886142 0.0239685308 -0.8686382 0.2892313624 -1.115943
> Aadac-2.493883 0.0022213531 -2.1678098 0.0051038251 -1.338884
> Aadat-3.647727 0.0006583596 -3.3660043 0.0011145806 -2.616356
> Aass -1.283668 0.0101430103 -1.9567394 0.0004421697 -1.315752
> # As you can see creating this type of data for a user would be quite
> simple if it is kept as data frames
>
> # We use the following functions to retrieve annotation IDs
> # They will produce several data frames each
> > getIDs_miR_mouse(miR)
>
> > head(miR_ensembl)
>
>  GENENAME   ID
> 1   mmu-let-7b-3p 
> 2   mmu-let-7c-5p 
> 3   mmu-let-7d-3p 
> 4   mmu-let-7e-3p 
> 5   mmu-let-7e-5p 
> 6 mmu-let-7f-1-3p 
>
> > head(miR_entrez)
>  GENENAME   ID
> 1   mmu-let-7b-3p 
> 2   mmu-let-7c-5p 
> 3   mmu-let-7d-3p 
> 4   mmu-let-7e-3p 
> 5   mmu-let-7e-5p 
> 6 mmu-let-7f-1-3p 
>
> > getIDs_miR_mouse(mRNA)
>
>   GENENAME ID
> 1  A2m ENSMUSG0030111
> 2 AA986860 ENSMUSG0042510
> 3Aadac ENSMUSG0027761
> 4Aadat ENSMUSG0057228
> 5 Aass ENSMUSG0029695
> 6 Abat ENSMUSG0057880
>
>   GENENAME ID
> 1  A2m 232345
> 2 AA986860 212439
> 3Aadac  67758
> 4Aadat  23923
> 5 Aass  30956
> 6 Abat 268860
>
> # The following function will combine the two data frames into a new one
> genetic_data <- CombineGenes(miR_data = miR, mRNA_data = mRNA)
>
> # This function will alter the new data frame into a nested list separated
> by a common string
> genelist <- GenesList(method = "c", genetic_data = genetic_data,
> timeString = "D")
> > as.data.frame(lapply(genelist, function(x) dim(x)))
>
> D1   D2   D3   D7  D14
> 1 2278 2278 2278 2278 2278
> 222222
>
> # Then we can filter out "non-significant" values
> > as.data.frame(lapply(filtered_genelist, function(x) dim(x)))
>
> D1   D2   D3   D7 D14
> 1 1108 1389 1037 1196 380
> 22222   2
>
>
> I could go on but I think the point is clear. This package is full of data
> frames and nested lists and it would be nice to use SE or MAE to tidy up
> the global environment. Is there a way of turning many many data frames/
> nested lists into an SE or MEA object? If there is please do let me know, I
> am not sure how to do this, and I feel as though it would be a necessary
> process to (at least) explore if I want my package on bioconductor.
>
> Many

[Bioc-devel] GO.db package data source

[James W. MacDonald]

Are we still using the scripts in BioconductorAnnotationPipeline/go/scripts
to download GO data and create the GO.db package?

If so, that is likely a problem that will only get worse with time.
Apparently geneontology.org is no longer generating the SQL dumps that the
go scripts rely on, so whatever we download is outdated. There have been
some complaints to the helpdesk about the data (
https://github.com/geneontology/helpdesk/issues/4), where they discuss a
new pipeline (RDF) that may not have ended up being the new pipeline?

Apparently they are now using OBO or OWL (
http://geneontology.org/docs/download-ontology/) for the downloadable data,
so we should consider switching.

I bring this up because apparently the current release GO.db is missing
terms that were added as far back as 2018.

Best,

Jim



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] GO.db package data source

[James W. MacDonald]

Further to this point, when comparing to the latest OBO from geneontology,
it looks like the current GO.db has just over 1000 GO IDs that are not in
GO any longer, and almost 500 GO IDs are in the GO OBO file that are not in
GO.db

On Wed, Apr 1, 2020 at 12:11 PM James W. MacDonald  wrote:

> Are we still using the scripts in
> BioconductorAnnotationPipeline/go/scripts to download GO data and create
> the GO.db package?
>
> If so, that is likely a problem that will only get worse with time.
> Apparently geneontology.org is no longer generating the SQL dumps that
> the go scripts rely on, so whatever we download is outdated. There have
> been some complaints to the helpdesk about the data (
> https://github.com/geneontology/helpdesk/issues/4), where they discuss a
> new pipeline (RDF) that may not have ended up being the new pipeline?
>
> Apparently they are now using OBO or OWL (
> http://geneontology.org/docs/download-ontology/) for the downloadable
> data, so we should consider switching.
>
> I bring this up because apparently the current release GO.db is missing
> terms that were added as far back as 2018.
>
> Best,
>
> Jim
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Author name displayed incorrectly in package landing page

[James W. MacDonald]

An alternative that might also work is to add a CITATION file, which might
make it easier to define first and last names.
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#CITATION-files

On Wed, Apr 22, 2020 at 4:42 PM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> You might have better luck updating the Author and Maintainer fields in
> the DESCRIPTION to Authors@R syntax.
> It should also be noted there should only be one maintainer for the
> package.
>
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Selles
> Vidal, Lara 
> Sent: Wednesday, April 22, 2020 4:00 PM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Author name displayed incorrectly in package landing
> page
>
> Dear Bioconductor team,
>
> I have recently realized the first author name in my rfaRm package is not
> displayed as intended in its landing page (
> https://secure-web.cisco.com/193JLq6IONh193nJKdBg7jMaHfoif8o0_WybBViZbQ0UP8aawQ14kwkCj_noco8kT0YPE3BXsytvhz50ObX6wK1Fe4l7-IDK0iuJoSGJNgkvmbjLvhzez_pidtmTAo5yRDK4kIXyrtr4XOfz64zfhM5hq75JJyTPeo8hOVt82rBZSsGEnglY-YtRN_f_XuGS0Ym64ZRjSqVy0Vqc6bqRgN5si-CXc2FIgMB1CKvYy504gmAGJWnwvxG9AAu7xfts8Fdzkq41r8Wo0ls7RzjqMd2lcl6rbr7_YVMXW4J-Rh9mulm1rNBt6cxB0RuxP6V55tG47KoMCP74tp38ozju5-CrZi3W2679q7ywr_niUN0M/https%3A%2F%2Fbioconductor.org%2Fpackages%2FrfaRm
> ).
>
> In short, I put my name as “Lara Selles Vidal” in the Author: field of the
> DESCRIPTION file. My first name is just “Lara”, and “Selles Vidal” are my
> surnames. However, it has been interpreted as Vidal, LS. The intended
> behaviour would have been Selles Vidal, L
>
> Is there any workaround for this?
>
> Thanks a lot in advance!
>
> Best wishes,
>
> Lara
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1UzidGd-ehJ4ORa4yOvWX0_J4p7Wq8VKsOkedj8YH1h3BDJVdpSK5mky2vW_dJY2PxDt20-ZWjTbdHleRkYzreIrvGMpm4aD2VsgoxiO4ttRh3f23Ret4_ZaLh19KKgImZYwPAhhiTZq50MSAg1Szfx-uyqYkfbvLxARG2RCtMhvIGta8ujwUg447PPij3BHbK81F6VREdtxqsoQRLAoOx6BkuB6fezNJZmo0LYxKjvQzCn3Zq6y3FmQNgOAaGaorBB4RsHDQ8ztJzxBcg9ng-BiY78WWYTVC9KEsxIhdGfjxEw7Sh01qvF0iRuzShsjKhRPP6eBA_K_GucZPRsHvwQ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Purpose of subsetted GO tables in OrgDb packages

[James W. MacDonald]

There is a bug in the way that the OrgDb packages that use the NOSCHEMA
schema figure out which tables to use, that was introduced by some changes
that Martin made to AnnotationForge last September:

commit 02749e3779eb5036211d600915506bab86633ea0
Author: Martin Morgan 
Date:   Fri Sep 27 12:18:48 2019 -0400

support go_cc, go_cc_all, etc when making OrgDb from data.frame()s

Which can be shown by doing

library(AnnotationForge)
example(makeOrgPackage)
library(org.Tgutatta.eg.db)
select(org.Tguttata.eg.db, head(keys(org.Tguttata.eg.db)), "GO")
Error in FUN(X[[i]], ...) :
  Two fields in the source DB have the same name.

This comes from the internal function  .deriveTableNameFromField, which
tries to infer the correct tables to use for the SQL query. Since there are
now lots of tables with 'GO' as one of their field names:

> con <- org.Tguttata.eg_dbconn()
> z <- grep("go", dbListTables(con), value = TRUE)
> sapply(z, dbListFields, con = con)
$go
[1] "_id"  "GO"   "EVIDENCE" "ONTOLOGY"

$go_all
[1] "_id" "GOALL"   "EVIDENCEALL" "ONTOLOGYALL"

$go_bp
[1] "_id"  "GO"   "EVIDENCE"

$go_bp_all
[1] "_id"  "GO"   "EVIDENCE"

$go_cc
[1] "_id"  "GO"   "EVIDENCE"

$go_cc_all
[1] "_id"  "GO"   "EVIDENCE"

$go_mf
[1] "_id"  "GO"   "EVIDENCE"

$go_mf_all
[1] "_id"  "GO"   "EVIDENCE"

It's no longer possible to figure out which table to use when a user wants
data from the 'GO' column. In the past this wasn't a problem because there
were just two tables (go and go_all) for NOSCHEMA OrgDbs, so it would pick
the go table.

An easy fix would be to subset out any but the go and go_all table as part
of .deriveTableNameFromField, but then it seems weird to even have these
other tables.  Which made me wonder if there are any instances where
anything but the go or go_all tables are used, but I can't find one, which
makes me wonder why we even have these other tables? So maybe the real easy
fix is to just back out the changes that Martin made, and maybe even remove
the subsetted GO tables from the DBSCHEMA packages as well?

Best,

Jim

-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Question about org.Dr.eg.db package

[James W. MacDonald]

Hi Gennady,

That information should probably be cleaned up, and the BiMaps that point
to the location data removed. While the OrgDbs do contain position
information, it's been deprecated, which you would find if you tried to
query using select():

> select(org.Dr.eg.db, "30037", "CHR")
'select()' returned 1:1 mapping between keys and columns
  ENTREZID CHR
130037   5
Warning message:
In .deprecatedColsMessage() :
  Accessing gene location information via 'CHR','CHRLOC','CHRLOCEND' is
  deprecated. Please use a range based accessor like genes(), or select()
  with columns values like TXCHROM and TXSTART on a TxDb or OrganismDb
  object instead.

The rationale being that the OrgDb packages are intended to contain
functional annotations, which are not based on any build, and instead are
current as of the construction of the OrgDb package. Since positional
information should be based on a genome release, those data have been
migrated to the TxDb and EnsDb packages, which are based on a given release.

Put a different way, the data in an OrgDb package is downloaded from NCBI
as of a particular date, and the positional data we get are whatever we got
from NCBI on that date. This is obviously a problem for the positional
data, because what we get isn't necessarily build-specific. We get the TxDb
data from the UCSC Genome Browser, which is build specific, so we can tell
end users exactly what build the data come from. Ideally these data would
be defunct in the OrgDb packages, but it hasn't happened yet.

Best,

Jim



On Thu, Aug 13, 2020 at 4:39 PM Margolin, Gennady (NIH/NICHD) [C] via
Bioc-devel  wrote:

> Hi Vincent,
>
> Thank you for responding.
>
> Here is from the R documentation help page from this package (I have
> version 3.10.0 (I doubt anything changed with the latest one, which is
> 3.11.4)):
>
> -
> org.Dr.egCHRLOC {org.Dr.eg.db}
> Entrez Gene IDs to Chromosomal Location
> Description
> org.Dr.egCHRLOC is an R object that maps entrez gene identifiers to the
> starting position of the gene. The position of a gene is measured as the
> number of base pairs.
> The CHRLOCEND mapping is the same as the CHRLOC mapping except that it
> specifies the ending base of a gene instead of the start.
> ……
> -
>
> This output also does not show any genome version:
> > org.Dr.eg_dbInfo()
>  name
>value
> 1 DBSCHEMAVERSION
>  2.1
> 2 Db type
>OrgDb
> 3  Supporting package
>  AnnotationDbi
> 4DBSCHEMA
> ZEBRAFISH_DB
> 5ORGANISM
>  Danio rerio
> 6 SPECIES
>Zebrafish
> 7EGSOURCEDATE
>   2019-Jul10
> 8EGSOURCENAME
>  Entrez Gene
> 9 EGSOURCEURL
> ftp://ftp.ncbi.nlm.nih.gov/gene/DATA
> 10  CENTRALID
>   EG
> 11  TAXID
> 7955
> 12   GOSOURCENAME
>  Gene Ontology
> 13GOSOURCEURL
> ftp://ftp.geneontology.org/pub/go/godatabase/archive/latest-lite/
> 14   GOSOURCEDATE
>   2019-Jul10
> 15 GOEGSOURCEDATE
>   2019-Jul10
> 16 GOEGSOURCENAME
>  Entrez Gene
> 17  GOEGSOURCEURL
> ftp://ftp.ncbi.nlm.nih.gov/gene/DATA
> 18 KEGGSOURCENAME
>  KEGG GENOME
> 19  KEGGSOURCEURL
> ftp://ftp.genome.jp/pub/kegg/genomes
> 20 KEGGSOURCEDATE
>   2011-Mar15
> 21   GPSOURCENAME  UCSC Genome Bioinformatics
> (Danio rerio)
> 22GPSOURCEURL
> 23   GPSOURCEDATE
>2017-Nov1
> 24   ENSOURCEDATE
>   2019-Jun24
> 25   ENSOURCENAME
>  Ensembl
> 26ENSOURCEURL
> ftp://ftp.ensembl.org/pub/current_fasta
> 27   UPSOURCENAME
>  Uniprot
> 28UPSOURCEURL
> http://www.UniProt.org/
> 29   UPSOURCEDATE  Mon Oct 21
> 14:32:30 2019
>
> From: Vincent Carey 
> Date: Thursday, August 13, 2020 at 2:46 PM
> To: "Margolin, Gennady (NIH/NICHD) [C]" 
> Cc: "bioc-devel@r-project.org" 
> Subject: Re: [Bioc-devel] Question about org.Dr.eg.db package
>
> This should probably be posed to the support site.  What version of the
> package are you using?  Where
> are you seeing coordinates?  I would expect those to be obtained from the
> TxDb package, or perhaps
> from AnnotationHub.
>
>
> > columns(org.Dr.eg.db)
>
>  [1] "ACCNUM"   "ALIAS""ENSEMBL"  "ENSEMBLPROT"
> "ENSEMBLTRANS"
>
>  [6] "ENTREZID" "ENZYME"   "EVIDENCE" "EVIDENCEALL"  "GENENAME"
>
> [11] "GO"   "GOALL""IPI"  "ONTOLOGY"
>  "ONTOLOGYALL"
>
> [16] "PATH" "PFAM" "PMID" "PROSITE"  "REFSEQ"
>
> [21] "SYMBOL"   "UNIGENE"  "UNIPROT"  "ZFIN"
>
>
> On Thu, Aug 13, 2020 at 2:13 PM Margolin, Gennady (NIH/NICHD) [C] via
> Bioc-devel mailto:bioc-devel@r-project.org>>
> wrote:
> Hello,
>
> I have a short question – how do I figure the genome version for
> org.Dr.eg.db package? I couldn’t see it in the DESCRIPTION and also it’s
> not in 

Re: [Bioc-devel] Question about org.Dr.eg.db package

[James W. MacDonald]

Glad to help!

On Thu, Aug 13, 2020 at 5:51 PM Margolin, Gennady (NIH/NICHD) [C] <
gennady.margo...@nih.gov> wrote:

> Hi Jim,
>
>
>
> Hi Jim,
>
>
>
> Awesome, that makes sense now. I was wondering whether org.Dr.eg.db has
> only functional annotation, which I thought it was as it did not refer to a
> specific genome, unlike TxDb packages, but then I found what I said in my
> previous emails.
>
>
>
> Thank you very much,
>
> Gennady
>
>
>
> *From: *"James W. MacDonald" 
> *Reply-To: *"jmac...@u.washington.edu" 
> *Date: *Thursday, August 13, 2020 at 5:41 PM
> *To: *"Margolin, Gennady (NIH/NICHD) [C]" 
> *Cc: *Vincent Carey , "
> bioc-devel@r-project.org" 
> *Subject: *Re: [Bioc-devel] Question about org.Dr.eg.db package
>
>
>
> Hi Gennady,
>
>
>
> That information should probably be cleaned up, and the BiMaps that point
> to the location data removed. While the OrgDbs do contain position
> information, it's been deprecated, which you would find if you tried to
> query using select():
>
>
>
> > select(org.Dr.eg.db, "30037", "CHR")
> 'select()' returned 1:1 mapping between keys and columns
>   ENTREZID CHR
> 130037   5
> Warning message:
> In .deprecatedColsMessage() :
>   Accessing gene location information via 'CHR','CHRLOC','CHRLOCEND' is
>   deprecated. Please use a range based accessor like genes(), or select()
>   with columns values like TXCHROM and TXSTART on a TxDb or OrganismDb
>   object instead.
>
>
>
> The rationale being that the OrgDb packages are intended to contain
> functional annotations, which are not based on any build, and instead are
> current as of the construction of the OrgDb package. Since positional
> information should be based on a genome release, those data have been
> migrated to the TxDb and EnsDb packages, which are based on a given release.
>
>
>
> Put a different way, the data in an OrgDb package is downloaded from NCBI
> as of a particular date, and the positional data we get are whatever we got
> from NCBI on that date. This is obviously a problem for the positional
> data, because what we get isn't necessarily build-specific. We get the TxDb
> data from the UCSC Genome Browser, which is build specific, so we can tell
> end users exactly what build the data come from. Ideally these data would
> be defunct in the OrgDb packages, but it hasn't happened yet.
>
>
>
> Best,
>
>
>
> Jim
>
>
>
>
>
>
>
> On Thu, Aug 13, 2020 at 4:39 PM Margolin, Gennady (NIH/NICHD) [C] via
> Bioc-devel  wrote:
>
> Hi Vincent,
>
> Thank you for responding.
>
> Here is from the R documentation help page from this package (I have
> version 3.10.0 (I doubt anything changed with the latest one, which is
> 3.11.4)):
>
> -
> org.Dr.egCHRLOC {org.Dr.eg.db}
> Entrez Gene IDs to Chromosomal Location
> Description
> org.Dr.egCHRLOC is an R object that maps entrez gene identifiers to the
> starting position of the gene. The position of a gene is measured as the
> number of base pairs.
> The CHRLOCEND mapping is the same as the CHRLOC mapping except that it
> specifies the ending base of a gene instead of the start.
> ……
> -
>
> This output also does not show any genome version:
> > org.Dr.eg_dbInfo()
>  name
>value
> 1 DBSCHEMAVERSION
>  2.1
> 2 Db type
>OrgDb
> 3  Supporting package
>  AnnotationDbi
> 4DBSCHEMA
> ZEBRAFISH_DB
> 5ORGANISM
>  Danio rerio
> 6 SPECIES
>Zebrafish
> 7EGSOURCEDATE
>   2019-Jul10
> 8EGSOURCENAME
>  Entrez Gene
> 9 EGSOURCEURL
> ftp://ftp.ncbi.nlm.nih.gov/gene/DATA
> 10  CENTRALID
>   EG
> 11  TAXID
> 7955
> 12   GOSOURCENAME
>  Gene Ontology
> 13GOSOURCEURL
> ftp://ftp.geneontology.org/pub/go/godatabase/archive/latest-lite/
> 14   GOSOURCEDATE
>   2019-Jul10
> 15 GOEGSOURCEDATE
>   2019-Jul10
> 16 GOEGSOURCENAME
>  Entrez Gene
> 17  GOEGSOURCEURL
> ftp://ftp.ncbi.nlm.nih.gov/gene/DATA
> 18 KEGGSOURCENAME
>  KEGG GENOME
> 19  KEGGSOURCEURL
> ftp://ftp.genome.jp/pub/kegg/genomes
> 20 KEGGSOURCEDATE
>   2011-Mar15
> 21   GPSOURCENAME  UCSC Genome Bioinformatics
> (Danio rerio)
> 22GPSOURCEURL
> 23   GPSOURCEDATE
>2017-Nov1
> 24   ENSOURCEDATE
>   201

[Bioc-devel] RCurl on Windows

[James W. MacDonald]

FYI, there appears to be a problem with RCurl on Windows, most likely due
to building against an old version of OpenSSL. Or at least that's what
Google tells me. Anyway, reproducible code:

> library(RCurl)
> url <- "www.uniprot.org/mapping"
> params <- c(from = "ACC+ID", to = "PDB_ID", format = "tab", query =
"P31946 P62258")
> getForm(url, .params = params, .opts = list(FOLLOWLOCATION = TRUE))
Error in function (type, msg, asError = TRUE)  :
  error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol
version

I sent the same to c...@r-project.org, which is the email for the
maintainer. So they have been notified, but maybe somebody knows whomever
is actually maintaining RCurl, and can pull a string?

Best,

Jim



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RCurl on Windows

[James W. MacDonald]

It's not something I need, per se, but what other packages that depend on
RCurl need. This issue was brought to my attention because someone on the
support site had a problem with the UniProt.ws package, which uses RCurl to
download data. Given the reverse dependency tree for RCurl I assume this
problem will have an outsized effect, at least amongst Windows users.

I know that DTL wrote the package back in the day, but apparently the CRAN
maintainers have been de facto maintainers/authors since 2013. So I sent
them the same reproducible error. Anyway, there isn't a current version on
Github (there is a two-year old version at github.com/cran/RCurl), so there
isn't a more interactive way to report the error.

On Mon, Nov 23, 2020 at 12:20 PM Vincent Carey 
wrote:

> I reproduced the problem you noted.  Rebuilding RCurl with (an updated?)
> openssl for
> windows is not a slam-dunk for me at the moment.  Can the curl package do
> what you need?
>
> On Mon, Nov 23, 2020 at 11:49 AM James W. MacDonald 
> wrote:
>
>> FYI, there appears to be a problem with RCurl on Windows, most likely due
>> to building against an old version of OpenSSL. Or at least that's what
>> Google tells me. Anyway, reproducible code:
>>
>> > library(RCurl)
>> > url <- "www.uniprot.org/mapping"
>> > params <- c(from = "ACC+ID", to = "PDB_ID", format = "tab", query =
>> "P31946 P62258")
>> > getForm(url, .params = params, .opts = list(FOLLOWLOCATION = TRUE))
>> Error in function (type, msg, asError = TRUE)  :
>>   error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol
>> version
>>
>> I sent the same to c...@r-project.org, which is the email for the
>> maintainer. So they have been notified, but maybe somebody knows whomever
>> is actually maintaining RCurl, and can pull a string?
>>
>> Best,
>>
>> Jim
>>
>>
>>
>> --
>> James W. MacDonald, M.S.
>> Biostatistician
>> University of Washington
>> Environmental and Occupational Health Sciences
>> 4225 Roosevelt Way NE, # 100
>> Seattle WA 98105-6099
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
> The information in this e-mail is intended only for th...{{dropped:25}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] updating released version of package

[James W. MacDonald]

Did you bump your version number? How long has it been since you committed
the changes? If you have a github repo, you remembered to push to both the
Bioconductor and GitHub repos?

On Thu, Dec 10, 2020 at 10:19 AM Ted Natoli  wrote:

> Hello all,
>
> I'm trying to update the released version of my package, cmapR, because one
> of the packages it depends on has been deprecated and hence install of
> cmapR now fails.
>
> I've followed the instructions here in order to get those changes over to
> the released version of the package:
>
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>
> However, I don't see that the released version has been updated. Looking at
> the build reports, the latest commit reflected there is from before I made
> the code changes. How do I get these changes to propagate to the release
> branch?
>
> I'm sure I must be missing something very basic, but any help would be
> appreciated.
>
> Thanks in advance,
> Ted
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] updating released version of package

[James W. MacDonald]

It looks like you bumped it just yesterday:

commit 5a9929aed33e40c11609f3d064b114d95d95e6cb
Author: Ted Natoli 
Date:   Wed Dec 9 16:42:16 2020 -0500

fixing version bump

commit accd8a5871fe38a8a1f63b32b4e79d2640e86792
Author: Ted Natoli 
Date:   Wed Dec 9 16:32:47 2020 -0500

update RELEASE version number

And it takes a while to propagate, so you are probably being too impatient.

Jim

On Thu, Dec 10, 2020 at 10:59 AM Ted Natoli  wrote:

> Hi James,
>
> Thanks for the response. The corresponding changes were committed to the
> master branch on November 23. The development build report seems to be
> using the correct code, or at least close to it, as the most recent commit
> it shows there is from December 8. I did push to both github and
> bioconductor repos and I did bump the version number too, which is
> reflected in the development build report but not release.
>
> Here are links to the build reports if it's helpful.
>
> devel: https://bioconductor.org/checkResults/3.13/bioc-LATEST/cmapR/
> release: https://bioconductor.org/checkResults/3.12/bioc-LATEST/cmapR/
>
> Thanks again,
> Ted
>
> On Thu, Dec 10, 2020 at 10:41 AM James W. MacDonald 
> wrote:
>
>> Did you bump your version number? How long has it been since you
>> committed the changes? If you have a github repo, you remembered to push to
>> both the Bioconductor and GitHub repos?
>>
>> On Thu, Dec 10, 2020 at 10:19 AM Ted Natoli 
>> wrote:
>>
>>> Hello all,
>>>
>>> I'm trying to update the released version of my package, cmapR, because
>>> one
>>> of the packages it depends on has been deprecated and hence install of
>>> cmapR now fails.
>>>
>>> I've followed the instructions here in order to get those changes over to
>>> the released version of the package:
>>>
>>> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>>>
>>> However, I don't see that the released version has been updated. Looking
>>> at
>>> the build reports, the latest commit reflected there is from before I
>>> made
>>> the code changes. How do I get these changes to propagate to the release
>>> branch?
>>>
>>> I'm sure I must be missing something very basic, but any help would be
>>> appreciated.
>>>
>>> Thanks in advance,
>>> Ted
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>> --
>> James W. MacDonald, M.S.
>> Biostatistician
>> University of Washington
>> Environmental and Occupational Health Sciences
>> 4225 Roosevelt Way NE, # 100
>> Seattle WA 98105-6099
>>
>

-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] updating released version of package

[James W. MacDonald]

You also have a commit from yesterday in master that isn't yet reflected on
the build machine, again because it takes time for the build machine to
build stuff. IIRC we are over 24 hours per build, but that may be old news
(FAKE NEWS!).

On Thu, Dec 10, 2020 at 11:09 AM James W. MacDonald  wrote:

> It looks like you bumped it just yesterday:
>
> commit 5a9929aed33e40c11609f3d064b114d95d95e6cb
> Author: Ted Natoli 
> Date:   Wed Dec 9 16:42:16 2020 -0500
>
> fixing version bump
>
> commit accd8a5871fe38a8a1f63b32b4e79d2640e86792
> Author: Ted Natoli 
> Date:   Wed Dec 9 16:32:47 2020 -0500
>
> update RELEASE version number
>
> And it takes a while to propagate, so you are probably being too impatient.
>
> Jim
>
> On Thu, Dec 10, 2020 at 10:59 AM Ted Natoli 
> wrote:
>
>> Hi James,
>>
>> Thanks for the response. The corresponding changes were committed to the
>> master branch on November 23. The development build report seems to be
>> using the correct code, or at least close to it, as the most recent commit
>> it shows there is from December 8. I did push to both github and
>> bioconductor repos and I did bump the version number too, which is
>> reflected in the development build report but not release.
>>
>> Here are links to the build reports if it's helpful.
>>
>> devel: https://bioconductor.org/checkResults/3.13/bioc-LATEST/cmapR/
>> release: https://bioconductor.org/checkResults/3.12/bioc-LATEST/cmapR/
>>
>> Thanks again,
>> Ted
>>
>> On Thu, Dec 10, 2020 at 10:41 AM James W. MacDonald 
>> wrote:
>>
>>> Did you bump your version number? How long has it been since you
>>> committed the changes? If you have a github repo, you remembered to push to
>>> both the Bioconductor and GitHub repos?
>>>
>>> On Thu, Dec 10, 2020 at 10:19 AM Ted Natoli 
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'm trying to update the released version of my package, cmapR, because
>>>> one
>>>> of the packages it depends on has been deprecated and hence install of
>>>> cmapR now fails.
>>>>
>>>> I've followed the instructions here in order to get those changes over
>>>> to
>>>> the released version of the package:
>>>>
>>>> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>>>>
>>>> However, I don't see that the released version has been updated.
>>>> Looking at
>>>> the build reports, the latest commit reflected there is from before I
>>>> made
>>>> the code changes. How do I get these changes to propagate to the release
>>>> branch?
>>>>
>>>> I'm sure I must be missing something very basic, but any help would be
>>>> appreciated.
>>>>
>>>> Thanks in advance,
>>>> Ted
>>>>
>>>>     [[alternative HTML version deleted]]
>>>>
>>>> ___
>>>> Bioc-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>
>>>
>>> --
>>> James W. MacDonald, M.S.
>>> Biostatistician
>>> University of Washington
>>> Environmental and Occupational Health Sciences
>>> 4225 Roosevelt Way NE, # 100
>>> Seattle WA 98105-6099
>>>
>>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] %outside% on GRanges

[James W. MacDonald]

Hi Oleksii,

That function is just a simplification of the negation of overlapsAny:

> getAnywhere("%outside%")
A single object matching '%outside%' was found
It was found in the following places
  package:IRanges
  namespace:IRanges
with value

function (query, subject) 
!overlapsAny(query, subject)



And overlapsAny has dispatch on Granges objects via inheritance from the Vector 
class.

> showMethods("overlapsAny")
Function: overlapsAny (package IRanges)
query="GRanges", subject="GRanges"
(inherited from: query="Vector", subject="Vector")
query="integer", subject="Vector"
query="IntegerRangesList", subject="IntegerRangesList"
query="Vector", subject="missing"
query="Vector", subject="Vector"

So far as I can tell there is no code in GenomicRanges to make this happen - it 
just dispatches via inheritance - so there is no direct help page in 
GenomicRanges.

Best,

Jim




-Original Message-
From: Bioc-devel  On Behalf Of Oleksii 
Nikolaienko
Sent: Wednesday, May 26, 2021 9:15 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] %outside% on GRanges

Dear Bioc team,
%outside% operator from IRanges works as one would expect even if GRanges 
objects are supplied as operands:


> a <- as("chr1:100-200", "GRanges")
> b <- as("chr2:150-250", "GRanges")
> IRanges::`%outside%`(a, b)
[1] TRUE

> IRanges::`%outside%`(ranges(a), ranges(b))
[1] FALSE

It is correct and intuitive, but %outside% does not seem to be defined or 
included in help pages of the GenomicRanges library. Can I rely on such 
behaviour of %outside% in the future?

Best,
Oleksii Nikolaienko

[[alternative HTML version deleted]]

___
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] problem pushing update to deltaCaptureC

[James W. MacDonald]

You are looking at the devel version of your package on git, but the release on 
the Bioconductor website.

/Rpacks/deltaCaptureC$ grep Version DESCRIPTION
Version: 1.7.1
/Rpacks/deltaCaptureC$ git checkout RELEASE_3_13
Switched to branch 'RELEASE_3_13'
Your branch is up-to-date with 'origin/RELEASE_3_13'.
/Rpacks/deltaCaptureC$ grep Version DESCRIPTION
Version: 1.6.0

If you have a bug, and need to update the release version, you need to fix both 
the release and devel branches, and increment both versions. 
http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/

-Original Message-
From: Bioc-devel  On Behalf Of Michael Shapiro
Sent: Thursday, June 24, 2021 10:23 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] problem pushing update to deltaCaptureC


I am trying to update the citation in my package deltaCaptureC but have not had 
any success.  I am following the instructions at 
https://bioconductor.org/developers/how-to/git/push-to-github-bioc/

My local copy of the package has version 1.7.1
   git remote -v
gives me
   origin https://github.com/michaeldshapiro/deltaCaptureC (fetch)
   origin https://github.com/michaeldshapiro/deltaCaptureC (push)
   upstream g...@git.bioconductor.org:packages/deltaCaptureC.git (fetch)
   upstream g...@git.bioconductor.org:packages/deltaCaptureC.git (push) as 
expected.
   git push origin master
and
   git push upstream master
both tell me
   Everything up-to-date

However, the copy of this package on bioconductor remains version 1.6.0

Please advise.

Many thanks,
Michael




The Francis Crick Institute Limited is a registered charity in England and 
Wales no. 1140062 and a company registered in England and Wales no. 06885462, 
with its registered office at 1 Midland Road London NW1 1AT

[[alternative HTML version deleted]]

___
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] Updating stable release

[James W. MacDonald]

The release version of your package is 1.8.0, and the devel is on increment 
ahead (e.g., 1.9.x). You cannot increment the middle version number of your 
release package because that makes it a devel package, hence the pre-release 
hook denying your changes.

You should change the version to 1.8.1 for the release version.

Jim


-Original Message-
From: Bioc-devel  On Behalf Of margaret linan
Sent: Wednesday, July 14, 2021 12:56 PM
To: bioc-devel 
Subject: Re: [Bioc-devel] Updating stable release

Hi -

I successfully updated my devel PoTRA package recently, now I am trying to push 
these same changes to the stable PoTRA package. I am encountering the following 
issue (see highlight below).
Note - in the github PoTRA repo, I have pulled and merged from head --> 
RELEASE_3_13. Also the devel commit never had a problem with my version bump.


 git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.

  git checkout RELEASE_3_13
Switched to branch 'RELEASE_3_13'
Your branch is up to date with 'origin/RELEASE_3_13'.

 git push upstream RELEASE_3_13
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 641 bytes | 641.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Error: Illegal version bump from '1.8.0' to '1.9.1'.
remote:
remote: Check http://bioconductor.org/developers/how-to/version-numbering/
remote: for details.
remote:
To git.bioconductor.org:packages/PoTRA.git
 ! [remote rejected] RELEASE_3_13 -> RELEASE_3_13 (pre-receive hook
declined)
error: failed to push some refs to 'git.bioconductor.org:packages/PoTRA.git'

Thanks,
Margaret




On Wed, Jul 14, 2021 at 9:01 AM Kern, Lori 
wrote:

> In your steps you were good when you checked out RELEASE_3_13
>
> So after git checkout RELEASE_3_13
>
> apply the changes you did to fix master.  You can do this manually or 
> you investigate how to use git cherry-pick
>
> When you have changed the files remember to do a git commit that 
> includes the version bump in the DESCRIPTION
>
> You should push those changes with a git push upstream RELEASE_3_13
>
> Please ask further questions on bioc-devel so other members of the 
> team can also assist.
>
> Cheers,
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* margaret linan 
> *Sent:* Wednesday, July 14, 2021 11:55 AM
> *To:* Kern, Lori 
> *Subject:* Re: [Bioc-devel] Updating stable release
>
> Hi Lori,
>
> I followed the instructions, but it seems that everything is 
> up-to-date already, I also didn't see anything pushed to RELEASE_3_13. 
> Here are my steps.
>
>  git fetch --all
> Fetching origin
> Fetching upstream
>
>  git checkout RELEASE_3_13
> Switched to a new branch 'RELEASE_3_13'
> Branch 'RELEASE_3_13' set up to track remote branch 'RELEASE_3_13' 
> from 'upstream'.
>
>  git merge upstream/RELEASE_3_13
> Already up to date.
>
>  git merge origin/RELEASE_3_13
> merge: origin/RELEASE_3_13 - not something we can merge
>
>  git checkout master
> Switched to branch 'master'
> Your branch is up to date with 'origin/master'.
>
>  git checkout -b RELEASE_3_13 upstream/RELEASE_3_13
> fatal: A branch named 'RELEASE_3_13' already exists.
>
>  git checkout master
> Already on 'master'
> Your branch is up to date with 'origin/master'.
>
>  git push upstream RELEASE_3_13
> Everything up-to-date
>
>  git push origin RELEASE_3_13
> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> remote:
> remote: Create a pull request for 'RELEASE_3_13' on GitHub by visiting:
> remote:  https://github.com/PoTRA-Package/PoTRA/pull/new/RELEASE_3_13
>  dQZXjtu2Ye_OFvo9Gt_SINdBynMZM_YiIsc25aGOnlsZlZ3JToY54VUPz4-nfYIJjjV_rQ
> adro327xvnfCleDCAGOngTyw2B46GkscVAiv5mtmvx1pgxaIF4dJMQiU7jfMDGy-yVU3Gh
> fXxjw2CzEpo9_ifAXV4zor7AUdJNhDovKaGRwy1Pze3n3vK24R-h8sK2D9emGrY79mD9qK
> HcmWyqL9KoxNcDddh_xCirS3DXCG6TkfRBuBXDuwYT-emKtz7EII4HhQluBIIQzoPGueOP
> -/https%3A%2F%2Fgithub.com%2FPoTRA-Package%2FPoTRA%2Fpull%2Fnew%2FRELE
> ASE_3_13>
> remote:
> To https://github.com/PoTRA-Package/PoTRA.git
> 
>  * [new branch]  RELEASE_3_13 -> RELEASE_3_13
>
>  git checkout RELEASE_3_13
> Switched to branch 'RELEASE_3_13'
> Your branch is up to date with 'upstream/RELEASE_3_13'.
>
>  git push upstream RELEASE_3_13
> Everything up-to-date
>
> >>

Re: [Bioc-devel] Regarding package nanotatoR

[James W. MacDonald]

Perhaps this helps explain things?

> z <- entrez_search("gtr","muscle_weakness", retmax = )$id 
> any(z %in% keys(org.Hs.eg.db))
[1] FALSE

> zz <- entrez_summary("gene", z)
> table(do.call(c,sapply(extract_from_esummary(zz, "organism"), 
> function(x) x$scientificname)))

   Apis melliferaBos taurus 
   11   118 
  Danio rerio   Drosophila melanogaster 
   96 1 
  Glycine max   Hordeum vulgare 
2 2 
 Mus musculus Rattus norvegicus 
   2013 
 Solanum lycopersicum Strongylocentrotus purpuratus 
435 
Triticum aestivumXenopus tropicalis 
3 1 
 Zea mays 
6

Apparently, muscle weakness no longer returns human IDs from GTR?

Best,

Jim


-Original Message-
From: Bioc-devel  On Behalf Of Bhattacharya, 
Surajit via Bioc-devel
Sent: Friday, July 30, 2021 3:48 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Regarding package nanotatoR

Hello,


I am the maintainer for the package nanotatoR. I have been facing an issue for 
a couple of weeks, where the package is failing in the build stage in all the 
platform, and throwing an error (attached error report for Linux platform). The 
error seems to show, that the package is failing at the vignette build stage 
and looking at the error "None of the keys entered are valid keys for 
'ENTREZID'. Please use the keys method to see a listing of valid arguments.", 
it seems like a org.Hs.eg.db error. I am using that package to convert from 
entrez id to gene symbol. I was not able to replicate this error, either in my 
local system nor was I able to replicate it on Travis CI(attached). Is it an 
issue with the version being used?  Are other people using org.Hs.eg.db facing 
similar issue, and is there any workaround ?



Please let mknow, in case you have any further questions.
With Regards,
Surajit Bhattacharya
Research Postdoctoral Fellow
Eric Vilain Lab
Center for Genetic Medicine Research
Children's National Medical Center

Confidentiality Notice: This e-mail message, including a...{{dropped:7}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Regarding package nanotatoR

[James W. MacDonald]

Perhaps this helps explain things?

> z <- entrez_search("gtr","muscle_weakness", retmax = )$id 
> any(z %in% keys(org.Hs.eg.db))
[1] FALSE

> zz <- entrez_summary("gene", z)
> table(do.call(c,sapply(extract_from_esummary(zz, "organism"), 
> function(x) x$scientificname)))

   Apis melliferaBos taurus 
   11   118 
  Danio rerio   Drosophila melanogaster 
   96 1 
  Glycine max   Hordeum vulgare 
2 2 
 Mus musculus Rattus norvegicus 
   2013 
 Solanum lycopersicum Strongylocentrotus purpuratus 
435 
Triticum aestivumXenopus tropicalis 
3 1 
 Zea mays 
6

Apparently, muscle weakness no longer returns human IDs from GTR?

Best,

Jim


-Original Message-
From: Bioc-devel  On Behalf Of Bhattacharya, 
Surajit via Bioc-devel
Sent: Friday, July 30, 2021 3:48 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Regarding package nanotatoR

Hello,


I am the maintainer for the package nanotatoR. I have been facing an issue for 
a couple of weeks, where the package is failing in the build stage in all the 
platform, and throwing an error (attached error report for Linux platform). The 
error seems to show, that the package is failing at the vignette build stage 
and looking at the error "None of the keys entered are valid keys for 
'ENTREZID'. Please use the keys method to see a listing of valid arguments.", 
it seems like a org.Hs.eg.db error. I am using that package to convert from 
entrez id to gene symbol. I was not able to replicate this error, either in my 
local system nor was I able to replicate it on Travis CI(attached). Is it an 
issue with the version being used?  Are other people using org.Hs.eg.db facing 
similar issue, and is there any workaround ?



Please let mknow, in case you have any further questions.
With Regards,
Surajit Bhattacharya
Research Postdoctoral Fellow
Eric Vilain Lab
Center for Genetic Medicine Research
Children's National Medical Center

Confidentiality Notice: This e-mail message, including a...{{dropped:7}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Best practices for joint release/update of BioC packages

[James W. MacDonald]

Webster lake. Has it been submitted yet? ;-D

-Original Message-
From: Bioc-devel  On Behalf Of Steve Lianoglou
Sent: Wednesday, August 25, 2021 12:02 PM
To: Nitesh Turaga 
Cc: Russell Bainer ; Hervé Pagès 

Subject: Re: [Bioc-devel] Best practices for joint release/update of BioC 
packages

Hello friends,

I'm the derelict collaborator :-)

I'll be submitting my package faster than you can (correctly) pronounce Lake 
Chargoggagoggmanchauggagoggchaubunagungamaugg
https://en.wikipedia.org/wiki/Lake_Chaubunagungamaug

-steve


On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga 
wrote:

> Hi Russell,
>
> The deprecation usually occurs around the time of release (October 
> 2021, but I don't have an exact date yet).
>
> If your collaborator has submitted the package to Bioconductor or 
> CRAN, and it gets accepted, and you can make everything build and 
> check cleanly before the release time, I think you should be ok. It 
> might mean that he submits the package 'sparrow' soon for review.
>
> The best way to do this (IMHO) is, wait for your collaborator's code 
> to get into Bioconductor/CRAN and plan the major release around that. 
> If it happens after this release, then do a major version update for 
> the next release cycle (April 2022 - approx). This will add all the 
> significant updates in your package only in the major version update 
> to 2.0.0. In the meantime, you may consider fixing/hiding parts of the 
> code why are failing for October 2021 release.
>
> Another "non-traditional" way is to add your collaborator as an Author 
> on your package and ingest parts that improve your package 
> significantly as code within your package. So this will attribute the 
> authorship of the code to your collaborator appropriately. Of course, 
> this will not allow for modular and independent development of two 
> separate packages adding a lot of complexity. (We should not consider 
> this method for the sake of good software engineering practices)
>
> I’m hoping other members on the team / community can provide better 
> suggestions.
>
> Best,
>
>
> Nitesh Turaga
> Scientist II, Department of Data Science, Bioconductor Core Team 
> Member Dana Farber Cancer Institute
>
> > On Aug 24, 2021, at 7:07 PM, Russell Bainer 
> wrote:
> >
> > Hello All,
> >
> > I am planning a major update to my BioC package in the next release 
> > (
> >
> https://www.bioconductor.org/packages/release/bioc/html/gCrisprTools.h
> tml
> ),
> > and some of the new functionality depends on another package that is
> being
> > submitted for acceptance by a collaborator.
> >
> > All of the code in my package passes R/BioC check using the package 
> > in my collaborator's github repo, but as his code has not yet been 
> > incorporated into BioC my current build is failing.
> >
> > What is the recommended way to deal with a situation like this?
> Obviously I
> > want to avoid deprecation of my own package, and obviously I could 
> > just hide all of the parts of the update that depend on external 
> > code. But I also think that my collaborator's work adds 
> > significantly to the utility
> of
> > my package, and I want to ensure that their contributions are 
> > properly highlighted/celebrated in my 2.0 release.
> >
> > Thanks in advance for the input.
> >
> > -R
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > 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
>

[[alternative HTML version deleted]]

___
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] Bioconductor build system using old commit

[James W. MacDonald]

Err. check that. Release is 3.13, so you should be checking out RELEASE_3_13

-Original Message-
From: James W. MacDonald 
Sent: Friday, September 17, 2021 2:23 PM
To: 'Kort, Eric' ; bioc-devel@r-project.org
Subject: RE: Bioconductor build system using old commit

You are pushing to the master repo, but then are checking the build results 
from the RELEASE_3_14 branch. Are you also checking out the release branch and 
making changes/pushing there as well? 
http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/

Best,

Jim





-Original Message-
From: Bioc-devel  On Behalf Of Kort, Eric
Sent: Friday, September 17, 2021 2:15 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Bioconductor build system using old commit

Good day. I have made updates to my package, slinky. I pushed my changes both 
to my github rep, and the Bioconductor git repository.

My remotes are set up as follows:

> git remote -v
origin https://github.com/vanandelinstitute/slinky (fetch)
origin https://github.com/vanandelinstitute/slinky (push)
upstream g...@git.bioconductor.org:packages/slinky.git (fetch)
upstream g...@git.bioconductor.org:packages/slinky.git (push)

Following directions here: 
https://bioconductor.org/developers/how-to/git/maintain-github-bioc/

I then did

git fetch upstream
git merge upstream/master
git push origin master

But on the build system 
(https://bioconductor.org/checkResults/3.13/bioc-LATEST/) where errors are 
being encountered, the git_last_commit shows an old commit and commit date.

Do I have the wrong remote? Or is there another mistake I am making?

-Eric




[[alternative HTML version deleted]]

___
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] Bioconductor build system using old commit

[James W. MacDonald]

You are pushing to the master repo, but then are checking the build results 
from the RELEASE_3_14 branch. Are you also checking out the release branch and 
making changes/pushing there as well? 
http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/

Best,

Jim





-Original Message-
From: Bioc-devel  On Behalf Of Kort, Eric
Sent: Friday, September 17, 2021 2:15 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Bioconductor build system using old commit

Good day. I have made updates to my package, slinky. I pushed my changes both 
to my github rep, and the Bioconductor git repository.

My remotes are set up as follows:

> git remote -v
origin https://github.com/vanandelinstitute/slinky (fetch)
origin https://github.com/vanandelinstitute/slinky (push)
upstream g...@git.bioconductor.org:packages/slinky.git (fetch)
upstream g...@git.bioconductor.org:packages/slinky.git (push)

Following directions here: 
https://bioconductor.org/developers/how-to/git/maintain-github-bioc/

I then did

git fetch upstream
git merge upstream/master
git push origin master

But on the build system 
(https://bioconductor.org/checkResults/3.13/bioc-LATEST/) where errors are 
being encountered, the git_last_commit shows an old commit and commit date.

Do I have the wrong remote? Or is there another mistake I am making?

-Eric




[[alternative HTML version deleted]]

___
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] Use set.seed inside function

[James W. MacDonald]

It appears that you don't actually want random colors, but instead you want the 
same colors each time. Why not just generate the vector of 'random distinct 
colors' one time and save the vector of colors?

-Original Message-
From: Bioc-devel  On Behalf Of Meng Chen
Sent: Monday, November 29, 2021 3:21 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Use set.seed inside function

Dear BioC team and developers,

I am using BiocCheck to check my package, it returns a warning:
" Remove set.seed usage in R code"

I am using "set.seed" inside my functions, before calling function 
distinctColorPalette (randomcoloR package) in order to generate reproducible 
"random distinct colors". So what would be the best practice to solve this 
warning? I think 1. use set.seed and don't change anything.
2. use the set.seed function, but include something like below inside the 
function *gl.seed <- .Random.seed* *on.exit(assign(".Random.seed", gl.seed, 
envir = .GlobalEnv))* 3. use some other functions for the purpose

Any suggestions will be appreciated. Thanks.
--
Best Regards,
Chen

[[alternative HTML version deleted]]

___
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] updating pathwayPCA: "permission denied (publickey)"

[James W. MacDonald]

That looks like you have the wrong RSA key. You should be able to check which 
key you are using by logging in here: 
https://git.bioconductor.org/BiocCredentials/login/

-Original Message-
From: Bioc-devel  On Behalf Of Gabriel Odom
Sent: Thursday, February 9, 2023 1:56 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] updating pathwayPCA: "permission denied (publickey)"

Dear BioC-Devel folks,

My package, pathwayPCA, had an error in the vignettes which I've just fixed. 
It's been a few years since my last bug fix, and I don't know what I'm doing 
wrong.
When I use "git push upstream master",  I see 
"mailto:g...@git.bioconductor.org: Permission denied (publickey)."
Using "git remote -v" shows "upstream    
mailto:g...@git.bioconductor.org:packages/pathwayPCA.git (push)" (and pull).
Am I missing something simple?

Best,
Gabriel

Gabriel J. Odom, PhD, ThD
Assistant Professor
Department of Biostatistics
Stempel College of Public Health
Florida International University
Office: (305) 348-5486
Email: gabriel.o...@fiu.edu

___
Bioc-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!lgUqo10igxIGCi2Ltk5ROGKBk4zpJU2-R56q0s-o57z8DPMtm03l92N486lSHV_-Luj2SloQg9_4$
 

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Request for advice on ANCOMBC package error messages in Linux platform

[James W. MacDonald]

You have this in line 1093-1094

```{r}
samp_frac = out$samp_frac

And yet it appears that there is no 'out' object ever generated. There is an 
'output' object, that perhaps you meant to use?

Also, the vignette building is skipped for Windows and MacOS, which is why it 
is passing check on those two builders.

Best,

Jim



-Original Message-
From: Bioc-devel  On Behalf Of Huang Lin 
(Frederick)
Sent: Tuesday, April 18, 2023 3:06 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Request for advice on ANCOMBC package error messages in 
Linux platform

!---|
  This Message Is From an Untrusted Sender
  You have not previously corresponded with this sender.
  See https://itconnect.uw.edu/email-tags for additional
  information.  Please contact the UW-IT Service Center,
  h...@uw.edu 206.221.5000, for assistance.
|---!

Dear BioC team,



I am the creator of the ANCOMBC package ( 
https://urldefense.com/v3/__http://bioconductor.org/packages/release/bioc/html/ANCOMBC.html__;!!K-Hz7m0Vt54!iPiUj30993RxkVF2s2Jx6STmZ4lP7fG0VIC1eBqKOy65FR8jmHQSkZYabB9jY2YxesE4hwfiNHj38afsbtZjhDc_iw$
 ).



Recently, I committed a bug-fixed change to the ANCOMBC package.
Unfortunately, I received error messages for both Bioc 3.16 and 3.17. The error 
occurred ONLY on the Linux platform (nebbiolo2 for Bioc 3.16, and
nebbiolo1 for Bioc 3.17), stating a vignette re-building error that :


Error(s) in re-building vignettes:

  ...

--- re-building ‘ANCOM.Rmd’ using rmarkdown

--- finished re-building ‘ANCOM.Rmd’



--- re-building ‘ANCOMBC.Rmd’ using rmarkdown

--- finished re-building ‘ANCOMBC.Rmd’



--- re-building ‘ANCOMBC2.Rmd’ using rmarkdown

Quitting from lines 1093-1103 (ANCOMBC2.Rmd)

Error: processing vignette 'ANCOMBC2.Rmd' failed with diagnostics:

object 'out' not found

--- failed re-building ‘ANCOMBC2.Rmd’



--- re-building ‘SECOM.Rmd’ using rmarkdown

--- finished re-building ‘SECOM.Rmd’



SUMMARY: processing the following file failed:

  ‘ANCOMBC2.Rmd’



Error: Vignette re-building failed.

Execution halted



The package works fine with Windows and macOS platforms.



As the release date for Bioc 3.17 is approaching, I would greatly appreciate 
your advice on how to address this issue in a timely manner.



Thank you very much!


Best,

Huang Lin

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!iPiUj30993RxkVF2s2Jx6STmZ4lP7fG0VIC1eBqKOy65FR8jmHQSkZYabB9jY2YxesE4hwfiNHj38afsbtYwVNNZVg$
 
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] maintenance question

[James W. MacDonald]

See here 
https://contributions.bioconductor.org/git-version-control.html#bug-fix-in-release-and-devel

-Original Message-
From: Bioc-devel  On Behalf Of Michael Shapiro
Sent: Wednesday, April 19, 2023 8:32 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] maintenance question


I recently got a build error message regarding the package deltaCaptureC which 
had been stable and error-free for several years.  I was able to fix the 
problem and move the resulting fix to devel.  The development version now shows 
a successful build.  However, this has not propagated to the release version 
which still shows the build error.  Does this automatically propagate to the 
release, or am I supposed to do something to propagate it?  If so, what?

Apologies for my ignorance here and thanks in advance.


The Francis Crick Institute Limited is a registered charity in England and 
Wales no. 1140062 and a company registered in England and Wales no. 06885462, 
with its registered office at 1 Midland Road London NW1 1AT

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!kZ3TSYFLwD6jcodpvF-HqFDZzQdf-5xz96Ag9A9zgKexs2X86BB1MZ3-fxPbjpWxA7i0k6XvXFugbIvAnUDzZL73CYQy$
 

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Not getting emails from watched tags

[James W. MacDonald]

Hi Stephanie,

I didn't add the tags to the original post, but I did edit the post to 
highlight the code, and then I responded. I guess it's possible that either 
action caused the email to be generated?

Best,

Jim



-Original Message-
From: Bioc-devel  On Behalf Of Stephanie 
Gogarten
Sent: Monday, December 4, 2023 4:03 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Not getting emails from watched tags

Hi,

I'm not getting emails for the tags I'm watching on the support site until 
someone else responds to them. For example, this thread:
https://urldefense.com/v3/__https://support.bioconductor.org/p/9155500/__;!!K-Hz7m0Vt54!iIBemFUBonwSB_0bVBMwuR2wOdwQKkdqcd73mxEnfpRhoT3Uoz8df7ChIW4DfTye1mYfLTA1rDv788Aq$
No email originally, but got an email when James MacDonald posted a response. 
Is that because the tags are getting added later?

thanks,
Stephanie Gogarten

-- 

Stephanie M. Gogarten, PhD

Senior Research Scientist / Genetic Analysis Center 


Department of Biostatistics 

UNIVERSITY OF WASHINGTON



UW Tower Box 359461

4333 Brooklyn Ave NE, Seattle, WA 98195

206.221.0757

sdmor...@uw.edu

she/her/hers

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!iIBemFUBonwSB_0bVBMwuR2wOdwQKkdqcd73mxEnfpRhoT3Uoz8df7ChIW4DfTye1mYfLTA1rEuGN3X2$
 

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects

[James W. MacDonald]

I don't believe a different OrgDb is required. The OrgDb package is meant to 
provide annotations for genes such as gene symbol or GO term, etc, which are 
orthogonal to the sequence of the genome, so the current version should suffice.

-Original Message-
From: Bioc-devel  On Behalf Of Vincent Carey
Sent: Sunday, December 10, 2023 1:44 PM
To: Christian Arnold 
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects

Good question.  I believe these will be forthcoming soon.  In the mean time you 
can create your own.  See, for example

https://urldefense.com/v3/__https://github.com/vjcitn/BiocT2T/blob/devel/inst/scripts/makeTxDb.R__;!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIMiLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adMcpWaIEw$
 

It's an active area so you can pull a gff file from 
https://urldefense.com/v3/__https://s3-us-west-2.amazonaws.com/human-pangenomics/index.html?prefix=T2T*CHM13*assemblies*annotation*__;Ly8vLw!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIMiLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adM7PNUeks$
and adjust the code noted above for the TxDb.

For the org.db I have to get back to you.

On Sun, Dec 10, 2023 at 12:06 PM Christian Arnold via Bioc-devel < 
bioc-devel@r-project.org> wrote:

> Hello, I am working with the new human T2T-CHM13v2.0  assembly and 
> while a BSgenome package already exists 
> (BSgenome.Hsapiens.NCBI.T2T.CHM13v2.0), I could not find the 
> corresponding TxDb and OrgDb packages. Is there any information when 
> they may also become available so it is easier to work with the new 
> genome for packages like ArchR, which support a custom genome but need 
> these standard annotation packages for their creation?
>
>
> Thanks a lot for any information regarding this!
>
> Best, Christian
>
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc
> -devel__;!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIM
> iLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adMOtbUwTc$
>

--
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIMiLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adMOtbUwTc$
 
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects

[James W. MacDonald]

Hi Christian,

This conversation is off-topic, both for this listserv (it’s meant to help 
people developing Bioconductor packages) and for the support site (which is 
meant to help people with (again), Bioconductor packages. I’ll answer your 
questions one more time, but if you have other questions, please move to 
biostars.org, or just ask the ArchR people directly, since it’s their package.

I believe you are misinterpreting what an OrgDb is intended to provide. There 
is no positional data in an OrgDb, and what the CHM13 project has done is 
completely positional (what data are provided in the ‘Gene Annotation’ section 
of the CHM13 Github are all GFF files, which are meant to provide positional 
information of genes on a genome).

The OrgDb package provides functional and within-annotation mappings. You can 
map an NCBI Gene ID to Ensembl, or to the HGNC gene symbol, or a GO term, etc. 
For example, I can map Gene symbol P53 to NCBI Gene ID 7157, or its UniProt 
symbol K7PPA8. If the new genome build says P53 has moved to a new genomic 
position, that has no affect on what UniProt thinks the ID for that gene’s 
protein should be, or what ID NCBI uses, or what GO terms are appended to that 
gene. Functionally it’s the same gene. We just might think it is located in a 
different place in the genome.

The difference between CHM13 and GRCh38 is not materially different from the 
difference between GRCh37 and GRCh38 (they represent the current knowledge of 
the genome at a point in time), and while we supply TxDb packages for GRCh38 
and GRCh37 (and variants based on NCBI’s mappings as well as Ensembl’s 
mappings), we have never supplied more than one human OrgDb package, because 
the positional and functional information are orthogonal.

It seems pretty simple to make what you need though.

> library(GenomicAlignments)
> tx <- 
> makeTxDbFromGFF(https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/009/914/755/GCF_009914755.1_T2T-CHM13v2.0/GCF_009914755.1_T2T-CHM13v2.0_genomic.gff.gz)
Import genomic features from the file as a GRanges object ... trying URL 
'https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/009/914/755/GCF_009914755.1_T2T-CHM13v2.0/GCF_009914755.1_T2T-CHM13v2.0_genomic.gff.gz'
Content type 'application/x-gzip' length 79009538 bytes (75.3 MB)
downloaded 75.3 MB

OK
Prepare the 'metadata' data frame ... OK
Make the TxDb object ... OK
Warning messages:
1: In .extract_transcripts_from_GRanges(tx_IDX, gr, mcols0$type, mcols0$ID,  :
  some transcripts have no
  "transcript_id" attribute ==>
  their name ("tx_name" column in
  the TxDb object) was set to NA
2: In .extract_transcripts_from_GRanges(tx_IDX, gr, mcols0$type, mcols0$ID,  :
  the transcript names ("tx_name"
  column in the TxDb object)
  imported from the
  "transcript_id" attribute are
  not unique
3: In .find_exon_cds(exons, cds) : The following transcripts have
  exons that contain more than one
  CDS (only the first CDS was kept
  for each exon):
  rna-NM_001134939.1,
  rna-NM_001172437.2,
  rna-NM_001184961.1,
  rna-NM_001301020.1,
  rna-NM_001301302.1,
  rna-NM_001301371.1,
  rna-NM_002537.3,
  rna-NM_004152.3,
  rna-NM_015068.3, rna-NM_016178.2
> tx
TxDb object:
# Db type: TxDb
# Supporting package: GenomicFeatures
# Data source: 
https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/009/914/755/GCF_009914755.1_T2T-CHM13v2.0/GCF_009914755.1_T2T-CHM13v2.0_genomic.gff.gz
# Organism: NA
# Taxonomy ID: NA
# miRBase build ID: NA
# Genome: NA
# Nb of transcripts: 188205
# Db created by: GenomicFeatures package from Bioconductor
# Creation time: 2023-12-12 10:17:34 -0500 (Tue, 12 Dec 2023)
# GenomicFeatures version at creation time: 1.54.1
# RSQLite version at creation time: 2.3.1
# DBSCHEMAVERSION: 1.2

genomeAnnotation <- createGenomeAnnotation(BSgenome.Hsapiens.NCBI.T2T.CHM13v2.0)
geneAnnotation <- createGeneAnnotation(TxDb = tx, OrgDb = org.Hs.eg.db)


Best,

Jim

From: Christian Arnold 
Sent: Tuesday, December 12, 2023 9:35 AM
To: Vincent Carey ; James W. MacDonald 

Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects

Dear Vincent and others, thanks for the reply! Irrespective of whether a 
different OrgDb is required, the name itself suggested that there "should be" 
also corresponding OrgDb and TxDb packages. I can build one on my own, I see, 
is there anyone
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
See https://itconnect.uw.edu/email-tags for additional information. Please 
contact the UW-IT Service Center, h...@uw.edu<mailto:h...@uw.edu> 206.221.5000, 
for assistance.
ZjQcmQRYFpfptBannerEnd

Dear Vincent and others,

thanks for the reply! Irrespective of whether a different OrgDb is required, 
the name itself suggested that there "should be" also corresponding OrgDb and 
TxDb packages. I can build one on

Re: [Bioc-devel] How to push to release branch

[James W. MacDonald]

It's not clear from your screenshot that you checked out the release branch, 
made the fix, and then tried to push? You don't want to push your devel branch 
onto the release branch. 

https://contributions.bioconductor.org/git-version-control.html#bug-fix-in-release-and-devel

-Original Message-
From: Bioc-devel  On Behalf Of Yue Cao via 
Bioc-devel
Sent: Wednesday, January 10, 2024 9:35 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] How to push to release branch

Dear Bioconductor team,

I have received package building error for scFeatures 
https://urldefense.com/v3/__https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/scFeatures/nebbiolo2-checksrc.html__;!!K-Hz7m0Vt54!ndWcNrE9ea12ac-vnY2R3-qffBIu5QKAl21UGUFGS1vAgQtMtfA4DyJLJulx1KBBXJedA6BBhfyL3aPEiVyh8A$
 

It seems it is building on the RELEASE_3_18 branch. I have pushed everything to 
the devel branch, but I believe I would need to push on the release branch to 
fix this building error.

However, while I can push to the devel branch, I got errors when pushing to the 
release branch (as shown in the screenshot attachment).

Wondering if you have any clue on this. Thank you for your help.

Best regards,
Yue

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BiocCheck error

[James W. MacDonald]

Are you subscribed to the bioc-devel mailing list?

-Original Message-
From: Bioc-devel  On Behalf Of Marek 
Gierlinski (Staff)
Sent: Thursday, January 25, 2024 5:51 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] BiocCheck error

When running BiocCheck::BiockCheck() on my package, it gets through almost 
everything and then produces an error:

...
* Checking for bioc-devel mailing list subscription...
* NOTE: Cannot determine whether maintainer is subscribed to the Bioc-Devel 
mailing list (requires admin
  credentials). Subscribe here: 
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!g8nTl4H3mS0txEb0EhOoiTBpinKkLxt0CndfgUZiq0NZmyclvGxWraoxus7i-EerExUjAEVpD-1753wCHT-xwd190w$
 
* Checking for support site registration...
Maintainer is registered at support site.
Error in strsplit(content(response)$watched_tags, split = ",") :
  non-character argument

Is something wrong with my package (it passes Check with no issues)? Or is it a 
bug?

BiocCheck version 1.38.0, Bioconductor 3.18, R 4.3.2, MacOS 14.3.

Marek

The University of Dundee is a registered Scottish Charity, No: SC015096

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!K-Hz7m0Vt54!g8nTl4H3mS0txEb0EhOoiTBpinKkLxt0CndfgUZiq0NZmyclvGxWraoxus7i-EerExUjAEVpD-1753wCHT-xwd190w$
 

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] dependencies=TRUE problem, affy, gcrma, oligoClasses

[James W. MacDonald]

Hi Keith,

On 1/22/2013 10:44 PM, Keith wrote:

To the Bioconductor developer group,

I emailed the author of the affy package (Rafael Irizarry) and he 
advised me to contact the Bioconductor developers with my problem.


My problem is with the affy package. My affylmGUI package depends on 
the affy package. I only noticed this problem when I tested my program 
on a fresh install of R-2.15.2. When affylmGUI normalizes data using 
the rma function in the affy package, it calls eventually the 
cdfFromBioC function (as coded in getCDFenv.R) which uses the 
"install.packages" function with the parameter "dependencies=TRUE". 
This worked fine up until R-2.15.0, but this version of R changed the 
meaning of the dependencies  parameter to include packages also 
mentioned in the "Suggests" field.


Consequently when affy installs a cdf package like "hgu95av2cdf", the 
dependency "AnnotationDbi" is installed, which is not a problem, but 
additionally all the packages in the "Suggests" field of AnnotationDbi 
are also installed. This causes the following to be installed:


There are two problems here. First, a normal BioC installation will 
already have AnnotationDbi installed, as this is one of only three core 
packages that are installed by


biocLite()

which is the first step in a 'regular' BioC installation procedure.

Second, if I install BioC and then strip out all of the packages you say 
will be installed, I can't reproduce what you are seeing:


> x <- c('XML', 'BSgenome', 'Rsamtools', 'bitops', 'GenomicRanges', 
'Biostrings','rtracklayer', 'biomaRt', 'RCurl', 'GenomicFeatures', 
'hgu95av2.db','GO.db', 'org.Sc.sgd.db', 'org.At.tair.db', 'KEGG.db', 
'RUnit','TxDb.Hsapiens.UCSC.hg19.knownGene', 'hom.Hs.inp.db', 
'org.Hs.eg.db','seqnames.db', 'reactome.db', 'AnnotationForge', 'DBI', 
'RSQLite' ,'IRanges', 'AnnotationDbi')

> sum(x %in% .packages(all.available = TRUE))
[1] 0

So I don't have any of these packages installed, including AnnotationDbi.

> library(affy)
> affy:::cdfFromBioC("hgu95av2cdf")
[1] "Attempting to obtain hgu95av2cdf from Bioconductor website"
[1] "Checking to see if package hgu95av2cdf is already installed"
[1] "The environment hgu95av2cdf was not found in these directories: 
/misc/staff/jmacdon/R-devel/library.  Now searching the internet 
repository."

[1] "Checking to see if your internet connection works ..."
also installing the dependencies DBI, RSQLite, IRanges, AnnotationDbi

So I end up installing the cdf, and four other packages.

I think the problem lies elsewhere.

Best,

Jim




'XML', 'BSgenome', 'Rsamtools', 'bitops', 'GenomicRanges', 'Biostrings',
'rtracklayer', 'biomaRt', 'RCurl', 'GenomicFeatures', 'hgu95av2.db',
'GO.db', 'org.Sc.sgd.db', 'org.At.tair.db', 'KEGG.db', 'RUnit',
'TxDb.Hsapiens.UCSC.hg19.knownGene', 'hom.Hs.inp.db', 'org.Hs.eg.db',
'seqnames.db', 'reactome.db', 'AnnotationForge', 'DBI', 'RSQLite' and
'IRanges'.

This is a 1.8GByte download which would rather destroy a lab lesson if 
it happened during a class! Of course the immediate solution is to 
install AnnotationDbi before running affylmGUI, but that may not 
always happen.


Therefore could someone please change line 102 of getCDFenv.R to 
'dependencies=c("Depends", "Imports")' to solve this problem.


It would be very helpful if you could make the change on R-2.15.2 to 
avoid the above mentioned problems.


After using Itoshi NIKAIDO's source code search engine at 
http://search.bioconductor.jp/ (Thanks for that Itoshi, it is an 
excellent tool), I suspect that 2 other packages would cause similar 
problems. Doing a code search for "dependencies=TRUE" showed that the 
gcrma package (file getPackages.R) and the oligoClasses package (file 
utils-general.R) have this parameter on the install.packages function 
call. Perhaps it would be wise to modify these packages in a similar way.


cheers,

Keith
--
Keith Satterley
Maintainer of affylmGUI
Bioinformatics Division,
The Walter & Eliza Hall Institute
Melbourne, Australia
-


__
The information in this email is confidential and intend...{{dropped:4}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Is it possible to trigger a new build for a package on george2/moscato2/petty ?

[James W. MacDonald]

Hi Frederic,

As long as you have incremented your version number it will be rebuilt 
tonight. There isn't a way to force the build machines to trigger a build.


Best,

Jim

On 1/23/2013 1:41 PM, Frederic Fournier wrote:

Hello everyone,

I recently submitted a package to bioconductor, and couple of days 
ago, the package started to fail the automated daily build on george2 
and moscato2. Today I made some changes that work on my testing 
environment, but I would like to know if the changes have corrected 
the situation on george2 and moscato2. Is there a way to trigger a new 
build on those machines, or do I have to be patient and wait until 
tomorrow to see if the package passes the nightly build again?


Thank you for your help,

Frederic

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Is it possible to trigger a new build for a package on george2/moscato2/petty ?

[James W. MacDonald]

Thanks Dan, my mistake.

On 1/23/2013 1:51 PM, Dan Tenenbaum wrote:

On Wed, Jan 23, 2013 at 10:47 AM, James W. MacDonald  wrote:

Hi Frederic,

As long as you have incremented your version number it will be rebuilt
tonight. There isn't a way to force the build machines to trigger a build.

Just to clarify; it is not necessary to bump your version number in
order for the build system to build the package with your latest
changes. It is only necessary to bump the version number if you intend
for those changes to be propagated to our web site.

Dan


Best,

Jim


On 1/23/2013 1:41 PM, Frederic Fournier wrote:

Hello everyone,

I recently submitted a package to bioconductor, and couple of days ago,
the package started to fail the automated daily build on george2 and
moscato2. Today I made some changes that work on my testing environment, but
I would like to know if the changes have corrected the situation on george2
and moscato2. Is there a way to trigger a new build on those machines, or do
I have to be patient and wait until tomorrow to see if the package passes
the nightly build again?

Thank you for your help,

Frederic

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] dependencies=TRUE problem, affy, gcrma, oligoClasses

[James W. MacDonald]

ckage(s) 'Biobase' 'IRanges' 'AnnotationDbi'
also installing the dependencies 'BiocGenerics', 'DBI', 'RSQLite'
...
package 'BiocGenerics' successfully unpacked and MD5 sums checked
package 'DBI' successfully unpacked and MD5 sums checked
package 'RSQLite' successfully unpacked and MD5 sums checked
package 'Biobase' successfully unpacked and MD5 sums checked
package 'IRanges' successfully unpacked and MD5 sums checked
package 'AnnotationDbi' successfully unpacked and MD5 sums checked
...
Old packages: 'foreign', 'lattice', 'MASS', 'Matrix', 'nlme', 'rpart',
'survival'
Update all/some/none? [a/s/n]: n


x<- c('XML', 'BSgenome', 'Rsamtools', 'bitops', 'GenomicRanges',
'Biostrings','rtracklayer', 'biomaRt', 'RCurl', 'GenomicFeatures',
'hgu95av2.db','GO.db', 'org.Sc.sgd.db', 'org.At.tair.db', 'KEGG.db',
'RUnit','TxDb.Hsapiens.UCSC.hg19.knownGene', 'hom.Hs.inp.db',
'org.Hs.eg.db','seqnames.db', 'reactome.db', 'AnnotationForge', 'DBI',
'RSQLite' ,'IRanges', 'AnnotationDbi')
sum(x %in% .packages(all.available = TRUE))

[1] 3

biocLite("affy")

BioC_mirror: http://bioconductor.org
Using Bioconductor version 2.11 (BiocInstaller 1.8.3), R version 2.15.
Installing package(s) 'affy'
also installing the dependencies 'affyio', 'preprocessCore', 'zlibbioc'
...
package 'affyio' successfully unpacked and MD5 sums checked
package 'preprocessCore' successfully unpacked and MD5 sums checked
package 'zlibbioc' successfully unpacked and MD5 sums checked
package 'affy' successfully unpacked and MD5 sums checked
...


sum(x %in% .packages(all.available = TRUE))

[1] 3


library(affy)
affy:::cdfFromBioC("hgu95av2cdf")

[1] "Attempting to obtain hgu95av2cdf from Bioconductor website"
[1] "Checking to see if package hgu95av2cdf is already installed"
[1] "The environment hgu95av2cdf was not found in these directories:
C:/RTest2/R-2.15.2/library.  Now searching the internet repository."

[1] "Checking to see if your internet connection works ..."
also installing the dependency 'AnnotationDbi'

also installing the dependencies 'XML', 'BSgenome', 'Rsamtools', 'bitops',
'GenomicRanges', 'Biostrings', 'rtracklayer', 'biomaRt', 'RCurl',
'GenomicFeatures', 'hgu95av2.db', 'GO.db', 'org.Sc.sgd.db',
'org.At.tair.db', 'KEGG.db', 'RUnit', 'TxDb.Hsapiens.UCSC.hg19.knownGene',
'hom.Hs.inp.db', 'org.Hs.eg.db', 'seqnames.db', 'reactome.db',
'AnnotationForge'
...

sessionInfo()

R version 2.15.2 (2012-10-26)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=C
LC_MONETARY=English_Australia.1252
[4] LC_NUMERIC=C LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics  grDevices utils datasets  methods base
other attached packages:
[1] affy_1.36.0 Biobase_2.18.0  BiocGenerics_0.4.0
BiocInstaller_1.8.3
loaded via a namespace (and not attached):
[1] affyio_1.26.0 preprocessCore_1.20.0 tools_2.15.2
zlibbioc_1.4.0





On 24/01/2013 2:15 AM, James W. MacDonald wrote:

Hi Keith,

On 1/22/2013 10:44 PM, Keith wrote:

To the Bioconductor developer group,

I emailed the author of the affy package (Rafael Irizarry) and he advised
me to contact the Bioconductor developers with my problem.

My problem is with the affy package. My affylmGUI package depends on the
affy package. I only noticed this problem when I tested my program on a
fresh install of R-2.15.2. When affylmGUI normalizes data using the rma
function in the affy package, it calls eventually the cdfFromBioC function
(as coded in getCDFenv.R) which uses the "install.packages" function with
the parameter "dependencies=TRUE". This worked fine up until R-2.15.0, but
this version of R changed the meaning of the dependencies  parameter to
include packages also mentioned in the "Suggests" field.

Consequently when affy installs a cdf package like "hgu95av2cdf", the
dependency "AnnotationDbi" is installed, which is not a problem, but
additionally all the packages in the "Suggests" field of AnnotationDbi are
also installed. This causes the following to be installed:


There are two problems here. First, a normal BioC installati

Re: [Bioc-devel] R version in Bioc packages (was Re: [BioC] Package \'jmosaics\' not found)

[James W. MacDonald]

Not that I can recall. But I do agree that it is at minimum redundant 
and probably just wrong to have R-version requirements for BioC packages.


And seriously? 500 packages? I find that surprising.

Best,

Jim

On 5/21/2013 11:38 AM, Martin Morgan wrote:
Pulling this over to Bioc-devel. It's tempting to strip this from the 
DESCRIPTION files of the ~500 packages that include it. It's not 
useful in the context of the Bioconductor release schedule, and makes 
a forward promise that cannot be guaranteed.


Is this something that has come up before?

Martin

On 05/21/2013 08:28 AM, James W. MacDonald wrote:

It does say R >= 2.15.2 in the Depends, which is misleading.





--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Can I analyze with bioconductor a microarray experiement where the distribution of probes intesisties follow a bi modal distribution?

[James W. MacDonald]

Hi Miguel,

On 6/7/2013 5:11 AM, Miguel Moreno-Risueno wrote:



Hello all,



We have recently received a microarray experiment in the Nimblegen platform
where the intensity of the probe sets follow a bi-modal distribution. We
have been said from the facility that this is because of the dynamic range
of the Agilent scanner they use. We are concerned about the statistical
analysis with bioconductor as it is our understanding that these statistical
analyses are developed for normal or normal-like distribution. We appreciate
any information on this regard.


If I understand your question correctly, you are noting that the overall 
distribution of probes within a sample has a bi-modal distribution. This 
doesn't really have anything to do with any statistical tests you might 
be computing, as you are not doing any statistics within a sample (e.g., 
one usually doesn't test to see if probe X is differentially expressed 
as compared to probe Z in sample Q).


Instead, what you should be concerned with are the distributions of the 
individual probes across samples. With microarray data we usually don't 
have enough data to even begin to assess the across-sample, within probe 
distributions (e.g., if you have three replicates for two sample types, 
good luck trying to discern if those probes follow a normal 
distribution, or are even 'hump-shaped'). In addition, there are usually 
tens of thousands of probes on a given chip. I have never heard of 
anybody looking at each probe, trying to assess if it follows a 
reasonable distribution across samples. I suppose you could do it, but 
to what point?


Instead we simply assume that the data follow a reasonable distribution 
and then do the test. This is one of the reasons that it is imperative 
to follow up promising leads with confirmatory testing, preferably with 
new samples.


Best,

Jim






Thank you in advance for your help,



Miguel






[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] How to update a release package?

[James W. MacDonald]

Hi Setia,

http://www.bioconductor.org/developers/how-to/source-control/

Best,

Jim



On Wednesday, December 04, 2013 11:40:51 AM, Setia Pramana wrote:

Dear All,
I made a modification of the development page (neaGUI). But It seems the 
release version is not updated. Please let me know how can I update or modify 
the release version?
Thank you in advanced for your help!
Warm regards,
Setia

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] very slow to use intronsByTranscript in GenomicFeatures

[James W. MacDonald]

Depends on what you mean by unacceptably slow. Took me almost 20 
seconds, during which time I got pretty fidgety.


> system.time(introns <- 
intronsByTranscript(TxDb.Hsapiens.UCSC.hg19.knownGene))

   user  system elapsed
 18.741   0.204  19.340

How long did it take you, and how much RAM do you have?

Best,

Jim


On 12/20/2013 11:25 AM, Ou, Jianhong wrote:

Dear all,

When I try to use intronsByTranscript to get introns for hg19 known genes, I 
found it is unacceptable slow. Does any body has the same problem?

My code:
library(GenomicFeatures)
library(TxDb.Hsapiens.UCSC.hg19.knownGene)
introns <- intronsByTranscript(TxDb.Hsapiens.UCSC.hg19.knownGene)


sessionInfo()

R Under development (unstable) (2013-12-12 r64453)
Platform: x86_64-apple-darwin12.5.0 (64-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  stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] TxDb.Hsapiens.UCSC.hg19.knownGene_2.10.1 GenomicFeatures_1.15.4
[3] AnnotationDbi_1.25.9 Biobase_2.23.3
[5] GenomicRanges_1.15.15XVector_0.3.5
[7] IRanges_1.21.17  BiocGenerics_0.9.2

loaded via a namespace (and not attached):
  [1] biomaRt_2.19.1   Biostrings_2.31.5bitops_1.0-6
 BSgenome_1.31.7
  [5] DBI_0.2-7GenomicAlignments_0.99.9 RCurl_1.95-4.1  
 Rsamtools_1.15.15
  [9] RSQLite_0.11.4   rtracklayer_1.23.6   stats4_3.1.0
 tools_3.1.0
[13] XML_3.98-1.1 zlibbioc_1.9.0

Yours sincerely,

Jianhong Ou

LRB 670A
Program in Gene Function and Expression
364 Plantation Street Worcester,
MA 01605

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] deprecated extractTranscriptsFromGenome

[James W. MacDonald]

Hi Raf,

Under ?extractTranscriptsFromGenome I see this:

Description:

WARNING: The tools described in this man page are obsolete and in
the process of being DEPRECATED.

‘extractTranscriptsFromGenome’ extracts the transcript sequences
from a BSgenome data package using the transcript information
(exon boundaries) stored in a TranscriptDb or GRangesList object.
DEPRECATED. Please use ‘extractTranscriptSeqs’ instead.

‘extractTranscripts’ extracts a set of transcripts from a single
DNA sequence. DEPRECATED. Please use ‘extractTranscriptSeqs’
instead.

Related utilities:

‘transcriptWidths’ to get the lengths of the transcripts (called
the "widths" in this context) based on the boundaries of their
exons.

‘transcriptLocs2refLocs’ converts transcript-based locations into
reference-based (aka chromosome-based or genomic) locations.

‘sortExonsByRank’ orders (or reorders) by rank the exons stored in
a GRangesList object containing exons grouped by transcript.


Best,

Jim


On 3/10/2014 11:57 AM, rcaloger wrote:

Hi, I am the maintainer of chimera package
I got an warning indicating the extractTranscriptsFromGenome and
extractTranscripts functions from GenomicFeatures package are deprecated.
Does anybody could tell me which are the functions that are going to
substitute them?
Cheers
Raf



--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] AnnotationDbi and select function

[James W. MacDonald]

Hi Nicolas,

On 3/12/2014 12:39 PM, Servant Nicolas wrote:

Dear all,

I have an error using the select function from the AnnotationDbi package.
I try to convert some geneID into Symbol, but for some strange reasons it 
crashed.


library(TxDb.Hsapiens.UCSC.hg19.knownGene)
txdb <- TxDb.Hsapiens.UCSC.hg19.knownGene
isActiveSeq(txdb)[seqlevels(txdb)] <- FALSE
isActiveSeq(txdb)[c("chr16","chr1")] <- TRUE
geneGR <- exonsBy(txdb, "gene")
library(Homo.sapiens)
symbol <- select(Homo.sapiens, keys = names(geneGR), keytype = "GENEID", columns = 
"SYMBOL")
Erreur dans head(select(Homo.sapiens, keys = names(geneGR)[1:1001], keytype = 
"GENEID",  :
   erreur d'évaluation de l'argument 'x' lors de la sélection d'une méthode 
pour la fonction 'head' : Erreur dans res[, .reverseColAbbreviations(x, 
cnames), drop = FALSE] :


length(geneGR)

[1] 3269
## The first 1K work

symbol <- select(Homo.sapiens, keys = names(geneGR)[1:1000], keytype = "GENEID", columns 
= "SYMBOL")

## The 1K+1 does not !

symbol <- select(Homo.sapiens, keys = names(geneGR)[1:1001], keytype = "GENEID", columns 
= "SYMBOL")

Erreur dans res[, .reverseColAbbreviations(x, cnames), drop = FALSE] :
   nombre de dimensions incorrect

It looks like I cannot convert more than 1K elements ?? Any reason for that ?
Thank you very much
Nicolas


Not sure what 'GENEID' is in this context - it appears to be Entrez 
Gene. But anyway, if you use "ENTREZID" instead, it works fine:


> symbol <- select(Homo.sapiens, names(geneGR), "SYMBOL", "ENTREZID")
> symbol <- select(Homo.sapiens, names(geneGR), "GENEID", "ENTREZID")
Error in res[, .reverseColAbbreviations(x, cnames), drop = FALSE] :
  incorrect number of dimensions
> symbol <- select(Homo.sapiens, names(geneGR)[1:1000], "GENEID", 
"ENTREZID")
> symbol <- select(Homo.sapiens, names(geneGR)[1:1001], "GENEID", 
"ENTREZID")

Error in res[, .reverseColAbbreviations(x, cnames), drop = FALSE] :
  incorrect number of dimensions

Best,

Jim






sessionInfo()

R Under development (unstable) (2014-03-05 r65125)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=fr_FR.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=fr_FR.UTF-8LC_COLLATE=fr_FR.UTF-8
  [5] LC_MONETARY=fr_FR.UTF-8LC_MESSAGES=fr_FR.UTF-8
  [7] LC_PAPER=fr_FR.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] parallel  stats graphics  grDevices utils datasets  methods
[8] base

other attached packages:
  [1] Homo.sapiens_1.1.2
  [2] org.Hs.eg.db_2.10.1
  [3] GO.db_2.10.1
  [4] RSQLite_0.11.4
  [5] DBI_0.2-7
  [6] OrganismDbi_1.5.3
  [7] XVector_0.3.7
  [8] TxDb.Hsapiens.UCSC.hg19.knownGene_2.10.1
  [9] GenomicFeatures_1.15.9
[10] AnnotationDbi_1.25.14
[11] GenomeInfoDb_0.99.17
[12] Biobase_2.23.6
[13] GenomicRanges_1.15.32
[14] IRanges_1.21.32
[15] BiocGenerics_0.9.3
[16] RColorBrewer_1.0-5
[17] reshape2_1.2.2
[18] reshape_0.8.4
[19] plyr_1.8.1
[20] ggplot2_0.9.3.1
[21] Matrix_1.1-2-2

loaded via a namespace (and not attached):
  [1] BatchJobs_1.2 BBmisc_1.5
  [3] BiocParallel_0.5.16   biomaRt_2.19.3
  [5] Biostrings_2.31.14bitops_1.0-6
  [7] brew_1.0-6BSgenome_1.31.12
  [9] codetools_0.2-8   colorspace_1.2-4
[11] dichromat_2.0-0   digest_0.6.4
[13] fail_1.2  foreach_1.4.1
[15] GenomicAlignments_0.99.29 graph_1.41.3
[17] grid_3.1.0gtable_0.1.2
[19] iterators_1.0.6   labeling_0.2
[21] lattice_0.20-27   MASS_7.3-29
[23] munsell_0.4.2 proto_0.3-10
[25] RBGL_1.39.2   Rcpp_0.11.0
[27] RCurl_1.95-4.1Rsamtools_1.15.32
[29] rtracklayer_1.23.15   scales_0.2.3
[31] sendmailR_1.1-2   stats4_3.1.0
[33] stringr_0.6.2 tools_3.1.0
[35] XML_3.98-1.1  zlibbioc_1.9.0

[[alternative HTML version deleted]]



___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Apparent error in illuminaHumanv4.db

[James W. MacDonald]

g frame 18, chromosome 16
open reading frame 19.

So it appears the ALIAS2PROBE mapping for C16ORF15 is actually for
C15orf16.  Indeed,
all.equal(xxAP[["C16ORF15"]], xxAP[["C15orf16"]])
# [1] TRUE

Some questions:
1) Why is there a mapping for both C16orf15 and C16ORF15?
2) Can you make the names for mappings like ALIAS2PROBE all upper case?
Perhaps there is a Bioconductor annotation convention that prevents this?
3) I also noticed:
nms <- names(xxAP)
length(nms); length(unique(nms)); length(unique(toupper(nms)))
# [1] 99696
# [1] 99696
# [1] 99378
Is there potentially a problem with the 300-odd names that are no longer
unique when raised to upper case?

Regards,

_Taku

  Taku A. Tokuyasu, PhD
Computational Biology Core
UCSF Helen Diller Family Comprehensive Cancer Center

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] error in summary method for KEGGHyperGResult

[James W. MacDonald]

Hi Gabe,

The getAnnMap function doesn't care if the annotation package is an old 
style env or a db. In other words, the error you see is because you 
don't have KEGG.db installed, not because of a bug in the annotation 
package:


> annotate:::getAnnMap("PATHID2NAME", "KEGG", load = TRUE)

KEGG.db contains mappings based on older data because the original
  resource was removed from the the public domain before the most
  recent update was produced. This package should now be considered
  deprecated and future versions of Bioconductor may not have it
  available.  Users who want more current data are encouraged to look
  at the KEGGREST or reactome.db packages

PATHID2NAME map for KEGG (object of class "AnnDbBimap")

> sessionInfo()
R version 3.1.0 (2014-04-10)
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=en_US.UTF-8   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] KEGG.db_2.14.0   Category_2.30.0  GO.db_2.14.0
 [4] RSQLite_0.11.4   DBI_0.2-7Matrix_1.1-3
 [7] AnnotationDbi_1.26.0 GenomeInfoDb_1.0.2   Biobase_2.24.0
[10] BiocGenerics_0.10.0

loaded via a namespace (and not attached):
 [1] annotate_1.42.0   genefilter_1.46.0 graph_1.42.0 grid_3.1.0
 [5] GSEABase_1.26.0   IRanges_1.22.3lattice_0.20-29 RBGL_1.40.0
 [9] splines_3.1.0 stats4_3.1.0  survival_2.37-7 tools_3.1.0
[13] XML_3.98-1.1  xtable_1.7-3

Best,

Jim



On 4/24/2014 9:45 AM, Gabe Becker wrote:

Hey all,

Apologies if I missed something. I am trying to fix a bug a user identified
in ReportingTools, so the original code is not my own.

It seems that the summary() method for class KEGGHyperGResult has an error
in it:


class(keggResults)

[1] "KEGGHyperGResult"
attr(,"package")
[1] "Category"

summary(keggResults)

Error: getAnnMap: package KEGG not available

summary(as(keggResults, "HyperGResult"))

KEGGID  Pvalue OddsRatio   ExpCount Count Size
1   04977 0.003627659 26.245614 0.09151194 2   23
2   04744 0.005355471 21.178138 0.11140584 2   28
3   05216 0.005738421 20.389864 0.11538462 2   29
4   04620 0.006476798  9.056140 0.38992042 3   98
5   05020 0.007834917 17.187500 0.13527851 2   34
6   00830 0.015235568 11.924485 0.19098143 2   48
7   04621 0.021800737  9.776316 0.23076923 2   58
8   00982 0.022512006  9.602955 0.23474801 2   59
9   05214 0.026211199  8.820034 0.25464191 2   64
10  00232 0.027536679 43.758333 0.02785146 17
11  04720 0.030141245  8.153967 0.27453581 2   69
12  04666 0.04894  6.183014 0.35809019 2   90


Specifically, the error is thrown in the call to getAnnMap

I don't currently have a local installation of bioc-devel 3.0 yet (mea
culpa) but a quick glance at the source code tells me that the relevant
summary method still calls getAnnMap with "KEGG" as it's second argument.


Thanks,
~G


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] question about affy::plotLocation - scripts

[James W. MacDonald]

Hi Kristóf,

On 6/16/2014 10:20 AM, Kristóf Jakab wrote:

It seems I can't send attachments, I copy the codes here.


test_plotLocation_affy.R

#!/usr/bin/env Rscript
#kristof.ja...@hegelab.org

# MAKE AFFYBATCH
#--
# download CEL file
library(GEOquery)
getGEOSuppFiles("GSM229005")

#--
# read CEL file
library(affy)
geoS <- ReadAffy(filenames=paste("GSM229005","GSM229005.CEL.gz", sep="/"))

# PLOTTING TO PNG
#--
# raw
png(filename="geo_testing_spot_locations_raw.png",height=744*10,width=744*10,res=1200)

## image (log scale intensities)
image(geoS,transfo=log)
## perfectmatches
l <- indexProbes(geoS, which="pm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
plotLocation(xy,col="tomato",pch=18,cex=0.075)
})
## missmatches
l <- indexProbes(geoS, which="mm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
plotLocation(xy,col="aquamarine",pch=18,cex=0.075)
})
dev.off()

#--
# mirrored
png(filename="geo_testing_spot_locations_mirrored.png",height=744*10,width=744*10,res=1200)

## image (log scale intensities)
image(geoS,transfo=log)
## perfectmatches
l <- indexProbes(geoS, which="pm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
xy <- cbind(x=xy[,1],y=(743-xy[,2])) # mirroring
plotLocation(xy,col="tomato",pch=18,cex=0.075)
})
## missmatches
l <- indexProbes(geoS, which="mm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
xy <- cbind(x=xy[,1],y=(743-xy[,2])) # mirroring
plotLocation(xy,col="aquamarine",pch=18,cex=0.075)
})
dev.off()


correction_for_plotLocation.R

plotLocation <- function(x, col="green", pch=22, ...) {
if (is.list(x)) {
  x <- cbind(unlist(lapply(x, function(x) x[,1])),
 unlist(lapply(x, function(x) x[,2])))
}
points(x[,1], 743-x[,2] # mirroring 744Ã---744 matrix, numbered from 0 to 
743
   , pch=pch, col=col, ...)
}


Thanks for pointing this out. It's apparent almost nobody ever uses this 
code, as it has been in the affy package since pretty much the beginning 
(2002), and you are the first to notice this.


Unfortunately, hard-coding the number of rows isn't the answer, since 
Affy arrays have different dimensions. Probably the best fix is to add 
an additional required argument 'affybatch' that we can use to extract 
the chip dimensions from.


Best,

Jim





On 06/16/2014 10:59 AM, Kristóf Jakab wrote:

Dear BiocDevelR!

I'm working lot with the excelent *affy package* of Rafael A.
Irizarry, I find it very useful.

I have a bit strange experience with it's *plotLocation function*.
It seems, *I have to mirror Y coordinates* to plot properly.
Perhaps it's because the CEL file reading starts from the top, and
plotting starts from the bottom.

I'm not sure if I'm rigtht, can you check, that I haven't made mistake?
If yes, I suggest a (simple) solution for this.

I attach two plot made from a GEO GSM CEL file (see script).
First I've plotted all gene name (ProbeSet) on the CEL file images,
second I've plotted after mirroring the Y coordinates.
As you can see on the raw plotting there are points on chip name
(printed by BioB spots).

I attach my plotting script too, and a potential correction for the
affy::plotLocation. (I've tried it, it seems good.)

Yours sincerly:
Kristóf Jakab

I've linked 2 files to this email:
geo_testing_spot_locations_mirrored.png
<https://www.box.com/shared/ow3q5sn3fpmyz3u8w533>(6.0 MB)Box
<https://www.box.com/thunderbird>https://www.box.com/shared/ow3q5sn3fpmyz3u8w533

geo_testing_spot_locations_raw.png
<https://www.box.com/shared/3sj9i3lpkixkq85qar0r>(6.1 MB)Box
<https://www.box.com/thunderbird>https://www.box.com/shared/3sj9i3lpkixkq85qar0r

Mozilla Thunderbird <http://www.getthunderbird.com> makes it easy to
share large files over email.



[[alternative HTML version deleted]]



___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] question about affy::plotLocation - scripts

[James W. MacDonald]

Hi Kristof,

This has been fixed in both the release and devel versions of affy. 
Ideally we would change the API so the user has to tell plotLocation() 
what array they are using, so the number of rows can be extracted from a 
reputable source.


However, the current implementation is pretty fragile to begin with 
(e.g., it simply assumes the end user has already generated an image), 
and it took 12 years for anybody to notice a problem (which implies to 
me that this is an underused function), so I took the expedient of just 
getting the number of rows from the image itself.


The new version(s) should propagate through the build machines in a day 
or so.


Best,

Jim

On 6/16/2014 10:35 AM, James W. MacDonald wrote:

Hi Kristóf,

On 6/16/2014 10:20 AM, Kristóf Jakab wrote:

It seems I can't send attachments, I copy the codes here.


test_plotLocation_affy.R

#!/usr/bin/env Rscript
#kristof.ja...@hegelab.org

# MAKE AFFYBATCH
#--
# download CEL file
library(GEOquery)
getGEOSuppFiles("GSM229005")

#--
# read CEL file
library(affy)
geoS <- ReadAffy(filenames=paste("GSM229005","GSM229005.CEL.gz",
sep="/"))

# PLOTTING TO PNG
#--
# raw
png(filename="geo_testing_spot_locations_raw.png",height=744*10,width=744*10,res=1200)


## image (log scale intensities)
image(geoS,transfo=log)
## perfectmatches
l <- indexProbes(geoS, which="pm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
plotLocation(xy,col="tomato",pch=18,cex=0.075)
})
## missmatches
l <- indexProbes(geoS, which="mm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
plotLocation(xy,col="aquamarine",pch=18,cex=0.075)
})
dev.off()

#--
# mirrored
png(filename="geo_testing_spot_locations_mirrored.png",height=744*10,width=744*10,res=1200)


## image (log scale intensities)
image(geoS,transfo=log)
## perfectmatches
l <- indexProbes(geoS, which="pm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
xy <- cbind(x=xy[,1],y=(743-xy[,2])) # mirroring
plotLocation(xy,col="tomato",pch=18,cex=0.075)
})
## missmatches
l <- indexProbes(geoS, which="mm", geneNames(geoS))
lapply(l,function(li){
xy <- indices2xy(li, abatch=geoS)
xy <- cbind(x=xy[,1],y=(743-xy[,2])) # mirroring
plotLocation(xy,col="aquamarine",pch=18,cex=0.075)
})
dev.off()


correction_for_plotLocation.R

plotLocation <- function(x, col="green", pch=22, ...) {
if (is.list(x)) {
  x <- cbind(unlist(lapply(x, function(x) x[,1])),
 unlist(lapply(x, function(x) x[,2])))
}
points(x[,1], 743-x[,2] # mirroring 744Ã---744 matrix, numbered
from 0 to 743
   , pch=pch, col=col, ...)
}


Thanks for pointing this out. It's apparent almost nobody ever uses this
code, as it has been in the affy package since pretty much the beginning
(2002), and you are the first to notice this.

Unfortunately, hard-coding the number of rows isn't the answer, since
Affy arrays have different dimensions. Probably the best fix is to add
an additional required argument 'affybatch' that we can use to extract
the chip dimensions from.

Best,

Jim





On 06/16/2014 10:59 AM, Kristóf Jakab wrote:

Dear BiocDevelR!

I'm working lot with the excelent *affy package* of Rafael A.
Irizarry, I find it very useful.

I have a bit strange experience with it's *plotLocation function*.
It seems, *I have to mirror Y coordinates* to plot properly.
Perhaps it's because the CEL file reading starts from the top, and
plotting starts from the bottom.

I'm not sure if I'm rigtht, can you check, that I haven't made mistake?
If yes, I suggest a (simple) solution for this.

I attach two plot made from a GEO GSM CEL file (see script).
First I've plotted all gene name (ProbeSet) on the CEL file images,
second I've plotted after mirroring the Y coordinates.
As you can see on the raw plotting there are points on chip name
(printed by BioB spots).

I attach my plotting script too, and a potential correction for the
affy::plotLocation. (I've tried it, it seems good.)

Yours sincerly:
Kristóf Jakab

I've linked 2 files to this email:
geo_testing_spot_locations_mirrored.png
<https://www.box.com/shared/ow3q5sn3fpmyz3u8w533>(6.0 MB)Box
<https://www.box.com/thunderbird>https://www.box.com/shared/ow3q5sn3fpmyz3u8w533


geo_testing_spot_locations_raw.png
<https://www.box.com/shared/3sj9i3lpkixkq85qar0r>(6.1 MB)Box
<https://www.box.com/thunderbird>https://www.box.com/shared/3sj9i3lpkixkq85qar0r


Mozilla Thunderbird

Re: [Bioc-devel] edgeR estimateGLMRobustDisp Fails when Called From A Package

[James W. MacDonald]

Hi Dario,

Isn't an easier fix to simply add

ImportFrom(limma, loessFit)

in your NAMESPACE file?

Best,

Jim


On 6/26/2014 12:00 AM, Dario Strbenac wrote:

Hello,

I am writing a package that has a function that uses
estimateGLMRobustDisp, leading to an error :

Error in dispBinTrend(y, design, offset = offset, method.trend =
"loess",  : could not find function "loessFit" Calls: edgeRselection
... estimateGLMTrendedDisp -> estimateGLMTrendedDisp.default ->
dispBinTrend

I import estimateGLMRobustDisp from edgeR in my NAMESPACE file. This
error is because edgeR depends on limma, rather than importing from
it. I want to avoid using parent.env<- and .onLoad to get around the
problem. Is there any hope of modifying the edgeR description file to
have limma in the Imports field ?

-- Dario Strbenac PhD Student
University of Sydney Camperdown NSW 2050 Australia

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Distinction between release and devel package websites

[James W. MacDonald]

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



--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Distinction between release and devel package websites

[James W. MacDonald]

Hi Andrzej,

On 7/22/2014 1:14 PM, Andrzej Oleś wrote:

Hi all,

I think having links is useful, e.g. for someone who uses BioC release
but wants to install by hand a particular package from the devel
branch.


I'm not sure I think this is a compelling reason for keeping the links. 
If someone is sophisticated enough to install a devel version of a 
package into their release install, then surely they are sophisticated 
enough to get it from svn?


It has always struck me as odd that we try time and again to get people 
to use biocLite() to install packages, yet make it so easy for people to 
ignore this advice.


Best,

Jim






Distinct colors between release and devel make sense only if one
understands their meaning, which in the end might prove not to be very
useful. I would rather recommend emphasizing the distinction between
release and devel in clear text across the package landing page,
possibly in multiple places, e.g. somewhere close to the actual
package version number; for instance, add the word "devel" after the
version number with a tooltip which will give some explanation/warning
that this is not the stable release version.

The concept of a notification box is far from ideal because it tends
to be annoing to the user and once dismissed 'forever' the user won't
be warned in the future.

I think that the actual problem arises from the fact that the release
landing pages are not clearly prioritized over the devel ones. Maybe
this could be  addressed by preventing the devel pages from being
harvested by google? It could make also sense to emphasize (bold face,
color, ...) the package release landing page on the result list
returned by the search engine on the BioC website. Currently, the
results for release and devel differ only in their relative path,
which can be easily overlooked, and both say " Home", see
example below:

Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html
   Bioconductor - DESeq2 Home
Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html
   Bioconductor - DESeq2 Home


Cheers,
Andrzej

On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald  wrote:

Given that we have an ongoing problem with people inadvisedly clicking and
installing things, is there a good rationale for allowing them to do so?

Perhaps the landing page for each package should be stripped of links and
replaced with some indication of the availability for each package on the
various operating systems. There could also be a note indicating that people
can install using biocLite().

Best,

Jim




On 7/22/2014 11:48 AM, Dan Tenenbaum wrote:


Seems like there are two problems, first that the release and devel pages
look similar, but more importantly that people are downloading and
installing from the package pages when they should be using biocLite().

I am open to the suggestions for making the release/devel pages look more
different from each other, but I think something needs to be done about the
second problem as well. Perhaps a popup that comes up when you click on a
package tarball saying "The best way to install this is with biocLite(); are
you sure you want to download it?"

Whatever we do probably won't happen until after BioC2014.

Dan


- Original Message -


From: "Julian Gehring" 
To: "Hervé Pagès" , "Michael Lawrence"
, "Vincent Carey"

Cc: bioc-devel@r-project.org
Sent: Tuesday, July 22, 2014 8:07:29 AM
Subject: Re: [Bioc-devel] Distinction between release and devel package
websites

Hi,

Tooltips that appear while hovering over selected links are easy to
miss.  This alone will likely not be clear enough.  We should convey
the
information that the entire website presents a different version of
the
package.

The idea of a notification box that can be made visible by the
individual user seems tempting.  One can combine this with an
optional
cookie, to remember the state between browser sessions.

Changing the layout of the devel page itself will also be helpful to
make the distinction more pronounced.  Hopefully we could approach
this
in a way that maintains the nice design of the bioc website.

Best
Julian


On 21.07.2014 21:50, Hervé Pagès wrote:


Hi,

In addition to these suggestions, how about using a special
background
color for package landing pages in devel?

Cheers,
H.

On 07/21/2014 07:32 PM, Michael Lawrence wrote:


Or an unobtrusive "notification box" that drops down from the top
of the
page, saying something like "this is devel"; there would be a
dismiss
button and a checkbox for whether to show again. The user is free
to
simply
ignore it and proceed as normal.




On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey

wrote:


how about a tooltip that reads "installation via biocLite() is
the
recommended approach to Bioconductor software
acquisition, other approaches may lead to inconsistent
package-sets"
that
appears wh

Re: [Bioc-devel] affycoretools in devel failed to install

[James W. MacDonald]

Hi Vojtech,


On 7/25/2014 7:32 AM, Vojtech Kulvait wrote:

Hello,
when I try to install affycoretools in devel i get an error:

* installing *source* package ‘affycoretools’ ...
** R
** inst
** preparing package for lazy loading
Error : object ‘symbols2indices’ is not exported by 'namespace:limma'
ERROR: lazy loading failed for package ‘affycoretools’


Cutting out just what you think is important from the output from 
biocLite isn't really helpful. Instead, please give us everything.


I cannot see how this has anything to do with affycoretools anyway. I 
don't import symbols2indices, nor do I call that function in any code in 
affycoretools. Plus, limma exports every function except those that 
begin with a period, so symbols2indices is for sure exported. And to top 
it all off, the build report for affycoretools is clean, except for some 
warnings I will have to clean up sometime 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/affycoretools/zin1-checksrc.html)


If I were to make a haphazard guess, I would think your limma package 
install is borked somehow and you might be better off re-installing it.


Best,

Jim




I think I have up to date instalation of all packages.
Vojtech.

[[alternative HTML version deleted]]



___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Importing summary from AnnotationDbi, Category, GOstats

[James W. MacDonald]

There is an issue on the support site having to do with the inability to
import the summary function from the namespaces from the packages listed in
the subject line. I see the same problem/errors with my affycoretools
package.

When you load ReportingTools, you get the following warnings:

Warning messages:
1: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]], c(lib.loc,  :
  No generic function found corresponding to requested imported methods for
"summary" from package "AnnotationDbi" (malformed exports?)
2: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]], c(lib.loc,  :
  No generic function found corresponding to requested imported methods for
"summary" from package "Category" (malformed exports?)
3: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]], c(lib.loc,  :
  No generic function found corresponding to requested imported methods for
"summary" from package "GOstats" (malformed exports?)


Is this because of the following changes?


r94092 | hpa...@fhcrc.org | 2014-09-12 18:02:34 -0700 (Fri, 12 Sep 2014) |
7 lines
Changed paths:
   M /trunk/madman/Rpacks/AnnotationDbi/DESCRIPTION
   M /trunk/madman/Rpacks/AnnotationDbi/NAMESPACE
   M /trunk/madman/Rpacks/AnnotationDbi/R/createAnnObjs-utils.R
   M /trunk/madman/Rpacks/AnnotationDbi/R/createAnnObjs.NCBIORG_DBs.R
   M /trunk/madman/Rpacks/AnnotationDbi/R/methods-Inparanoid.R
   M /trunk/madman/Rpacks/AnnotationDbi/R/methods-Inparanoid8.R
   M /trunk/madman/Rpacks/AnnotationDbi/R/methods-geneCentricDbs.R

- Drop dependency on IRanges (stuff from IRanges needed by AnnotationDbi is
  now in S4Vectors).
- Add dependency on stats4 and import summary() from it. This is an S4
  generic and AnnotationDbi defines and exports S4 methods for it.
- Address the "A package almost never needs to use ::: for its own objects"
  NOTE from 'R CMD check'.

which included

Index: NAMESPACE
===
--- NAMESPACE (revision 94000)
+++ NAMESPACE (working copy)
@@ -1,11 +1,11 @@
 import(methods)
 import(utils)
+importFrom(stats4, summary)
 import(Biobase)
 import(DBI)
 import(RSQLite)
 import(BiocGenerics)
-importFrom(S4Vectors, isTRUEorFALSE, isSingleString, metadata)
-importFrom(IRanges, elementLengths)
+importFrom(S4Vectors, isTRUEorFALSE, isSingleString, metadata,
elementLengths)

 importFrom(GenomeInfoDb, genomeStyles, extractSeqlevels, mapSeqlevels)
 exportClasses(
@@ -169,9 +169,6 @@
 intraIDMapper,
 idConverter,

-#Needs to be exported from RSQLite
-summary,
-
 ## AnnotationDb
 metadata,

so it appears summary is no longer exported?

Best,

Jim




-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Importing summary from AnnotationDbi, Category, GOstats

[James W. MacDonald]

   evaluate_0.5.5

[22] fail_1.2 foreach_1.4.2formatR_1.0

[25] Formula_1.1-2genefilter_1.46.1geneplotter_1.42.0

[28] GenomicAlignments_1.0.6  GenomicFeatures_1.16.2   GenomicRanges_1.16.4

[31] ggbio_1.12.10ggplot2_1.0.0GO.db_2.14.0

[34] GOstats_2.30.0   graph_1.42.0 grid_3.1.0

[37] gridExtra_0.9.1  GSEABase_1.26.0  gtable_0.1.2

[40] Hmisc_3.14-4 hwriter_1.3.1IRanges_1.22.10

[43] iterators_1.0.7  lattice_0.20-29  latticeExtra_0.6-26

[46] limma_3.20.9 locfit_1.5-9.1   MASS_7.3-34

[49] Matrix_1.1-4 munsell_0.4.2PFAM.db_2.14.0

[52] plyr_1.8.1   proto_0.3-10 RBGL_1.40.1

[55] RColorBrewer_1.0-5   Rcpp_0.11.2
 RcppArmadillo_0.4.400.0
[58] RCurl_1.95-4.3   reshape2_1.4 R.methodsS3_1.6.1

[61] R.oo_1.18.0  Rsamtools_1.16.1 rtracklayer_1.24.2

[64] R.utils_1.33.0   scales_0.2.4 sendmailR_1.1-2

[67] splines_3.1.0        stats4_3.1.0 stringr_0.6.2

[70] survival_2.37-7  tools_3.1.0
 VariantAnnotation_1.10.5
[73] XML_3.98-1.1 xtable_1.7-3 XVector_0.4.0

[76] zlibbioc_1.10.0
>

Jim



On Tue, Sep 23, 2014 at 1:43 PM, Hervé Pagès  wrote:

> Hi Jim,
>
> On 09/23/2014 09:42 AM, James W. MacDonald wrote:
>
>> There is an issue on the support site having to do with the inability to
>> import the summary function from the namespaces from the packages listed
>> in
>> the subject line. I see the same problem/errors with my affycoretools
>> package.
>>
>> When you load ReportingTools, you get the following warnings:
>>
>> Warning messages:
>> 1: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported methods
>> for
>> "summary" from package "AnnotationDbi" (malformed exports?)
>> 2: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported methods
>> for
>> "summary" from package "Category" (malformed exports?)
>> 3: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported methods
>> for
>> "summary" from package "GOstats" (malformed exports?)
>>
>>
>> Is this because of the following changes?
>>
>> 
>> r94092 | hpa...@fhcrc.org | 2014-09-12 18:02:34 -0700 (Fri, 12 Sep 2014)
>> |
>> 7 lines
>> Changed paths:
>> M /trunk/madman/Rpacks/AnnotationDbi/DESCRIPTION
>> M /trunk/madman/Rpacks/AnnotationDbi/NAMESPACE
>> M /trunk/madman/Rpacks/AnnotationDbi/R/createAnnObjs-utils.R
>> M /trunk/madman/Rpacks/AnnotationDbi/R/createAnnObjs.NCBIORG_DBs.R
>> M /trunk/madman/Rpacks/AnnotationDbi/R/methods-Inparanoid.R
>> M /trunk/madman/Rpacks/AnnotationDbi/R/methods-Inparanoid8.R
>> M /trunk/madman/Rpacks/AnnotationDbi/R/methods-geneCentricDbs.R
>>
>> - Drop dependency on IRanges (stuff from IRanges needed by AnnotationDbi
>> is
>>now in S4Vectors).
>> - Add dependency on stats4 and import summary() from it. This is an S4
>>generic and AnnotationDbi defines and exports S4 methods for it.
>> - Address the "A package almost never needs to use ::: for its own
>> objects"
>>NOTE from 'R CMD check'.
>>
>> which included
>>
>> Index: NAMESPACE
>> ===
>> --- NAMESPACE (revision 94000)
>> +++ NAMESPACE (working copy)
>> @@ -1,11 +1,11 @@
>>   import(methods)
>>   import(utils)
>> +importFrom(stats4, summary)
>>   import(Biobase)
>>   import(DBI)
>>   import(RSQLite)
>>   import(BiocGenerics)
>> -importFrom(S4Vectors, isTRUEorFALSE, isSingleString, metadata)
>> -importFrom(IRanges, elementLengths)
>> +importFrom(S4Vectors, isTRUEorFALSE, isSingleString, metadata,
>> elementLengths)
>>
>>   importFrom(GenomeInfoDb, genomeStyles, extractSeqlevels, mapSeqlevels)
>>   exportClasses(
>> @@ -169,9 +169,6 @@
>>   intraIDMapper,
>>   idConverter,
>>
>> -#Needs to be exported from RSQLite
>> -summary,
>> -
>>   ## AnnotationDb
>>   metadata,
>>
>> so it appears summary is no longer exported?
&

Re: [Bioc-devel] Importing summary from AnnotationDbi, Category, GOstats

[James W. MacDonald]

Never mind. Installing all of GOstats, Category, AnnotationDbi and
ReportingTools fixed the issue.

Thanks,

Jim



On Tue, Sep 23, 2014 at 1:55 PM, James W. MacDonald  wrote:

> Hi Herve,
>
> No joy:
>
>
> > biocLite("ReportingTools")
> BioC_mirror: http://bioconductor.org
> Using Bioconductor version 2.14 (BiocInstaller 1.14.2), R version
>   3.1.0.
> Installing package(s) 'ReportingTools'
> trying URL '
> http://bioconductor.org/packages/2.14/bioc/src/contrib/ReportingTools_2.4.0.tar.gz
> '
> Content type 'application/x-gzip' length 2570348 bytes (2.5 Mb)
> opened URL
> ==
> downloaded 2.5 Mb
>
> * installing *source* package ‘ReportingTools’ ...
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
> c(lib.loc,  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "AnnotationDbi" (malformed exports?)
> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
> c(lib.loc,  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "Category" (malformed exports?)
> Warning: found methods to import for function ‘summary’ but not the
> generic itself
> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
> c(lib.loc,  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "GOstats" (malformed exports?)
> Warning: found methods to import for function ‘summary’ but not the
> generic itself
> in method for ‘objectToHTML’ with signature ‘object="ggbio"’: no
> definition for class “ggbio”
> Note: no visible binding for '<<-' assignment to '.reportDirectory'
> Note: no visible binding for '<<-' assignment to '.reportDirectory'
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded
> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
> c(lib.loc,  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "AnnotationDbi" (malformed exports?)
> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
> c(lib.loc,  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "Category" (malformed exports?)
> Warning: found methods to import for function ‘summary’ but not the
> generic itself
> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
> c(lib.loc,  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "GOstats" (malformed exports?)
> Warning: found methods to import for function ‘summary’ but not the
> generic itself
> * DONE (ReportingTools)
>
> And when I load ReportingTools I still get the warnings:
>
> Warning messages:
> 1: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]], c(lib.loc,
>  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "AnnotationDbi" (malformed exports?)
> 2: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]], c(lib.loc,
>  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "Category" (malformed exports?)
> 3: found methods to import for function ‘summary’ but not the generic
> itself
> 4: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]], c(lib.loc,
>  :
>   No generic function found corresponding to requested imported methods
> for "summary" from package "GOstats" (malformed exports?)
> 5: found methods to import for function ‘summary’ but not the generic
> itself
> > sessionInfo()
> R version 3.1.0 (2014-04-10)
> 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=en_US.UTF-8   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] ReportingTools_2.4.0 Annotati

Re: [Bioc-devel] Importing summary from AnnotationDbi, Category, GOstats

[James W. MacDonald]

Exactly! And re-installing the various packages didn't result in any
version changes, so it's a mystery as to why there was a problem in the
first place.


On Tue, Sep 23, 2014 at 2:24 PM, Hervé Pagès  wrote:

> Also note that, according to the sessionInfo() you sent, it seems you
> were using the release. I've no idea how you could get these warnings
> with the release since the changes I made recently to AnnotationDbi,
> Category, and GOstats are in devel only...
>
> H.
>
> On 09/23/2014 11:05 AM, James W. MacDonald wrote:
>
>> Never mind. Installing all of GOstats, Category, AnnotationDbi and
>> ReportingTools fixed the issue.
>>
>> Thanks,
>>
>> Jim
>>
>>
>>
>> On Tue, Sep 23, 2014 at 1:55 PM, James W. MacDonald > <mailto:jmac...@uw.edu>> wrote:
>>
>> Hi Herve,
>>
>> No joy:
>>
>>
>>  > biocLite("ReportingTools")
>> BioC_mirror: http://bioconductor.org
>> Using Bioconductor version 2.14 (BiocInstaller 1.14.2), R version
>>3.1.0.
>> Installing package(s) 'ReportingTools'
>> trying URL
>> 'http://bioconductor.org/packages/2.14/bioc/src/
>> contrib/ReportingTools_2.4.0.tar.gz'
>> Content type 'application/x-gzip' length 2570348 bytes (2.5 Mb)
>> opened URL
>> ==
>> downloaded 2.5 Mb
>>
>> * installing *source* package ‘ReportingTools’ ...
>> ** R
>> ** data
>> ** inst
>> ** byte-compile and prepare package for lazy loading
>> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "AnnotationDbi" (malformed
>> exports?)
>> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "Category" (malformed exports?)
>> Warning: found methods to import for function ‘summary’ but not the
>> generic itself
>> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "GOstats" (malformed exports?)
>> Warning: found methods to import for function ‘summary’ but not the
>> generic itself
>> in method for ‘objectToHTML’ with signature ‘object="ggbio"’: no
>> definition for class “ggbio”
>> Note: no visible binding for '<<-' assignment to '.reportDirectory'
>> Note: no visible binding for '<<-' assignment to '.reportDirectory'
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** installing vignettes
>> ** testing if installed package can be loaded
>> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "AnnotationDbi" (malformed
>> exports?)
>> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "Category" (malformed exports?)
>> Warning: found methods to import for function ‘summary’ but not the
>> generic itself
>> Warning in namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "GOstats" (malformed exports?)
>> Warning: found methods to import for function ‘summary’ but not the
>> generic itself
>> * DONE (ReportingTools)
>>
>> And when I load ReportingTools I still get the warnings:
>>
>> Warning messages:
>> 1: In namespaceImportMethods(ns, loadNamespace(j <- imp[[1L]],
>> c(lib.loc,  :
>>No generic function found corresponding to requested imported
>> methods for "summary" from package "AnnotationDbi" (malformed
>> exports?)
>> 2: In namespac

Re: [Bioc-devel] hedgehog Subversion server upgrade Tuesday 9/30

[James W. MacDonald]

Hi Dan,

I got this when I tried to commit a change.

Transmitting file data ..svn: Commit failed (details follow):
svn: Commit blocked by pre-commit hook (exit code 1) with output:
Use of the encoding pragma is deprecated at
/extra/svndata/gentleman/svnroot/bioconductor/hooks/
check-case-insensitive.pl line 36.
sh: 1: /usr/local/subversion3/bin/svnlook: not found
sh: 1: /usr/local/subversion3/bin/svnlook: not found
Please enter a commit message which details what has changed during this
commit.

Best,

Jim




On Tue, Sep 30, 2014 at 1:01 PM, Dan Tenenbaum  wrote:

> The switchover has happened, hedgehog is a new server now. Please let me
> know if you run into any issues with it.
> Dan
>
>
> - Original Message -
> > From: "Dan Tenenbaum" 
> > To: "bioc-devel" 
> > Sent: Monday, September 29, 2014 9:34:36 AM
> > Subject: Fwd: [Bioc-devel] hedgehog Subversion server upgrade Tuesday
> 9/30
> >
> > Reminder, this is tomorrow.
> > Dan
> >
> >
> > - Forwarded Message -
> > From: "Dan Tenenbaum" 
> > To: "bioc-devel" 
> > Sent: Wednesday, September 17, 2014 1:35:39 PM
> > Subject: [Bioc-devel] hedgehog Subversion server upgrade Tuesday 9/30
> >
> > Hello Bioconductor developers,
> >
> > On Tuesday 9/30 at 8:00 AM (Seattle time), the Subversion server on
> > hedgehog will
> > stop for two hours until 10:00 AM.
> >
> > hedgehog is the svn server for all Bioconductor packages, so this
> > will
> > mean you will be unable to commit or check out repositories during
> > this
> > time. If you are using the Git-Svn bridge, it will also not
> > be syncing during this time but should catch up afterwards.
> >
> > The purpose of this downtime is to move the Subversion service to
> > new faster hardware, a new OS (Ubuntu 14.04 LTS), and new versions
> > of Subversion (v1.8.8) and Apache2 (v2.4.7).
> >
> > The server itself will still be named hedgehog, but the IP address
> > will change. Part of the 2-hour downtime is to allow changes to DNS
> > to take place, moving the name from one address to the other.
> >
> > Everything else about Subversion on hedgehog will remain the same.
> > If you are still using this service, you should not have to make any
> > changes due to this upgrade.
> >
> > Please reply to the list if you have any questions about this.
> > Dan
> >
> > ___
> > 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
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] hedgehog Subversion server upgrade Tuesday 9/30

[James W. MacDonald]

Thanks Dan!


On Tue, Sep 30, 2014 at 1:19 PM, Dan Tenenbaum  wrote:

>
>
> - Original Message -
> > From: "James W. MacDonald" 
> > To: "Dan Tenenbaum" 
> > Cc: "bioc-devel" 
> > Sent: Tuesday, September 30, 2014 10:14:00 AM
> > Subject: Re: [Bioc-devel] hedgehog Subversion server upgrade Tuesday 9/30
> >
> >
> > Hi Dan,
> >
> >
> > I got this when I tried to commit a change.
> >
> >
> >
> >
> > Transmitting file data ..svn: Commit failed (details follow):
> > svn: Commit blocked by pre-commit hook (exit code 1) with output:
> > Use of the encoding pragma is deprecated at
> > /extra/svndata/gentleman/svnroot/bioconductor/hooks/
> > check-case-insensitive.pl line 36.
> > sh: 1: /usr/local/subversion3/bin/svnlook: not found
> > sh: 1: /usr/local/subversion3/bin/svnlook: not found
> > Please enter a commit message which details what has changed during
> > this commit.
> >
> >
>
> Please try it again now.
> Dan
>
>
> > Best,
> >
> >
> > Jim
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Sep 30, 2014 at 1:01 PM, Dan Tenenbaum < dtene...@fhcrc.org >
> > wrote:
> >
> >
> > The switchover has happened, hedgehog is a new server now. Please let
> > me know if you run into any issues with it.
> > Dan
> >
> >
> > - Original Message -
> > > From: "Dan Tenenbaum" < dtene...@fhcrc.org >
> > > To: "bioc-devel" < bioc-devel@r-project.org >
> >
> >
> > > Sent: Monday, September 29, 2014 9:34:36 AM
> > > Subject: Fwd: [Bioc-devel] hedgehog Subversion server upgrade
> > > Tuesday 9/30
> > >
> > > Reminder, this is tomorrow.
> > > Dan
> > >
> > >
> > > - Forwarded Message -
> > > From: "Dan Tenenbaum" < dtene...@fhcrc.org >
> > > To: "bioc-devel" < bioc-devel@r-project.org >
> > > Sent: Wednesday, September 17, 2014 1:35:39 PM
> > > Subject: [Bioc-devel] hedgehog Subversion server upgrade Tuesday
> > > 9/30
> > >
> > > Hello Bioconductor developers,
> > >
> > > On Tuesday 9/30 at 8:00 AM (Seattle time), the Subversion server on
> > > hedgehog will
> > > stop for two hours until 10:00 AM.
> > >
> > > hedgehog is the svn server for all Bioconductor packages, so this
> > > will
> > > mean you will be unable to commit or check out repositories during
> > > this
> > > time. If you are using the Git-Svn bridge, it will also not
> > > be syncing during this time but should catch up afterwards.
> > >
> > > The purpose of this downtime is to move the Subversion service to
> > > new faster hardware, a new OS (Ubuntu 14.04 LTS), and new versions
> > > of Subversion (v1.8.8) and Apache2 (v2.4.7).
> > >
> > > The server itself will still be named hedgehog, but the IP address
> > > will change. Part of the 2-hour downtime is to allow changes to DNS
> > > to take place, moving the name from one address to the other.
> > >
> > > Everything else about Subversion on hedgehog will remain the same.
> > > If you are still using this service, you should not have to make
> > > any
> > > changes due to this upgrade.
> > >
> > > Please reply to the list if you have any questions about this.
> > > Dan
> > >
> > > ___
> > > 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
> >
> >
> >
> >
> > --
> >
> > James W. MacDonald, M.S.
> > Biostatistician
> > University of Washington
> > Environmental and Occupational Health Sciences
> > 4225 Roosevelt Way NE, # 100
> > Seattle WA 98105-6099
> >
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] RMarkdown for vignettes

[James W. MacDonald]

Hi Gordon,

Sean Davis has something about this on his blog:

http://watson.nci.nih.gov/~sdavis/blog/convert_from_sweave_to_r_markdown_vignettes/

Best,

Jim



On Fri, Oct 3, 2014 at 9:06 AM, Gordon Ball  wrote:

> Hello
>
> Is it possible to use (RStudio's) rmarkdown package as a vignette
> builder for the upcoming release?
>
> ie, with the (at least locally working) configuration
>
> DESCRIPTION
>
> Suggests: knitr, rmarkdown, BiocStyle
> VignetteBuilder: knitr
>
> vignette/vignette.Rmd
>
> ---
> title: ...
> output: BiocStyle::html_document
> vignette: >
> %% \VignetteEngine{knitr::rmarkdown}
> %% \VignetteIndexEntry{...}
> 
>
> I couldn't find any explicit reference to markdown vs rmarkdown in the
> package guidelines. The documentation for [BiocStyle] indicates that it
> isn't possible to build package vignettes with the newer rmarkdown - is
> that still correct?
>
> I note that the newer [rmarkdown] is now in CRAN, so presumably can be
> used by the builders - but do they have the non-R dependency (pandoc)
> available?
>
> The rationale for wanting rmarkdown instead markdown is support for a
> few extended features, particularly being able to cite from a bibtex
> file (which as far as I know isn't possible with the older markdown).
>
> Thanks
>
> Gordon Ball
> Computational Medicine Group
> Karolinska Institute
>
>
>
> [BiocStyle]:
>
> http://www.bioconductor.org/packages/devel/bioc/vignettes/BiocStyle/inst/doc/HtmlStyle.html
>
> [rmarkdown]: http://cran.r-project.org/web/packages/rmarkdown/
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BiocStyle on windows with spaces in path names

[James W. MacDonald]

Hi Steffen,

It looks like you are running R as an administrator, rather than as a
regular user (or you are on something really old like XP). By default R
should try to create a user-level library directory in your Documents
folder. It is probably not such a good idea to run R as administrator if
you are on a more modern version of Windows.

Note that system.file (which BiocStyle::latex()  calls to find the package
path) will in the case of base packages use .Library to construct the path:

> system.file()
[1] "C:/PROGRA~1/R/R-31~1.0/library/base"

Which being an 8.1 path, will work for MikTex. But if I run as an
administrator and put BiocStyle in my Program Files library, I get

> latex()
\RequirePackage{C:/Program
Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}

\AtBeginDocument{\bibliographystyle{C:/Program
Files/R/R-3.1.0/library/BiocStyle/sty/unsrturl}}

Which of course will fail. So the best option is to stop running R as an
administrator, and install packages in your Documents folder in a path with
no spaces.

Best,

Jim



On Mon, Oct 6, 2014 at 4:34 PM, Neumann, Steffen 
wrote:

> Hi,
>
> sometimes I am forced to R CMD check packages on windows,
> and my problem is that both the system-wide library and
> the personal library with BiocStyle contain spaces, so that
> BiocStyle::latex() results in:
> \RequirePackage{C:/Program
> Files/R/R-3.1.0/library/BiocStyle/sty/Bioconductor}
>
> which causes MiKTeX to fail with
> ! LaTeX Error: File
> `C:/ProgramFiles/R/R-3.1.0/library/BiocStyle/sty/Bioconductor.sty' not
> found.
> (This is with BiocStyles-1.3.15)
>
> What is the recommended solution here ? Installing R to a non-standard
> location ?
> Use texlive instead of miktex (does that make a difference ?) Or something
> else ?
>
> Yours,
> Steffen
>
>
>
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] depends on packages providing classes

[James W. MacDonald]

I agree with Vince. It's your job as a package developer to make available
to your package all the functions necessary for the package to work. But I
am not sure it is your job to load all the packages that your end user
might need.

Best,

Jim



On Tue, Oct 28, 2014 at 11:04 AM, Vincent Carey 
wrote:

> On Tue, Oct 28, 2014 at 10:19 AM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> > What is the current best paradigm for using all the classes in
> > S4Vectors/GenomeInfoDb/GenomicRanges/IRanges
> >
> > I obviously import methods and classes from the relevant packages.
> >
> > But shouldn't I depend on these packages as well?  Since I basically want
> > the user to have this functionality at the command line? That is what I
> do
> > now.
> >
> >
> I've wondered about this as well.  It seems the principle is that the user
> should
> take care of attaching additional packages when needed.  It might be
> appropriate
> to give a hint in the package startup message, if having some other package
> attached
> would typically be of great utility.
>
> Given your list above, I would think that depending on GenomicRanges would
> often
> be sufficient, and IRanges/S4Vectors would not require dependency
> assertion.  I would
> think that GenomeInfoDb should be a voluntary attachment for a specific
> session.
>
> These are just my guesses -- I doubt there will be complete consensus, but
> I have
> started to think very critically about using Depends, and I think it is
> better when its
> use is minimized.
>
>
> > That of course leads to the R CMD check NOTE on depending on too many
> > packages I guess I should ignore that one.
> >
> > Best,
> > Kasper
> >
> > [[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
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] About Hg38 BSgenome

[James W. MacDonald]

Hi Raffaele,

See here:

http://bioconductor.org/packages/release/data/annotation/html/BSgenome.Hsapiens.NCBI.GRCh38.html

Best,

Jim



On Tue, Dec 2, 2014 at 9:10 AM, Raffaele Adolfo Calogero <
raffaele.calog...@unito.it> wrote:

> Dear Bioc Team,
> I am the maintainer of chimera package.
> Recently some of the users asked for the possibility to use chimera with
> fusions detected on hg38 human genome.
> I checked for the availability of hg38 as BSgenome but I did not find it in
> Bioc repository, as instead there is TxDb.Hsapiens.UCSC.hg38.knownGene. I
> would like to know if it is planned the release of hg38 as BSgenome, maybe
> in the next Bioc release.
> In case it is not planned could please suggest me what to read to build it?
> Cheers
> Raffaele
>
> --
> 
> Prof. Raffaele A. Calogero
> Bioinformatics and Genomics Unit
> MBC Centro di Biotecnologie Molecolari
> Via Nizza 52, Torino 10126
> Tel.   ++39 0116706457
> Fax++39 0112366457
> Mobile ++39 827080
> email: raffaele.calog...@unito.it
>raffaele.calog...@gmail.com
> www:   http://www.bioinformatica.unito.it
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Replacing deprecated org.Hs.egCHR and friends

[James W. MacDonald]

Hi Peter,

This isn't a devel question. Next time please ask this sort of thing on the
support site.

As for the message, it seems pretty clear to me. The org.Hs.eg.db package
doesn't have the chromosomal location data any more, but the relevant TxDb
package does have those data, in a much more useful format. The message
can't be any more explicit than that, as there is more than one TxDb
package for human.

You could have hypothetically gone to the annotation data page (
http://bioconductor.org/packages/release/BiocViews.html#___AnnotationData)
and searched for, say 'TxDb', in which case you would see three packages
with names like TxDb.Hsapiens.UCSC.hg19.knownGene. Which one you decide to
use is dependent on the build/source you care about.

And if you are completely unfamiliar with these packages, you need to read
the GenomicFeatures vignette.

Best,

Jim



On Tue, Jan 13, 2015 at 12:34 AM, Peter Langfelder <
peter.langfel...@gmail.com> wrote:

> Hi all,
>
> can anyone please explain or point me to an explanation of how to
> replace org.Hs.egCHR and friends that appear to be deprecated in the
> devel version? The deprecation message isn't very helpful. Thanks!
>
> x = org.Hs.egCHR
> Warning message:
> In (function ()  :
>   org.Hs.egCHR is deprecated. Please use an appropriate TxDb object or
>   package for this kind of data.
>
> sessionInfo()
>
> R Under development (unstable) (2014-11-24 r67057)
> 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=en_US.UTF-8   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  stats4stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
>  [1] org.Hs.eg.db_3.0.0RSQLite_1.0.0 DBI_0.3.1
>  [4] AnnotationDbi_1.29.12 GenomeInfoDb_1.3.12   IRanges_2.1.35
>  [7] S4Vectors_0.5.16  Biobase_2.27.1BiocGenerics_0.13.4
> [10] BiocInstaller_1.17.3
>
> loaded via a namespace (and not attached):
> [1] tools_3.2.0
>
> _______
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Documentation of GenomicRanges::follow etc. very hard to find

[James W. MacDonald]

I agree with Michael. In my opinion, the help pages for S4 methods are
painfully obscure, and expecting anybody (let alone a newbie) to figure out
that they need to do something like method?"follow,GenomicRanges,
GenomicRanges" in order to get the help page for a method is a high hurdle
indeed.

In fact, I can't remember the last time I actually tried to find a help
page for an S4 method. I much prefer traversing the methods tree using
showMethods(), and tracking down the method that will dispatch on whatever
object I have in hand, rather than trying to figure out what incredibly
unintuitive combination of names, quotes, question marks (and the required
order thereof) is required to get the help page.

Best,

Jim



On Wed, Feb 18, 2015 at 9:10 AM, Michael Lawrence  wrote:

> I guess this is really an argument for having _all_ method man pages be
> aliased with the symbol of the generic. I wonder if R should just be made
> smarter and bring up a menu whenever help is requested on a generic,
> listing all of the available methods, with the default method as the
> default selection.
>
> On Wed, Feb 18, 2015 at 8:38 AM, Philip Lijnzaad  >
> wrote:
>
> > On 02/18/2015 05:13 PM, Martin Morgan wrote:
> >
> >> On 02/18/2015 08:05 AM, Philip Lijnzaad wrote:
> >>
> >>>
> >>> Dear all,
> >>> looking up the documentation on functions like follow() and
> >>> precede() is
> >>> very hard, since they are only documented under the topic
> >>> "nearest-methods",
> >>> which currently (GenomicRanges package 1.18.4) can only be found
> >>> using the
> >>> ?? operator (and having found the name of the topic, most newbies
> >>> are still
> >>>
> >>
> >> FWIW
> >>
> >> > method?"follow
> >>
> >> shows
> >>
> >> ANY,SummarizedExperiment
> >> GenomicRanges,GenomicRanges
> >> GenomicRanges,missing
> >> SummarizedExperiment,ANY
> >> SummarizedExperiment,SummarizedExperiment
> >> Ranges,RangesORmissing
> >>
> >> suggesting, e.g.,
> >>
> >> > method?"follow,GenomicRanges,GenomicRanges"
> >>
> >>
> > Hi Martin, thanks for the feedback. To be honest, your solution involves
> > more typing, and is not newbie-friendly since the
> > newbie doesn't now anything about "methods". S/he simply types ?follow
> and
> > gets back an answer (from the IRanges docu),
> > and subsequently thing "oh well, follow() doesn't know about strands, and
> > then gets stuck). My request is simply to add the plain \alias{}es, i.e.
> > just like we have for findOverlaps and the methods described in
> > inter-range-methods.Rd. Or what would be the argument against that?
> >
> > Cheers,
> >
> >
> > Philip
> >
> > --
> > Philip Lijnzaad, PhD
> > Molecular Cancer Research
> > University Medical Center (UMC), Utrecht
> > Stratenum room 2.211
> > IM: plijnz...@jabber.org , philip.lijnz...@gmail.com
> > P.O. Box 85060, 3508 AB Utrecht
> > (Universiteitsweg 100, 3584 CG Utrecht)
> > The Netherlands
> > tel: +31 (0)8875 68464
> >
> > 
> > --
> >
> > De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> > uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> > ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
> > direct
> > te informeren door het bericht te retourneren. Het Universitair Medisch
> > Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de
> > W.H.W.
> > (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat
> geregistreerd
> > bij
> > de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
> >
> > Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
> >
> > 
> > --
> >
> > This message may contain confidential information and ...{{dropped:11}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] GEOquery Warnings When Reading SOFT File

[James W. MacDonald]

Hi Dario,

This isn't the right forum for your question (this listserv is for
development of packages, not questions about existing packages), so you
should ask on the support site.

Best,

Jim



On Thu, Feb 19, 2015 at 1:00 AM, Dario Strbenac 
wrote:

> library(GEOquery)
> gastricChina <- getGEO("GSE65801", GSEMatrix = FALSE)
>
> Generates warnings
>
> > head(warnings(), 1)
> Warning message:
> In readLines(con, n = chunksize) :
>   seek on a gzfile connection returned an internal error
>
> Does it affect the correctness of the imported data ?
>
> Also, experimentData(gastricChina) gives an empty result
>
> Experiment data
>   Experimenter name:
>   Laboratory:
>   Contact information:
>   Title:
>   URL:
>   PMIDs:
>   No abstract available.
>
> whereas some of the fields are filled in on the webpage.
>
> --
> Dario Strbenac
> PhD Student
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Warnings from ls() in AnnotationDbi

[James W. MacDonald]

A poster on the support site reported some warnings issued when running
hyperGTest() from GOstats. I tracked this down to the ls() function from
AnnotationDbi, when it dispatches on AnnDbBimap objects. The method is:

setMethod("ls", signature(name="Bimap"),
function(name, pos, envir, all.names, pattern){
if (!missing(pos))
  warning("ignoring 'pos' argument")
if (!missing(envir))
  warning("ignoring 'envir' argument")
if (!missing(all.names))
  warning("ignoring 'all.names' argument")
.ls(name, pos, envir, all.names, pattern)
}
)

And as noted, everything but 'name' is ignored in .ls().

This seemingly hasn't changed in years. In R-3.1.1 the method appears as

> showMethods(ls, class = "AnnDbBimap", includeDefs = T)
Function: ls (package base)
name="AnnDbBimap"
function (name, pos = -1L, envir = as.environment(pos), all.names = FALSE,
pattern)
{
if (!missing(pos))
warning("ignoring 'pos' argument")
if (!missing(envir))
warning("ignoring 'envir' argument")
if (!missing(all.names))
warning("ignoring 'all.names' argument")
.ls(name, pos, envir, all.names, pattern)
}

And now in R-3.2.0, the method appears as

> showMethods(ls, class = "Bimap", includeDefs = TRUE)
Function: ls (package base)
name="Bimap"
function (name, pos = -1L, envir = as.environment(pos), all.names = FALSE,
pattern, sorted = TRUE)
{
.local <- function (name, pos, envir, all.names, pattern)
{
if (!missing(pos))
warning("ignoring 'pos' argument")
if (!missing(envir))
warning("ignoring 'envir' argument")
if (!missing(all.names))
warning("ignoring 'all.names' argument")
.ls(name, pos, envir, all.names, pattern)
}
.local(name, pos, envir, all.names, pattern)
}

Where everything gets wrapped in a call to .local(). Prior to this, we
never saw the warnings, but now we do:

 z <- ls(annotate:::getAnnMap("BPPARENTS", chip = "GO"))
Warning messages:
1: In .local(name, pos, envir, all.names, pattern) :
  ignoring 'pos' argument
2: In .local(name, pos, envir, all.names, pattern) :
  ignoring 'envir' argument
3: In .local(name, pos, envir, all.names, pattern) :
  ignoring 'all.names' argument

This is going to be a consistent issue going forward, so should all those
warnings be stripped out of the method for ls() in AnnotationDbi?

Best,

Jim





-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Changes in AnnotationDbi

[James W. MacDonald]

In the last release, the warning message from select() telling people that
their results include one-to-many mappings was removed. While some may find
this warning annoying, I think silently returning something unexpected to
our users is dangerous.

In other words, for me it is a common practice to do something like this:

fit <- lmFit(eset, design)
fit2 <- eBayes(fit)
gns <- select(, featureNames(eset), c("ENTREZID","SYMBOL"))
gns <- gns[!duplicated(gns[,1]),]
fit2$genes <- gns

I add in the step where dups are removed because I already know they are
there. But a naive user might instead do

fit2$genes <- select(, featureNames(eset),
c("ENTREZID","SYMBOL"))

Which will work just fine, but then all the annotation (except for the
first few lines) will now be completely incorrect, and there wasn't a
warning to let the end user know that they may have made a mistake.

lmFit() will parse the featureData slot of an ExpressionSet and use those
data for annotation, so that gives some hypothetical protections, for those
who first put their annotation data into their ExpressionSet. However,
?eSet says:

 ‘featureData’: Contains variables describing features (i.e., rows
  in ‘assayData’) unique to this experiment. Use the
  ‘annotation’ slot to efficiently reference feature data
  common to the annotation package used in the experiment.
  Class: ‘AnnotatedDataFrame-class’

Which to me indicates that the featureData slot isn't really intended to
contain annotation data, but instead some unique information that pertains
to a given experiment. But maybe I misunderstand.

Is the featureData slot actually intended for annotation data? If not, what
is the intended pipeline for annotating data in an ExpressionSet? Am I
alone in being concerned about this?

Best,

Jim


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Changes in AnnotationDbi

[James W. MacDonald]

I agree that a warning is probably not the way to go, as it does imply that
there might have been something wrong with either the input or output.
Plus, not everybody understands the distinction between error and warning.

And having additional documentation can't possibly hurt. But that assumes
that most/some/all of the end users both peruse and understand the
documentation, which we all know is not the case. The main issue, for me at
least, is that a significant proportion of people seem to think there is
some sort of uniqueness imposed on things like Entrez Gene IDs and Hugo
symbols, etc. While that is the ultimate goal, we do not have and maybe
never will achieve unique IDs for each annotatable object.

I used to work for a PI who was a very smart, well informed statistical
geneticist who was absolutely shocked when I informed her that a) there are
SNPs in dbSNP that have more than one RS ID, and that b.) there are RS IDs
in dbSNP that have been assigned to multiple SNPs. She just assumed that
there was a one-to-one RS ID -> SNP mapping.

So this is to me the crux of the problem. It is perfectly valid to return
one-to-many mappings, and that is what should be expected *by those of us
who already understand such things. *But for those of us who are ignorant
of the details, and those who assume uniqueness of IDs, it would be really
nice if they got a message telling them something like

*Please note that there are one-to-many mappings between the input and
output IDs, so the output is longer than your input vector. Please see
?select for more detail.*

And if the message is objectionable to some, you could give the option for
people to set a global flag to shut it off. Something like

if(!pleaseMakeItStop)
  message()

and they could set

pleaseMakeItStop = TRUE in their .Rprofile

Is that a reasonable compromise?

Jim



On Thu, Jun 4, 2015 at 6:06 PM, Marc Carlson  wrote:

> Hi Jim,
>
> I do agree that the warning was protective for that (this is why I put it
> there).
>
> But it was also annoying for many and a source of some confusion because
> when people see a warning() they think that something has gone wrong with
> the code that was just run.  And in this case the select method was
> actually doing exactly what it was supposed to be doing.  What it was
> actually warning you about was what you did separately in that assignment
> to fit2...  Which is the step right after the select method already did
> it's work.  And I can understand why that seems a little bit confusing
> since you are basically telling someone to be careful with the data you
> just gave them.
>
> Now I could replace it with a message() I guess, but in cases like this
> where the warning is about something that happens outside of the function
> you are calling, shouldn't that probably be handled by documentation?  Or
> at least, that is the argument that finally persuaded me to remove it.
> That and that fact that almost every call to select() ended up accompanied
> by the warning you mentioned, because it turns out that perfect 1:1
> relationships are pretty rare for annotation data.  Very often, you are
> going to get back multiple results.
>
> But I didn't just remove the warning, I also supplied an alternative for
> people who have a real need for consistent 1:1 mapping.
>
> The mapIds() method takes most of the same arguments as select, except
> that unlike select(), it only looks up one column and it always returns a
> vector that is the same size as the vector that came in.
>
> So for your example, you could do something like this psuedocode here:
>
> mapIds(, featureNames(eset), column="ENTREZID",
> keytype="PROBEID")
>
> And mapIds will follow a rule specified by the default value for the
> multiVals argument so that you can get back your results in a 1:1 manner.
> And if you don't like any of the options available for the multiVals
> argument, you can make your own function and pass it in.
>
>
> Anyhow please continue to let us know what you think?
>
>
>  Marc
>
>
>
>
>
>
>
> On 06/04/2015 10:50 AM, James W. MacDonald wrote:
>
>> In the last release, the warning message from select() telling people that
>> their results include one-to-many mappings was removed. While some may
>> find
>> this warning annoying, I think silently returning something unexpected to
>> our users is dangerous.
>>
>> In other words, for me it is a common practice to do something like this:
>>
>> fit <- lmFit(eset, design)
>> fit2 <- eBayes(fit)
>> gns <- select(, featureNames(eset), c("ENTREZID","SYMBOL"))
>> gns <- gns[!duplicated(gns[,1]),]
>> fit2$genes <- gns
>>
>> I add in the step where dups are removed

Re: [Bioc-devel] Changes in AnnotationDbi

[James W. MacDonald]

Thanks Marc!

On Mon, Jun 8, 2015 at 3:12 PM, Marc Carlson  wrote:

>  OK Jim,
>
> I will put very simple messages in (one liners) that will simply state
> whether the relationship between keys and the requested columns was 1:1,
> 1:many, many:1, or many:many.   Hopefully this will represent an acceptable
> compromise.
>
>  Marc
>
>
>
> On 06/05/2015 08:37 AM, James W. MacDonald wrote:
>
> I agree that a warning is probably not the way to go, as it does imply
> that there might have been something wrong with either the input or output.
> Plus, not everybody understands the distinction between error and warning.
>
>  And having additional documentation can't possibly hurt. But that
> assumes that most/some/all of the end users both peruse and understand the
> documentation, which we all know is not the case. The main issue, for me at
> least, is that a significant proportion of people seem to think there is
> some sort of uniqueness imposed on things like Entrez Gene IDs and Hugo
> symbols, etc. While that is the ultimate goal, we do not have and maybe
> never will achieve unique IDs for each annotatable object.
>
>  I used to work for a PI who was a very smart, well informed statistical
> geneticist who was absolutely shocked when I informed her that a) there are
> SNPs in dbSNP that have more than one RS ID, and that b.) there are RS IDs
> in dbSNP that have been assigned to multiple SNPs. She just assumed that
> there was a one-to-one RS ID -> SNP mapping.
>
>  So this is to me the crux of the problem. It is perfectly valid to
> return one-to-many mappings, and that is what should be expected *by
> those of us who already understand such things. *But for those of us who
> are ignorant of the details, and those who assume uniqueness of IDs, it
> would be really nice if they got a message telling them something like
>
>  *Please note that there are one-to-many mappings between the input and
> output IDs, so the output is longer than your input vector. Please see
> ?select for more detail.*
>
>  And if the message is objectionable to some, you could give the option
> for people to set a global flag to shut it off. Something like
>
>  if(!pleaseMakeItStop)
>   message()
>
>  and they could set
>
>  pleaseMakeItStop = TRUE in their .Rprofile
>
>  Is that a reasonable compromise?
>
>  Jim
>
>
>
> On Thu, Jun 4, 2015 at 6:06 PM, Marc Carlson 
> wrote:
>
>> Hi Jim,
>>
>> I do agree that the warning was protective for that (this is why I put it
>> there).
>>
>> But it was also annoying for many and a source of some confusion because
>> when people see a warning() they think that something has gone wrong with
>> the code that was just run.  And in this case the select method was
>> actually doing exactly what it was supposed to be doing.  What it was
>> actually warning you about was what you did separately in that assignment
>> to fit2...  Which is the step right after the select method already did
>> it's work.  And I can understand why that seems a little bit confusing
>> since you are basically telling someone to be careful with the data you
>> just gave them.
>>
>> Now I could replace it with a message() I guess, but in cases like this
>> where the warning is about something that happens outside of the function
>> you are calling, shouldn't that probably be handled by documentation?  Or
>> at least, that is the argument that finally persuaded me to remove it.
>> That and that fact that almost every call to select() ended up accompanied
>> by the warning you mentioned, because it turns out that perfect 1:1
>> relationships are pretty rare for annotation data.  Very often, you are
>> going to get back multiple results.
>>
>> But I didn't just remove the warning, I also supplied an alternative for
>> people who have a real need for consistent 1:1 mapping.
>>
>> The mapIds() method takes most of the same arguments as select, except
>> that unlike select(), it only looks up one column and it always returns a
>> vector that is the same size as the vector that came in.
>>
>> So for your example, you could do something like this psuedocode here:
>>
>> mapIds(, featureNames(eset), column="ENTREZID",
>> keytype="PROBEID")
>>
>> And mapIds will follow a rule specified by the default value for the
>> multiVals argument so that you can get back your results in a 1:1 manner.
>> And if you don't like any of the options available for the multiVals
>> argument, you can make your own function and pass it in.
>>
>>
>> Anyhow please continue to 

Re: [Bioc-devel] Changes in AnnotationDbi

[James W. MacDonald]

As select() works currently, the returned keys are in identical order as
the input, with extra rows inserted as needed. And any one-to-nothing
mapping results in a NA returned. So by definition my (admittedly naive)
method is guaranteed to work. But your point is well taken - match() is
safer. But my point isn't to say how people should deal with duplicates,
and I didn't intend for my example to be an example of what anybody should
do. Instead, I object to the idea that we would silently return something
that the average user might not expect, without some indication to alert
the user.

Anyway, the issue is much more complicated than you seem to realize. If you
ask for more than one thing to be returned (e.g., ENTREZID and SYMBOL), if
either has duplicates, you get multiple rows returned. So if there is a
single Entrez Gene ID, but multiple symbols, which symbol do you choose?
Which is the 'preferred' symbol? For that matter, which is the 'preferred'
Entrez Gene ID? Are there duplicates because NCBI hasn't yet discontinued
some duplicates that point to the same thing, or are there duplicates
because a given reporter is measuring multiple highly similar genes?

We have long insisted that the annotation packages we provide are 'as is',
and that we are not the arbiters of correctness. We simply give end users
the ability to easily get available data from within R. I would argue that
we should maintain that stance. I am not particularly enthused with any
filtering we might do, as I don't think we have the time or personnel
required to do it well. We should leave it to the manufacturer of the array
and the people at NCBI and Ensembl to do that part. And it should be up to
the end user to figure which ID is the 'preferred' one. As a simple example:

> z <- mapIds(hugene20sttranscriptcluster.db,
keys(hugene20sttranscriptcluster.db), "ENTREZID", "PROBEID", multiVals =
"CharacterList")

> head(z[sapply(z, length) > 1])
CharacterList of length 6
[["16657436"]] 100287102 100288486 100287029 84771 100287596
[["16657440"]] 100422919 100422834 100422831 100302278
[["16657450"]] 729737 101929819 441124 100132062 101059936
[["16657473"]] 81399 729759 26683 441308
[["16657910"]] 8511 8510
[["16658119"]] 284630 100287898

If we now go to NCBI and look at the five IDs for the first gene, they are
all current, and map to DDX11L1, DDX11L9, DDX11L10, DDX11L2, and DDX11L5.
We can certainly choose the first one (and that is what I do for my
collaborators, in general), but is that the right thing to do? If so, why?

Best,

Jim



On Tue, Jun 9, 2015 at 5:52 AM, Simon Anders  wrote:

> Hi
>
> My two cents:
>
> On 04/06/15 19:50, James W. MacDonald wrote:
>
>> In other words, for me it is a common practice to do something like this:
>>
>> fit <- lmFit(eset, design)
>> fit2 <- eBayes(fit)
>> gns <- select(, featureNames(eset), c("ENTREZID","SYMBOL"))
>> gns <- gns[!duplicated(gns[,1]),]
>> fit2$genes <- gns
>>
>> I add in the step where dups are removed because I already know they are
>> there. But a naive user might instead do
>>
>> fit2$genes <- select(, featureNames(eset),
>> c("ENTREZID","SYMBOL"))
>>
>
> I'm not even that happy with James' first solution, as it relies on the
> order being correct after removing the duplicates. I'd feel safer to use
> 'match' to ensure that. (What if an EntrezId is not found in the Annotation
> DB? Will we have a line with NA, or is the line simply missing? The latter
> would break James' code.)
>
> What users really want here is a way to get the "preferred" symbol for an
> entrezId, and for lack of this, they accept simply a random one or the
> first one (in some unspecified collation). So, we should have a function,
> maybe 'select1', to select one and only one hit for each query value.
>
>   select1(x, keys, columns, keytype, requireUnique=FALSE, ... )
>
> This would query the AnnotationDbi object 'x' as does 'select', but return
> a data frame with the columns specified in 'columns', and the vector that
> was passed as 'keys' as row names, thus guaranteeing that each line in the
> data frame corresponds to one query key. If there were multiple records for
> a key, the first one is used, unless 'requireUnique' is set, in which case
> an error is issued. And if no record is present for a key, the data frame
> contains a row of NAs for this key.
>
> This would be quite convenient for any kind of ID conversion issues.
>
>   Simon
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Removed packages and package landing pages

[James W. MacDonald]

Hi Sean,

For your first question, you can always look at the release announcement,
all the way at the bottom: http://bioconductor.org/news/bioc_3_1_release/.
That's a bit hands-on, as you sometimes have to go back several releases to
see when it got removed, so hopefully Dan has a more reasonable approach.

Jim



On Thu, Aug 6, 2015 at 6:35 AM, Sean Davis  wrote:

> Hi, Dan.
>
> A user asked me a question about the DnaseR package.  It appears to have
> been removed from Bioc?  Where would I find that out?  What is the behavior
> of the release/devel pages if a package has been previously removed?
>
> Thanks,
> Sean
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] IPI numbers in annotation packages

[James W. MacDonald]

I am building the annotation db0 packages for the upcoming Bioconductor
release, which are used to generate all the orgDb and chip annotation
packages that we distribute. Up to the previous release we have always
included IPI identifiers (as part of the table containing the PROSITE and
PFAM IDs). Unfortunately, IPI <https://www.ebi.ac.uk/IPI> is no longer
maintained (since 2011), and UniProt, which is where we got data for the
last few releases, has now dropped support as well.

Given that this annotation source is no longer maintained, I decided to
exclude these IDs from the current build of the following db0 packages:

   - rat.db0
   - chicken.db0
   - zebrafish.db0
   - mouse.db0
   - bovine.db0
   - human.db0

In addition, it is not clear to me (nor can Marc recall) where the data for
PFAM in the yeast.db0 package comes from. Given that we are pretty far
behind schedule for these packages, I have excluded that table as well.

If this will break anybody's package, or if there are people who rely on
these IDs, I can just parse out of the last release and deprecate, so you
will have the IDs for one more release. However, if nobody cares about such
things, I will just go with what we have. Please speak up if this will
affect you.

-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] IPI numbers in annotation packages

[James W. MacDonald]

Hi Marc,

That script has this in it:

## For now just get data for the ones that we have traditionally supported
## I don't even know if the other species are available...
speciesList = c("chipsrc_human.sqlite",
  "chipsrc_rat.sqlite",
  "chipsrc_chicken.sqlite",
  "chipsrc_zebrafish.sqlite",
  #  "chipsrc_worm.sqlite",
  #  "chipsrc_fly.sqlite",
  "chipsrc_mouse.sqlite",
  "chipsrc_bovine.sqlite"
  #  "chipsrc_arabidopsis.sqlite"  ## this is available and could be
"activated"
  ## But to activate arabidopsis, remember you have to pre-add the tables...
  #  "chipsrc_canine.sqlite",
  #  "chipsrc_rhesus.sqlite",
  #  "chipsrc_chimp.sqlite",
  #  "chipsrc_anopheles.sqlite"
  )

And there is no mention of yeast anywhere. If I search all the scripts for
say 'INSERT INTO pfam', I get

custom_anno/script/bindb.sql
328:INSERT INTO pfam

pfam/script/srcdb_pfam.sql
202:-- INSERT INTO pfamb

organism_annotation/script/bindb_yeast.sql
441:-- INSERT INTO pfam

yeast/script/bindb.sql
241:-- INSERT INTO pfam

The first one is just doing all the metadata tables, and the other three
are in code blocks that are commented out. Is it possible that you used a
script that didn't make it into svn?

Jim



On Sun, Oct 4, 2015 at 2:36 PM, Marc Carlson  wrote:

> Hi Jim,
>
> You asked me on Friday where the PFAM Ids for yeast came from and I
> couldn't recall because at the moment I was at Seattle Childrens (and thus
> nowhere near my copy of my source code).  But I also said I would look into
> it for you later (and I have).  Here is what my code tells me:  So ever
> since IPI shut down, we have been getting the PFAM and IPI data from
> UniProt.  There is a script in the UniProt.ws package
> called processDataForBuild.R that is supposed to be called by the script
> "src_build.sh" (it's the last thing that script does).  That code should
> get the pfam data from yeast for you.  Please note that yeast required a
> lot of special code to get it processed.  Nothing with yeast annotations is
> ever easy.  It's like karmic accounting to compensate for all the bread and
> beer.  ;)
>
> Let me know if you need any more explanations about what is in there.
> Because of the crazy timing, before I left I build I pushed into devel a
> fresh set of .DB0s and core packages (in late August) just in case it was
> too crazy to do a refresh right now.  But it sounds like you won't need
> that.
>
>
>   Marc
>
>
>
> On Sun, Oct 4, 2015 at 6:27 AM, James W. MacDonald  wrote:
>
>> I am building the annotation db0 packages for the upcoming Bioconductor
>> release, which are used to generate all the orgDb and chip annotation
>> packages that we distribute. Up to the previous release we have always
>> included IPI identifiers (as part of the table containing the PROSITE and
>> PFAM IDs). Unfortunately, IPI <https://www.ebi.ac.uk/IPI> is no longer
>> maintained (since 2011), and UniProt, which is where we got data for the
>> last few releases, has now dropped support as well.
>>
>> Given that this annotation source is no longer maintained, I decided to
>> exclude these IDs from the current build of the following db0 packages:
>>
>>- rat.db0
>>- chicken.db0
>>- zebrafish.db0
>>- mouse.db0
>>- bovine.db0
>>- human.db0
>>
>> In addition, it is not clear to me (nor can Marc recall) where the data
>> for
>> PFAM in the yeast.db0 package comes from. Given that we are pretty far
>> behind schedule for these packages, I have excluded that table as well.
>>
>> If this will break anybody's package, or if there are people who rely on
>> these IDs, I can just parse out of the last release and deprecate, so you
>> will have the IDs for one more release. However, if nobody cares about
>> such
>> things, I will just go with what we have. Please speak up if this will
>> affect you.
>>
>> --
>> James W. MacDonald, M.S.
>> Biostatistician
>> University of Washington
>> Environmental and Occupational Health Sciences
>> 4225 Roosevelt Way NE, # 100
>> Seattle WA 98105-6099
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] IPI numbers in annotation packages

[James W. MacDonald]

Ah. That's the problem. The script in getdb.sh has

R --slave <
/home/ubuntu/cpb_anno/AnnotationBuildPipeline/annosrc/uniprot/script/
uniprot.ws/inst/script/processDataForBuild.R

which is a modification of what is in svn (to match the directory structure
of the AMI), which calls on a script in a local version of the UniProt.ws
package. The local version doesn't have any code for yeast, but the 'real'
version (UniProt.ws) does. I assumed the local version was special, and
that I should be using that because you were specifically using that one
rather than an actually installed package.

annosrc$ grep -i yeast uniprot/script/
uniprot.ws/inst/script/processDataForBuild.R
annosrc$
annosrc$ grep -i yeast
~/R/x86_64-pc-linux-gnu-library/3.2/UniProt.ws/script/processDataForBuild.R
## Now for special treatment for missing stuff from yeast.
getYeastData <- function(dbFile, db){
doYeastInserts <- function(db, table, data){
## just one more run through to just do what is needed to get pfam into
yeast.
species <- 'chipsrc_yeast.sqlite'
res <- getYeastData(species, db)
doYeastInserts(db, "pfam", res[["pfam"]])
doYeastInserts(db, "smart", res[["smart"]])


Thanks!

Jim



On Mon, Oct 5, 2015 at 10:16 AM, Marc Carlson  wrote:

> You need to scroll down that script a ways...  Look for 'yeast'.
>
> On Mon, Oct 5, 2015 at 6:11 AM, James W. MacDonald  wrote:
>
>> Hi Marc,
>>
>> That script has this in it:
>>
>> ## For now just get data for the ones that we have traditionally supported
>> ## I don't even know if the other species are available...
>> speciesList = c("chipsrc_human.sqlite",
>>   "chipsrc_rat.sqlite",
>>   "chipsrc_chicken.sqlite",
>>   "chipsrc_zebrafish.sqlite",
>>   #  "chipsrc_worm.sqlite",
>>   #  "chipsrc_fly.sqlite",
>>   "chipsrc_mouse.sqlite",
>>   "chipsrc_bovine.sqlite"
>>   #  "chipsrc_arabidopsis.sqlite"  ## this is available and could be
>> "activated"
>>   ## But to activate arabidopsis, remember you have to pre-add the
>> tables...
>>   #  "chipsrc_canine.sqlite",
>>   #  "chipsrc_rhesus.sqlite",
>>   #  "chipsrc_chimp.sqlite",
>>   #  "chipsrc_anopheles.sqlite"
>>   )
>>
>> And there is no mention of yeast anywhere. If I search all the scripts
>> for say 'INSERT INTO pfam', I get
>>
>> custom_anno/script/bindb.sql
>> 328:INSERT INTO pfam
>>
>> pfam/script/srcdb_pfam.sql
>> 202:-- INSERT INTO pfamb
>>
>> organism_annotation/script/bindb_yeast.sql
>> 441:-- INSERT INTO pfam
>>
>> yeast/script/bindb.sql
>> 241:-- INSERT INTO pfam
>>
>> The first one is just doing all the metadata tables, and the other three
>> are in code blocks that are commented out. Is it possible that you used a
>> script that didn't make it into svn?
>>
>> Jim
>>
>>
>>
>> On Sun, Oct 4, 2015 at 2:36 PM, Marc Carlson  wrote:
>>
>>> Hi Jim,
>>>
>>> You asked me on Friday where the PFAM Ids for yeast came from and I
>>> couldn't recall because at the moment I was at Seattle Childrens (and thus
>>> nowhere near my copy of my source code).  But I also said I would look into
>>> it for you later (and I have).  Here is what my code tells me:  So ever
>>> since IPI shut down, we have been getting the PFAM and IPI data from
>>> UniProt.  There is a script in the UniProt.ws package
>>> called processDataForBuild.R that is supposed to be called by the script
>>> "src_build.sh" (it's the last thing that script does).  That code should
>>> get the pfam data from yeast for you.  Please note that yeast required a
>>> lot of special code to get it processed.  Nothing with yeast annotations is
>>> ever easy.  It's like karmic accounting to compensate for all the bread and
>>> beer.  ;)
>>>
>>> Let me know if you need any more explanations about what is in there.
>>> Because of the crazy timing, before I left I build I pushed into devel a
>>> fresh set of .DB0s and core packages (in late August) just in case it was
>>> too crazy to do a refresh right now.  But it sounds like you won't need
>>> that.
>>>
>>>
>>>   Marc
>>>
>>>
>>>
>>> On Sun, Oct 4, 2015 at 6:27 AM, James W. MacDonald 
>>> wrote:
>>>
>>>> I am building the annotation db0 packages for the upcoming Bioconductor
>>>> re

Re: [Bioc-devel] Accepting an answer on the support website

[James W. MacDonald]

The OP needs to accept your answer.

On Tue, Oct 20, 2015 at 10:14 AM, Kevin Rue-Albrecht <
kevin@ucdconnect.ie> wrote:

> Dear all,
>
> Being on the developer side of things, I have resolved two items related to
> my package on the support website, and I would like to know how my answer
> could be marked as "accepted", so that it shows in the corresponding badge
> on my package web page.
>
> Kind regards
> Kevin
>
> --
> Kévin RUE-ALBRECHT
> Wellcome Trust Computational Infection Biology PhD Programme
> University College Dublin
> Ireland
> http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel




-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Accepting an answer on the support website

[James W. MacDonald]

Yes. The original poster 'owns' their post, and they AFAIK are the only one
who can accept an answer.

On Tue, Oct 20, 2015 at 11:34 AM, Kevin Rue-Albrecht <
kevin@ucdconnect.ie> wrote:

> "Original Post(er)" I assume?
>
>
>
> On 20 October 2015 at 16:15, James W. MacDonald  wrote:
>
>> The OP needs to accept your answer.
>>
>> On Tue, Oct 20, 2015 at 10:14 AM, Kevin Rue-Albrecht <
>> kevin@ucdconnect.ie> wrote:
>>
>>> Dear all,
>>>
>>> Being on the developer side of things, I have resolved two items related
>>> to
>>> my package on the support website, and I would like to know how my answer
>>> could be marked as "accepted", so that it shows in the corresponding
>>> badge
>>> on my package web page.
>>>
>>> Kind regards
>>> Kevin
>>>
>>> --
>>> Kévin RUE-ALBRECHT
>>> Wellcome Trust Computational Infection Biology PhD Programme
>>> University College Dublin
>>> Ireland
>>> http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>>
>>
>> --
>> James W. MacDonald, M.S.
>> Biostatistician
>> University of Washington
>> Environmental and Occupational Health Sciences
>> 4225 Roosevelt Way NE, # 100
>> Seattle WA 98105-6099
>>
>
>
>
> --
> Kévin RUE-ALBRECHT
> Wellcome Trust Computational Infection Biology PhD Programme
> University College Dublin
> Ireland
> http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Access check.log file after error

[James W. MacDonald]

As I already told you on the support site, everything you need to know is
in the Command output (the 00check.log is the same output) found by
clicking on the Error for each build machine. For Moscato, you have:

Warning: replacing previous import by 'data.table::melt' when loading
'MSstats'
Error in library.dynam(lib, package, package.lib) :
  DLL 'mzR' not found: maybe not installed for this architecture?

Error: processing vignette 'SWATH2stats_vignette.Rnw' failed with
diagnostics:
 chunk 33
Error : package or namespace load failed for 'MSstats'

That seems pretty clear to me - MStats appears not to be installed, maybe
because mzR isn't installed either? Anyway, neither one is really your
problem.

For Zin2 (linux) the Command output says

  Running ‘test-all.R’ [6s/6s]
 ERROR
Running the tests in ‘tests/test-all.R’ failed.
Last 13 lines of output:
  7: with_sink(temp, withCallingHandlers(withVisible(code), warning =
wHandler, message = mHandler))
  8: withCallingHandlers(withVisible(code), warning = wHandler, message =
mHandler)
  9: withVisible(code)
  10: disaggregate(data.max.test2)
  11: stop(paste("The number of transitions annotated and measured do not
match in the following transitions:\n",
 paste(unlist(n.transitions[n.transitions2 != n.transitions4]),
collapse = ", ")))

  testthat results

  OK: 46 SKIPPED: 0 FAILED: 1
  1. Error: data conversion

Which says to me 'I tried to run all 46 of your unit tests, and bombed out
on the first one'.



On Wed, Nov 11, 2015 at 10:38 AM, Blattmann Peter <
blattm...@imsb.biol.ethz.ch> wrote:

> Dear all,
>
> I am maintaining the R package SWATH2stats and I received an error after
> having added a new test and committed it to the devel branch. As I cannot
> reproduce the error on my own computer I wanted to have a look at the error
> log that exists from the CHECK report on the Bioconductor devel branch.
>
> So my question is how do I access the error log file? I don't mean the
> html website that is produced but it says at the end that there is further
> details in:
> '/Users/biocbuild/bbs-3.3-bioc/meat/SWATH2stats.Rcheck/00check.log' and I
> don't know where to find this "00check.log" file?
>
> Thanks for the help.
>
> Peter
>
> __
>
> ETH Zurich
> Dr. Peter Blattmann
> Institute of Molecular Systems Biology
> Aebersold group
> HPT E58
> Auguste-Piccard-Hof 1
> 8093 Zurich
> Switzerland
>
> phone: +41 44 633 0473
> cellphone: +41 79 745 8061
> fax: +41 44 633 1532
> e-mail: blattm...@imsb.biol.ethz.ch<mailto:blattm...@imsb.biol.ethz.ch>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Behavior of select function in AnnotationDbi

[James W. MacDonald]

There is an inconsistency in how select() works in AnnotationDbi when a
user passes in duplicated keys to be mapped, depending on if the mapping is
1:1 or 1:many. It's easiest to show using an example.

> select(org.Hs.eg.db, rep("1", 3), "SYMBOL")
'select()' returned many:1 mapping between keys and columns
  ENTREZID SYMBOL
11   A1BG
21   A1BG
31   A1BG

> select(org.Hs.eg.db, rep("1", 3), "GO")
'select()' returned many:many mapping between keys and columns
  ENTREZID GO EVIDENCE ONTOLOGY
11 GO:0003674   ND   MF
21 GO:0003674   ND   MF
31 GO:0003674   ND   MF

This is obviously a bug. A single query for that ID results in this:

> select(org.Hs.eg.db, "1", "GO")
'select()' returned 1:many mapping between keys and columns
  ENTREZID GO EVIDENCE ONTOLOGY
11 GO:0003674   ND   MF
21 GO:0005576  IDA   CC
31 GO:0005615  IDA   CC
41 GO:0008150   ND   BP
51 GO:0070062  IDA   CC
61 GO:0072562  IDA   CC

So the returned results are completely borked.

However, the question I have is what should be returned? To be consistent
with the first example, it should be the output expected for a single key,
repeated three times, which I have patched AnnotationDbi to do:

> select(org.Hs.eg.db, rep("1", 3), "GO")
'select()' returned many:many mapping between keys and columns
   ENTREZID GO EVIDENCE ONTOLOGY
1 1 GO:0003674   ND   MF
2 1 GO:0005576  IDA   CC
3 1 GO:0005615  IDA   CC
4 1 GO:0008150   ND   BP
5 1 GO:0070062  IDA   CC
6 1 GO:0072562  IDA   CC
7 1 GO:0003674   ND   MF
8 1 GO:0005576  IDA   CC
9 1 GO:0005615  IDA   CC
101 GO:0008150   ND   BP
111 GO:0070062  IDA   CC
121 GO:0072562  IDA   CC
131 GO:0003674   ND   MF
141 GO:0005576  IDA   CC
151 GO:0005615  IDA   CC
161 GO:0008150   ND   BP
171 GO:0070062  IDA   CC
181 GO:0072562  IDA   CC

So, two questions.


   1. Should duplicate keys be allowed, or should duplicates be removed
   before querying the database, preferably with a message saying that dups
   were removed?
   2. If the answer to #1 is yes, then to be consistent, I will just commit
   the patch I have made to both devel and release.

Best,

Jim



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Behavior of select function in AnnotationDbi

[James W. MacDonald]

Hi Hervé,

I think you make a valid point, but I am not sure it conforms to either the
historical expectations for the annotation packages, nor the expected use
case. In other words, the annotation packages have, since the beginning,
returned something that was as close to parallel to the input as possible.
This started with the env-based packages, where e.g., mget() returned
things parallel to the input, rather than randomly, as the SQL model would
have done. This was actually true for biomaRt back in the day when you
could use either the MySQL or CURL interfaces. The SQL interface returned
something parallel to input, and it was a bit of a change when Steffen went
to just using the CURL interface, and people had to learn to add the query
key into the return in order to re-sort.

So from a historical perspective it would be a real change to go from
returning something as close to parallel to the input to a SQL type model.
I agree that makes sense for those who are versed in SQL, but if we were
really trying to help people familiar with SQL, we would just be giving
them the RSQLite DB and telling them to have at it, no? The whole rationale
behind wrapping the DB in a package is to shield the end user from having
to understand SQL, which includes knowing that SQL doesn't enforce the
order of the returned data.

>From a use case perspective, the only use case that I am familiar with is
the one where people have a rectangular array of data, where the rows are
genes or whatnot, and they want to append additional columns to the array,
where the added columns conform to the existing array. This is not always
possible to do in the case of 1:many mappings, obviously, but that is what
mapIds() is for - there is an implicit contract there that you can input a
set of keys, and get out an ordered result that you can then tack onto the
side of your array of data and go forward. I think that is a really useful
thing to be able to do. It is obviously quite easy to take two matrices
that are ordered differently, reorder one, and then bind together. But if
you don't have to do that, then it's an improvement, and quite helpful for
naive users who might not have considered that the returned result might
not actually be parallel to their input.

And being the one who convinced Marc to put the warnings back in, I will
have to respectively disagree about whether or not it is useful to emit the
warnings. Well, I agree it isn't useful at all for those of us who already
know that the results might not be parallel. But that isn't the reason for
a warning is it? To warn those who already understand what is going on? My
argument is (and was) that a warning is intended to tell people that
something that they *might not have expected* just happened. I don't think
it is unreasonable to think that a significant proportion of naive end
users would get tripped up by that if the warning weren't there. They still
might be, but at least we gave them a chance.

Anyway, it took like three lines of code to make it work consistently for
many:many mappings, so that's what I did.

Best,

Jim



On Fri, Nov 20, 2015 at 6:32 PM, Hervé Pagès  wrote:

> On 11/20/2015 03:21 PM, Hervé Pagès wrote:
>
>> Hi Jim,
>>
>> I think we should choose the biomaRt model, that is, duplicated are
>> allowed but silently ignored.
>>
>> Note that this is also the SQL model. When you do
>>
>>SELECT * FROM ... WHERE key IN c('key1', 'key2', ...)
>>
> ^
> I meant:
>
>  SELECT * FROM ... WHERE key IN ('key1', 'key2', ...)
>
> No c() (too much R lately...)
>
> H.
>
>
>
>> duplicated keys don't generate duplicates in the output.
>>
>> Also note that, like SELECT, even if the keys supplied to
>> biomaRt::getBM() (via the 'values' arg) don't contain duplicates
>> and if all the mappings are 1-to-1, biomaRt::getBM() is not
>> guarantee to preserve order.
>>
>> Generally speaking having duplicates in the input produce duplicates
>> in the output is useful in vectorized operations when the output
>> is expected to be parallel to the input. Vectorized operations also
>> need to propagate NAs and to preserve order. However, like SELECT
>> and biomaRt::getBM(), select() cannot produce an output that is
>> parallel to the input *in general*.
>>
>> It seems that the current philosophy for select() is to emit a note
>> or a warning every time the output is not parallel to the input.
>> Personally I find this too noisy and not that useful.
>>
>> Thanks,
>> H.
>>
>>
>> On 11/20/2015 02:30 PM, James W. MacDonald wrote:
>>
>>> There is an inconsistency in how select() works in AnnotationDbi when a
&g

Re: [Bioc-devel] Behavior of select function in AnnotationDbi

[James W. MacDonald]

-level select() is still extremely useful and adds a lot of value
> over letting the users write their own SQL queries. It is the same
> level of usefulness that biomaRt::getBM() adds for querying Ensembl
> (compared to typing SQL queries in an MySQL client to query the Ensembl
> MySQL db). With biomaRt::getBM() and with this low-level select(), you
> don't need to know any SQL. All you need to know is that the output
> is not guaranteed to be parallel to the input.
>
> Another approach is the exact opposite one: make select() reliable for
> the mapping/cbinding use case i.e. make it produce an output that is
> always parallel to the input by default. That means it would also need
> a mechanism to resolve ambiguous mappings like mapIds() does (e.g.
> via a 'multiVals' argument).
>
> Right now select() sits in the middle of these 2 approaches.
>
> If select()'s behavior cannot be changed, maybe we can try to make it
> a little less noisy i.e. have warnings (and not messages) only when
> the output is not parallel to the input. Also how about having a
> warning that suggests the use of mapIds()? Something like "Hey, your
> output is not parallel to your input! Use mapIds() if that matters
> to you."
>
> Thanks,
> H.
>
>
>
> On 11/21/2015 08:28 AM, James W. MacDonald wrote:
>
>> Hi Hervé,
>>
>> I think you make a valid point, but I am not sure it conforms to either
>> the historical expectations for the annotation packages, nor the
>> expected use case. In other words, the annotation packages have, since
>> the beginning, returned something that was as close to parallel to the
>> input as possible. This started with the env-based packages, where e.g.,
>> mget() returned things parallel to the input, rather than randomly, as
>> the SQL model would have done. This was actually true for biomaRt back
>> in the day when you could use either the MySQL or CURL interfaces. The
>> SQL interface returned something parallel to input, and it was a bit of
>> a change when Steffen went to just using the CURL interface, and people
>> had to learn to add the query key into the return in order to re-sort.
>>
>> So from a historical perspective it would be a real change to go from
>> returning something as close to parallel to the input to a SQL type
>> model. I agree that makes sense for those who are versed in SQL, but if
>> we were really trying to help people familiar with SQL, we would just be
>> giving them the RSQLite DB and telling them to have at it, no? The whole
>> rationale behind wrapping the DB in a package is to shield the end user
>> from having to understand SQL, which includes knowing that SQL doesn't
>> enforce the order of the returned data.
>>
>>  From a use case perspective, the only use case that I am familiar with
>> is the one where people have a rectangular array of data, where the rows
>> are genes or whatnot, and they want to append additional columns to the
>> array, where the added columns conform to the existing array. This is
>> not always possible to do in the case of 1:many mappings, obviously, but
>> that is what mapIds() is for - there is an implicit contract there that
>> you can input a set of keys, and get out an ordered result that you can
>> then tack onto the side of your array of data and go forward. I think
>> that is a really useful thing to be able to do. It is obviously quite
>> easy to take two matrices that are ordered differently, reorder one, and
>> then bind together. But if you don't have to do that, then it's an
>> improvement, and quite helpful for naive users who might not have
>> considered that the returned result might not actually be parallel to
>> their input.
>>
>> And being the one who convinced Marc to put the warnings back in, I will
>> have to respectively disagree about whether or not it is useful to emit
>> the warnings. Well, I agree it isn't useful at all for those of us who
>> already know that the results might not be parallel. But that isn't the
>> reason for a warning is it? To warn those who already understand what is
>> going on? My argument is (and was) that a warning is intended to tell
>> people that something that they /might not have expected/ just happened.
>> I don't think it is unreasonable to think that a significant proportion
>> of naive end users would get tripped up by that if the warning weren't
>> there. They still might be, but at least we gave them a chance.
>>
>> Anyway, it took like three lines of code to make it work consistently
>> for many:many mappings, so that's what I did

Re: [Bioc-devel] Common workflow to build an microarray annatation package, like hgu133a.db

[James W. MacDonald]

On Jan 5, 2016 7:01 PM, "Tim Triche, Jr."  wrote:
>
> 1) this is a support.bioconductor.org question
> 2) don't use .db0 packages, you will rue the day you did

Can you expand on this statement? Right now all of the ChipDb are built
using a db0 package, so it's not clear to me why this might be a problem.

> best,
>
> --t
>
> On Tue, Jan 5, 2016 at 3:53 PM, Zhilong Jia  wrote:
>
> > Hello,
> >
> > Happy new year.
> >
> > What is the common work-flow to build an microarray annotation package,
> > like hgu133a.db.
> >
> > For some array, there are probe sequences available, then maybe mapping
is
> > used? While for other situations, how to deal with? If code used by the
> > team available, that will be great. Thank you.
> >
> > The specific goal is to build new platform annotation packages which are
> > not available now from Bioconductor (what I need is just probe to gene
> > symbols).
> >
> > It seems Bioconductor update the annotation package when a new version
> > releasing due to the update of gene symbols.
> >
> > BTW, why name it as hgu133a.db instead of GPL96.db (from GEO) in
> > Bioconductor? And user have to find the mapping relationship between
them,
> > though there are some mappings, such as
> >
https://gist.github.com/seandavi/bc6b1b82dc65c47510c7#file-platformmap-txt
> > .
> >
> >
> > Regards,
> > Zhilong
> >
> > --
> > Zhilong JIA
> > zhilong...@gmail.com
> > https://github.com/zhilongjia
> >
> > [[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

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] topGO and cat() and print() statements in program code

[James W. MacDonald]

I can't speak to the issue of changing somebody else's code without forking
(which you are free to do), or getting their OK. But do note that there are
usually ways around this. First, you can use include = FALSE in your chunk
options statement, which will run all the code, but silence everything.
This isn't a good use case if you need to print, but that can usually be
split out. Something like

```r{noisypart, include = FALSE}

noisy code goes here

```

```r{quietpart, echo = FALSE, fig.cap = ""}

plots go here

```

An alternative is to use GOstats, which may be less noisy, but which still
has 18 calls to cat() (vs 121 for topGO) and 2 calls to print() (vs 29 for
topGO).

Best,

Jim



On Tue, Feb 2, 2016 at 5:19 AM, Witold E Wolski  wrote:

> Hi,
>
> I am using the very usefull package topGO to generate a report (R
> markdown). There is not much to complain about topGO (on the contrary)
> except that the package uses cat instead of message to display
> progress information. which ruins the report.
>
> Also the bioconductor package guidelines state:
> cat() or print() are used only when displaying an object to the user,
> e.g., in a show method.
>
> This makes it difficult to integrate topGO.
>
> I did contact the maintainer asking to update topGO. However I did not
> get an reply. It seems that the maintainer is occupied with other
> problems. I did offer to replace the cat with message for these
> functions I am using myself. No reply.
>
> So what I am wondering is... If I do the corrections, and would like
> to commit the code... Sure I could create a branch but since I do not
> have write access to svn no chance to push (commit) it for review.
> And who is going to review it if the maintainer does not have time?
>
> best
> Witold
>
>
>
>
>
> --
> Witold Eryk Wolski
>
> _______
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] inconsistent results from applyPileups and pileLettersAt

[James W. MacDonald]

The Bioc-devel list is intended for people who are developing packages.
Your question should be posted on the bioconductor support site,
https://support.bioconductor.org.

Jim



On Fri, May 27, 2016 at 11:05 AM, Jesper Gådin 
wrote:

> Hello everyone,
>
> I find inconsistent results from applyPileups and pileLettersAt. I have a
> placed a full example on github, so you can try the code with data that
> will reproduce what I am suspecting is a "bug".
>
> #Repo with reproducible example
> https://github.com/pappewaio/ExampleData
>
> #Here a short summary of what is happening
> One version requires the user to use readGAlignments first and then use
> pileLettersAt, here I can read in 450 reads into R, but after using
> pileLettersAt I am left with only 413 counts. What could possibly explain
> this difference? Is it because some reads are spanning the position I am
> piling letters at, but not having any sequence information for the
> position?
>
> The second version uses applyPileups and summarize straight from the bam
> file, and here I would expect to have at least the 413 counts found by
> pileLettersAt. But instead I can only find 385 counts. Why is it so?
>
> Until now I have been using version one to get allele counts. But version
> two is very much faster, so would be very nice to be able to switch to it,
> without losing counts.
>
> looking forward to hearing your thoughts,
> Jesper
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Announcement of a new package called bacon

[James W. MacDonald]

You should post this on the support site (https://support.bioconductor.org),
using the 'News' item description. This bioc-devel is intended for
discussion of issues with development of packages, not really for
announcing new packages.

Jim



On Thu, Jun 9, 2016 at 9:37 AM, Maarten van Iterson 
wrote:

> Dear list,
>
> I would like to introduce the package bacon that has been added to
> bioconductor just before the release of version 3.3.
>
> bacon can be used to estimate and control for bias and inflation often
> present in epigenome- and transcriptome-wide association
> studies(EWAS/TWAS). The idea behind bacon is to estimate the empirical null
> distribution from the data (using Bayesian statistics) and use the
> empirical null i.s.o. a theoretical null for inference. Bacon supports
> bias- and inflation-controlled fixed-effect meta-analysis that can be
> executed in parallel. A manuscript is available from biorxiv (
> http://biorxiv.org/content/early/2016/05/27/055772).
>
> Kind regards,
>
> Maarten van Iterson
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Announcement of a new package called bacon

[James W. MacDonald]

I agree, but bacon is part of release. As Maarten said "
*I would like to introduce the package bacon that has been added
tobioconductor just before the release of version 3.3." 😁*

On Thu, Jun 9, 2016 at 10:09 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 06/09/2016 10:06 AM, James W. MacDonald wrote:
>
>> You should post this on the support site (
>> https://support.bioconductor.org),
>> using the 'News' item description. This bioc-devel is intended for
>> discussion of issues with development of packages, not really for
>> announcing new packages.
>>
>
> actually the email to developers on package acceptance encourages them to
> post to bioc-devel.
>
> I think the rationale was that the package is only available in devel, so
> advertising on the support site would just lead to disappointment.
>
> Open to revised policies / suggestions, though.
>
> Martin
>
>
>> Jim
>>
>>
>>
>> On Thu, Jun 9, 2016 at 9:37 AM, Maarten van Iterson 
>> wrote:
>>
>> Dear list,
>>>
>>> I would like to introduce the package bacon that has been added to
>>> bioconductor just before the release of version 3.3.
>>>
>>> bacon can be used to estimate and control for bias and inflation often
>>> present in epigenome- and transcriptome-wide association
>>> studies(EWAS/TWAS). The idea behind bacon is to estimate the empirical
>>> null
>>> distribution from the data (using Bayesian statistics) and use the
>>> empirical null i.s.o. a theoretical null for inference. Bacon supports
>>> bias- and inflation-controlled fixed-effect meta-analysis that can be
>>> executed in parallel. A manuscript is available from biorxiv (
>>> http://biorxiv.org/content/early/2016/05/27/055772).
>>>
>>> Kind regards,
>>>
>>> Maarten van Iterson
>>>
>>>  [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>>
>>
>>
>>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Confusion on biocLite() with github and annotation data repo

[James W. MacDonald]

I had a similar experience, where the dependencies were not found upon
installation. I didn't do anything to fix it - instead it seemed that just
re-running biocLite after the initial failed install ended up working.

Maybe the same will work for you?

Best,

Jim



On Mon, Jun 27, 2016 at 5:03 PM, Davis, Sean (NIH/NCI) [E] <
sdav...@mail.nih.gov> wrote:

> I am trying to install from Jim’s annotation workflow from github (
> https://github.com/jmacdon/BiocAnno2016), but biocLite() fails because it
> cannot find annotation data packages.  I *can* go back and install the
> annotation data package with a separate call to biocLite().  Is this
> expected behavior?  If so, is it possible and desirable to install from
> github and have it “do the right thing” to get Bioc dependencies?
>
> Thanks,
> Sean
>
>
> > biocLite('jmacdon/BiocAnno2016',dependencies=TRUE,build_vignettes=TRUE)
> BioC_mirror: https://bioconductor.org
> Using Bioconductor 3.3 (BiocInstaller 1.22.3), R 3.3.0 (2016-05-03).
> Installing github package(s) ‘jmacdon/BiocAnno2016’
> Downloading GitHub repo jmacdon/BiocAnno2016@master
> from URL https://api.github.com/repos/jmacdon/BiocAnno2016/zipball/master
> Installing BiocAnno2016
> Skipping 7 unavailable packages: BSgenome.Hsapiens.UCSC.hg19,
> EnsDb.Hsapiens.v79, EnsDb.Mmusculus.v79, Homo.sapiens,
> hugene20sttranscriptcluster.db, org.Hs.eg.db,
> TxDb.Hsapiens.UCSC.hg19.knownGene
> Skipping 19 packages ahead of CRAN: AnnotationDbi, AnnotationHub, Biobase,
> BiocGenerics, BiocParallel, biomaRt, Biostrings, BSgenome,
> GenomicAlignments, GenomicRanges, interactiveDisplayBase, IRanges,
> rmarkdown, Rsamtools, rtracklayer, S4Vectors, SummarizedExperiment,
> XVector, zlibbioc
> '/Library/Frameworks/R.framework/Resources/bin/R' --no-site-file
> --no-environ  \
>   --no-save --no-restore --quiet CMD build  \
>
> '/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/Rtmpq8yntE/devtools32fa3fcc4899/jmacdon-BiocAnno2016-7317126'
> \
>   --no-resave-data --no-manual
>
> * checking for file
> ‘/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/Rtmpq8yntE/devtools32fa3fcc4899/jmacdon-BiocAnno2016-7317126/DESCRIPTION’
> ... OK
> * preparing ‘BiocAnno2016’:
> * checking DESCRIPTION meta-information ... OK
> * installing the package to process help pages
>   ---
> ERROR: dependencies ‘EnsDb.Hsapiens.v79’, ‘Homo.sapiens’,
> ‘EnsDb.Mmusculus.v79’ are not available for package ‘BiocAnno2016’
> * removing
> ‘/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/RtmpBduTCP/Rinst33cf24872f4e/BiocAnno2016’
>   ---
> ERROR: package installation failed
> Error: Command failed (1)
> > biocLite('Homo.sapiens')
> BioC_mirror: https://bioconductor.org
> Using Bioconductor 3.3 (BiocInstaller 1.22.3), R 3.3.0 (2016-05-03).
> Installing package(s) ‘Homo.sapiens’
> installing the source package ‘Homo.sapiens’
>
> trying URL '
> https://bioconductor.org/packages/3.3/data/annotation/src/contrib/Homo.sapiens_1.3.1.tar.gz
> '
> Content type 'application/x-gzip' length 1617 bytes
> ==
> downloaded 1617 bytes
>
> * installing *source* package ‘Homo.sapiens’ ...
> ** R
> ** data
> ** preparing package for lazy loading
> Warning: package ‘GenomicRanges’ was built under R version 3.3.1
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> Warning: package ‘GenomicRanges’ was built under R version 3.3.1
> * DONE (Homo.sapiens)
>
> The downloaded source packages are in
>
> ‘/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/Rtmpq8yntE/downloaded_packages’
> Old packages: 'airway', 'BiocStyle', 'ComplexHeatmap', 'dendextend',
> 'DESeq2',
>   'devtools', 'docopt', 'dplyr', 'ensembldb', 'genefilter',
> 'GenomicFeatures',
>   'GEOquery', 'Gviz', 'h2o', 'HSMMSingleCell', 'lfa', 'limma', 'miRLAB',
>   'monocle', 'nlme', 'oligo', 'pracma', 'purrr', 'RBGL', 'RcppArmadillo',
>   'Rhtslib', 'robustbase', 'rstudioapi', 'rvest', 'sevenbridges',
>   'SomaticCancerAlterations', 'survival', 'tidyr', 'tximport',
>   'VariantAnnotation', 'vegan', 'VGAM', 'withr', 'XLConnect',
> 'XLConnectJars',
>   'xml2'
>

Re: [Bioc-devel] Confusion on biocLite() with github and annotation data repo

[James W. MacDonald]

Sean did that. His original call was

biocLite('jmacdon/BiocAnno2016',dependencies=TRUE,build_vignettes=TRUE)

On Tue, Jun 28, 2016 at 11:24 AM, Dan Tenenbaum 
wrote:

> I think you need to add the
>
> dependencies=TRUE
>
> argument which gets passed to devtools::install_github() and thence to
> devtools::install().
>
> Dan
>
>
> - Original Message -
> > From: "Martin Morgan" 
> > To: "James W. MacDonald" , "Sean Davis" <
> sdav...@mail.nih.gov>
> > Cc: "bioc-devel" 
> > Sent: Tuesday, June 28, 2016 8:11:26 AM
> > Subject: Re: [Bioc-devel] Confusion on biocLite() with github and
> annotation data repo
>
> > On 06/28/2016 10:56 AM, James W. MacDonald wrote:
> >> I had a similar experience, where the dependencies were not found upon
> >> installation. I didn't do anything to fix it - instead it seemed that
> just
> >> re-running biocLite after the initial failed install ended up working.
> >
> > Installing from github delegates to devtools::install_github, and that
> > the annotation repository is not found. So something like
> >
> > > options(repos=BiocInstaller::biocinstallRepos())
> > > biocLite("jmacdon/BiocAnno2016")
> >
> > I think the code is trying to do that, though
> >
> >
> https://github.com/Bioconductor-mirror/BiocInstaller/blob/master/R/biocLite.R#L72
> >
> > so don't really understand why it fails...
> >
> > Martin
> >
> >>
> >> Maybe the same will work for you?
> >>
> >> Best,
> >>
> >> Jim
> >>
> >>
> >>
> >> On Mon, Jun 27, 2016 at 5:03 PM, Davis, Sean (NIH/NCI) [E] <
> >> sdav...@mail.nih.gov> wrote:
> >>
> >>> I am trying to install from Jim’s annotation workflow from github (
> >>> https://github.com/jmacdon/BiocAnno2016), but biocLite() fails
> because it
> >>> cannot find annotation data packages.  I *can* go back and install the
> >>> annotation data package with a separate call to biocLite().  Is this
> >>> expected behavior?  If so, is it possible and desirable to install from
> >>> github and have it “do the right thing” to get Bioc dependencies?
> >>>
> >>> Thanks,
> >>> Sean
> >>>
> >>>
> >>>>
> biocLite('jmacdon/BiocAnno2016',dependencies=TRUE,build_vignettes=TRUE)
> >>> BioC_mirror: https://bioconductor.org
> >>> Using Bioconductor 3.3 (BiocInstaller 1.22.3), R 3.3.0 (2016-05-03).
> >>> Installing github package(s) ‘jmacdon/BiocAnno2016’
> >>> Downloading GitHub repo jmacdon/BiocAnno2016@master
> >>> from URL
> https://api.github.com/repos/jmacdon/BiocAnno2016/zipball/master
> >>> Installing BiocAnno2016
> >>> Skipping 7 unavailable packages: BSgenome.Hsapiens.UCSC.hg19,
> >>> EnsDb.Hsapiens.v79, EnsDb.Mmusculus.v79, Homo.sapiens,
> >>> hugene20sttranscriptcluster.db, org.Hs.eg.db,
> >>> TxDb.Hsapiens.UCSC.hg19.knownGene
> >>> Skipping 19 packages ahead of CRAN: AnnotationDbi, AnnotationHub,
> Biobase,
> >>> BiocGenerics, BiocParallel, biomaRt, Biostrings, BSgenome,
> >>> GenomicAlignments, GenomicRanges, interactiveDisplayBase, IRanges,
> >>> rmarkdown, Rsamtools, rtracklayer, S4Vectors, SummarizedExperiment,
> >>> XVector, zlibbioc
> >>> '/Library/Frameworks/R.framework/Resources/bin/R' --no-site-file
> >>> --no-environ  \
> >>>--no-save --no-restore --quiet CMD build  \
> >>>
> >>>
> '/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/Rtmpq8yntE/devtools32fa3fcc4899/jmacdon-BiocAnno2016-7317126'
> >>> \
> >>>--no-resave-data --no-manual
> >>>
> >>> * checking for file
> >>>
> ‘/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/Rtmpq8yntE/devtools32fa3fcc4899/jmacdon-BiocAnno2016-7317126/DESCRIPTION’
> >>> ... OK
> >>> * preparing ‘BiocAnno2016’:
> >>> * checking DESCRIPTION meta-information ... OK
> >>> * installing the package to process help pages
> >>>---
> >>> ERROR: dependencies ‘EnsDb.Hsapiens.v79’, ‘Homo.sapiens’,
> >>> ‘EnsDb.Mmusculus.v79’ are not available for package ‘BiocAnno2016’
> >>> * removing
> >>>
> ‘/private/var/folders/21/b_rp6qyj1_b1j5cp8qby0tnrgn/T/RtmpBduTCP/Rinst33cf24872f4e/BiocAnno201

Re: [Bioc-devel] BiomartGeneRegionTrack question

[James W. MacDonald]

Hi Holly,

This list is intended for those that are developing packages. Your question
should be asked on the support site (https://support.bioconductor.org).
Please repost over there.

Best,

Jim



On Wed, Jul 20, 2016 at 2:04 PM, Holly  wrote:

> Dear Bioconductor helpers,
> I am trying to plot a region of interest using the Gviz package.
> I met error when running the following example code:
> > library(Gviz)
> > library(GenomicRanges)
> > bmTrack <- BiomartGeneRegionTrack(start=26682683, end=26711643,
> + chromosome=7, genome="mm9")
> Entity 'nbsp' not defined
> Entity 'hellip' not defined
> Entity 'hellip' not defined
> Entity 'nbsp' not defined
> Entity 'raquo' not defined
> Entity 'hellip' not defined
> Entity 'hellip' not defined
> Entity 'hellip' not defined
> Entity 'hellip' not defined
> Entity 'hellip' not defined
> Opening and ending tag mismatch: img line 68 and li
> Opening and ending tag mismatch: li line 68 and ul
> Opening and ending tag mismatch: ul line 67 and div
> Entity 'copy' not defined
> Opening and ending tag mismatch: div line 19 and body
> Opening and ending tag mismatch: body line 17 and html
> Premature end of data in tag html line 2
> Error: 1: Entity 'nbsp' not defined
> 2: Entity 'hellip' not defined
> 3: Entity 'hellip' not defined
> 4: Entity 'nbsp' not defined
> 5: Entity 'raquo' not defined
> 6: Entity 'hellip' not defined
> 7: Entity 'hellip' not defined
> 8: Entity 'hellip' not defined
> 9: Entity 'hellip' not defined
> 10: Entity 'hellip' not defined
> 11: Opening and ending tag mismatch: img line 68 and li
> 12: Opening and ending tag mismatch: li line 68 and ul
> 13: Opening and ending tag mismatch: ul line 67 and div
> 14: Entity 'copy' not defined
> 15: Opening and ending tag mismatch: div line 19 and body
> 16: Opening and ending tag mismatch: body line 17 and html
> 17: Premature end of data in tag html line 2
> >  sessionInfo()
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
>  [1] grid  parallel  stats4stats graphics  grDevices utils
>  [8] datasets  methods   base
>
> other attached packages:
> [1] Gviz_1.16.1  GenomicRanges_1.24.2 GenomeInfoDb_1.8.2
> [4] IRanges_2.6.1S4Vectors_0.10.2 BiocGenerics_0.18.0
>
> loaded via a namespace (and not attached):
>  [1] SummarizedExperiment_1.2.3VariantAnnotation_1.18.3
>  [3] splines_3.3.1 lattice_0.20-33
>  [5] colorspace_1.2-6  htmltools_0.3.5
>  [7] rtracklayer_1.32.1GenomicFeatures_1.24.4
>  [9] chron_2.3-47  interactiveDisplayBase_1.10.3
> [11] survival_2.39-5   XML_3.98-1.4
> [13] foreign_0.8-66DBI_0.4-1
> [15] ensembldb_1.4.7   BiocParallel_1.6.2
> [17] RColorBrewer_1.1-2matrixStats_0.50.2
> [19] plyr_1.8.4zlibbioc_1.18.0
> [21] Biostrings_2.40.2 munsell_0.4.3
> [23] gtable_0.2.0  latticeExtra_0.6-28
> [25] Biobase_2.32.0biomaRt_2.28.0
> [27] BiocInstaller_1.22.3  httpuv_1.3.3
> [29] AnnotationDbi_1.34.4  Rcpp_0.12.5
> [31] acepack_1.3-3.3   xtable_1.8-2
> [33] BSgenome_1.40.1   scales_0.4.0
> [35] Hmisc_3.17-4  XVector_0.12.0
> [37] mime_0.5  Rsamtools_1.24.0
> [39] gridExtra_2.2.1   AnnotationHub_2.4.2
> [41] ggplot2_2.1.0 digest_0.6.9
> [43] biovizBase_1.20.0 shiny_0.13.2
> [45] tools_3.3.1   bitops_1.0-6
> [47] RCurl_1.95-4.8RSQLite_1.0.0
> [49] dichromat_2.0-0   Formula_1.2-1
> [51] cluster_2.0.4 Matrix_1.2-6
> [53] data.table_1.9.6  httr_1.2.1
> [55] R6_2.1.2  rpart_4.1-10
> [57] GenomicAlignments_1.8.4   nnet_7.3-12
> >
>
> Thank you for help,
> Holly
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] chimera Attempts to Open Non-existent File

[James W. MacDonald]

This sort of thing should be reported on the support site. The devel
listserv is intended for issues with the development of packages.

On Wed, Nov 2, 2016 at 11:00 PM, Dario Strbenac 
wrote:

> Good day,
>
> The importFusionData function fails trying to open a file that doesn't
> exist.
>
> > fd = importFusionData("star", "/verona/nobackup/biostat/
> datasets/melanoma/AAHChimeric.out.junction")
> Error in file(file, "rt") : cannot open the connection
> In addition: Warning message:
> In file(file, "rt") :
>   cannot open file 'Thu_Nov_3_13-46-27_2016': No such file or directory
>
> The section of code where the error occurs seems to be in the .starImport
> function.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
>
> _______
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] lumi package is not available

[James W. MacDonald]

On Wed, Nov 9, 2016 at 4:48 PM, Martin Morgan  wrote:

> I updated the code to remove the R CMD check error (svn revision r123826)
> and to clean up miscellaneous NOTEs about formatting (r123827). I ported
> these changes to release.
>
> It is likely that the package has a number of other similar problems
> (assigning exprs() with incompatible dimnames) so a thorough review is
> required.
>
> There are vignette products in the vignettes/ directory, but no Rnw / Rmd
> files; this needs to be corrected.
>
> If there is no-one willing to actively maintain this package, I think that
> it should be deprecated in devel. This would impact a number of packages
> that Depend, Import, or Suggest lumi.
>

Pan Du has several packages. Is this an issue for all of those packages or
just lumi?

Jim



>
> Martin
>
> On 10/28/2016 06:47 AM, Gang Feng wrote:
>
>> Hi,
>>
>> We are working on one issue in the lumi package. Sorry about this.
>>
>> Gilbert
>>
>> On 10/28/16 3:20 AM, "Bioc-devel on behalf of 王棣台"
>> 
>> wrote:
>>
>> Hi, all
>>>
>>> I am the author of package "anamiR".
>>> I got a Warning message "Warning: dependency ''lumi" is not available"
>>> when I installed anamiR.
>>> Also, I tried other packages which depend on "lumi" package, and all got
>>> the same warning message.
>>> Is there any way I can solve this problem?
>>>
>>> Best regards,
>>> T.Wang
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>>> hz.ch_mailman_
>>> listinfo_bioc-2Ddevel&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7r
>>> tNXt_d012z2PA6
>>> ws&r=k93hb-mTY3FnvPobw-XK7YsatsLioMulL2zwAXZNoRo&m=LgNbgBxYv
>>> 1xoQVTZ41uDrgo
>>> XiSE2MpwIrBuyrgPBGQQ&s=_cCwN-6SMimKn17T4EAM9tLSK8ouLKv-GtD9MKPf9_U&e=
>>>
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] lumi package is not available

[James W. MacDonald]

>> Pan Du has several packages. Is this an issue for all of those packages
>> or just lumi?
>>
>
> I think that's a reasonable conclusion. Martin
>

I am not sure I follow. What is the reasonable conclusion? That it's just
this one package, or all of them?

Jim


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] destiny git mirror and SVN desynced

[James W. MacDonald]

On Wed, Dec 14, 2016 at 10:02 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

>
>>
> yes; the current situation is unsatisfactory.
>
> Currently the cannonical repository is svn. The build system (and hence
> packages seen by the user) don't care about the mirror. Also, the mirror is
> in many ways confusing -- not the official repository, and not the
> developer repository.
>

What is the goal as far as the repository goes? Are we transitioning to
git/github, and this is just the messy intervening period, or are we
sticking with svn and just trying to find a workable way to add git
functionality for those who prefer to work with git?

-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] plotPCA in affycoretools not working

[James W. MacDonald]

This isn't a question for Bioc-devel, which is intended for questions about
package development. In future, please use the support site,
https://support.bioconductor.org

That said, I have checked in a fix which should propagate through the build
servers in the next day or two. In the meantime you can simply do

exprs <- ExpressionSet(WEHAsum)
plotPCA(exprs[,-1])



On Thu, Jan 26, 2017 at 10:38 AM, Vojtech Kulvait  wrote:

> When using this code
>
> WEHAsum = read.csv("/tmp/wehasum.csv", check.names = FALSE, as.is=TRUE)
> plotPCA(as.matrix(WEHAsum[,-1][,sort(colnames(WEHAsum[,-1]))]),
> x.coord=-20, y.coord=20)
>
> I get
>
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function 'plotPCA' for signature
> '"matrix"'
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] problem installing 'Affycoretools' in linux ubuntu

[James W. MacDonald]

plotter’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/geneplotter’
> ERROR: dependency ‘GenomeInfoDb’ is not available for package
> ‘GenomicRanges’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/GenomicRanges’
> ERROR: dependencies ‘annotate’, ‘XML’ are not available for package
> ‘GSEABase’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/GSEABase’
> ERROR: dependencies ‘GenomeInfoDb’, ‘GenomicRanges’ are not available for
> package ‘Rsamtools’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/Rsamtools’
> ERROR: dependencies ‘GSEABase’, ‘genefilter’, ‘annotate’ are not available
> for package ‘Category’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/Category’
> ERROR: dependencies ‘GenomicRanges’, ‘GenomeInfoDb’ are not available for
> package ‘SummarizedExperiment’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/
> SummarizedExperiment’
> ERROR: dependencies ‘GenomeInfoDb’, ‘GenomicRanges’,
> ‘SummarizedExperiment’, ‘Rsamtools’ are not available for package
> ‘GenomicAlignments’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/
> GenomicAlignments’
> ERROR: dependencies ‘GenomicRanges’, ‘SummarizedExperiment’, ‘genefilter’,
> ‘geneplotter’ are not available for package ‘DESeq2’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/DESeq2’
> ERROR: dependencies ‘Category’, ‘annotate’, ‘AnnotationForge’ are not
> available for package ‘GOstats’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/GOstats’
> ERROR: dependencies ‘GenomicRanges’, ‘SummarizedExperiment’ are not
> available for package ‘oligoClasses’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/oligoClasses’
> ERROR: dependencies ‘GenomicRanges’, ‘XML’, ‘GenomeInfoDb’, ‘RCurl’,
> ‘Rsamtools’, ‘GenomicAlignments’ are not available for package ‘rtracklayer’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/rtracklayer’
> ERROR: dependencies ‘GenomeInfoDb’, ‘GenomicRanges’, ‘rtracklayer’,
> ‘Rsamtools’ are not available for package ‘BSgenome’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/BSgenome’
> ERROR: dependencies ‘GenomeInfoDb’, ‘GenomicRanges’, ‘RCurl’,
> ‘rtracklayer’, ‘biomaRt’ are not available for package ‘GenomicFeatures’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/
> GenomicFeatures’
> ERROR: dependencies ‘GenomeInfoDb’, ‘GenomicRanges’,
> ‘SummarizedExperiment’, ‘Rsamtools’, ‘BSgenome’, ‘rtracklayer’,
> ‘GenomicFeatures’ are not available for package ‘VariantAnnotation’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/
> VariantAnnotation’
> ERROR: dependencies ‘GenomicFeatures’, ‘GenomicRanges’ are not available
> for package ‘OrganismDbi’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/OrganismDbi’
> ERROR: dependencies ‘GenomicRanges’, ‘GenomicFeatures’, ‘GenomeInfoDb’,
> ‘rtracklayer’, ‘AnnotationHub’, ‘Rsamtools’ are not available for package
> ‘ensembldb’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/ensembldb’
> ERROR: dependencies ‘GenomeInfoDb’, ‘GenomicRanges’,
> ‘SummarizedExperiment’, ‘Rsamtools’, ‘GenomicAlignments’,
> ‘GenomicFeatures’, ‘VariantAnnotation’, ‘ensembldb’ are not available for
> package ‘biovizBase’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/biovizBase’
> ERROR: dependencies ‘biovizBase’, ‘GenomeInfoDb’, ‘GenomicRanges’,
> ‘SummarizedExperiment’, ‘Rsamtools’, ‘GenomicAlignments’, ‘BSgenome’,
> ‘VariantAnnotation’, ‘rtracklayer’, ‘GenomicFeatures’, ‘OrganismDbi’,
> ‘ensembldb’ are not available for package ‘ggbio’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/ggbio’
> ERROR: dependencies ‘Category’, ‘GOstats’, ‘annotate’, ‘GSEABase’, ‘XML’,
> ‘DESeq2’, ‘ggbio’ are not available for package ‘ReportingTools’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/ReportingTools’
> ERROR: dependencies ‘GOstats’, ‘oligoClasses’, ‘ReportingTools’ are not
> available for package ‘affycoretools’
> * removing ‘/home/deepti/R/x86_64-pc-linux-gnu-library/3.3/affycoretools’
>
> The downloaded source packages are in
> ‘/tmp/RtmpPFOwZE/downloaded_packages’
> installation path not writeable, unable to update packages: Matrix, mgcv,
> nlme, survival
> There were 31 warnings (use warnings() to see them)
>
>
>
> I will be greatfull for your help in this.
>
>
> best,
>
> DA
>
> [[alternative HTML version deleted]]
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] developing R package for new release

[James W. MacDonald]

On Fri, Mar 17, 2017 at 3:45 PM, Nicholas Clark 
wrote:

> I’m planning on adding some new features to my package (GRmetrics) before
> this upcoming release and I have a few development questions.
>
>
> 1) Which version of R should I be using? I looked at this page (
> http://bioconductor.org/developers/how-to/useDevel/
> ), but I was still confused as to whether I should use the recently
> released R 3.3.3 or the R-devel 3.4.0 at http://r.research.att.com/


For the spring release you should use R-devel. For the fall release you
should use the most current version of R. This is because we release twice
a year, but R is only released in spring.

Looking at the useDevel page I see that I am simply repeating (almost
verbatim) what is written there. Is there something unclear about this that
we should address? It seems clear enough to me, but I've been doing this a
long time.


>
> .
>
>
> 2) What is the best/easiest way to work with github? Should I fork the
> repository from the read-only Bioconductor repo and work on that or
> maintain a separate repo? Or does it not matter?
>

I believe you should fork the repo from the Bioconductor mirror and use
that. There is some info here (
http://bioconductor.org/developers/how-to/git-mirrors/). But there are some
considerations to be made. Right now, we are using subversion for version
control, and anything you do in github has to be 'subversionized' in order
for your commits to be checked into the main version control repository.
It's far easier IMO to just use subversion to do all your version control,
because you don't have to worry about getting git to talk to subversion.

That said, after the April release we are transitioning to git, so we will
be using git soon enough. But for now I am still using SVN because it's a
direct commit to the main repo. My advice is to use whatever the main repo
is based on, because mixing and matching adds an extra level of complexity
that doesn't appear to have much to offer in return.


>
> 3) Should I make a “release-3.5” branch and commit changes there, or
> should it be “devel”, or just the “master” branch? http://bioconductor.
> org/developers/how-to/git-mirrors/
>  talks about this, but again, it’s not clear to me.
>

You never make your own branches. That's controlled by BioC core. Unless
you are fixing a bug in the release version of your package you should be
using the master branch (or if you use SVN, you should just be checking out
of the trunk,
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/GRmetrics).


>
> 4) It looks like my package is failing the Windows build because it
> requires “SummarizedExperiment”, which is failing the Windows build. Is
> there anything I can do to fix this? Apologies if this has already been
> addressed. The error is: ERROR: dependency ‘SummarizedExperiment’ is not
> available for package ‘GRmetrics' (http://bioconductor.org/
> checkResults/release/bioc-LATEST/GRmetrics/tokay1-buildsrc.html
> )
>

If one of your dependencies is failing, and in particular if the dependency
is maintained by Bioc core, then the best thing to do is wait. If you are
relying on somebody else's package and they are consistently failing you
might contact them and find out if you can help.

Jim



>
> Best,
> Nick Clark
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel




-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Package not being built on Windows or Mac

[James W. MacDonald]

It's probably because you depend on RCytoscape, which isn't supported on
Windows or MacOS. And maybe this has something to do with XMLRPC?

Jim



On Mon, Mar 20, 2017 at 4:59 PM, Robert M. Flight 
wrote:

> As per the exhortation to check the build status on Devel prior to next
> version of Bioconductor release, I just noticed that my package
> categoryCompare has a "not supported" on Windows and Mac.
>
> Looking at release history, this seems to  I have changed at Bioc v 3.4,
> and I'm curious why that would be the case.
>
> Regards,
>
> Robert
>
> Robert M Flight, PhD
> Bioinformatics Research Associate
> Puller of Rabbits from Hats
> Resource Center for Stable Isotope Resolved Metabolomics
> Manager, Systems Biology and Omics Integration Journal Club
> Markey Cancer Center
> CC434 Roach Building
> University of Kentucky
> Lexington, KY
>
> Twitter: @rmflight
> Web: rmflight.github.io
> ORCID: http://orcid.org/-0001-8141-7788
> EM rfligh...@gmail.com
> PH 502-509-1827
>
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. - Ronald Fisher
>
> [[alternative HTML version deleted]]
>
> _______
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Fwd: Gostats and custom list

[James W. MacDonald]

This list is intended for discussions about package development, not
general queries. Please post that sort of question on the support site,
https://support.bioconductor.org

On Tue, Apr 11, 2017 at 8:32 AM, amit kumar subudhi 
wrote:

> Hi,
>
> I am using Gostats to perform GO enrichment from custom list of genes and
> custom annotations. My annotation file looks like this
> head (geneGO)
>   GOterm evi   GeneID
> 1 GO:0016020  ND PCHAS_010020
> 2 GO:0016021  ND PCHAS_010020
> 3 GO:0016020  ND PCHAS_010030
> 4 GO:0016021  ND PCHAS_010030
> 5 GO:0016020  ND PCHAS_010040
> 6 GO:0016021  ND PCHAS_010040
>
> My hyperGtest result looks like this
> >Over.bp.Phase_0_2 <-hyperGTest(params.bp.Phase_0_2 )
> >Over.bp.Phase_0_2
> Gene to GO BP Conditional test for over-representation
> 228 GO BP ids tested (45 have p < 0.05)
> Selected gene set size: 37
> Gene universe size: 1707
> Annotation package: Based on a GeneSetCollection Object
> and my summary result looks like this
>
> enrichgobp.Phase_9_12 <-summary(Over.bp.Phase_9_12 )
>GOBPID   Pvalue OddsRatioExpCount Count
> Size  Term V8
> 1  GO:0019362 4.441045e-05 17.239583  0.43350908 5   20
> pyridine nucleotide metabolic process Phase_0_2
> 2  GO:0046031 1.163932e-04 22.370370  0.28178090 4
> 13 ADP metabolic process Phase_0_2
> 3  GO:0006096 1.163932e-04 22.370370  0.28178090 4
> 13glycolytic process Phase_0_2
> 4  GO:0016052 1.163932e-04 22.370370  0.28178090 4
> 13carbohydrate catabolic process Phase_0_2
> 5  GO:0009185 1.604285e-04 20.121212  0.30345636 4   14
> ribonucleoside diphosphate metabolic process Phase_0_2
> 6  GO:0009135 1.604285e-04 20.121212  0.30345636 4   14   purine
> nucleoside diphosphate metabolic process Phase_0_2
> 7  GO:0043436 2.085503e-04  5.450461  2.21089631 9
> 102 oxoacid metabolic process Phase_0_2
> 8  GO:0006165 2.153810e-04 18.280992  0.32513181 4   15
> nucleoside diphosphate phosphorylation Phase_0_2
> 9  GO:0051186 1.523968e-03  7.114211  0.88680352 5
> 42cofactor metabolic process Phase_0_2
>
> what am I suppose to do, If I want to retrieve the geneIDs associated with
> each GOterms. The other information about params is
>
> params.bp.Phase_0_2<-GSEAGOHyperGParams(name="P.
> chabaudi",geneSetCollection=gsc,geneIds=Phase_0_2
> ,universeGeneIds=universe,ontology="BP",pvalueCutoff=0.
> 05,conditional=TRUE,
> testDirection="over")
>
> Looking forward to hear from you.
>
> With best regards, Amit
>
> --
> Amit Kumar Subudhi, PhD
> Post Doctoral Research Scientist,
> Pathogen Genomics Group,
> Division of Biological and Environmental Sciences and Engineering,
> Level 4, 4326-WS10, Building 2,
> King Abdullah University of Science and Technology (KAUST),
>
> Thuwal 23955-6900, Kingdom of Saudi Arabia,
> Phone: (+966 12) 808 0614 <+966%2012%20808%200614>, Mobile: (+966) 5
> 40375986,
> Email Address: amit.subu...@kaust.edu.sa
>
>
>
> --
> Amit Kumar Subudhi, PhD
> Post Doctoral Research Scientist,
> Pathogen Genomics Group,
> Division of Biological and Environmental Sciences and Engineering,
> Level 4, 4326-WS10, Building 2,
> King Abdullah University of Science and Technology (KAUST),
>
> Thuwal 23955-6900, Kingdom of Saudi Arabia,
> Phone: (+966 12) 808 0614, Mobile: (+966) 5 40375986,
> Email Address: amit.subu...@kaust.edu.sa
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Vignette update after change in git mirror repo

[James W. MacDonald]

The update won't get built if there is an error during check:

Quitting from lines 42-54 (timescape_vignette.Rmd)
Error: processing vignette 'timescape_vignette.Rmd' failed with diagnostics:
Perturbations data frame must have the following column names: "pert_name",
"prev_tp", "frac"
Execution halted

You can either check the build page (which you should be doing, since
packages that fail check won't be part of the release on MONDAY):
http://bioconductor.org/checkResults/devel/bioc-LATEST/ or (better yet),
you should build and check locally before you check in your changes.

On Fri, Apr 21, 2017 at 4:41 PM, Maia Smith  wrote:

> I believe I did (see diff in DESCRIPTION file in the commit -
> https://github.com/Bioconductor-mirror/timescape/commit/
> 13597696049eda5858b755ca2777486f5b88f588
> ).
>
> Maia
>
>
>
> On Fri, Apr 21, 2017 at 10:53 AM, Sean Davis  wrote:
>
> > Be sure that you bumped the version number to trigger a build.
> >
> > Sean
> >
> >
> > On Fri, Apr 21, 2017 at 1:18 PM, Maia Smith  wrote:
> >
> >> Hi Sean,
> >>
> >> Thanks for your response, perhaps I was unclear. I used "Scenario 1: Use
> >> Git Locally, No GitHub Repository" in the how-to page, and committed to
> svn
> >> (I think!). The changes are reflected in the bioconductor mirror (
> >> https://github.com/Bioconductor-mirror/timescape) but not in the
> >> vignette (https://bioconductor.org/packages/devel/bioc/vignettes/time
> >> scape/inst/doc/timescape_vignette.html). Perhaps I made an error
> >> somewhere?
> >>
> >> Best,
> >> Maia
> >>
> >> On Thu, Apr 20, 2017 at 1:24 PM, Sean Davis  wrote:
> >>
> >>> Hi, Maia.
> >>>
> >>> The git mirror is not used for building packages.  Instead, you will
> >>> need to commit to svn for changes to show up on Bioconductor.  See
> here for
> >>> details of working with git and svn together.
> >>>
> >>> https://www.bioconductor.org/developers/how-to/git-mirrors/
> >>>
> >>> If I misunderstood what you are saying, could you clarify a bit?
> >>>
> >>> Sean
> >>>
> >>>
> >>> On Thu, Apr 20, 2017 at 3:35 PM Maia Smith  wrote:
> >>>
> >>>> How long does it take for the html vignette to update after a change
> in
> >>>> the
> >>>> git mirror has taken place? I changed my code in the git mirror a few
> >>>> days
> >>>> ago, and the html vignette hasn't incorporated these changes yet.
> >>>>
> >>>> Thanks in advance for your help.
> >>>>
> >>>> Maia
> >>>>
> >>>> [[alternative HTML version deleted]]
> >>>>
> >>>> ___
> >>>> Bioc-devel@r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>>
> >>>
> >>
> >
> >
> > --
> > Sean Davis, MD, PhD
> > Center for Cancer Research
> > National Cancer Institute
> > National Institutes of Health
> > Bethesda, MD 20892
> > https://seandavi.github.io/
> > https://twitter.com/seandavis12
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Windows binaries for the new release?

[James W. MacDonald]

I see the binaries on the respective web pages, but biocLite seems not to:

> biocLite()
BioC_mirror: https://bioconductor.org
Using Bioconductor 3.5 (BiocInstaller 1.26.0), R 3.4.0 (2017-04-21).
installation path not writeable, unable to update packages: foreign
Old packages: 'AnnotationDbi', 'Biobase', 'BiocGenerics', 'biomaRt',
'IRanges',
  'S4Vectors'
Update all/some/none? [a/s/n]: a

  There are binary versions available but the source versions are later:
   binary source needs_compilation
AnnotationDbi  1.37.4 1.38.0 FALSE
Biobase2.35.1 2.36.0  TRUE
BiocGenerics   0.21.3 0.22.0 FALSE
biomaRt   2.31.10 2.32.0 FALSE
IRanges2.9.19 2.10.0  TRUE
S4Vectors 0.13.17 0.14.0  TRUE

Do you want to install from sources the packages which need compilation?
y/n:

> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 14393)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] BiocInstaller_1.26.0

loaded via a namespace (and not attached):
[1] compiler_3.4.0 tools_3.4.0

-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Windows binaries for the new release?

[James W. MacDonald]

On Wed, Apr 26, 2017 at 10:09 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 04/26/2017 10:00 AM, James W. MacDonald wrote:
>
>> I see the binaries on the respective web pages, but biocLite seems not to:
>>
>
> I'm not 100% sure but can you try again in a new R session? I think you
> have a cached version of the repository index.
>

At a command prompt, using --vanilla:

C:\Users\jmacdon> C:\Progra~1\R\R-3.4.0\bin\x64\R --vanilla

R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(BiocInstaller)
Bioconductor version 3.5 (BiocInstaller 1.26.0), ?biocLite for help
> biocLite()
BioC_mirror: https://bioconductor.org
Using Bioconductor 3.5 (BiocInstaller 1.26.0), R 3.4.0 (2017-04-21).
installation path not writeable, unable to update packages: foreign
Old packages: 'Biobase', 'IRanges', 'S4Vectors'
Update all/some/none? [a/s/n]: a

  There are binary versions available but the source versions are later:
   binary source needs_compilation
Biobase2.35.1 2.36.0  TRUE
IRanges2.9.19 2.10.0  TRUE
S4Vectors 0.13.17 0.14.0  TRUE

Do you want to install from sources the packages which need compilation?
y/n:

Is there a way to remove the cache manually? I have already uninstalled and
re-installed BiocInstaller.

Jim




> Martin
>
>
>> biocLite()
>>>
>> BioC_mirror: https://bioconductor.org
>> Using Bioconductor 3.5 (BiocInstaller 1.26.0), R 3.4.0 (2017-04-21).
>> installation path not writeable, unable to update packages: foreign
>> Old packages: 'AnnotationDbi', 'Biobase', 'BiocGenerics', 'biomaRt',
>> 'IRanges',
>>   'S4Vectors'
>> Update all/some/none? [a/s/n]: a
>>
>>   There are binary versions available but the source versions are later:
>>binary source needs_compilation
>> AnnotationDbi  1.37.4 1.38.0 FALSE
>> Biobase2.35.1 2.36.0  TRUE
>> BiocGenerics   0.21.3 0.22.0 FALSE
>> biomaRt   2.31.10 2.32.0 FALSE
>> IRanges2.9.19 2.10.0  TRUE
>> S4Vectors 0.13.17 0.14.0  TRUE
>>
>> Do you want to install from sources the packages which need compilation?
>> y/n:
>>
>> sessionInfo()
>>>
>> R version 3.4.0 (2017-04-21)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 14393)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> other attached packages:
>> [1] BiocInstaller_1.26.0
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.4.0 tools_3.4.0
>>
>>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Windows binaries for the new release?

[James W. MacDonald]

On Wed, Apr 26, 2017 at 11:11 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 04/26/2017 10:34 AM, James W. MacDonald wrote:
>
>>
>>
>> On Wed, Apr 26, 2017 at 10:09 AM, Martin Morgan
>> mailto:martin.mor...@roswellpark.org>>
>>
>> wrote:
>>
>> On 04/26/2017 10:00 AM, James W. MacDonald wrote:
>>
>> I see the binaries on the respective web pages, but biocLite
>> seems not to:
>>
>>
>> I'm not 100% sure but can you try again in a new R session? I think
>> you have a cached version of the repository index.
>>
>>
>> At a command prompt, using --vanilla:
>>
>> C:\Users\jmacdon> C:\Progra~1\R\R-3.4.0\bin\x64\R --vanilla
>>
>> R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
>> Copyright (C) 2017 The R Foundation for Statistical Computing
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>   Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>> library(BiocInstaller)
>>>
>> Bioconductor version 3.5 (BiocInstaller 1.26.0), ?biocLite for help
>>
>>> biocLite()
>>>
>> BioC_mirror: https://bioconductor.org
>> Using Bioconductor 3.5 (BiocInstaller 1.26.0), R 3.4.0 (2017-04-21).
>> installation path not writeable, unable to update packages: foreign
>> Old packages: 'Biobase', 'IRanges', 'S4Vectors'
>> Update all/some/none? [a/s/n]: a
>>
>>   There are binary versions available but the source versions are later:
>>binary source needs_compilation
>> Biobase2.35.1 2.36.0  TRUE
>> IRanges2.9.19 2.10.0  TRUE
>> S4Vectors 0.13.17 0.14.0  TRUE
>>
>> Do you want to install from sources the packages which need compilation?
>> y/n:
>>
>> Is there a way to remove the cache manually? I have already uninstalled
>> and re-installed BiocInstaller.
>>
>
>   contrib.url(BiocInstaller::biocinstallRepos())
>
> should be pointing to
>
>   https://bioconductor.org/packages/3.5/bioc/bin/windows/contrib
>
> and
>
>   https://bioconductor.org/packages/3.5/bioc/bin/windows/contrib
> /3.4/PACKAGES
>
> has the current information
>
> Package: Biobase
> Version: 2.36.0
> Depends: R (>= 2.10), BiocGenerics (>= 0.3.2), utils
> Imports: methods
> Suggests: tools, tkWidgets, ALL, RUnit, golubEsets
> License: Artistic-2.0
> Archs: i386, x64
>
> as well as in R
>
> > fl = "https://bioconductor.org/packages/3.5/bioc/bin/windows/cont
> rib/3.4/PACKAGES.rds"
> > xx = readRDS(url(fl))
> > xx['Biobase', , drop=FALSE]Package   Version  Priority
> Biobase "Biobase" "2.36.0" NA
> Depends   Imports   LinkingTo
> Biobase "R (>= 2.10), BiocGenerics (>= 0.3.2), utils" "methods" NA
> Suggests   Enhances License
> Biobase "tools, tkWidgets, ALL, RUnit, golubEsets" NA   "Artistic-2.0"
> License_is_FOSS License_restricts_use OS_type Archs   MD5sum
> Biobase NA  NANA  "i386, x64" NA
>
> should be pointing to the current .zip files.
>
> biocLite() delegates to available.packages(), which should be checking the
> session temporary directory and, since you're in a new session, retrieving
> the rds file above. You could
>
>   debug(available.packages)
>
> and try and figure out where the issue is?
>
> FWIW with a new R installation I could not reproduce your problem.


OK. If it's just weirdness on my end I don't really care. I was just
concerned that this would be a problem for regular end users.

Thanks,

Jim



>
>
> > sessionInfo()
> R version 3.4.0 (2017-04-21)
> Platform: i386-w64-mingw32/i386 (32-bit)
> Running under: Windows Server 2012 R2 x64 (build 9600)
>
> Matrix products: default
>
> lo

Re: [Bioc-devel] Windows binaries for the new release?

[James W. MacDonald]

On Wed, Apr 26, 2017 at 11:26 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 04/26/2017 11:23 AM, James W. MacDonald wrote:
>
>>
>>
>> On Wed, Apr 26, 2017 at 11:11 AM, Martin Morgan
>> mailto:martin.mor...@roswellpark.org>>
>> wrote:
>>
>> On 04/26/2017 10:34 AM, James W. MacDonald wrote:
>>
>>
>>
>> On Wed, Apr 26, 2017 at 10:09 AM, Martin Morgan
>> > <mailto:martin.mor...@roswellpark.org>
>> <mailto:martin.mor...@roswellpark.org
>>
>>     <mailto:martin.mor...@roswellpark.org>>>
>>
>> wrote:
>>
>> On 04/26/2017 10:00 AM, James W. MacDonald wrote:
>>
>> I see the binaries on the respective web pages, but
>> biocLite
>> seems not to:
>>
>>
>> I'm not 100% sure but can you try again in a new R session?
>> I think
>> you have a cached version of the repository index.
>>
>>
>> At a command prompt, using --vanilla:
>>
>> C:\Users\jmacdon> C:\Progra~1\R\R-3.4.0\bin\x64\R --vanilla
>>
>> R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
>> Copyright (C) 2017 The R Foundation for Statistical Computing
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>   Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>> library(BiocInstaller)
>>
>> Bioconductor version 3.5 (BiocInstaller 1.26.0), ?biocLite for
>> help
>>
>> biocLite()
>>
>> BioC_mirror: https://bioconductor.org
>> Using Bioconductor 3.5 (BiocInstaller 1.26.0), R 3.4.0
>> (2017-04-21).
>> installation path not writeable, unable to update packages:
>> foreign
>> Old packages: 'Biobase', 'IRanges', 'S4Vectors'
>> Update all/some/none? [a/s/n]: a
>>
>>   There are binary versions available but the source versions
>> are later:
>>binary source needs_compilation
>> Biobase2.35.1 2.36.0  TRUE
>> IRanges2.9.19 2.10.0  TRUE
>> S4Vectors 0.13.17 0.14.0  TRUE
>>
>> Do you want to install from sources the packages which need
>> compilation?
>> y/n:
>>
>> Is there a way to remove the cache manually? I have already
>> uninstalled
>> and re-installed BiocInstaller.
>>
>>
>>   contrib.url(BiocInstaller::biocinstallRepos())
>>
>> should be pointing to
>>
>>   https://bioconductor.org/packages/3.5/bioc/bin/windows/contrib
>> <https://bioconductor.org/packages/3.5/bioc/bin/windows/contrib>
>>
>> and
>>
>>   https://bioconductor.org/packages/3.5/bioc/bin/windows/contrib
>> <https://bioconductor.org/packages/3.5/bioc/bin/windows/contrib>
>> /3.4/PACKAGES
>>
>> has the current information
>>
>> Package: Biobase
>> Version: 2.36.0
>> Depends: R (>= 2.10), BiocGenerics (>= 0.3.2), utils
>> Imports: methods
>> Suggests: tools, tkWidgets, ALL, RUnit, golubEsets
>> License: Artistic-2.0
>> Archs: i386, x64
>>
>> as well as in R
>>
>> > fl =
>> "https://bioconductor.org/packages/3.5/bioc/bin/windows/cont
>> rib/3.4/PACKAGES.rds
>> <https://bioconductor.org/packages/3.5/bioc/bin/windows/cont
>> rib/3.4/PACKAGES.rds>"
>> > xx = readRDS(url(fl))
>> > xx['Biobase', , drop=FALSE]Package   Version  Priority
>> Biobase "Biobase" "2.36.0" NA
>> Depends

Re: [Bioc-devel] Question about creating a bulleted list without bullets in rstudio

[James W. MacDonald]

https://stackoverflow.com/questions/9267584/when-documenting-in-roxygen-how-do-i-make-an-itemized-list-in-details

See last answer. It's not clear to me if you can have bulletted lists in
all of the sections of an Rd file or not, so it may be that the 'value'
section can't have bulletted lists. I don't see anything in the R-exts
manual that precludes it, however.

On Fri, Jun 9, 2017 at 11:08 AM, Aimin Yan  wrote:

> I have a question about making R package documentation.
>
> I use rstudio to make this package. In my test.R file, I have code like the
> following:
>
> ...
>
> #' @return Returns a dataframe with several following variables (columns)
> #'   \itemize{
> #'  \item geneID: Gene ID
> #'  \item geneWisePvalue: each gene is represented by the smallest
> p-value among its features
> #'  \item sig.gene: a gene is significant (1) or not (0)
> #'  \item mostSigDeFeature: the most significant gene feature
> #'  \item numFeature: number of gene features within the gene
> #' }
>
> ...
>
> After rebuild, I get help documentation like the following:
> Value
>
> Returns a dataframe with several following variables (columns)
>
>-
>
>geneID: Gene ID
>-
>
>geneWisePvalue: each gene is represented by the smallest p-value among
>its features
>-
>
>sig.gene: a gene is significant (1) or not (0)
>-
>
>mostSigDeFeature: the most significant gene feature
>-
>
>numFeature: number of gene features within the gene
>
>
>Now, I want to get the following:
>Value
>
>Returns a dataframe with several following variables (columns)
>
>  geneID: Gene ID
>
>  geneWisePvalue: each gene is represented by the smallest
>p-value among its features
>
>  sig.gene: a gene is significant (1) or not (0)
>
>  mostSigDeFeature: the most significant gene feature
>
>  numFeature: number of gene features within the gene
>
>That is to say, to create a a bulleted list without bullets.
>
>Does anyone has idea on how to change settings in test.R file?
>
>
>Thank you,
>
>Aimin
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Updating package development version

[James W. MacDonald]

On Fri, Aug 18, 2017 at 1:46 PM, Pedro Russo  wrote:

> Dear maintainers,
>
> I've followed the tutorials for updating my package CEMiTool in the new Git
> server as detailed in:
>
> https://www.bioconductor.org/developers/how-to/git/bug-fix-
> in-release-and-devel/
>
> including the steps
>
> git checkout master
> git push upstream master
> git push origin master
>
> However, when I execute useDevel() and biocLite("CEMiTool"), I see that the
> changes I made aren't there.
>

When did you make those changes? Do note that it takes a day or so for any
changes to propagate through the build servers, so changes don't appear
right away.



>
> The url for my package,
> https://bioconductor.org/packages/devel/bioc/html/CEMiTool.html
>
> also shows a previous version of the package.
>
> I'm new to Bioconductor package maintenance, so I apologize if I'm missing
> anything simple, but I'm really stuck!
>
> [[alternative HTML version deleted]]
>
> _______
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Git transition -- regenerating repositories from svn

[James W. MacDonald]

roblem is manifest as 'unknown' authors in
>> a git commit, e.g., in Biobase from svn user 'jmc'
>>
>> commit b5ae43bc8aae967b80062da13e5085a6a305b274
>> Author: unknown 
>> Date:   Fri Dec 7 15:17:06 2001 +
>>
>>  fixed the arguments to 'show' methods
>>
>>
>> A more common problem is that the git author 'name' is 'unknown', as in
>> this limma commit
>>
>> commit 5910dc34a952a72816ada787d3f2c849edf48a95
>> Author: unknown 
>> Date:   Tue Jul 25 07:23:39 2017 +
>>
>>
>>
>> The problem primarily affects users with svn accounts from the earlier
>> part of Bioconductor's svn history, and stems from incomplete historical
>> records about the user name associated with svn accounts (this information
>> is not stored in svn per se).
>>
>> Please feel free to respond here if your package is listed above but you
>> would like it to be regenerated anyway; remember that you will loose any
>> commits made, and invalidate your local repository.
>>
>> Sorry for the inconvenience,
>>
>> Martin
>>
>>
>> This email message may contain legally privileged and/or...{{dropped:2}}
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel