date:20150317

Re: [Bioc-devel] zero-width ranges representing insertions

2015-03-17 Thread Hervé Pagès

On 03/16/2015 07:36 PM, Valerie Obenchain wrote:

On 03/16/2015 05:31 PM, Hervé Pagès wrote:

On 03/16/2015 04:06 PM, Michael Lawrence wrote:

On Mon, Mar 16, 2015 at 3:12 PM, Robert Castelo mailto:robert.cast...@upf.edu>> wrote:

+1 IMO BioC could adopt the zero-width ranges representation for
insertions, adapting readVcf(), writeVcf(), XtraSNPlocs.*, etc., to
deal with each corresponding beast, be VCF, dbSNP or the like. Who
knows, VCF could also change their representation in the future and
it'll be a headache to update the affected packages if we decide to
keep using its insertion representation internally to store variant
ranges in BioC.

That would break just about every tool, so let's hope not. There's a
bunch of code on top of Bioc that currently depends on the current
representation. For example, zero width ranges do not overlap anything,
so they need special treatment to e.g. detect whether an insertion falls
within a gene. There are real benefits to keeping the representation of
indels consistent with the rest of the field (VCF). There was much
thought put into this.

Note that findOverlaps() now handles zero-width ranges.

predictCoding and locateVariants had to work around the fact that
findOverlaps didn't work on zero-length ranges. Now that we can handle
zero-length overlaps this code should be updated (yes, my fault for not
updating).

How predictCoding and locateVariants currently handle insertions can be
modified. The current behavior (bug) should not have no bearing on how
we want to represent indels in the VCF class in general.

I agree with Michael that much thought went into making the VCF class
consistent with the VCF specs. While information has been added to the
file format over the years I am not aware of any changes related to the
positional representation of the variant (ie, it has been stable) and
think it unlikely this would change in the future.

Just to clarify, my point was that the ranges of the insertions as
currently reported in VCF and VRanges objects cannot be used as-is
in findOverlaps() to detect whether an insertion falls within a gene
or where is falls exactly within a gene. So these ranges need special
treatment like zero-width ranges do.

H.

Val

Straight use of findOverlaps() on the ranges of a VCF object leads to
some subtle problems on insertions. For example predictCoding() (which
I guess uses findOverlaps() internally) reports strange things for
these 2 insertions (1 right before and 1 right after the stop codon):

library(TxDb.Hsapiens.UCSC.hg19.knownGene)
txdb <- TxDb.Hsapiens.UCSC.hg19.knownGene

 > cdsBy(txdb, use.names=TRUE)$uc002wcw.3
GRanges object with 2 ranges and 3 metadata columns:
   seqnames ranges strand |cds_idcds_name exon_rank
   |   
   [1]chr20 [68351, 68408]  + |206100 1
   [2]chr20 [76646, 77058]  + |206101 2
   ---
   seqinfo: 93 sequences (1 circular) from hg19 genome

library(VariantAnnotation)
 > rowRanges(vcf)  # hand-made VCF
GRanges object with 2 ranges and 5 metadata columns:
 seqnames ranges strand | paramRangeID
 | 
   ins before stop codonchr20 [77055, 77055]  * | 
ins after stop codonchr20 [77058, 77058]  * | 
REFALT  QUAL
FILTER

   ins before stop codon  T TG70
PASS
ins after stop codon  A AG70
PASS
   ---
   seqinfo: 1 sequence from hg19 genome

Calling predictCoding():

 > library(BSgenome.Hsapiens.UCSC.hg19)
 > predictCoding(vcf, txdb, Hsapiens)
GRanges object with 2 ranges and 17 metadata columns:
 seqnames ranges strand | paramRangeID
 | 
   ins before stop codonchr20 [77055, 77055]  + | 
ins after stop codonchr20 [77058, 77058]  + | 
REFALT  QUAL
FILTER

   ins before stop codon  T TG70
PASS
ins after stop codon  A AG70
PASS
  varAllele CDSLOCPROTEINLOC
QUERYID

   ins before stop codon TG [468, 468]
156 1
ins after stop codon AG [471, 471]
157 2
TXID CDSID  GENEID
CONSEQUENCE

   ins before stop codon   70477245938
frameshift
ins after stop codon   70477245938
frameshift
   REFCODON   VARCODON REFAA

   ins before stop codonAATAAT

Re: [Bioc-devel] Bioconductor 3.1 release schedule now available

2015-03-17 Thread Martin, Tiphaine

Thank Kasper and Dan for your explanations.
Yes, it will be the first release of my package that has currently a
version number of 0.99.9

Regards,

Tiphaine

On 17/03/2015 02:34, "Dan Tenenbaum"  wrote:

>
>
>- Original Message -
>> From: "Kasper Daniel Hansen" 
>> To: "Tiphaine Martin" 
>> Cc: "Dan Tenenbaum" , "bioc-devel"
>>
>> Sent: Monday, March 16, 2015 6:43:40 PM
>> Subject: Re: [Bioc-devel] Bioconductor 3.1 release schedule now
>>available
>> 
>> 
>> If your package passes build and check without warnings it happens
>> automatically, including the version bump.
>> 
>
>Yes, the only time you need to let us know is if you DO NOT want your
>package in the release.
>
>> 
>> If this is the first release of your package, it should have a
>> version number of 0.99.Z (which seems to be the case). This is
>> checked / fixed when your package gets accepted.
>> 
>
>Actually it's done during the release process. So your package will
>remain at 0.99.z until the release but then in the new release branch it
>will be 1.0.0 and in the new devel (trunk) it will be 1.1.0. See
>http://bioconductor.org/developers/how-to/version-numbering/
>
>Dan
>
>
>> 
>> Best,
>> Kasper
>> 
>> 
>> On Mon, Mar 16, 2015 at 9:29 PM, Martin, Tiphaine <
>> tiphaine.mar...@kcl.ac.uk > wrote:
>> 
>> 
>> Dear Dan,
>> 
>> I have 2 naive questions.
>> I would like to know whether we (developers of a R package currently
>> only in the development version of Bioconductor) need to say that we
>> would like to have our packages accessible in the next version of
>> Bioconductor or it is automatic for any packages passing R CMD build
>> and check without warning.
>> If I have my new package that is going in the next release, should I
>> need to upgrade the version of my package ( from 0.99.Z to 1.0.0 )
>> and push it in svn or is it also done automatically ?
>> 
>> Regards,
>> 
>> Tiphaine
>> 
>> 
>> From: Bioc-devel < bioc-devel-boun...@r-project.org > on behalf of
>> Dan Tenenbaum < dtene...@fredhutch.org >
>> Sent: 27 February 2015 18:14
>> To: bioc-devel
>> Subject: Re: [Bioc-devel] Bioconductor 3.1 release schedule now
>> available
>> 
>> 
>> 
>> - Original Message -
>> > From: "Dan Tenenbaum" < dtene...@fredhutch.org >
>> > To: "bioc-devel" < bioc-devel@r-project.org >
>> > Sent: Friday, February 27, 2015 10:12:44 AM
>> > Subject: [Bioc-devel] Bioconductor 3.1 release schedule now
>> > available
>> > 
>> > Hi all,
>> > 
>> > The next version of Bioconductor will be 3.0 and its release
>> > schedule
>> > is now up on our website:
>> > 
>> 
>> 3.1 of course! Sorry for the typo.
>> 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
>> 
>> 

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

Re: [Bioc-devel] Contents of Bioc-devel digest

2015-03-17 Thread Islam Tolan



[[alternative HTML version deleted]]

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

[Bioc-devel] FEM package updation build frequence

2015-03-17 Thread Yinming Jiao

Hi Guys

As a maintainer of FEM BioC package, a new FEM version(2.0.1, previous 1.1.0,  
z in the version number x.y.z is also  bumped)  is submitted to our SVN server 
last Sunday.It was built once on Monday, but it has an error. Then I 
resubmitted it.

In the following link http://bioconductor.org/checkResults/ ,so  how often are 
the packages built and checked.

And, after the package passes the check test, When will it be published on 
bioconductor.org website?

Thanks so much for your attention on our FEM package welcome to play with it. 

Really thanks for  your help. 

Kind Regards

Yinming

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

[Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

2015-03-17 Thread Robert Castelo


hi,

there is a little tiny bug in the current devel version of 
VariantAnnotation::predictCoding(), and more concretely within
VariantAnnotation:::.localCoordinates(), that precludes the correct 
annotation of the CDSID column:


library(VariantAnnotation)
library(TxDb.Hsapiens.UCSC.hg19.knownGene)
library(BSgenome.Hsapiens.UCSC.hg19)

vcf <- readVcf(system.file("extdata", "CEUtrio.vcf.bgz", 
package="VariantFiltering"), genome="hg19")

seqlevelsStyle(vcf) <- seqlevelsStyle(txdb)
vcf <- dropSeqlevels(vcf, "chrM")
coding1 <- predictCoding(vcf, txdb, Hsapiens)
head(coding1$CDSID)
IntegerList of length 6
[[1]] integer(0)
[[2]] integer(0)
[[3]] integer(0)
[[4]] integer(0)
[[5]] integer(0)
[[6]] integer(0)
table(elementLengths(coding1$CDSID))

   0
6038

my sessionInfo() is at the end of the message.

here is the patch, just replacing 'map2$trancriptHits' by 
'map2$transcriptsHits':


--- R/AllUtilities.R(revision 100756)
+++ R/AllUtilities.R(working copy)
@@ -284,7 +284,7 @@
 cdsid <- IntegerList(integer(0))
 map2 <- mapToTranscripts(unname(from)[xHits], to,
  ignore.strand=ignore.strand)
-cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$trancriptsHits]
+cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$transcriptsHits]
 if (length(cds)) {
 cdslst <- unique(splitAsList(cds, map2$xHits))
 cdsid <- cdslst

with this fix then things seem to work again:

coding1 <- predictCoding(vcf, txdb, Hsapiens)
> head(coding1$CDSID)
IntegerList of length 6
[["1"]] 21771
[["2"]] 21771
[["3"]] 21771
[["4"]] 21771
[["5"]] 21428
[["6"]] 21428
table(elementLengths(coding1$CDSID))

   123456789   10   12   13   14   16   19
 873 1229 1024  993  615  524  324  168   82   21   12   15   42   76   40

while investigating this bug i used VariantAnnotation::locateVariants() 
which also annotates the CDSID column, and it seemed to be working. 
however, i noticed that both, predictCoding() and locateVariants(), do 
not give an identical annotation for the CDSID column in coding variants:


coding2 <- locateVariants(vcf, txdb, CodingVariants())
head(loc_all$CDSID)
IntegerList of length 6
[["1"]] 210777
[["2"]] 210777
[["3"]] 210777
[["4"]] 210778
[["5"]] 208140
[["6"]] 208141
table(elementLengths(coding2$CDSID))

   1234
4987  901  138   12

in principle, it seems that both are annotating valid CDSID keys:

allcdsinfo <- select(txdb, keys=keys(txdb, keytype="CDSID"), 
columns="CDSID", keytype="CDSID")
sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in% 
allcdsinfo$CDSID)

[1] 0
sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in% 
allcdsinfo$CDSID)

[1] 0

but predictCoding() annotates CDSID values that are not present in 
locateVariants() annotations and viceversa:


sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in% 
as.character(unlist(coding2$CDSID, use.names=FALSE)))

[1] 24057
sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in% 
as.character(unlist(coding1$CDSID, use.names=FALSE)))

[1] 7251

length(unique(intersect(as.character(unlist(coding2$CDSID, 
use.names=FALSE)), as.character(unlist(coding1$CDSID, use.names=FALSE)

[1] 0

should not both annotate the same CDSID values on coding variants?


thanks!
robert.
ps: sessionInfo()
R Under development (unstable) (2014-10-14 r66765)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
 [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
 [7] LC_PAPER=en_US.UTF8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C

attached base packages:
[1] stats4parallel  stats graphics  grDevices
[6] utils datasets  methods   base

other attached packages:
 [1] TxDb.Hsapiens.UCSC.hg19.knownGene_3.1.1
 [2] GenomicFeatures_1.19.31
 [3] AnnotationDbi_1.29.17
 [4] Biobase_2.27.2
 [5] BSgenome.Hsapiens.UCSC.hg19_1.4.0
 [6] BSgenome_1.35.17
 [7] rtracklayer_1.27.8
 [8] VariantAnnotation_1.13.40
 [9] Rsamtools_1.19.44
[10] Biostrings_2.35.11
[11] XVector_0.7.4
[12] GenomicRanges_1.19.46
[13] GenomeInfoDb_1.3.13
[14] IRanges_2.1.43
[15] S4Vectors_0.5.22
[16] BiocGenerics_0.13.6
[17] vimcom_1.0-0
[18] setwidth_1.0-3
[19] colorout_1.0-3

loaded via a namespace (and not attached):
 [1] BiocParallel_1.1.15  biomaRt_2.23.5
 [3] bitops_1.0-6 DBI_0.3.1
 [5] GenomicAlignments_1.3.31 RCurl_1.95-4.5
 [7] RSQLite_1.0.0tools_3.2.0
 [9] XML_3.98-1.1 zlibbioc_1.13.2

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

[Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

2015-03-17 Thread Robert Castelo


in my message below, the line that it says:

head(loc_all$CDSID)

it should say

head(coding2$CDSID)

cheers,

robert.

==
hi,

there is a little tiny bug in the current devel version of 
VariantAnnotation::predictCoding(), and more concretely within
VariantAnnotation:::.localCoordinates(), that precludes the correct 
annotation of the CDSID column:


library(VariantAnnotation)
library(TxDb.Hsapiens.UCSC.hg19.knownGene)
library(BSgenome.Hsapiens.UCSC.hg19)

vcf <- readVcf(system.file("extdata", "CEUtrio.vcf.bgz", 
package="VariantFiltering"), genome="hg19")

seqlevelsStyle(vcf) <- seqlevelsStyle(txdb)
vcf <- dropSeqlevels(vcf, "chrM")
coding1 <- predictCoding(vcf, txdb, Hsapiens)
head(coding1$CDSID)
IntegerList of length 6
[[1]] integer(0)
[[2]] integer(0)
[[3]] integer(0)
[[4]] integer(0)
[[5]] integer(0)
[[6]] integer(0)
table(elementLengths(coding1$CDSID))

   0
6038

my sessionInfo() is at the end of the message.

here is the patch, just replacing 'map2$trancriptHits' by 
'map2$transcriptsHits':


--- R/AllUtilities.R(revision 100756)
+++ R/AllUtilities.R(working copy)
@@ -284,7 +284,7 @@
 cdsid <- IntegerList(integer(0))
 map2 <- mapToTranscripts(unname(from)[xHits], to,
  ignore.strand=ignore.strand)
-cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$trancriptsHits]
+cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$transcriptsHits]
 if (length(cds)) {
 cdslst <- unique(splitAsList(cds, map2$xHits))
 cdsid <- cdslst

with this fix then things seem to work again:

coding1 <- predictCoding(vcf, txdb, Hsapiens)

head(coding1$CDSID)

IntegerList of length 6
[["1"]] 21771
[["2"]] 21771
[["3"]] 21771
[["4"]] 21771
[["5"]] 21428
[["6"]] 21428
table(elementLengths(coding1$CDSID))

   123456789   10   12   13   14   16   19
 873 1229 1024  993  615  524  324  168   82   21   12   15   42   76   40

while investigating this bug i used VariantAnnotation::locateVariants() 
which also annotates the CDSID column, and it seemed to be working. 
however, i noticed that both, predictCoding() and locateVariants(), do 
not give an identical annotation for the CDSID column in coding variants:


coding2 <- locateVariants(vcf, txdb, CodingVariants())
head(loc_all$CDSID)
IntegerList of length 6
[["1"]] 210777
[["2"]] 210777
[["3"]] 210777
[["4"]] 210778
[["5"]] 208140
[["6"]] 208141
table(elementLengths(coding2$CDSID))

   1234
4987  901  138   12

in principle, it seems that both are annotating valid CDSID keys:

allcdsinfo <- select(txdb, keys=keys(txdb, keytype="CDSID"), 
columns="CDSID", keytype="CDSID")
sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in% 
allcdsinfo$CDSID)

[1] 0
sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in% 
allcdsinfo$CDSID)

[1] 0

but predictCoding() annotates CDSID values that are not present in 
locateVariants() annotations and viceversa:


sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in% 
as.character(unlist(coding2$CDSID, use.names=FALSE)))

[1] 24057
sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in% 
as.character(unlist(coding1$CDSID, use.names=FALSE)))

[1] 7251

length(unique(intersect(as.character(unlist(coding2$CDSID, 
use.names=FALSE)), as.character(unlist(coding1$CDSID, use.names=FALSE)

[1] 0

should not both annotate the same CDSID values on coding variants?


thanks!
robert.
ps: sessionInfo()
R Under development (unstable) (2014-10-14 r66765)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
 [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
 [7] LC_PAPER=en_US.UTF8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C

attached base packages:
[1] stats4parallel  stats graphics  grDevices
[6] utils datasets  methods   base

other attached packages:
 [1] TxDb.Hsapiens.UCSC.hg19.knownGene_3.1.1
 [2] GenomicFeatures_1.19.31
 [3] AnnotationDbi_1.29.17
 [4] Biobase_2.27.2
 [5] BSgenome.Hsapiens.UCSC.hg19_1.4.0
 [6] BSgenome_1.35.17
 [7] rtracklayer_1.27.8
 [8] VariantAnnotation_1.13.40
 [9] Rsamtools_1.19.44
[10] Biostrings_2.35.11
[11] XVector_0.7.4
[12] GenomicRanges_1.19.46
[13] GenomeInfoDb_1.3.13
[14] IRanges_2.1.43
[15] S4Vectors_0.5.22
[16] BiocGenerics_0.13.6
[17] vimcom_1.0-0
[18] setwidth_1.0-3
[19] colorout_1.0-3

loaded via a namespace (and not attached):
 [1] BiocParallel_1.1.15  biomaRt_2.23.5
 [3] bitops_1.0-6 DBI_0.3.1
 [5] GenomicAlignments_1.3.31 RCurl_1.95-4.5
 [7] RSQLite_1.0.0tools_3.2.0
 [9] XML_3.98-1.1 zlibbioc_1.13.2

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

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

2015-03-17 Thread Valerie Obenchain


Hi Robert,

Thanks for reporting the typo and bug. Now fixed in 1.13.41.

Valerie

On 03/17/2015 10:58 AM, Robert Castelo wrote:

in my message below, the line that it says:

head(loc_all$CDSID)

it should say

head(coding2$CDSID)

cheers,

robert.

==
hi,

there is a little tiny bug in the current devel version of
VariantAnnotation::predictCoding(), and more concretely within
VariantAnnotation:::.localCoordinates(), that precludes the correct
annotation of the CDSID column:

library(VariantAnnotation)
library(TxDb.Hsapiens.UCSC.hg19.knownGene)
library(BSgenome.Hsapiens.UCSC.hg19)

vcf <- readVcf(system.file("extdata", "CEUtrio.vcf.bgz",
package="VariantFiltering"), genome="hg19")
seqlevelsStyle(vcf) <- seqlevelsStyle(txdb)
vcf <- dropSeqlevels(vcf, "chrM")
coding1 <- predictCoding(vcf, txdb, Hsapiens)
head(coding1$CDSID)
IntegerList of length 6
[[1]] integer(0)
[[2]] integer(0)
[[3]] integer(0)
[[4]] integer(0)
[[5]] integer(0)
[[6]] integer(0)
table(elementLengths(coding1$CDSID))

0
6038

my sessionInfo() is at the end of the message.

here is the patch, just replacing 'map2$trancriptHits' by
'map2$transcriptsHits':

--- R/AllUtilities.R(revision 100756)
+++ R/AllUtilities.R(working copy)
@@ -284,7 +284,7 @@
  cdsid <- IntegerList(integer(0))
  map2 <- mapToTranscripts(unname(from)[xHits], to,
   ignore.strand=ignore.strand)
-cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$trancriptsHits]
+cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$transcriptsHits]
  if (length(cds)) {
  cdslst <- unique(splitAsList(cds, map2$xHits))
  cdsid <- cdslst

with this fix then things seem to work again:

coding1 <- predictCoding(vcf, txdb, Hsapiens)

head(coding1$CDSID)

IntegerList of length 6
[["1"]] 21771
[["2"]] 21771
[["3"]] 21771
[["4"]] 21771
[["5"]] 21428
[["6"]] 21428
table(elementLengths(coding1$CDSID))

123456789   10   12   13   14   16   19
  873 1229 1024  993  615  524  324  168   82   21   12   15   42   76   40

while investigating this bug i used VariantAnnotation::locateVariants()
which also annotates the CDSID column, and it seemed to be working.
however, i noticed that both, predictCoding() and locateVariants(), do
not give an identical annotation for the CDSID column in coding variants:

coding2 <- locateVariants(vcf, txdb, CodingVariants())
head(loc_all$CDSID)
IntegerList of length 6
[["1"]] 210777
[["2"]] 210777
[["3"]] 210777
[["4"]] 210778
[["5"]] 208140
[["6"]] 208141
table(elementLengths(coding2$CDSID))

1234
4987  901  138   12

in principle, it seems that both are annotating valid CDSID keys:

allcdsinfo <- select(txdb, keys=keys(txdb, keytype="CDSID"),
columns="CDSID", keytype="CDSID")
sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
allcdsinfo$CDSID)
[1] 0
sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
allcdsinfo$CDSID)
[1] 0

but predictCoding() annotates CDSID values that are not present in
locateVariants() annotations and viceversa:

sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
as.character(unlist(coding2$CDSID, use.names=FALSE)))
[1] 24057
sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
as.character(unlist(coding1$CDSID, use.names=FALSE)))
[1] 7251

length(unique(intersect(as.character(unlist(coding2$CDSID,
use.names=FALSE)), as.character(unlist(coding1$CDSID, use.names=FALSE)
[1] 0

should not both annotate the same CDSID values on coding variants?


thanks!
robert.
ps: sessionInfo()
R Under development (unstable) (2014-10-14 r66765)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
  [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
  [7] LC_PAPER=en_US.UTF8   LC_NAME=C
  [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C

attached base packages:
[1] stats4parallel  stats graphics  grDevices
[6] utils datasets  methods   base

other attached packages:
  [1] TxDb.Hsapiens.UCSC.hg19.knownGene_3.1.1
  [2] GenomicFeatures_1.19.31
  [3] AnnotationDbi_1.29.17
  [4] Biobase_2.27.2
  [5] BSgenome.Hsapiens.UCSC.hg19_1.4.0
  [6] BSgenome_1.35.17
  [7] rtracklayer_1.27.8
  [8] VariantAnnotation_1.13.40
  [9] Rsamtools_1.19.44
[10] Biostrings_2.35.11
[11] XVector_0.7.4
[12] GenomicRanges_1.19.46
[13] GenomeInfoDb_1.3.13
[14] IRanges_2.1.43
[15] S4Vectors_0.5.22
[16] BiocGenerics_0.13.6
[17] vimcom_1.0-0
[18] setwidth_1.0-3
[19] colorout_1.0-3

loaded via a namespace (and not attached):
  [1] BiocParallel_1.1.15  biomaRt_2.23.5
  [3] bitops_1.0-6 DBI_0.3.1
  [5] GenomicAlignments_1.3.31 RCurl_1.95-4.5
  [7] RSQLite_1.0.0tools_3.2.0
  [9] XML_3.98-1.1 zlibbioc_1.13.2

___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

2015-03-17 Thread Robert Castelo

Thanks! Do you have an explanation for the apparent disagreement in CDSID 
annotations that i described below the bug, between predictCoding() and 
locateVariants()?

robert.

 Original message 
From: Valerie Obenchain  
Date:17/03/2015  19:18  (GMT+01:00) 
To: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] little tiny bug in CDSID annotations from
predictCoding() 

Hi Robert,

Thanks for reporting the typo and bug. Now fixed in 1.13.41.

Valerie

On 03/17/2015 10:58 AM, Robert Castelo wrote:
> in my message below, the line that it says:
>
> head(loc_all$CDSID)
>
> it should say
>
> head(coding2$CDSID)
>
> cheers,
>
> robert.
>
> ==
> hi,
>
> there is a little tiny bug in the current devel version of
> VariantAnnotation::predictCoding(), and more concretely within
> VariantAnnotation:::.localCoordinates(), that precludes the correct
> annotation of the CDSID column:
>
> library(VariantAnnotation)
> library(TxDb.Hsapiens.UCSC.hg19.knownGene)
> library(BSgenome.Hsapiens.UCSC.hg19)
>
> vcf <- readVcf(system.file("extdata", "CEUtrio.vcf.bgz",
> package="VariantFiltering"), genome="hg19")
> seqlevelsStyle(vcf) <- seqlevelsStyle(txdb)
> vcf <- dropSeqlevels(vcf, "chrM")
> coding1 <- predictCoding(vcf, txdb, Hsapiens)
> head(coding1$CDSID)
> IntegerList of length 6
> [[1]] integer(0)
> [[2]] integer(0)
> [[3]] integer(0)
> [[4]] integer(0)
> [[5]] integer(0)
> [[6]] integer(0)
> table(elementLengths(coding1$CDSID))
>
> 0
> 6038
>
> my sessionInfo() is at the end of the message.
>
> here is the patch, just replacing 'map2$trancriptHits' by
> 'map2$transcriptsHits':
>
> --- R/AllUtilities.R    (revision 100756)
> +++ R/AllUtilities.R    (working copy)
> @@ -284,7 +284,7 @@
>   cdsid <- IntegerList(integer(0))
>   map2 <- mapToTranscripts(unname(from)[xHits], to,
>    ignore.strand=ignore.strand)
> -    cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$trancriptsHits]
> +    cds <- mcols(unlist(to, use.names=FALSE))$cds_id[map2$transcriptsHits]
>   if (length(cds)) {
>   cdslst <- unique(splitAsList(cds, map2$xHits))
>   cdsid <- cdslst
>
> with this fix then things seem to work again:
>
> coding1 <- predictCoding(vcf, txdb, Hsapiens)
>> head(coding1$CDSID)
> IntegerList of length 6
> [["1"]] 21771
> [["2"]] 21771
> [["3"]] 21771
> [["4"]] 21771
> [["5"]] 21428
> [["6"]] 21428
> table(elementLengths(coding1$CDSID))
>
> 1    2    3    4    5    6    7    8    9   10   12   13   14   16   19
>   873 1229 1024  993  615  524  324  168   82   21   12   15   42   76   40
>
> while investigating this bug i used VariantAnnotation::locateVariants()
> which also annotates the CDSID column, and it seemed to be working.
> however, i noticed that both, predictCoding() and locateVariants(), do
> not give an identical annotation for the CDSID column in coding variants:
>
> coding2 <- locateVariants(vcf, txdb, CodingVariants())
> head(loc_all$CDSID)
> IntegerList of length 6
> [["1"]] 210777
> [["2"]] 210777
> [["3"]] 210777
> [["4"]] 210778
> [["5"]] 208140
> [["6"]] 208141
> table(elementLengths(coding2$CDSID))
>
> 1    2    3    4
> 4987  901  138   12
>
> in principle, it seems that both are annotating valid CDSID keys:
>
> allcdsinfo <- select(txdb, keys=keys(txdb, keytype="CDSID"),
> columns="CDSID", keytype="CDSID")
> sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
> allcdsinfo$CDSID)
> [1] 0
> sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
> allcdsinfo$CDSID)
> [1] 0
>
> but predictCoding() annotates CDSID values that are not present in
> locateVariants() annotations and viceversa:
>
> sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
> as.character(unlist(coding2$CDSID, use.names=FALSE)))
> [1] 24057
> sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
> as.character(unlist(coding1$CDSID, use.names=FALSE)))
> [1] 7251
>
> length(unique(intersect(as.character(unlist(coding2$CDSID,
> use.names=FALSE)), as.character(unlist(coding1$CDSID, use.names=FALSE)
> [1] 0
>
> should not both annotate the same CDSID values on coding variants?
>
>
> thanks!
> robert.
> ps: sessionInfo()
> R Under development (unstable) (2014-10-14 r66765)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
>   [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C
>   [3] LC_TIME=en_US.UTF8    LC_COLLATE=en_US.UTF8
>   [5] LC_MONETARY=en_US.UTF8    LC_MESSAGES=en_US.UTF8
>   [7] LC_PAPER=en_US.UTF8   LC_NAME=C
>   [9] LC_ADDRESS=C  LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats4    parallel  stats graphics  grDevices
> [6] utils datasets  methods   base
>
> other attached packages:
>   [1] TxDb.Hsapiens.UCSC.hg19.knownGene_3.1.1
>   [2] GenomicFeatures_1.19.31
>   [3] AnnotationDbi_1.29.17
>   [4] Biobase_2.27.2
>   [5] BSgenome.Hsapiens.UCSC.hg19_1.4.0
>   [6] BSgenome_1.35

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

2015-03-17 Thread Valerie Obenchain

The second mapping in .localCoordinates() in AllUtils.R was using a 
listed 'to' instead of unlisted 'to'. This means the mapping was at the 
level of the outer list elements vs the inner.  We want to map/overlap 
with an unlisted object because each range can have a different CDSID. 
This second mapping provided the index for retrieving the CDSIDs which 
is why you saw a difference between the two.


This was a bug for predictCoding only.

Valerie


On 03/17/2015 11:39 AM, Robert Castelo wrote:

Thanks! Do you have an explanation for the apparent disagreement in
CDSID annotations that i described below the bug, between
predictCoding() and locateVariants()?

robert.


 Original message 
From: Valerie Obenchain
Date:17/03/2015 19:18 (GMT+01:00)
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] little tiny bug in CDSID annotations from
predictCoding()

Hi Robert,

Thanks for reporting the typo and bug. Now fixed in 1.13.41.

Valerie

On 03/17/2015 10:58 AM, Robert Castelo wrote:
 > in my message below, the line that it says:
 >
 > head(loc_all$CDSID)
 >
 > it should say
 >
 > head(coding2$CDSID)
 >
 > cheers,
 >
 > robert.
 >
 > ==
 > hi,
 >
 > there is a little tiny bug in the current devel version of
 > VariantAnnotation::predictCoding(), and more concretely within
 > VariantAnnotation:::.localCoordinates(), that precludes the correct
 > annotation of the CDSID column:
 >
 > library(VariantAnnotation)
 > library(TxDb.Hsapiens.UCSC.hg19.knownGene)
 > library(BSgenome.Hsapiens.UCSC.hg19)
 >
 > vcf <- readVcf(system.file("extdata", "CEUtrio.vcf.bgz",
 > package="VariantFiltering"), genome="hg19")
 > seqlevelsStyle(vcf) <- seqlevelsStyle(txdb)
 > vcf <- dropSeqlevels(vcf, "chrM")
 > coding1 <- predictCoding(vcf, txdb, Hsapiens)
 > head(coding1$CDSID)
 > IntegerList of length 6
 > [[1]] integer(0)
 > [[2]] integer(0)
 > [[3]] integer(0)
 > [[4]] integer(0)
 > [[5]] integer(0)
 > [[6]] integer(0)
 > table(elementLengths(coding1$CDSID))
 >
 > 0
 > 6038
 >
 > my sessionInfo() is at the end of the message.
 >
 > here is the patch, just replacing 'map2$trancriptHits' by
 > 'map2$transcriptsHits':
 >
 > --- R/AllUtilities.R(revision 100756)
 > +++ R/AllUtilities.R(working copy)
 > @@ -284,7 +284,7 @@
 >   cdsid <- IntegerList(integer(0))
 >   map2 <- mapToTranscripts(unname(from)[xHits], to,
 >ignore.strand=ignore.strand)
 > -cds <- mcols(unlist(to,
use.names=FALSE))$cds_id[map2$trancriptsHits]
 > +cds <- mcols(unlist(to,
use.names=FALSE))$cds_id[map2$transcriptsHits]
 >   if (length(cds)) {
 >   cdslst <- unique(splitAsList(cds, map2$xHits))
 >   cdsid <- cdslst
 >
 > with this fix then things seem to work again:
 >
 > coding1 <- predictCoding(vcf, txdb, Hsapiens)
 >> head(coding1$CDSID)
 > IntegerList of length 6
 > [["1"]] 21771
 > [["2"]] 21771
 > [["3"]] 21771
 > [["4"]] 21771
 > [["5"]] 21428
 > [["6"]] 21428
 > table(elementLengths(coding1$CDSID))
 >
 > 123456789   10   12   13   14
16   19
 >   873 1229 1024  993  615  524  324  168   82   21   12   15   42
76   40
 >
 > while investigating this bug i used VariantAnnotation::locateVariants()
 > which also annotates the CDSID column, and it seemed to be working.
 > however, i noticed that both, predictCoding() and locateVariants(), do
 > not give an identical annotation for the CDSID column in coding variants:
 >
 > coding2 <- locateVariants(vcf, txdb, CodingVariants())
 > head(loc_all$CDSID)
 > IntegerList of length 6
 > [["1"]] 210777
 > [["2"]] 210777
 > [["3"]] 210777
 > [["4"]] 210778
 > [["5"]] 208140
 > [["6"]] 208141
 > table(elementLengths(coding2$CDSID))
 >
 > 1234
 > 4987  901  138   12
 >
 > in principle, it seems that both are annotating valid CDSID keys:
 >
 > allcdsinfo <- select(txdb, keys=keys(txdb, keytype="CDSID"),
 > columns="CDSID", keytype="CDSID")
 > sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
 > allcdsinfo$CDSID)
 > [1] 0
 > sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
 > allcdsinfo$CDSID)
 > [1] 0
 >
 > but predictCoding() annotates CDSID values that are not present in
 > locateVariants() annotations and viceversa:
 >
 > sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
 > as.character(unlist(coding2$CDSID, use.names=FALSE)))
 > [1] 24057
 > sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
 > as.character(unlist(coding1$CDSID, use.names=FALSE)))
 > [1] 7251
 >
 > length(unique(intersect(as.character(unlist(coding2$CDSID,
 > use.names=FALSE)), as.character(unlist(coding1$CDSID,
use.names=FALSE)
 > [1] 0
 >
 > should not both annotate the same CDSID values on coding variants?
 >
 >
 > thanks!
 > robert.
 > ps: sessionInfo()
 > R Under development (unstable) (2014-10-14 r66765)
 > Platform: x86_64-unknown-linux-gnu (64-bit)
 >
 > locale:
 >   [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

2015-03-17 Thread Robert Castelo

Ah, ok, sorry. I didn't get that this was also fixed at the same time.

Thanks
robert.



 Original message 
From: Valerie Obenchain  
Date:17/03/2015  19:59  (GMT+01:00) 
To: Robert Castelo ,bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] little tiny bug in CDSID annotations from  
predictCoding() 

The second mapping in .localCoordinates() in AllUtils.R was using a 
listed 'to' instead of unlisted 'to'. This means the mapping was at the 
level of the outer list elements vs the inner.  We want to map/overlap 
with an unlisted object because each range can have a different CDSID. 
This second mapping provided the index for retrieving the CDSIDs which 
is why you saw a difference between the two.

This was a bug for predictCoding only.

Valerie


On 03/17/2015 11:39 AM, Robert Castelo wrote:
> Thanks! Do you have an explanation for the apparent disagreement in
> CDSID annotations that i described below the bug, between
> predictCoding() and locateVariants()?
>
> robert.
>
>
>  Original message 
> From: Valerie Obenchain
> Date:17/03/2015 19:18 (GMT+01:00)
> To: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] little tiny bug in CDSID annotations from
> predictCoding()
>
> Hi Robert,
>
> Thanks for reporting the typo and bug. Now fixed in 1.13.41.
>
> Valerie
>
> On 03/17/2015 10:58 AM, Robert Castelo wrote:
>  > in my message below, the line that it says:
>  >
>  > head(loc_all$CDSID)
>  >
>  > it should say
>  >
>  > head(coding2$CDSID)
>  >
>  > cheers,
>  >
>  > robert.
>  >
>  > ==
>  > hi,
>  >
>  > there is a little tiny bug in the current devel version of
>  > VariantAnnotation::predictCoding(), and more concretely within
>  > VariantAnnotation:::.localCoordinates(), that precludes the correct
>  > annotation of the CDSID column:
>  >
>  > library(VariantAnnotation)
>  > library(TxDb.Hsapiens.UCSC.hg19.knownGene)
>  > library(BSgenome.Hsapiens.UCSC.hg19)
>  >
>  > vcf <- readVcf(system.file("extdata", "CEUtrio.vcf.bgz",
>  > package="VariantFiltering"), genome="hg19")
>  > seqlevelsStyle(vcf) <- seqlevelsStyle(txdb)
>  > vcf <- dropSeqlevels(vcf, "chrM")
>  > coding1 <- predictCoding(vcf, txdb, Hsapiens)
>  > head(coding1$CDSID)
>  > IntegerList of length 6
>  > [[1]] integer(0)
>  > [[2]] integer(0)
>  > [[3]] integer(0)
>  > [[4]] integer(0)
>  > [[5]] integer(0)
>  > [[6]] integer(0)
>  > table(elementLengths(coding1$CDSID))
>  >
>  > 0
>  > 6038
>  >
>  > my sessionInfo() is at the end of the message.
>  >
>  > here is the patch, just replacing 'map2$trancriptHits' by
>  > 'map2$transcriptsHits':
>  >
>  > --- R/AllUtilities.R    (revision 100756)
>  > +++ R/AllUtilities.R    (working copy)
>  > @@ -284,7 +284,7 @@
>  >   cdsid <- IntegerList(integer(0))
>  >   map2 <- mapToTranscripts(unname(from)[xHits], to,
>  >    ignore.strand=ignore.strand)
>  > -    cds <- mcols(unlist(to,
> use.names=FALSE))$cds_id[map2$trancriptsHits]
>  > +    cds <- mcols(unlist(to,
> use.names=FALSE))$cds_id[map2$transcriptsHits]
>  >   if (length(cds)) {
>  >   cdslst <- unique(splitAsList(cds, map2$xHits))
>  >   cdsid <- cdslst
>  >
>  > with this fix then things seem to work again:
>  >
>  > coding1 <- predictCoding(vcf, txdb, Hsapiens)
>  >> head(coding1$CDSID)
>  > IntegerList of length 6
>  > [["1"]] 21771
>  > [["2"]] 21771
>  > [["3"]] 21771
>  > [["4"]] 21771
>  > [["5"]] 21428
>  > [["6"]] 21428
>  > table(elementLengths(coding1$CDSID))
>  >
>  > 1    2    3    4    5    6    7    8    9   10   12   13   14
> 16   19
>  >   873 1229 1024  993  615  524  324  168   82   21   12   15   42
> 76   40
>  >
>  > while investigating this bug i used VariantAnnotation::locateVariants()
>  > which also annotates the CDSID column, and it seemed to be working.
>  > however, i noticed that both, predictCoding() and locateVariants(), do
>  > not give an identical annotation for the CDSID column in coding variants:
>  >
>  > coding2 <- locateVariants(vcf, txdb, CodingVariants())
>  > head(loc_all$CDSID)
>  > IntegerList of length 6
>  > [["1"]] 210777
>  > [["2"]] 210777
>  > [["3"]] 210777
>  > [["4"]] 210778
>  > [["5"]] 208140
>  > [["6"]] 208141
>  > table(elementLengths(coding2$CDSID))
>  >
>  > 1    2    3    4
>  > 4987  901  138   12
>  >
>  > in principle, it seems that both are annotating valid CDSID keys:
>  >
>  > allcdsinfo <- select(txdb, keys=keys(txdb, keytype="CDSID"),
>  > columns="CDSID", keytype="CDSID")
>  > sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
>  > allcdsinfo$CDSID)
>  > [1] 0
>  > sum(!as.character(unlist(coding2$CDSID, use.names=FALSE)) %in%
>  > allcdsinfo$CDSID)
>  > [1] 0
>  >
>  > but predictCoding() annotates CDSID values that are not present in
>  > locateVariants() annotations and viceversa:
>  >
>  > sum(!as.character(unlist(coding1$CDSID, use.names=FALSE)) %in%
>  > as.character(unlist(coding2$CDSID, use.names=FALS

Re: [Bioc-devel] FEM package updation build frequence

2015-03-17 Thread Dan Tenenbaum

Hi,



- Original Message -
> From: "Yinming Jiao" <20907...@zju.edu.cn>
> To: "bioc-devel" 
> Sent: Tuesday, March 17, 2015 7:52:20 AM
> Subject: [Bioc-devel] FEM package updation build frequence
> 
> Hi Guys
> 
> As a maintainer of FEM BioC package, a new FEM version(2.0.1,
> previous 1.1.0,  z in the version number x.y.z is also  bumped)  is
> submitted to our SVN server last Sunday.It was built once on Monday,
> but it has an error. Then I resubmitted it.
> 
> In the following link http://bioconductor.org/checkResults/ ,so  how
> often are the packages built and checked.
> 
> And, after the package passes the check test, When will it be
> published on bioconductor.org website?
> 

It was published on the Bioconductor web site:

http://bioconductor.org/packages/devel/bioc/html/FEM.html

(The Mavericks version isn't updated yet because the Mavericks machine did not 
complete the build last night due to an unrelated issue).

You might have been expecting to see the update at 

http://bioconductor.org/packages/release/bioc/html/FEM.html

But it's not there. Bioconductor has two branches, release and devel. devel is 
for active development of packages. The only commits you should make to release 
are bug fixes and documentation enhancements. 

The next release will be on April 17 and after that, devel will become release. 

Incidentally, you bumped to version 2.0.1 but according to our guidelines 
(http://bioconductor.org/developers/how-to/version-numbering/) it should be 
2.1.0. That is, the y in the x.y.z version number should always be odd in devel 
and even in release.

Dan



> Thanks so much for your attention on our FEM package welcome to play
> with it.
> 



> Really thanks for  your help.
> 
> Kind Regards
> 
> Yinming
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

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

[Bioc-devel] New netbenchmark package

2015-03-17 Thread Pau Bellot Pujalte

Dear Bioconductor members,

I'd like to draw your attention to the new package that implements a
benchmarking
of several gene network inference algorithms from gene expression data.

The *netbenchmark* package is now available in the development branch:

http://master.bioconductor.org/packages/3.1/bioc/html/netbenchmark.html

In the last decade, several methods have tackled the challenge of
reconstructing gene regulatory networks from gene expression data. Several
papers have compared and evaluated the different network inference methods
relying on simulated data. This is a new comparison that assesses different
methods in a high-heterogeneity data scenario which could reveal the
specialization of methods for the different network types and data.

Your comments and suggestions are welcome and will assist in continuously
improving the package.

Kind regards,

Pau Bellot

-
OOO Pau Bellot, PhD Candidate 
OOO Image Processing Group 
OOO Universitat Politècnica de Catalunya 

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] FEM package updation build frequence

2015-03-17 Thread Yinming Jiao

Dear Dan

Your reply is really exiting. Here I change the version number 2.0.1 to 2.1.2. 
As you say, I have bumped to version 2.0.1 but according to our guidelines 
(http://bioconductor.org/developers/how-to/version-numbering/) it should be 
2.1.0. That is, the y in the x.y.z version number should always be odd in devel 
and even in release. Now z is bumped to 2 from 1 which is needed to be added to 
the repository.

Whether this means that the one with right version number will be built again 
and published on the Bioconductor web site tomorrow. 

So,after then, could FEM 2.2.0(which needed to be bumped in release) be 
included in the new BioC release on April 19. 

Thanks again for your help. 

Kind Regards
Yinming

> -原始邮件-
> 发件人: "Dan Tenenbaum" 
> 发送时间: 2015年3月18日 星期三
> 收件人: "Yinming Jiao" <20907...@zju.edu.cn>
> 抄送: bioc-devel 
> 主题: Re: [Bioc-devel] FEM package updation build frequence
> 
> Hi,
> 
> 
> 
> - Original Message -
> > From: "Yinming Jiao" <20907...@zju.edu.cn>
> > To: "bioc-devel" 
> > Sent: Tuesday, March 17, 2015 7:52:20 AM
> > Subject: [Bioc-devel] FEM package updation build frequence
> > 
> > Hi Guys
> > 
> > As a maintainer of FEM BioC package, a new FEM version(2.0.1,
> > previous 1.1.0,  z in the version number x.y.z is also  bumped)  is
> > submitted to our SVN server last Sunday.It was built once on Monday,
> > but it has an error. Then I resubmitted it.
> > 
> > In the following link http://bioconductor.org/checkResults/ ,so  how
> > often are the packages built and checked.
> > 
> > And, after the package passes the check test, When will it be
> > published on bioconductor.org website?
> > 
> 

> (The Mavericks version isn't updated yet because the Mavericks machine did 
> not complete the build last night due to an unrelated issue).
> 
> You might have been expecting to see the update at 
> 
> http://bioconductor.org/packages/release/bioc/html/
> 
> But it's not there. Bioconductor has two branches, release and devel. devel 
> is for active development of packages. The only commits you should make to 
> release are bug fixes and documentation enhancements. 
> 
> The next release will be on April 17 and after that, devel will become 
> release. 
> 
> Incidentally, you bumped to version 2.0.1 but according to our guidelines 
> (http://bioconductor.org/developers/how-to/version-numbering/) it should be 
> 2.1.0. That is, the y in the x.y.z version number should always be odd in 
> devel and even in release.
> 
> Dan
> 
> 
> 
> > Thanks so much for your attention on our FEM package welcome to play
> > with it.
> > 
> 
> 
> 
> > Really thanks for  your help.
> > 
> > Kind Regards
> > 
> > Yinming
> > 
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > 


--
CAS-MPG Partner Institute for Computational Biology
320 Yue Yang Road
Shanghai 200031
China
Email: 20907...@zju.edu.cn or jiaoyinm...@picb.ac.cn
Mob: +86 1852139 6188

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

Re: [Bioc-devel] FEM package updation build frequence

2015-03-17 Thread Dan Tenenbaum



- Original Message -
> From: "Yinming Jiao" <20907...@zju.edu.cn>
> To: "Dan Tenenbaum" 
> Cc: bioc-devel@r-project.org, "Andrew Teschendorff" 
> Sent: Tuesday, March 17, 2015 10:29:16 PM
> Subject: Re: Re: [Bioc-devel] FEM package updation build frequence
> 
> Dear Dan
> 
> Your reply is really exiting. Here I change the version number 2.0.1
> to 2.1.2. As you say, I have bumped to version 2.0.1 but according
> to our guidelines
> (http://bioconductor.org/developers/how-to/version-numbering/) it
> should be 2.1.0. That is, the y in the x.y.z version number should
> always be odd in devel and even in release. Now z is bumped to 2
> from 1 which is needed to be added to the repository.
> 

No, it's not needed to be added to the repository. It is already in the 
repository.



> Whether this means that the one with right version number will be
> built again and published on the Bioconductor web site tomorrow.
> 
> So,after then, could FEM 2.2.0(which needed to be bumped in release)
> be included in the new BioC release on April 19.


Yes, FEM will be included in the new release. It will be automatically bumped 
(you do not have to do anything) to 2.2.0.

Dan



> 
> Thanks again for your help.
> 
> Kind Regards
> Yinming
> 
> > -原始邮件-
> > 发件人: "Dan Tenenbaum" 
> > 发送时间: 2015年3月18日 星期三
> > 收件人: "Yinming Jiao" <20907...@zju.edu.cn>
> > 抄送: bioc-devel 
> > 主题: Re: [Bioc-devel] FEM package updation build frequence
> > 
> > Hi,
> > 
> > 
> > 
> > - Original Message -
> > > From: "Yinming Jiao" <20907...@zju.edu.cn>
> > > To: "bioc-devel" 
> > > Sent: Tuesday, March 17, 2015 7:52:20 AM
> > > Subject: [Bioc-devel] FEM package updation build frequence
> > > 
> > > Hi Guys
> > > 
> > > As a maintainer of FEM BioC package, a new FEM version(2.0.1,
> > > previous 1.1.0,  z in the version number x.y.z is also  bumped)
> > >  is
> > > submitted to our SVN server last Sunday.It was built once on
> > > Monday,
> > > but it has an error. Then I resubmitted it.
> > > 
> > > In the following link http://bioconductor.org/checkResults/ ,so
> > >  how
> > > often are the packages built and checked.
> > > 
> > > And, after the package passes the check test, When will it be
> > > published on bioconductor.org website?
> > > 
> > 
> 
> > (The Mavericks version isn't updated yet because the Mavericks
> > machine did not complete the build last night due to an unrelated
> > issue).
> > 
> > You might have been expecting to see the update at
> > 
> > http://bioconductor.org/packages/release/bioc/html/
> > 
> > But it's not there. Bioconductor has two branches, release and
> > devel. devel is for active development of packages. The only
> > commits you should make to release are bug fixes and documentation
> > enhancements.
> > 
> > The next release will be on April 17 and after that, devel will
> > become release.
> > 
> > Incidentally, you bumped to version 2.0.1 but according to our
> > guidelines
> > (http://bioconductor.org/developers/how-to/version-numbering/) it
> > should be 2.1.0. That is, the y in the x.y.z version number should
> > always be odd in devel and even in release.
> > 
> > Dan
> > 
> > 
> > 
> > > Thanks so much for your attention on our FEM package welcome to
> > > play
> > > with it.
> > > 
> > 
> > 
> > 
> > > Really thanks for  your help.
> > > 
> > > Kind Regards
> > > 
> > > Yinming
> > > 
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > > 
> 
> 
> --
> CAS-MPG Partner Institute for Computational Biology
> 320 Yue Yang Road
> Shanghai 200031
> China
> Email: 20907...@zju.edu.cn or jiaoyinm...@picb.ac.cn
> Mob: +86 1852139 6188
> 
> 

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

Re: [Bioc-devel] zero-width ranges representing insertions

Re: [Bioc-devel] Bioconductor 3.1 release schedule now available

Re: [Bioc-devel] Contents of Bioc-devel digest

[Bioc-devel] FEM package updation build frequence

[Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

[Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

Re: [Bioc-devel] little tiny bug in CDSID annotations from predictCoding()

Re: [Bioc-devel] FEM package updation build frequence

[Bioc-devel] New netbenchmark package

Re: [Bioc-devel] FEM package updation build frequence

Re: [Bioc-devel] FEM package updation build frequence

14 matches

Site Navigation

Mail list logo

Footer information