[Bioc-devel] namespace question
Dan Tenenbaum
dtenenba at fredhutch.org
Sat Apr 2 19:58:32 CEST 2016
BTW, looks like the change has been made to R-devel:
#### CHANGES IN R-devel NEW FEATURES
* The ‘import()’ namespace directive now accepts an argument ‘except’ which names symbols to exclude from the imports. The ‘except’ expression should evaluate to a character vector (after substituting symbols for strings). See Writing R Extensions.
URL: http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2016/04/02#n2016-04-02
----- Original Message -----
> From: "Michael Lawrence" <lawrence.michael at gene.com>
> To: "Hervé Pagès" <hpages at fredhutch.org>
> Cc: "Michael Lawrence" <lawrence.michael at gene.com>, "bioc-devel" <bioc-devel at r-project.org>
> Sent: Saturday, April 2, 2016 4:10:10 AM
> Subject: Re: [Bioc-devel] namespace question
> Also, just btw, there are two other places where arbitrary R code can
> be evaluated in the NAMESPACE, but no one has abused them yet. as far
> as I know. The first argument to if() and the .fixes argument to
> useDynLib(). The latter sets the precedent for the except= behavior.
> Although someone forgot to document it, you can do .fixes=c("prefix",
> "suffix") to both prefix and suffix incoming native symbols.
> Currently, the documentation only mentions prefixing. Not sure when
> suffixing would be desirable.
>
>
> On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpages at fredhutch.org> wrote:
>> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>>
>>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>>> You're right that it's a big door and could let people do weird
>>> things. Do you foresee a problem with that?
>>
>>
>> Opening such a big door raises many questions. In addition to allowing
>> people do weird/crazy things (like putting calls to library()
>> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
>> R code in them become more complicated to maintain and the tools for
>> parsing/processing them also become more complicated to write and
>> maintain.
>>
>> Now we have a new category of errors that can happen at package
>> installation time: errors triggered by the evaluation of the R
>> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
>> will report something that can be understood by mere mortals when this
>> happens.
>>
>> Once you create the feeling that a NAMESPACE file is just a file
>> that contains arbitrary R code then people expect import(), export()
>> etc.. to be ordinary R functions with a man page (being able to do
>> ?import would not hurt actually) and they'll naturally try to do
>> things like
>>
>> unwanted_foo_symbols <- ... long and complicated expression
>> eventually calling user-defined helper
>> functions located in the NAMESPACE file ...
>> import(foo, except=unwanted_foo_symbols)
>>
>> Can't blame them for that. But is this the kind of things that we're
>> ready to see in NAMESPACE files?
>>
>> Also once you've open that door, people will naturally wonder why they
>> can use an R expression in the 'except' part of import( , except=) but
>> not elsewhere e.g. in
>>
>> import(foo, only=paste0("bar", 1:10))
>>
>> as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
>> This dissymmetry between the syntax of "import only this" and "import
>> all except this" feels very arbitrary. If you don't support the
>> import( , only=) syntax, people might legitimately ask things like
>>
>> do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10))))
>>
>> to work. Again, can't blame them for that. But do we want this kind of
>> things to work? I'm worried debugging NAMESPACE files would become a
>> full-time job...
>>
>>> I guess one could have implemented NAMESPACE parsing by evaluating the
>>> code in an environment (inheriting from the base namespace) where
>>> import(), export(), etc, were defined. Maybe there's a good reason why
>>> it was not implemented that way.
>>
>>
>> I'm sure there is ;-)
>>
>> H.
>>
>>
>>>
>>> On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès <hpages at fredhutch.org> wrote:
>>>>
>>>> On 03/31/2016 04:07 PM, Michael Lawrence wrote:
>>>>>
>>>>>
>>>>> I agree. The importExcept idea also works that way: importExcept(foo,
>>>>> bar,
>>>>> baz)
>>>>>
>>>>> But import(foo, except=c(bar, baz)) reads better.
>>>>
>>>>
>>>>
>>>> mmh... so R expressions with calls to base functions like base::c() are
>>>> making their way in the NAMESPACE file. That's opening a big door. Does
>>>> that mean that we'll be able to do things like:
>>>>
>>>> import(foo, except=paste0("bar", 1:10))
>>>>
>>>> Or maybe c(bar, baz) in your above example is just an arbitrary syntax
>>>> that just happens to look like an R expression but won't be evaluated
>>>> as such?
>>>>
>>>>
>>>> H.
>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 31, 2016 at 4:00 PM, <luke-tierney at uiowa.edu> wrote:
>>>>>>
>>>>>>
>>>>>> I don't think you want to separate it from the import. Better to allow
>>>>>> something like
>>>>>>
>>>>>> import(foo, exclude=bar)
>>>>>>
>>>>>> or
>>>>>>
>>>>>> import(foo, exclude=c("bar", "baz"))
>>>>>>
>>>>>> This seems reasonably natural and shouldn't be too hard to
>>>>>> implement. (But is has been a while since I've worked on this code).
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> luke
>>>>>>
>>>>>>
>>>>>> On Thu, 31 Mar 2016, Karim Mezhoud wrote:
>>>>>>
>>>>>>> I think "From" is needed to specify which package we want to exlude
>>>>>>> functions.
>>>>>>>
>>>>>>> I think excludeFrom (package, function) seems to be intuitive.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Karim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès <hpages at fredhutch.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 03/31/2016 12:55 PM, Michael Lawrence wrote:
>>>>>>>>
>>>>>>>>> Probably should just stick to exact symbols for now. If there is a
>>>>>>>>> case where a pattern is actually useful, rather than just an
>>>>>>>>> obfuscation, we can extend the feature set.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Fair enough. Not really intuitive that excludeImport uses the same
>>>>>>>> syntax as (but does the opposite of) importFrom though. Maybe having
>>>>>>>> the name of the directive start with "import" would help e.g.
>>>>>>>>
>>>>>>>> importExcept(hash, values) # opposite of importFrom(hash, values)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> H.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
>>>>>>>>> <Julie.Zhu at umassmed.edu> wrote:
>>>>>>>>>
>>>>>>>>>> Herve,
>>>>>>>>>>
>>>>>>>>>> That is a very interesting idea and works for me! Thanks!
>>>>>>>>>>
>>>>>>>>>> importPatternFrom(IRanges, "^values$")
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Julie
>>>>>>>>>>
>>>>>>>>>> On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
>>>>>>>>>> <bioc-devel-bounces at r-project.org on behalf of
>>>>>>>>>> hpages at fredhutch.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 03/30/2016 08:35 PM, Michael Lawrence wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> That would work, but R is not going to be happy about redundant
>>>>>>>>>>>> imports. Interactively, users would balk at symbol qualification.
>>>>>>>>>>>>
>>>>>>>>>>>> There are two classes of conflict:
>>>>>>>>>>>> 1) Same semantics, where a common generic would arbitrate, or one
>>>>>>>>>>>> package could depend on the other, and
>>>>>>>>>>>> 2) Different semantics, in which case one of the functions should
>>>>>>>>>>>> probably be renamed, although that might not be practical or easy
>>>>>>>>>>>> to
>>>>>>>>>>>> agree upon.
>>>>>>>>>>>>
>>>>>>>>>>>> When those approaches fail, qualification is the only recourse.
>>>>>>>>>>>>
>>>>>>>>>>>> I will think about adding an excludeImport() or importAs().
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What about having something like an importPatternFrom() directive
>>>>>>>>>>> similar to the exportPattern() directive and have these directives
>>>>>>>>>>> support some of the grep() toggles like 'ignore.case', 'fixed',
>>>>>>>>>>> 'invert' etc... ?
>>>>>>>>>>>
>>>>>>>>>>> Then Julie could just do:
>>>>>>>>>>>
>>>>>>>>>>> importPatternFrom(hash, "^values$", invert=TRUE)
>>>>>>>>>>>
>>>>>>>>>>> H.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight
>>>>>>>>>>>> <rflight79 at gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> In the cases of having conflicting names, is it not appropriate
>>>>>>>>>>>>> then
>>>>>>>>>>>>> to use
>>>>>>>>>>>>> the "package::function" form for calling a particular function?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
>>>>>>>>>>>>> <lawrence.michael at gene.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can't find the hash function in IRanges. Are you sure it has
>>>>>>>>>>>>> one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>>>>>>>>>>>>>> <Julie.Zhu at umassmed.edu> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Michael,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have the same user case as Kasper. Another example is that
>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>> IRanges
>>>>>>>>>>>>>>> and hash packages have hash. I need to use the hash from the
>>>>>>>>>>>>>>> hash
>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>> instead of the one from IRanges.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Julie
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>>>>>>>>>>>>>>> <kasperdanielhansen at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My usecase is when I import() two packages who has a conflict
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> name.
>>>>>>>>>>>>>>> For example, both Biobase and matrixStats has both anyMissing
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> rowMedians. I am happy to get all of these two packages, but I
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> resolve the conflict. Since I want to keep the ones from
>>>>>>>>>>>>>>> matrixStats I
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> need to figure out how to import Biobase selectively. Which I
>>>>>>>>>>>>>>> can,
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> the tools from codetoolsBioC, but I would also be happy with
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> importFromExcept(), which would make my life much easier.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>> Kasper
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>>>>>>>>>>>>>>> <lawrence.michael at gene.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm curious about which symbols you wouldn't want to import,
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> why.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>>>>>>>>>>>>>>> <Julie.Zhu at umassmed.edu> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is there a function to import all the exported objects from
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>>>> except a few named ones in NAMESPACE file?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For example, I would like to import all the functions in
>>>>>>>>>>>>>>>>> S4Vectors
>>>>>>>>>>>>>>>>> except fold. Is there a way to specify this without listing
>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>> functions using importFrom?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Many thanks for your help!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Julie
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ********************************************
>>>>>>>>>>>>>>>>> Lihua Julie Zhu, Ph.D
>>>>>>>>>>>>>>>>> Research Professor
>>>>>>>>>>>>>>>>> Department of Molecular, Cell and Cancer Biology (MCCB)
>>>>>>>>>>>>>>>>> Head of MCCB Bioinformatics Core
>>>>>>>>>>>>>>>>> Program in Molecular Medicine
>>>>>>>>>>>>>>>>> Program in Bioinformatics and Integrative Biology
>>>>>>>>>>>>>>>>> University of Massachusetts Medical School
>>>>>>>>>>>>>>>>> 364 Plantation Street, Room 613
>>>>>>>>>>>>>>>>> Worcester, MA 01605
>>>>>>>>>>>>>>>>> 508-856-5256 phone
>>>>>>>>>>>>>>>>> (508) 856 5460 fax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE&Perso
>>>>>>>>>>>>>> n=1134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [[alternative HTML version deleted]]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_ma
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ilman_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeR
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> jY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=Rxzbh
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> vEdYoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8
>>>>>>>>>>>>>>>>> CzeHHAAJ5kmgmJxQ&e=
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> lman_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEd
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeH
>>>>>>>>>>>>>>>> HAAJ5kmgmJxQ&e=
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> an_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4D
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> erPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-Vr
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> N42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmg
>>>>>>>>>>>>>> mJxQ&e=
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> [[alternative HTML version deleted]]
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> n_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> PlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-VrN42
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgmJxQ
>>>>>>>>>>>>> &e=
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPl
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> OmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-VrN42rfi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> K5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgmJxQ&e=
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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: hpages at fredhutch.org
>>>>>>>>>>> Phone: (206) 667-5791
>>>>>>>>>>> Fax: (206) 667-1319
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOm
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> hQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-VrN42rfiK5-
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgmJxQ&e=
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> 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: hpages at fredhutch.org
>>>>>>>> Phone: (206) 667-5791
>>>>>>>> Fax: (206) 667-1319
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [[alternative HTML version deleted]]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Luke Tierney
>>>>>> Ralph E. Wareham Professor of Mathematical Sciences
>>>>>> University of Iowa Phone: 319-335-3386
>>>>>> Department of Statistics and Fax: 319-335-3017
>>>>>> Actuarial Science
>>>>>> 241 Schaeffer Hall email: luke-tierney at uiowa.edu
>>>>>> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>>>>
>>>>
>>>>
>>>> --
>>>> 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: hpages at 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: hpages at fredhutch.org
>> Phone: (206) 667-5791
>> Fax: (206) 667-1319
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
More information about the Bioc-devel
mailing list