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.mich...@gene.com> > To: "Hervé Pagès" <hpa...@fredhutch.org> > Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel" > <bioc-devel@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 <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 _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel