warning in lumi
1
0
Entering edit mode
@francesco-mancuso-4483
Last seen 9.6 years ago
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? 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 -- *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@crg.eu <mailto:francesco.mancuso@crg.eu> Phone: +34 933160202 http://www.crg.es/bioinformatics_unit [[alternative HTML version deleted]]
Proteomics lumi Proteomics lumi • 1.2k views
ADD COMMENT
0
Entering edit mode
@martin-morgan-1513
Last seen 6 weeks ago
United States
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 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 -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793
ADD COMMENT
0
Entering edit mode
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 > > -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793
ADD REPLY
0
Entering edit mode
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? 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 >> >> > >
ADD REPLY
0
Entering edit mode
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 >>> >>> >> >> -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793
ADD REPLY
0
Entering edit mode
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". 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). In what sense are "those days behind us"? 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 >>>> >>>> >>> >>> > >
ADD REPLY
0
Entering edit mode
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 >>>>> >>>>> >>>> >>>> >> >> -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793
ADD REPLY
0
Entering edit mode
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’ 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@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@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@crg.eu <mailto:francesco.mancuso@crg.eu> Phone: +34 933160202 http://www.crg.es/bioinformatics_unit [[alternative HTML version deleted]]
ADD REPLY
0
Entering edit mode
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
ADD REPLY
0
Entering edit mode
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' 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@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@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@crg.eu<mailto:francesco.mancuso@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@crg.eu <mailto:francesco.mancuso@crg.eu> Phone: +34 933160202 http://www.crg.es/bioinformatics_unit [[alternative HTML version deleted]]
ADD REPLY
0
Entering edit mode
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
ADD REPLY

Login before adding your answer.

Traffic: 763 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6