Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Hervé Pagès 

Hi Dan,

Thanks for making that change. Would be great to have this for the
previous releases too. One often lands on an announcement page directly
from Google and has no easy way to tell when that release happened.

Thanks,
H.


On 10/16/2015 08:45 AM, Dan Tenenbaum wrote:

Done, the change should appear within 20 minutes. Thanks for the suggestion.
Dan


- Original Message -

From: "Levi Waldron" 
To: "bioc-devel" 
Sent: Friday, October 16, 2015 8:23:17 AM
Subject: Re: [Bioc-devel] BioC 3.2 branch created

Just a small suggestion, it might be helpful to put a date on
https://www.bioconductor.org/news/bioc_3_2_release/ - currently it's
not
obvious when you land on that page when the announcement was made, or
that
this is the current release version.

Thanks core team for your hard work in getting another release out on
schedule!



On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum

wrote:



The BioC 3.2 branch is now ready.

Remember, you always have access to 2 versions of your package:
the "release" and the "devel" versions.

Right now the "release" version of your package (which is not
officially released yet but will be tomorrow if
everything goes well) is in the 3.2 branch and accessible at:

https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/


Only bug fixes and documentation improvements should go here.

As always the "devel" version of your package is at:

  https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/

Similarly for experiment packages, where your package is available
in
devel at

https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/

The release branch of it is in:

https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/



Normal development of your package can now resume here.

Please let us know if you have any questions.


Thanks!

Dan

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





--
Levi Waldron
Assistant Professor of Biostatistics
City University of New York School of Public Health, Hunter College
2180 3rd Ave Rm 538
New York NY 10035-4003
phone: 212-396-7747
www.waldronlab.org

[[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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Dan Tenenbaum 


- Original Message -
> From: "Hervé Pagès" 
> To: "Dan Tenenbaum" , "Levi Waldron" 
> 
> Cc: "bioc-devel" 
> Sent: Friday, October 16, 2015 10:07:03 AM
> Subject: Re: [Bioc-devel] BioC 3.2 branch created
> 
> Hi Dan,
> 
> Thanks for making that change. Would be great to have this for the
> previous releases too. One often lands on an announcement page
> directly
> from Google and has no easy way to tell when that release happened.
> 

Just committed the change, it should show up son. Looks like we used to do this 
and then stopped at some point.
Dan


> Thanks,
> H.
> 
> 
> On 10/16/2015 08:45 AM, Dan Tenenbaum wrote:
> > Done, the change should appear within 20 minutes. Thanks for the
> > suggestion.
> > Dan
> >
> >
> > - Original Message -
> >> From: "Levi Waldron" 
> >> To: "bioc-devel" 
> >> Sent: Friday, October 16, 2015 8:23:17 AM
> >> Subject: Re: [Bioc-devel] BioC 3.2 branch created
> >>
> >> Just a small suggestion, it might be helpful to put a date on
> >> https://www.bioconductor.org/news/bioc_3_2_release/ - currently
> >> it's
> >> not
> >> obvious when you land on that page when the announcement was made,
> >> or
> >> that
> >> this is the current release version.
> >>
> >> Thanks core team for your hard work in getting another release out
> >> on
> >> schedule!
> >>
> >>
> >>
> >> On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum
> >> 
> >> wrote:
> >>
> >>>
> >>> The BioC 3.2 branch is now ready.
> >>>
> >>> Remember, you always have access to 2 versions of your package:
> >>> the "release" and the "devel" versions.
> >>>
> >>> Right now the "release" version of your package (which is not
> >>> officially released yet but will be tomorrow if
> >>> everything goes well) is in the 3.2 branch and accessible at:
> >>>
> >>> https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/
> >>> 
> >>>
> >>> Only bug fixes and documentation improvements should go here.
> >>>
> >>> As always the "devel" version of your package is at:
> >>>
> >>>   https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/
> >>>
> >>> Similarly for experiment packages, where your package is
> >>> available
> >>> in
> >>> devel at
> >>>
> >>> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/
> >>>
> >>> The release branch of it is in:
> >>>
> >>> https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/
> >>> 
> >>>
> >>>
> >>> Normal development of your package can now resume here.
> >>>
> >>> Please let us know if you have any questions.
> >>>
> >>>
> >>> Thanks!
> >>>
> >>> Dan
> >>>
> >>> ___
> >>> Bioc-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>
> >>
> >>
> >>
> >> --
> >> Levi Waldron
> >> Assistant Professor of Biostatistics
> >> City University of New York School of Public Health, Hunter
> >> College
> >> 2180 3rd Ave Rm 538
> >> New York NY 10035-4003
> >> phone: 212-396-7747
> >> www.waldronlab.org
> >>
> >>[[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
> >
> 
> --
> Hervé Pagès
> 
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
> 
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
> 

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

Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Hervé Pagès 

On 10/16/2015 10:52 AM, Dan Tenenbaum wrote:



- Original Message -

From: "Hervé Pagès" 
To: "Dan Tenenbaum" , "Levi Waldron" 

Cc: "bioc-devel" 
Sent: Friday, October 16, 2015 10:07:03 AM
Subject: Re: [Bioc-devel] BioC 3.2 branch created

Hi Dan,

Thanks for making that change. Would be great to have this for the
previous releases too. One often lands on an announcement page
directly
from Google and has no easy way to tell when that release happened.



Just committed the change, it should show up son. Looks like we used to do this 
and then stopped at some point.


Great. Thanks Dan!

H.


Dan



Thanks,
H.


On 10/16/2015 08:45 AM, Dan Tenenbaum wrote:

Done, the change should appear within 20 minutes. Thanks for the
suggestion.
Dan


- Original Message -

From: "Levi Waldron" 
To: "bioc-devel" 
Sent: Friday, October 16, 2015 8:23:17 AM
Subject: Re: [Bioc-devel] BioC 3.2 branch created

Just a small suggestion, it might be helpful to put a date on
https://www.bioconductor.org/news/bioc_3_2_release/ - currently
it's
not
obvious when you land on that page when the announcement was made,
or
that
this is the current release version.

Thanks core team for your hard work in getting another release out
on
schedule!



On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum

wrote:



The BioC 3.2 branch is now ready.

Remember, you always have access to 2 versions of your package:
the "release" and the "devel" versions.

Right now the "release" version of your package (which is not
officially released yet but will be tomorrow if
everything goes well) is in the 3.2 branch and accessible at:

https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/


Only bug fixes and documentation improvements should go here.

As always the "devel" version of your package is at:

   https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/

Similarly for experiment packages, where your package is
available
in
devel at

https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/

The release branch of it is in:

https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/



Normal development of your package can now resume here.

Please let us know if you have any questions.


Thanks!

Dan

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





--
Levi Waldron
Assistant Professor of Biostatistics
City University of New York School of Public Health, Hunter
College
2180 3rd Ave Rm 538
New York NY 10035-4003
phone: 212-396-7747
www.waldronlab.org

[[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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

2015-10-16 Thread Michael Lawrence 
Sure, "*" makes more sense for strand, given the precedent.

On Fri, Oct 16, 2015 at 9:55 AM, Hervé Pagès  wrote:
> On 10/16/2015 09:28 AM, Michael Lawrence wrote:
>>
>> I kind of wish it would return NA for things like seqnames and strand,
>> but yes that would be very useful.
>
>
> Could do this for seqnames() but I'm hesitant to do this for strand().
> If you look at ?strand in BiocGenerics, ‘*’ is used when the exact
> strand of the location is unknown, or irrelevant, or when the "feature"
> at that location belongs to both strands. A pair with discordant strand
> belongs to both strands. Also there is a lot of code around that
> assumes strand() never returns NAs.
>
>
> H.
>
>>
>> On Fri, Oct 16, 2015 at 9:15 AM, Hervé Pagès  wrote:
>>>
>>> Hi Michael, Martin,
>>>
>>> On 10/16/2015 06:48 AM, Michael Lawrence wrote:


 It does seem like starting with the more general data structure is the
 better approach, but I couldn't find an easy way to move the paired
 subset
 of GAlignmentsList to GAlignmentPairs. You mention a coercion, but it's
 not
 obvious to me, unfortunately.

 Another approach would be a GAlignmentPairs where the unpaired reads
 have
 "missing" mates. I know GAlignments has no concept of missing, but it
 would
 get everything into a single data structure that is convenient for
 computing on pairs.
>>>
>>>
>>>
>>> I could modify readGAlignmentPairs() to have the discordant and/or
>>> ambiguous pairs end up in th GAlignmentPairs. The ambiguous pairs
>>> could be marked as such thru a metadata col of the object or thru
>>> a proper slot. The seqnames() and strand() accessors will return
>>> * on discordant pairs. Does that sound reasonable?
>>>
>>> H.
>>>
>>>

 On Fri, Oct 16, 2015 at 5:21 AM, Morgan, Martin <
 martin.mor...@roswellpark.org> wrote:

>
>
>> -Original Message-
>> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf
>> Of
>> Michael Lawrence
>> Sent: Friday, October 16, 2015 7:41 AM
>> To: bioc-devel@r-project.org
>> Subject: [Bioc-devel] readGAlignmentPairs with discordant strand
>>
>> Now that GAlignmentPairs supports discordant strand between mates, how
>> hard would it be to relax that restriction on readGAlignmentPairs()?
>>
>> Also, would be nice if getDumpedAlignments() returned those dumped by
>> readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the
>
>
> extra
>>
>>
>> mcols) and calling makeGAlignmentPairs(). Not so convenient.
>
>
>
> I'm not sure whether this is relevant to your use case but
> readGAlignmentsList returns a list of paired mates, and if appropriate
> (based on ScanBamParam) list elements with solo travelers. The paired
> portion of the list can be coerced to GAlignmentPairs if the additional
> structure of that class is required.
>
> Martin
>
>>
>> Michael
>>
>> [[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.
>

  [[alternative HTML version deleted]]

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

>>>
>>> --
>>> Hervé Pagès
>>>
>>> Program in Computational Biology
>>> Division of Public Health Sciences
>>> Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N, M1-B514
>>> P.O. Box 19024
>>> Seattle, WA 98109-1024
>>>
>>> E-mail: hpa...@fredhutch.org
>>> Phone:  (206) 667-5791
>>> Fax:(206) 667-1319
>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319

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

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

2015-10-16 Thread Hervé Pagès 

On 10/16/2015 09:28 AM, Michael Lawrence wrote:

I kind of wish it would return NA for things like seqnames and strand,
but yes that would be very useful.


Could do this for seqnames() but I'm hesitant to do this for strand().
If you look at ?strand in BiocGenerics, ‘*’ is used when the exact
strand of the location is unknown, or irrelevant, or when the "feature"
at that location belongs to both strands. A pair with discordant strand
belongs to both strands. Also there is a lot of code around that
assumes strand() never returns NAs.

H.



On Fri, Oct 16, 2015 at 9:15 AM, Hervé Pagès  wrote:

Hi Michael, Martin,

On 10/16/2015 06:48 AM, Michael Lawrence wrote:


It does seem like starting with the more general data structure is the
better approach, but I couldn't find an easy way to move the paired subset
of GAlignmentsList to GAlignmentPairs. You mention a coercion, but it's
not
obvious to me, unfortunately.

Another approach would be a GAlignmentPairs where the unpaired reads have
"missing" mates. I know GAlignments has no concept of missing, but it
would
get everything into a single data structure that is convenient for
computing on pairs.



I could modify readGAlignmentPairs() to have the discordant and/or
ambiguous pairs end up in th GAlignmentPairs. The ambiguous pairs
could be marked as such thru a metadata col of the object or thru
a proper slot. The seqnames() and strand() accessors will return
* on discordant pairs. Does that sound reasonable?

H.




On Fri, Oct 16, 2015 at 5:21 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:





-Original Message-
From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
Michael Lawrence
Sent: Friday, October 16, 2015 7:41 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] readGAlignmentPairs with discordant strand

Now that GAlignmentPairs supports discordant strand between mates, how
hard would it be to relax that restriction on readGAlignmentPairs()?

Also, would be nice if getDumpedAlignments() returned those dumped by
readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the


extra


mcols) and calling makeGAlignmentPairs(). Not so convenient.



I'm not sure whether this is relevant to your use case but
readGAlignmentsList returns a list of paired mates, and if appropriate
(based on ScanBamParam) list elements with solo travelers. The paired
portion of the list can be coerced to GAlignmentPairs if the additional
structure of that class is required.

Martin



Michael

[[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.



 [[alternative HTML version deleted]]

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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319


--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Bioc-devel] Error in GenomicFeatures::makeTxDbFromUCSC()

2015-10-16 Thread Arora, Sonali 

Hi ,

I get an error when creating a txdb object for hg19 from the refGene Table

> txdb <- makeTxDbFromUCSC(genome = "hg19", tablename = "refGene")
Error in tableNames(ucscTableQuery(session, track = track)) :
  error in evaluating the argument 'object' in selecting a method for 
function 'tableNames': Error in relist(ans_unlistData, ans_partitioning) :

  shape of 'skeleton' is not compatible with 'NROW(flesh)'

Is this because GenomicRanges() is broken in devel ? Please advise.


> sessionInfo()
R Under development (unstable) (2015-10-15 r69519)
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  LC_CTYPE=English_United 
States.1252LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C   LC_TIME=English_United 
States.1252


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


other attached packages:
[1] GenomicFeatures_1.23.1 AnnotationDbi_1.33.0 Biobase_2.31.0 
GenomicRanges_1.21.32  GenomeInfoDb_1.7.0
[6] IRanges_2.5.0  S4Vectors_0.9.0 BiocGenerics_0.17.0
BiocInstaller_1.21.1


loaded via a namespace (and not attached):
 [1] XVector_0.11.0 zlibbioc_1.17.0 
GenomicAlignments_1.7.0BiocParallel_1.5.0
 [5] tools_3.3.0SummarizedExperiment_1.1.0 
DBI_0.3.1  lambda.r_1.1.7
 [9] futile.logger_1.4.1rtracklayer_1.31.0 
futile.options_1.0.0   bitops_1.0-6
[13] RCurl_1.95-4.7 biomaRt_2.27.0 
RSQLite_1.0.0  Biostrings_2.39.0

[17] Rsamtools_1.23.0   XML_3.98-1.3

--
Thanks and Regards,
Sonali

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

Re: [Bioc-devel] Error in GenomicFeatures::makeTxDbFromUCSC()

2015-10-16 Thread Michael Lawrence 
Seemed to work for me. Could just be a transient issue with UCSC?

On Fri, Oct 16, 2015 at 12:02 PM, Arora, Sonali  wrote:
> Hi ,
>
> I get an error when creating a txdb object for hg19 from the refGene Table
>
>> txdb <- makeTxDbFromUCSC(genome = "hg19", tablename = "refGene")
> Error in tableNames(ucscTableQuery(session, track = track)) :
>   error in evaluating the argument 'object' in selecting a method for
> function 'tableNames': Error in relist(ans_unlistData, ans_partitioning) :
>   shape of 'skeleton' is not compatible with 'NROW(flesh)'
>
> Is this because GenomicRanges() is broken in devel ? Please advise.
>
>
>> sessionInfo()
> R Under development (unstable) (2015-10-15 r69519)
> 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  LC_CTYPE=English_United
> States.1252LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C   LC_TIME=English_United
> States.1252
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils datasets
> methods   base
>
> other attached packages:
> [1] GenomicFeatures_1.23.1 AnnotationDbi_1.33.0 Biobase_2.31.0
> GenomicRanges_1.21.32  GenomeInfoDb_1.7.0
> [6] IRanges_2.5.0  S4Vectors_0.9.0 BiocGenerics_0.17.0
> BiocInstaller_1.21.1
>
> loaded via a namespace (and not attached):
>  [1] XVector_0.11.0 zlibbioc_1.17.0 GenomicAlignments_1.7.0
> BiocParallel_1.5.0
>  [5] tools_3.3.0SummarizedExperiment_1.1.0 DBI_0.3.1
> lambda.r_1.1.7
>  [9] futile.logger_1.4.1rtracklayer_1.31.0 futile.options_1.0.0
> bitops_1.0-6
> [13] RCurl_1.95-4.7 biomaRt_2.27.0 RSQLite_1.0.0
> Biostrings_2.39.0
> [17] Rsamtools_1.23.0   XML_3.98-1.3
>
> --
> Thanks and Regards,
> Sonali
>
> ___
> 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] Adding a lengths() method to List class

2015-10-16 Thread Hervé Pagès 

On 10/15/2015 11:24 AM, Michael Lawrence wrote:

Btw, a subtle issue here is that elementLengths currently calls NROW(),
not length(), and code might be relying on DataFrameList returning row
counts. That behavior has proven convenient, so it would be nice not to
lose it. I guess nrow() already does that, but anyway, lengths() is not
the equivalent of elementLengths() there.


There is actually a big note in ?BiocGenerics::lengths about this.
This means we will need to keep elementLengths() around but the plan
is to rename it elementNROWS() (consistent with extractROWS). The
current name is clearly a misnomer and a source of confusion.

H.



On Wed, Sep 30, 2015 at 9:37 PM, Hervé Pagès > wrote:

On 09/30/2015 05:28 PM, Michael Lawrence wrote:

It wasn't a conscious choice, but it would slow things down a
bit. Not
by much though, since we're already attempting dispatch on
length(). I
can make the change.


That would be great. Thanks Michael!

H.


On Wed, Sep 30, 2015 at 1:33 PM, Hervé Pagès

>> wrote:

 Hi Michael,

 I was expecting this to just work:

base::lengths(IntegerList(1:4, 1:6))

 but it doesn't:

Error in base::lengths(IntegerList(1:4, 1:6)) :
  'x' must be a list or atomic vector

 The man page says:

   This function loops over ‘x’ and returns a compatible
vector
   containing the length of each element in ‘x’.
Effectively,
   ‘length(x[[i]])’ is called for all ‘i’, so any
methods on ‘length’
   are considered.

 If length(x[[i]]) is called for all i then it should work
on any object
 for which [[ is defined. Note that this is what happens with
 base::sapply(), base::mapply(), etc... they all use [[
internally.

 Do you know of any reason why lengths() doesn't do this?

 Thanks,
 H.


 On 09/28/2015 09:51 PM, Michael Lawrence wrote:

 That is the plan. Note that we already have
elementLengths()
 that serves
 the same purpose. It was the direct inspiration for
lengths().

 On Mon, Sep 28, 2015 at 9:41 PM, Peter Hickey
 
>>
 wrote:

 The lengths() function was added in R 3.2 to "get
the length
 of each
 element of a list or atomic vector (is.atomic) as
an integer
 or numeric
 vector." It seems useful to me to have also a
similar method
 defined for
 the S4Vectors::List class (and subclasses). What do
others
 think?

   [[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


 --
 Hervé Pagès

 Program in Computational Biology
 Division of Public Health Sciences
 Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N, M1-B514
 P.O. Box 19024
 Seattle, WA 98109-1024

 E-mail: hpa...@fredhutch.org 
>
 Phone: (206) 667-5791 

 Fax: (206) 667-1319 




--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org 
Phone: (206) 667-5791 
Fax: (206) 667-1319 




--
Hervé Pagès

Re: [Bioc-devel] SV4Vectors installation problem

2015-10-16 Thread Hervé Pagès 

Hi Michael,

On 10/15/2015 10:08 AM, Michael Lawrence wrote:

Tangentially related, it seems like nchar is worth defining in
BiocGenerics, with a signature of "x". I saw that Biostrings uses "type",
but I'm not sure why.


The 2 "nchar" methods that dispatch on the 'type' argument are from
the Biostrings 1 era (> 9 years old) and were kept in the 
Biostrings/Biostrings1/ folder for legacy only (this code doesn't

get evaluated, not even installed). That reminds me that it's probably
time to get rid of all that stuff.


But if we're just going to use the signature of 'x',
I can make nchar dispatch internally, so we don't need an R-level generic.
Will that work?


If by "make nchar dispatch internally" you mean "turn nchar() into a
primitive in R", like, say, length(), names(), dim(), dimnames(), `[`,
etc... then works for me.

Thanks,
H.



Michael

On Thu, Oct 15, 2015 at 5:19 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:





-Original Message-
From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
Marcin Cieslik
Sent: Thursday, October 15, 2015 7:46 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] SV4Vectors installation problem

Dear Bioconductors,

Somewhere in August S4Vectors stopped installing correctly resulting in

a:


Creating a generic function for ‘nchar’ from package ‘base’ in package
‘S4Vectors’

message (that cannot be suppressed) each time the package is loaded. The
issue is not fixed by a fresh reinstall of bioconductor. The first hint

of the

you're right that this is a message and that it cannot be suppressed, but
the package still functions correctly, right?

The problem was introduced by a change in R. The above is a work-around.
The permanent solution is now to use the current version of R (3.2.2) and
Bioc (3.2). The specific commit was


r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul
2015) | 5 lines

define nchar,Rle-method in .onLoad

- work-around consequences of changed base::nchar signature for
   3.2.1 binary builds used in 3.2.0



some related / belated discussion is at

https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html

Martin



problem appears during installation

http://pastebin.com/UpKdeNTH

It appears I am not the only one affected a search reveals many

instances:


e.g.
https://rpubs.com/Pazz/advanced_annotation
http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
LATEST/S4Vectors/petty-install.html
http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html

Thanks a lot for your work! If needed I can provide  a Docker image that
reproduces the problem.

Yours,
Marcin

   [[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.
___
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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Bioc-devel] New packages: DAPAR and Prostar

2015-10-16 Thread Samuel Wieczorek 
Dear Bioconductor developers,

As the Bioconductor was released, I would like to present two new 
packages : DAPAR and Prostar.


DAPAR (Differential Analysis for Proteomics Analysis with R) is an R 
package for the analysis mass spectrometry-based discovery proteomics 
quantitative dataset. It is built on pre-existing Bioconductor packages 
devoted to proteomics and uses the MSnSet data structure from MSnbase. 
The package contains functions to import data from CSV files (such as 
those from Maxquant), and to export data to Excel files. DAPAR is made 
to guide the practitioner through the following classical steps of a 
protein-level data analysis:

* *Descriptive statistics*: Exploration and visualization of your 
dataset with a detailed overview, which includes the following 
functionalities: Missing Values exploration, heatmap and correlation 
matrices, boxplots, expectation and variance distribution.

* *Filtering*: DAPAR allows to filter proteins according to their number 
of missing values in each condition.

* *Cross replicate normalisation*, with the following methods:
 (i) global rescaling (quantiles method, proportion method),
 (ii) median or mean centering (overall or within conditions),
 (iii) mean centering and scaling (overall or within 
conditions).

* *Missing values imputation*, with the following methods: (i) for 
random occurences: k-nearest-neighbors, Bayesian Principal Component 
Analysis and Maximum Likelihood Estimation; for left censored missing 
values: Quantile Regression for Imputation of Left Censored data.

* *Differential analysis*, according to a Welch t-test or a Limma 
moderated t-test.


The package Prostar provides a GUI, based on Shiny, to interact with 
DAPAR. It offers a good flexibility to navigate through the different 
processing tools and plots available.

The development of these two packages is very active and we work now on 
new functionalities and processing tools that will be available soon

Do not hesitate to test this tool and to give me a feedback of your 
experience.

Best

Samuel Wieczorek

-- 
Samuel Wieczorek
Etude de la Dynamique des Proteomes (EDyP) http://edyp.fr/
Laboratoire Biologie a Grande Echelle (BGE)
U1038 INSERM/CEA/UJF
Institut de Recherches en Technologies et Sciences pour le Vivant (iRTSV)
CEA/Grenoble
17 rue des Martyrs
F-38054 Grenoble Cedex 9
Tel : 04 38 78 44 14
Tel : 04 38 78 34 40


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] SV4Vectors installation problem

2015-10-16 Thread Michael Lawrence 
On Thu, Oct 15, 2015 at 11:04 PM, Hervé Pagès  wrote:

> Hi Michael,
>
> On 10/15/2015 10:08 AM, Michael Lawrence wrote:
>
>> Tangentially related, it seems like nchar is worth defining in
>> BiocGenerics, with a signature of "x". I saw that Biostrings uses "type",
>> but I'm not sure why.
>>
>
> The 2 "nchar" methods that dispatch on the 'type' argument are from
> the Biostrings 1 era (> 9 years old) and were kept in the
> Biostrings/Biostrings1/ folder for legacy only (this code doesn't
> get evaluated, not even installed). That reminds me that it's probably
> time to get rid of all that stuff.
>
> But if we're just going to use the signature of 'x',
>> I can make nchar dispatch internally, so we don't need an R-level generic.
>> Will that work?
>>
>
> If by "make nchar dispatch internally" you mean "turn nchar() into a
> primitive in R", like, say, length(), names(), dim(), dimnames(), `[`,
> etc... then works for me.
>
>
Essentially, yes. I've modified the methods package to support internal
dispatch within .Internal() calls. So no need to make it a primitive. Will
move ahead, thanks.


> Thanks,
> H.
>
>
>
>> Michael
>>
>> On Thu, Oct 15, 2015 at 5:19 AM, Morgan, Martin <
>> martin.mor...@roswellpark.org> wrote:
>>
>>
>>>
>>> -Original Message-
 From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
 Marcin Cieslik
 Sent: Thursday, October 15, 2015 7:46 AM
 To: bioc-devel@r-project.org
 Subject: [Bioc-devel] SV4Vectors installation problem

 Dear Bioconductors,

 Somewhere in August S4Vectors stopped installing correctly resulting in

>>> a:
>>>

 Creating a generic function for ‘nchar’ from package ‘base’ in package
 ‘S4Vectors’

 message (that cannot be suppressed) each time the package is loaded. The
 issue is not fixed by a fresh reinstall of bioconductor. The first hint

>>> of the
>>>
>>> you're right that this is a message and that it cannot be suppressed, but
>>> the package still functions correctly, right?
>>>
>>> The problem was introduced by a change in R. The above is a work-around.
>>> The permanent solution is now to use the current version of R (3.2.2) and
>>> Bioc (3.2). The specific commit was
>>>
>>> 
>>> r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul
>>> 2015) | 5 lines
>>>
>>> define nchar,Rle-method in .onLoad
>>>
>>> - work-around consequences of changed base::nchar signature for
>>>3.2.1 binary builds used in 3.2.0
>>>
>>> 
>>>
>>> some related / belated discussion is at
>>>
>>> https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html
>>>
>>> Martin
>>>
>>>
>>> problem appears during installation

 http://pastebin.com/UpKdeNTH

 It appears I am not the only one affected a search reveals many

>>> instances:
>>>

 e.g.
 https://rpubs.com/Pazz/advanced_annotation
 http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
 LATEST/S4Vectors/petty-install.html
 http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html

 Thanks a lot for your work! If needed I can provide  a Docker image that
 reproduces the problem.

 Yours,
 Marcin

[[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.
>>> ___
>>> 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
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] ideas for ScanBamParam filters

2015-10-16 Thread Morgan, Martin 


> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Friday, October 16, 2015 7:56 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] ideas for ScanBamParam filters
> 
> Maybe I just missed these, but these are a couple of things we could filter
> by, in addition to what's there already:
> 
> - Minimum MAPQ
> - Read group

see tagFilter and mapqFilter args to ScanBamParam. I don't know how heavily 
used these are so bugs welcome.

Martin

> 
> The first is mostly for convenience, but the second should also benefit
> performance.
> 
> I can help implement this, but wanted to make sure this is a reasonable
> approach.
> 
> Michael
> 
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

2015-10-16 Thread Morgan, Martin 


> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Friday, October 16, 2015 7:41 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] readGAlignmentPairs with discordant strand
> 
> Now that GAlignmentPairs supports discordant strand between mates, how
> hard would it be to relax that restriction on readGAlignmentPairs()?
> 
> Also, would be nice if getDumpedAlignments() returned those dumped by
> readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the extra
> mcols) and calling makeGAlignmentPairs(). Not so convenient.

I'm not sure whether this is relevant to your use case but readGAlignmentsList 
returns a list of paired mates, and if appropriate (based on ScanBamParam) list 
elements with solo travelers. The paired portion of the list can be coerced to 
GAlignmentPairs if the additional structure of that class is required.

Martin

>   
> Michael
> 
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] ideas for ScanBamParam filters

2015-10-16 Thread Michael Lawrence 
Maybe I just missed these, but these are a couple of things we could filter
by, in addition to what's there already:

- Minimum MAPQ
- Read group

The first is mostly for convenience, but the second should also benefit
performance.

I can help implement this, but wanted to make sure this is a reasonable
approach.

Michael

[[alternative HTML version deleted]]

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

[Bioc-devel] readGAlignmentPairs with discordant strand

2015-10-16 Thread Michael Lawrence 
Now that GAlignmentPairs supports discordant strand between mates, how hard
would it be to relax that restriction on readGAlignmentPairs()?

Also, would be nice if getDumpedAlignments() returned those dumped by
readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the extra
mcols) and calling makeGAlignmentPairs(). Not so convenient.

Michael

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] SV4Vectors installation problem

2015-10-16 Thread Marcin Cieślik 
Dear All,

I can confirm that the issue is fixed in the latest BioC / R versions.

Thanks a lot.

Yours,
Marcin





On Fri, Oct 16, 2015 at 7:09 AM, Michael Lawrence  wrote:

> On Thu, Oct 15, 2015 at 11:04 PM, Hervé Pagès 
> wrote:
>
> > Hi Michael,
> >
> > On 10/15/2015 10:08 AM, Michael Lawrence wrote:
> >
> >> Tangentially related, it seems like nchar is worth defining in
> >> BiocGenerics, with a signature of "x". I saw that Biostrings uses
> "type",
> >> but I'm not sure why.
> >>
> >
> > The 2 "nchar" methods that dispatch on the 'type' argument are from
> > the Biostrings 1 era (> 9 years old) and were kept in the
> > Biostrings/Biostrings1/ folder for legacy only (this code doesn't
> > get evaluated, not even installed). That reminds me that it's probably
> > time to get rid of all that stuff.
> >
> > But if we're just going to use the signature of 'x',
> >> I can make nchar dispatch internally, so we don't need an R-level
> generic.
> >> Will that work?
> >>
> >
> > If by "make nchar dispatch internally" you mean "turn nchar() into a
> > primitive in R", like, say, length(), names(), dim(), dimnames(), `[`,
> > etc... then works for me.
> >
> >
> Essentially, yes. I've modified the methods package to support internal
> dispatch within .Internal() calls. So no need to make it a primitive. Will
> move ahead, thanks.
>
>
> > Thanks,
> > H.
> >
> >
> >
> >> Michael
> >>
> >> On Thu, Oct 15, 2015 at 5:19 AM, Morgan, Martin <
> >> martin.mor...@roswellpark.org> wrote:
> >>
> >>
> >>>
> >>> -Original Message-
>  From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf
> Of
>  Marcin Cieslik
>  Sent: Thursday, October 15, 2015 7:46 AM
>  To: bioc-devel@r-project.org
>  Subject: [Bioc-devel] SV4Vectors installation problem
> 
>  Dear Bioconductors,
> 
>  Somewhere in August S4Vectors stopped installing correctly resulting
> in
> 
> >>> a:
> >>>
> 
>  Creating a generic function for ‘nchar’ from package ‘base’ in package
>  ‘S4Vectors’
> 
>  message (that cannot be suppressed) each time the package is loaded.
> The
>  issue is not fixed by a fresh reinstall of bioconductor. The first
> hint
> 
> >>> of the
> >>>
> >>> you're right that this is a message and that it cannot be suppressed,
> but
> >>> the package still functions correctly, right?
> >>>
> >>> The problem was introduced by a change in R. The above is a
> work-around.
> >>> The permanent solution is now to use the current version of R (3.2.2)
> and
> >>> Bioc (3.2). The specific commit was
> >>>
> >>>
> 
> >>> r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul
> >>> 2015) | 5 lines
> >>>
> >>> define nchar,Rle-method in .onLoad
> >>>
> >>> - work-around consequences of changed base::nchar signature for
> >>>3.2.1 binary builds used in 3.2.0
> >>>
> >>>
> 
> >>>
> >>> some related / belated discussion is at
> >>>
> >>> https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html
> >>>
> >>> Martin
> >>>
> >>>
> >>> problem appears during installation
> 
>  http://pastebin.com/UpKdeNTH
> 
>  It appears I am not the only one affected a search reveals many
> 
> >>> instances:
> >>>
> 
>  e.g.
>  https://rpubs.com/Pazz/advanced_annotation
>  http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
>  LATEST/S4Vectors/petty-install.html
>  http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html
> 
>  Thanks a lot for your work! If needed I can provide  a Docker image
> that
>  reproduces the problem.
> 
>  Yours,
>  Marcin
> 
> [[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.
> >>> ___
> >>> 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] ideas for ScanBamParam filters

2015-10-16 Thread Michael Lawrence 
I see, thanks. Was just using an old version (wrong laptop), so missed the
mapqFilter().

On Fri, Oct 16, 2015 at 5:10 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:

>
>
> > -Original Message-
> > From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> > Michael Lawrence
> > Sent: Friday, October 16, 2015 7:56 AM
> > To: bioc-devel@r-project.org
> > Subject: [Bioc-devel] ideas for ScanBamParam filters
> >
> > Maybe I just missed these, but these are a couple of things we could
> filter
> > by, in addition to what's there already:
> >
> > - Minimum MAPQ
> > - Read group
>
> see tagFilter and mapqFilter args to ScanBamParam. I don't know how
> heavily used these are so bugs welcome.
>
> Martin
>
> >
> > The first is mostly for convenience, but the second should also benefit
> > performance.
> >
> > I can help implement this, but wanted to make sure this is a reasonable
> > approach.
> >
> > Michael
> >
> >   [[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.
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

2015-10-16 Thread Michael Lawrence 
It does seem like starting with the more general data structure is the
better approach, but I couldn't find an easy way to move the paired subset
of GAlignmentsList to GAlignmentPairs. You mention a coercion, but it's not
obvious to me, unfortunately.

Another approach would be a GAlignmentPairs where the unpaired reads have
"missing" mates. I know GAlignments has no concept of missing, but it would
get everything into a single data structure that is convenient for
computing on pairs.

On Fri, Oct 16, 2015 at 5:21 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:

>
>
> > -Original Message-
> > From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> > Michael Lawrence
> > Sent: Friday, October 16, 2015 7:41 AM
> > To: bioc-devel@r-project.org
> > Subject: [Bioc-devel] readGAlignmentPairs with discordant strand
> >
> > Now that GAlignmentPairs supports discordant strand between mates, how
> > hard would it be to relax that restriction on readGAlignmentPairs()?
> >
> > Also, would be nice if getDumpedAlignments() returned those dumped by
> > readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the
> extra
> > mcols) and calling makeGAlignmentPairs(). Not so convenient.
>
> I'm not sure whether this is relevant to your use case but
> readGAlignmentsList returns a list of paired mates, and if appropriate
> (based on ScanBamParam) list elements with solo travelers. The paired
> portion of the list can be coerced to GAlignmentPairs if the additional
> structure of that class is required.
>
> Martin
>
> >
> > Michael
> >
> >   [[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.
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Levi Waldron 
Just a small suggestion, it might be helpful to put a date on
https://www.bioconductor.org/news/bioc_3_2_release/ - currently it's not
obvious when you land on that page when the announcement was made, or that
this is the current release version.

Thanks core team for your hard work in getting another release out on
schedule!



On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum 
wrote:

>
> The BioC 3.2 branch is now ready.
>
> Remember, you always have access to 2 versions of your package:
> the "release" and the "devel" versions.
>
> Right now the "release" version of your package (which is not
> officially released yet but will be tomorrow if
> everything goes well) is in the 3.2 branch and accessible at:
>
> https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/
> 
>
> Only bug fixes and documentation improvements should go here.
>
> As always the "devel" version of your package is at:
>
>  https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/
>
> Similarly for experiment packages, where your package is available in
> devel at
>
> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/
>
> The release branch of it is in:
>
> https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/
> 
>
>
> Normal development of your package can now resume here.
>
> Please let us know if you have any questions.
>
>
> Thanks!
>
> Dan
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
Levi Waldron
Assistant Professor of Biostatistics
City University of New York School of Public Health, Hunter College
2180 3rd Ave Rm 538
New York NY 10035-4003
phone: 212-396-7747
www.waldronlab.org

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Dan Tenenbaum 
Done, the change should appear within 20 minutes. Thanks for the suggestion.
Dan


- Original Message -
> From: "Levi Waldron" 
> To: "bioc-devel" 
> Sent: Friday, October 16, 2015 8:23:17 AM
> Subject: Re: [Bioc-devel] BioC 3.2 branch created
> 
> Just a small suggestion, it might be helpful to put a date on
> https://www.bioconductor.org/news/bioc_3_2_release/ - currently it's
> not
> obvious when you land on that page when the announcement was made, or
> that
> this is the current release version.
> 
> Thanks core team for your hard work in getting another release out on
> schedule!
> 
> 
> 
> On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum
> 
> wrote:
> 
> >
> > The BioC 3.2 branch is now ready.
> >
> > Remember, you always have access to 2 versions of your package:
> > the "release" and the "devel" versions.
> >
> > Right now the "release" version of your package (which is not
> > officially released yet but will be tomorrow if
> > everything goes well) is in the 3.2 branch and accessible at:
> >
> > https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/
> > 
> >
> > Only bug fixes and documentation improvements should go here.
> >
> > As always the "devel" version of your package is at:
> >
> >  https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/
> >
> > Similarly for experiment packages, where your package is available
> > in
> > devel at
> >
> > https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/
> >
> > The release branch of it is in:
> >
> > https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/
> > 
> >
> >
> > Normal development of your package can now resume here.
> >
> > Please let us know if you have any questions.
> >
> >
> > Thanks!
> >
> > Dan
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> 
> 
> 
> --
> Levi Waldron
> Assistant Professor of Biostatistics
> City University of New York School of Public Health, Hunter College
> 2180 3rd Ave Rm 538
> New York NY 10035-4003
> phone: 212-396-7747
> www.waldronlab.org
> 
>   [[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] readGAlignmentPairs with discordant strand

2015-10-16 Thread Hervé Pagès 

Hi Michael, Martin,

On 10/16/2015 06:48 AM, Michael Lawrence wrote:

It does seem like starting with the more general data structure is the
better approach, but I couldn't find an easy way to move the paired subset
of GAlignmentsList to GAlignmentPairs. You mention a coercion, but it's not
obvious to me, unfortunately.

Another approach would be a GAlignmentPairs where the unpaired reads have
"missing" mates. I know GAlignments has no concept of missing, but it would
get everything into a single data structure that is convenient for
computing on pairs.


I could modify readGAlignmentPairs() to have the discordant and/or
ambiguous pairs end up in th GAlignmentPairs. The ambiguous pairs
could be marked as such thru a metadata col of the object or thru
a proper slot. The seqnames() and strand() accessors will return
* on discordant pairs. Does that sound reasonable?

H.



On Fri, Oct 16, 2015 at 5:21 AM, Morgan, Martin <
martin.mor...@roswellpark.org> wrote:





-Original Message-
From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
Michael Lawrence
Sent: Friday, October 16, 2015 7:41 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] readGAlignmentPairs with discordant strand

Now that GAlignmentPairs supports discordant strand between mates, how
hard would it be to relax that restriction on readGAlignmentPairs()?

Also, would be nice if getDumpedAlignments() returned those dumped by
readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the

extra

mcols) and calling makeGAlignmentPairs(). Not so convenient.


I'm not sure whether this is relevant to your use case but
readGAlignmentsList returns a list of paired mates, and if appropriate
(based on ScanBamParam) list elements with solo travelers. The paired
portion of the list can be coerced to GAlignmentPairs if the additional
structure of that class is required.

Martin



Michael

   [[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.



[[alternative HTML version deleted]]

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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Diego Diez 
Nice addition, thank you. Just want to note that now the 3.1 page says
"April 17, 2005". Thats a long time ago! I guess it means "April 17,
2015".

Diego

On Sat, Oct 17, 2015 at 3:30 AM, Hervé Pagès  wrote:
> On 10/16/2015 10:52 AM, Dan Tenenbaum wrote:
>>
>>
>>
>> - Original Message -
>>>
>>> From: "Hervé Pagès" 
>>> To: "Dan Tenenbaum" , "Levi Waldron"
>>> 
>>> Cc: "bioc-devel" 
>>> Sent: Friday, October 16, 2015 10:07:03 AM
>>> Subject: Re: [Bioc-devel] BioC 3.2 branch created
>>>
>>> Hi Dan,
>>>
>>> Thanks for making that change. Would be great to have this for the
>>> previous releases too. One often lands on an announcement page
>>> directly
>>> from Google and has no easy way to tell when that release happened.
>>>
>>
>> Just committed the change, it should show up son. Looks like we used to do
>> this and then stopped at some point.
>
>
> Great. Thanks Dan!
>
> H.
>
>
>> Dan
>>
>>
>>> Thanks,
>>> H.
>>>
>>>
>>> On 10/16/2015 08:45 AM, Dan Tenenbaum wrote:

 Done, the change should appear within 20 minutes. Thanks for the
 suggestion.
 Dan


 - Original Message -
>
> From: "Levi Waldron" 
> To: "bioc-devel" 
> Sent: Friday, October 16, 2015 8:23:17 AM
> Subject: Re: [Bioc-devel] BioC 3.2 branch created
>
> Just a small suggestion, it might be helpful to put a date on
> https://www.bioconductor.org/news/bioc_3_2_release/ - currently
> it's
> not
> obvious when you land on that page when the announcement was made,
> or
> that
> this is the current release version.
>
> Thanks core team for your hard work in getting another release out
> on
> schedule!
>
>
>
> On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum
> 
> wrote:
>
>>
>> The BioC 3.2 branch is now ready.
>>
>> Remember, you always have access to 2 versions of your package:
>> the "release" and the "devel" versions.
>>
>> Right now the "release" version of your package (which is not
>> officially released yet but will be tomorrow if
>> everything goes well) is in the 3.2 branch and accessible at:
>>
>>
>> https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/
>> 
>>
>> Only bug fixes and documentation improvements should go here.
>>
>> As always the "devel" version of your package is at:
>>
>>
>> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/
>>
>> Similarly for experiment packages, where your package is
>> available
>> in
>> devel at
>>
>> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/
>>
>> The release branch of it is in:
>>
>>
>> https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/
>> 
>>
>>
>> Normal development of your package can now resume here.
>>
>> Please let us know if you have any questions.
>>
>>
>> Thanks!
>>
>> Dan
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
>
> --
> Levi Waldron
> Assistant Professor of Biostatistics
> City University of New York School of Public Health, Hunter
> College
> 2180 3rd Ave Rm 538
> New York NY 10035-4003
> phone: 212-396-7747
> www.waldronlab.org
>
> [[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

>>>
>>> --
>>> Hervé Pagès
>>>
>>> Program in Computational Biology
>>> Division of Public Health Sciences
>>> Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N, M1-B514
>>> P.O. Box 19024
>>> Seattle, WA 98109-1024
>>>
>>> E-mail: hpa...@fredhutch.org
>>> Phone:  (206) 667-5791
>>> Fax:(206) 667-1319
>>>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] BioC 3.2 branch created

2015-10-16 Thread Dan Tenenbaum 
Thanks. Fixed, the change will propagate soon.
Dan


- Original Message -
> From: "Diego Diez" 
> To: "Hervé Pagès" 
> Cc: "Dan Tenenbaum" , "bioc-devel" 
> 
> Sent: Friday, October 16, 2015 5:11:08 PM
> Subject: Re: [Bioc-devel] BioC 3.2 branch created
> 
> Nice addition, thank you. Just want to note that now the 3.1 page
> says
> "April 17, 2005". Thats a long time ago! I guess it means "April 17,
> 2015".
> 
> Diego
> 
> On Sat, Oct 17, 2015 at 3:30 AM, Hervé Pagès 
> wrote:
> > On 10/16/2015 10:52 AM, Dan Tenenbaum wrote:
> >>
> >>
> >>
> >> - Original Message -
> >>>
> >>> From: "Hervé Pagès" 
> >>> To: "Dan Tenenbaum" , "Levi Waldron"
> >>> 
> >>> Cc: "bioc-devel" 
> >>> Sent: Friday, October 16, 2015 10:07:03 AM
> >>> Subject: Re: [Bioc-devel] BioC 3.2 branch created
> >>>
> >>> Hi Dan,
> >>>
> >>> Thanks for making that change. Would be great to have this for
> >>> the
> >>> previous releases too. One often lands on an announcement page
> >>> directly
> >>> from Google and has no easy way to tell when that release
> >>> happened.
> >>>
> >>
> >> Just committed the change, it should show up son. Looks like we
> >> used to do
> >> this and then stopped at some point.
> >
> >
> > Great. Thanks Dan!
> >
> > H.
> >
> >
> >> Dan
> >>
> >>
> >>> Thanks,
> >>> H.
> >>>
> >>>
> >>> On 10/16/2015 08:45 AM, Dan Tenenbaum wrote:
> 
>  Done, the change should appear within 20 minutes. Thanks for the
>  suggestion.
>  Dan
> 
> 
>  - Original Message -
> >
> > From: "Levi Waldron" 
> > To: "bioc-devel" 
> > Sent: Friday, October 16, 2015 8:23:17 AM
> > Subject: Re: [Bioc-devel] BioC 3.2 branch created
> >
> > Just a small suggestion, it might be helpful to put a date on
> > https://www.bioconductor.org/news/bioc_3_2_release/ - currently
> > it's
> > not
> > obvious when you land on that page when the announcement was
> > made,
> > or
> > that
> > this is the current release version.
> >
> > Thanks core team for your hard work in getting another release
> > out
> > on
> > schedule!
> >
> >
> >
> > On Tue, Oct 13, 2015 at 4:20 PM, Dan Tenenbaum
> > 
> > wrote:
> >
> >>
> >> The BioC 3.2 branch is now ready.
> >>
> >> Remember, you always have access to 2 versions of your
> >> package:
> >> the "release" and the "devel" versions.
> >>
> >> Right now the "release" version of your package (which is not
> >> officially released yet but will be tomorrow if
> >> everything goes well) is in the 3.2 branch and accessible at:
> >>
> >>
> >> https://hedgehog.fhcrc.org/bioconductor/branches/RELEASE_3_2/madman/Rpacks/
> >> 
> >>
> >> Only bug fixes and documentation improvements should go here.
> >>
> >> As always the "devel" version of your package is at:
> >>
> >>
> >> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/
> >>
> >> Similarly for experiment packages, where your package is
> >> available
> >> in
> >> devel at
> >>
> >> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/
> >>
> >> The release branch of it is in:
> >>
> >>
> >> https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_3_2/experiment/pkgs/
> >> 
> >>
> >>
> >> Normal development of your package can now resume here.
> >>
> >> Please let us know if you have any questions.
> >>
> >>
> >> Thanks!
> >>
> >> Dan
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >
> >
> >
> > --
> > Levi Waldron
> > Assistant Professor of Biostatistics
> > City University of New York School of Public Health, Hunter
> > College
> > 2180 3rd Ave Rm 538
> > New York NY 10035-4003
> > phone: 212-396-7747
> > www.waldronlab.org
> >
> > [[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
> 
> >>>
> >>> --
> >>> Hervé Pagès
> >>>
> >>> Program in Computational Biology
> >>> Division of Public Health Sciences
> >>> Fred Hutchinson Cancer Research Center
> >>> 1100 Fairview Ave. N, M1-B514
> >>> P.O. Box 19024
> >>> Seattle, WA

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

2015-10-16 Thread Michael Lawrence 
I kind of wish it would return NA for things like seqnames and strand,
but yes that would be very useful.

On Fri, Oct 16, 2015 at 9:15 AM, Hervé Pagès  wrote:
> Hi Michael, Martin,
>
> On 10/16/2015 06:48 AM, Michael Lawrence wrote:
>>
>> It does seem like starting with the more general data structure is the
>> better approach, but I couldn't find an easy way to move the paired subset
>> of GAlignmentsList to GAlignmentPairs. You mention a coercion, but it's
>> not
>> obvious to me, unfortunately.
>>
>> Another approach would be a GAlignmentPairs where the unpaired reads have
>> "missing" mates. I know GAlignments has no concept of missing, but it
>> would
>> get everything into a single data structure that is convenient for
>> computing on pairs.
>
>
> I could modify readGAlignmentPairs() to have the discordant and/or
> ambiguous pairs end up in th GAlignmentPairs. The ambiguous pairs
> could be marked as such thru a metadata col of the object or thru
> a proper slot. The seqnames() and strand() accessors will return
> * on discordant pairs. Does that sound reasonable?
>
> H.
>
>
>>
>> On Fri, Oct 16, 2015 at 5:21 AM, Morgan, Martin <
>> martin.mor...@roswellpark.org> wrote:
>>
>>>
>>>
 -Original Message-
 From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
 Michael Lawrence
 Sent: Friday, October 16, 2015 7:41 AM
 To: bioc-devel@r-project.org
 Subject: [Bioc-devel] readGAlignmentPairs with discordant strand

 Now that GAlignmentPairs supports discordant strand between mates, how
 hard would it be to relax that restriction on readGAlignmentPairs()?

 Also, would be nice if getDumpedAlignments() returned those dumped by
 readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the
>>>
>>> extra

 mcols) and calling makeGAlignmentPairs(). Not so convenient.
>>>
>>>
>>> I'm not sure whether this is relevant to your use case but
>>> readGAlignmentsList returns a list of paired mates, and if appropriate
>>> (based on ScanBamParam) list elements with solo travelers. The paired
>>> portion of the list can be coerced to GAlignmentPairs if the additional
>>> structure of that class is required.
>>>
>>> Martin
>>>

 Michael

[[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.
>>>
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319

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