On 02/24/2012 01:32 AM, Francesco Mancuso wrote: > Hi! > I think you already know. Now when requiring lumi instead of a warning, > I have the following error: > > Error : objects ?plot?, ?summary? are not exported by > 'namespace:BiocGenerics' Have you used updated BiocGenerics? The following might be useful source("http://bioconductor.org/biocLite.R") biocLite(character()) which will discover and ask if you want to update all packages. I should have updated the version dependency in BiocGenerics. Also, there is a warning Warning message: replacing previous import 'plot' when loading 'graphics' that comes from the genoset package; this warning will be addressed separately. > > Best, > Francesco > > On 23/02/2012 14:43, Martin Morgan wrote: >> On 02/23/2012 03:38 AM, Francesco Mancuso wrote: >>> Martin, >>> many thanks for the explanations! >>> But still in the lumi version 2.7.3 the warning persist. >>> >>> Warning message: >>> Functions for exporting methods must have been made generic, explicitly >>> or implicitly; not true when loading ?lumi? for ?summary? >> Bioconductor builds its packages on a daily basis; wait until version >> 2.7.4 is available, hopefully at 9:30am PST. Martin >> >>> Best, >>> Francesco >>> >>> > sessionInfo() >>> R Under development (unstable) (2012-02-22 r58461) >>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) >>> >>> locale: >>> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8 >>> >>> attached base packages: >>> [1] stats graphics grDevices utils datasets methods base >>> >>> other attached packages: >>> [1] lumi_2.7.3 nleqslv_1.9.2 methylumi_2.1.13 >>> Biobase_2.15.3 BiocGenerics_0.1.4 >>> >>> loaded via a namespace (and not attached): >>> [1] affy_1.33.2 affyio_1.23.1 annotate_1.33.1 >>> AnnotationDbi_1.17.15 bigmemory_4.2.11 BiocInstaller_1.3.7 >>> Biostrings_2.23.6 BSgenome_1.23.2 >>> [9] DBI_0.2-5 DNAcopy_1.29.0 GenomicRanges_1.7.25 >>> genoset_1.4.15 grid_2.15.0 hdrcde_2.15 >>> IRanges_1.13.24 KernSmooth_2.23-7 >>> [17] lattice_0.20-0 MASS_7.3-17 Matrix_1.0-4 >>> mgcv_1.7-13 nlme_3.1-103 preprocessCore_1.17.1 >>> RSQLite_0.11.1 xtable_1.6-0 >>> [25] zlibbioc_1.1.1 >>> >>> >>> On 22/02/2012 21:39, Martin Morgan wrote: >>>> On 02/22/2012 12:07 PM, Kevin R. Coombes wrote: >>>>> I am now really confused. (This is, perhaps, not an unusual state.) >>>>> >>>>> I just checked the documentation in R2.14.1, which is still the current >>>>> release. The three function "standardGeneric", "isGeneric" and >>>>> "setGeneric" are still there. The example NAMESPACE information in page >>>>> 36 of "Writing R Extensions" include the following lines taken from the >>>>> "stats4" package: >>>>> >>>>> export(mle) >>>>> importFrom("graphics", plot) >>>>> importFrom("stats", optim, qchisq) >>>>> ## For these, we define methods or (AIC, BIC, nobs) an implicit generic: >>>>> importFrom("stats", AIC, BIC, coef, confint, logLik, nobs, profile, >>>>> update, vcov) >>>>> exportClasses(mle, profile.mle, summary.mle) >>>>> ## All methods for imported generics: >>>>> exportMethods(coef, confint, logLik, plot, profile, summary, show, >>>>> update, vcov) >>>>> ## implicit generics which do not have any methods here >>>>> export(AIC, BIC, nobs) >>>>> >>>>> It also explicitly claims that "exporting methods on a generic in the >>>>> namespace will also export the generic, and >>>>> exporting a generic in the namespace will also export its methods". >>>> These are both true statements. >>>> >>>> I would say that the next lines >>>> >>>> "If the generic function is not local to this package, either because it >>>> was imported as a generic function or because the non-generic version >>>> has been made generic solely to add S4 methods to it (as for functions >>>> such as plot in the example above), it can be declared via either or >>>> both of export or exportMethods" >>>> >>>> are no longer accurate, as evidenced by the warning message that started >>>> this thread. I would also say that, if the remedy to the warning has >>>> been to use setGeneric("plot"), then the next clause >>>> >>>> "but the latter is clearer (and is used in the stats4 example above)" >>>> >>>> would not reflect my opinion -- the generic is being exported, along >>>> with its newly-adorned methods. >>>> >>>>> Also, even when I am using BioConductor, I am often also using >>>>> non-BioConductor packages (that might create their own generic version >>>>> of plot, because R core still only supplies S3 generics and not S4 >>>>> generics for everything -- or at least the obvious things). >>>> yes, you might choose to import a non-BiocGenerics generic to add your >>>> method to, or to create your own generic and export that, or use the >>>> generic provided by BiocGenerics, all of these are possible and until >>>> plot is made an S4 generic in R, all will introduce multiple versions of >>>> the plot generic. Choosing to use BiocGenerics reduces conflicts with >>>> other Bioconductor packages, without having any further deterimental >>>> consequences for non-Bioc packages -- at least a partial if not complete >>>> win, with no down-sides. >>>> >>>> The 'if(!isGeneric("plot"))' construct implies that you do not want to >>>> rely on imports, but instead on the search path (because otherwise you >>>> would know whether plot was a generic or not, without having to >>>> determine that in your code). This opens up any number of possible >>>> problems, for instance that the plot generic on the search path has been >>>> defined with different default behaviors or to dispatch on different >>>> arguments than the method that you'd like to introduce. >>>> >>>>> In what sense are "those days behind us"? >>>> I meant the days of not having a name space. >>>> >>>> Martin >>>> >>>>> On 2/22/2012 1:43 PM, Martin Morgan wrote: >>>>>> On 02/22/2012 11:18 AM, Kevin R. Coombes wrote: >>>>>>> Is this problem avoided by an explicit call to setGeneric in the R code >>>>>>> of the package, in the usual idiom: >>>>>>> >>>>>>> if (!isGeneric("plot")) >>>>>>> setGeneric("plot", function(x, y, ...) standardGeneric("plot")) >>>>>>> >>>>>>> or is there something else going on here that I don't understand? >>>>>> This idiom is problematic. The rules are that if the developer >>>>>> promotes the function to a generic, then it needs to be documented >>>>>> (fair enough, the generic is not the same as the original). But the >>>>>> construct is conditional, so the documentation is only sometimes >>>>>> required. Further, if the developer promotes the generic, then they >>>>>> need to export the generic rather than the method, export(plot) rather >>>>>> than exportMethods(plot). Again this would be conditional with the >>>>>> above scenario. >>>>>> >>>>>> Also, the developer is defining a method in their name space, and the >>>>>> developer has full control of the name space -- there is no need to >>>>>> determine at run time whether 'plot' is a generic or not; >>>>>> importFrom(graphics, plot) imports a non-generic, so the promotion >>>>>> would be required. It might be that plot has been promoted to a >>>>>> generic somewhere on the user search path, but relying on the user >>>>>> search path is not appropriate for a package; problems arise when a >>>>>> third package tries to import methods from an intermediate package >>>>>> (gory details available on request). >>>>>> >>>>>> And finally, within Bioconductor, it makes sense to avoid name >>>>>> collisions as much as possible. So if the function has been promoted >>>>>> to a generic in BiocGenerics, then that is the preferred source for >>>>>> import -- importFrom(BiocGenerics, plot). >>>>>> >>>>>> I think the conditional construct dates from pre-NAMESPACE days, when >>>>>> one really didn't have a choice. Those days are behind us. >>>>>> >>>>>> Martin >>>>>> >>>>>>> On 2/22/2012 12:18 PM, Martin Morgan wrote: >>>>>>>> On 02/22/2012 09:16 AM, Martin Morgan wrote: >>>>>>>>> On 02/22/2012 07:56 AM, Francesco Mancuso wrote: >>>>>>>>>> Dear all, >>>>>>>>>> I am the author of a CRAN package (HumMeth27QCReport) that >>>>>>>>>> denpends on >>>>>>>>>> lumi. >>>>>>>>>> Every time I call the lumi package I obtain the following warning: >>>>>>>>>> >>>>>>>>>> " >>>>>>>>>> Functions for exporting methods must have been made generic, >>>>>>>>>> explicitly or implicitly; not true when loading ?lumi? for ?summary? >>>>>>>>>> " >>>>>>>>>> >>>>>>>>>> Since this error comes not only when I try to build ny package but >>>>>>>>>> also >>>>>>>>>> when I require lumi from normal R command line, I think this is a >>>>>>>>>> problem in lumi package itself. Am I correct? >>>>>>>>>> Is there the possibility to solve it? >>>>>>>>> Hi Francesco -- we are addressing these warnings in a number of Bioc >>>>>>>>> packages; this particular problem was fixed in the devel branch last >>>>>>>>> night. Martin >>>>>>>> Maybe to provide developers with a little insight on this -- >>>>>>>> >>>>>>>> Previously, in a NAMESPACE file one might >>>>>>>> >>>>>>>> importFrom(graphics, plot) >>>>>>>> >>>>>>>> 'plot' is a standard R function in graphics. and then somewhere in the >>>>>>>> package code say >>>>>>>> >>>>>>>> setMethod(plot, "MyClass", ...) >>>>>>>> >>>>>>>> This would implicitly promote 'plot' from a standard R function to an >>>>>>>> S4 generic, and then associate a method for plotting instances of >>>>>>>> MyClass. Common practice was to then add to the NAMESPACE >>>>>>>> >>>>>>>> exportMethods(plot) >>>>>>>> >>>>>>>> This now generates a warning (soon to be an error, if I understand >>>>>>>> R-core's intentions), because the plot method is exported without a >>>>>>>> generic on which to export it. The solution is to explicitly create a >>>>>>>> generic for 'plot', and to export (and document) that, as well. >>>>>>>> >>>>>>>> Several functions, including plot, are 'promoted' in this way >>>>>>>> independently in different packages. This means that there would be >>>>>>>> many separate plot generics on which to hang methods and the user >>>>>>>> would potentially have to resolve dispatch to the package -- >>>>>>>> lumi::plot(...). The BiocGenerics package has been developed to >>>>>>>> provide a central location for generic definition, in hopes of >>>>>>>> avoiding this conflict. The BiocGenerics package creates commonly used >>>>>>>> generics, and these are made available to other packages. So the >>>>>>>> changes to lumi are >>>>>>>> >>>>>>>> 1. Add Imports: BiocGenerics to the DESCRIPTION file >>>>>>>> 2. Add importFrom(BiocGenerics, plot) to the NAMESPACE file >>>>>>>> 3. Remove importFrom(graphics, plot) from the NAMESPACE file >>>>>>>> >>>>>>>> If the generic were not defined in BiocGenerics, the solution would be >>>>>>>> >>>>>>>> 0. Tell us (via the bioc-devel list) that foo should be in >>>>>>>> BiocGenerics? >>>>>>>> 1. Introduce an explicit generic with setGeneric... >>>>>>>> 2. Perhaps provide an S3 version of the S4 method, see ?Methods >>>>>>>> 3. Export and document the explicit generic >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>>> r62969 |mtmorgan at fhcrc.org | 2012-02-21 20:37:50 -0800 (Tue, 21 Feb >>>>>>>>> 2012) | 6 lines >>>>>>>>> >>>>>>>>> code tidyup >>>>>>>>> >>>>>>>>> - avoid implicit plot, summary generic with BiocGenerics >>>>>>>>> - avoid partial matching >>>>>>>>> - remove empty documentation sections >>>>>>>>> >>>>>>>>> >>>>>>>>>> Many thanks, >>>>>>>>>> Francesco >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> sessionInfo() >>>>>>>>>> R Under development (unstable) (2012-01-30 r58238) >>>>>>>>>> Platform: i386-apple-darwin9.8.0/i386 (32-bit) >>>>>>>>>> >>>>>>>>>> locale: >>>>>>>>>> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8 >>>>>>>>>> >>>>>>>>>> attached base packages: >>>>>>>>>> [1] stats graphics grDevices utils datasets methods base >>>>>>>>>> >>>>>>>>>> other attached packages: >>>>>>>>>> [1] lumi_2.7.2 nleqslv_1.9.2 methylumi_2.1.13 >>>>>>>>>> Biobase_2.15.3 BiocGenerics_0.1.4 >>>>>>>>>> >>>>>>>>>> loaded via a namespace (and not attached): >>>>>>>>>> [1] affy_1.33.2 affyio_1.23.1 annotate_1.33.1 >>>>>>>>>> AnnotationDbi_1.17.15 BiocInstaller_1.3.7 DBI_0.2-5 >>>>>>>>>> grid_2.15.0 hdrcde_2.15 >>>>>>>>>> [9] IRanges_1.13.20 KernSmooth_2.23-7 lattice_0.20-0 >>>>>>>>>> MASS_7.3-16 Matrix_1.0-3 mgcv_1.7-13 >>>>>>>>>> nlme_3.1-103 preprocessCore_1.17.1 >>>>>>>>>> [17] RSQLite_0.11.1 tools_2.15.0 xtable_1.6-0 >>>>>>>>>> zlibbioc_1.1.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Bioconductor mailing list >>>>>>>>>> Bioconductor at r-project.org >>>>>>>>>> https://stat.ethz.ch/mailman/listinfo/bioconductor >>>>>>>>>> Search the archives: >>>>>>>>>> http://news.gmane.org/gmane.science.biology.informatics.conductor >>> -- >>> >>> *Francesco Mattia Mancuso* >>> Bioinformatician >>> >>> - Bioinformatics Core Facility >>> - Proteomics Core Facility >>> >>> CRG-Centre for Genomic Regulation (Room 439) >>> C/ Dr. Aiguader, 88 (Edif. PRBB) >>> 08003 Barcelona, Spain >>> >>> Mail:francesco.mancuso at crg.eu <mailto:francesco.mancuso at="" crg.eu=""> >>> Phone: +34 933160202 >>> http://www.crg.es/bioinformatics_unit >> >> -- >> Computational Biology >> Fred Hutchinson Cancer Research Center >> 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 >> >> Location: M1-B861 >> Telephone: 206 667-2793 >> . >> > > -- > > *Francesco Mattia Mancuso* > Bioinformatician > > - Bioinformatics Core Facility > - Proteomics Core Facility > > CRG-Centre for Genomic Regulation (Room 439) > C/ Dr. Aiguader, 88 (Edif. PRBB) > 08003 Barcelona, Spain > > Mail: francesco.mancuso at crg.eu <mailto:francesco.mancuso at="" crg.eu=""> > Phone: +34 933160202 > http://www.crg.es/bioinformatics_unit -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793