At the same time, it would empower developers, who should be free to
assume their own risks. There are already many ways an R user can
break things.
But I agree with the simplicity argument. NAMESPACE, while conforming
to R syntax, does not have "standard" R semantics. Mixing semantics,
especially within the same general syntax, is confusing. It would
become difficult to document the rules to which a valid NAMESPACE file
must conform.
One solution would be to support defining a namespace in pure R via a
NAMESPACE.R that is evaluated in a special environment where the
import/export functions are defined. It would be required to pass
symbols as character vectors. I'm not going there though.
I do think that the current NAMESPACE parser could be simplified by
evaluating the code in a highly constrained environment, only
borrowing if() from base.
For now though I will just change it to only support 'c'. Or, what
about this syntax:
import(foo, except(bar, baz))
Not so R-like but seems to fit in with all of the variadic calls in NAMESPACE.
Michael
On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpa...@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 <hpa...@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-tier...@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 <hpa...@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....@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-boun...@r-project.org on behalf of
>>>>>>>>> hpa...@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
>>>>>>>>>>> <rfligh...@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.mich...@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....@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
>>>>>>>>>>>>>> <kasperdanielhan...@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.mich...@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....@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@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@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@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@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@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: hpa...@fredhutch.org
>>>>>>>>>> Phone: (206) 667-5791
>>>>>>>>>> Fax: (206) 667-1319
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Bioc-devel@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: 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [[alternative HTML version deleted]]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bioc-devel@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-tier...@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: 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
