Hi Robert, On 7/9/2010 10:36 AM, Robert M. Flight wrote: > Thanks to both Martin and James for the suggestions, but I give up. > I've tried adding the stuff to the NAMESPACE file that Martin > suggested, and that doesn't seem to work. However, I can't figure out > where or how I would add the kluge that James suggests, as this isn't > required in GOstats and it figures it out fine. No it doesn't. Martin may be correct that the problem finding summary methods might have been fixed, but as it stands with the GOstats package, the same kludge still exists for finding the correct summary method from within a function. As you have already noted, *from within a function* there is some problem dispatching on the correct summary method (i.e., finding the summary method for a GOHyperGResults object). I thought what I gave you yesterday was pretty explicit, but maybe I can make it more so. If we look at the code for probeSetSummary, we get to a point where we are going to want to call the summary method on a GOHyperGResults object. However, knowing that the correct dispatch isn't going to happen, Seth adds in a kludgetastic little function to go out and get the correct summary function first (which he has named in such a manner that nobody in their right mind will ever mistakenly call it). summary <- Category:::XXX_getSummaryGeneric_XXX() This step ensures that the summary function called within the probeSetSummary() function will be the correct one. In the next step, we go ahead and call the summary function, knowing now that we have the right one goids <- summary(result, pvalue, categorySize)[, 1] So for this to work with your package, you will need to add an import(Category) to your NAMESPACE file, and then in your function that is attempting to use the summary function, you will need to do step number one above first, and then you will be able to call summary correctly. > > I know I can access what I need using the slots of the object, I just > figured that I would use the methods already available. > > For the record, determining how to go from a simple function with > "require" to a package that has access to the right functions and > methods is a real pain, and the documentation is none too stupendous > on how to do that. As with most R documentation, everything you need is there, but it has been boiled down to the epitome of terseness. See http://cran.r-project.org/doc/manuals/R-exts.html#Package-name-spaces And even more enlightening, see just about any of the 'base' packages in BioC. For instance, the NAMESPACE file for GOstats, which shows you how to do just about any import or export directive. Note that they are really simple in structure: import(foo) gets all exported functions from a package called foo. importFrom(foo, bar, bas) imports just two functions, bar and bas, from package foo, etc, etc. Best, Jim > > Thanks, > > -Robert > > Robert M. Flight, Ph.D. > Bioinformatics and Biomedical Computing Laboratory > University of Louisville > Louisville, KY > > PH 502-852-0467 > EM robert.flight at louisville.edu > EM rflight79 at gmail.com > > Williams and Holland's Law: > If enough data is collected, anything may be proven by > statistical methods. I'm not sure either Williams nor Holland can be trusted to make any such statement if they don't know that data is the plural of datum. ;-D > > > > On Thu, Jul 8, 2010 at 18:42, Martin Morgan<mtmorgan at="" fhcrc.org=""> wrote: >> On 07/08/2010 01:56 PM, Robert M. Flight wrote: >>> This strikes me as really weird (and annoying) behavior. >>> >>> I have a GOHyperGResult, calculated using GOstats and Category from >>> which I want to obtain a summary. This summary call is within a >>> function, that I tested time and time again to verify that it was >>> working (worked yesterday, haven't changed my setup). However, now, >>> whenever I call summary on the GOHyperGResult in my function, I get >>> this (via browser(expr=TRUE) just before where I would actually use >>> it): >>> >>> R> summary(GOHyperGResultObject) >>> >>> Length Class Mode >>> 1 GOHyperGResult S4 >>> >>> However, showMethods("summary") gives the following: >>> >>> Function: summary (package base) >>> object="AnnDbBimap" >>> object="ANY" >>> object="Bimap" >>> object="DBIObject" >>> object="GOHyperGResult" >>> object="HyperGResultBase" >>> object="KEGGHyperGResult" >>> object="LinearMResultBase" >>> object="PFAMHyperGResult" >>> object="SQLiteConnection" >>> object="SQLiteDriver" >>> object="SQLiteResult" >>> >>> When outside the function (in the base workspace), I get the actual >>> summary I am after. However, when I check if there is a difference in >>> showMethods("summary"), I see the same list: >>> Function: summary (package base) >>> object="AnnDbBimap" >>> object="ANY" >>> object="Bimap" >>> object="DBIObject" >>> object="GOHyperGResult" >>> object="HyperGResultBase" >>> object="KEGGHyperGResult" >>> object="LinearMResultBase" >>> object="PFAMHyperGResult" >>> object="SQLiteConnection" >>> object="SQLiteDriver" >>> object="SQLiteResult" >>> >>> The object in the base workspace is a save of the object being >>> generated in my function, so I know it is not because they are >>> different objects. I thought this might due to installing a new >>> package (KEGGgraph was the last one I installed), but even after >>> removing and restarting the same behavior continues. >>> >>> If anyone could shed some light on this behavior, I would really, >>> really appreciate it, because I can't see why this is happening. My >>> function is in a package, do I need to explicitly import the "summary" >>> method from GOstats in the NAMESPACE? I already have GOstats in the >>> require, and it loads the package. >> >> If your function is in a package, then yes, you should in the >> DESCRIPTION file >> >> Imports: GOstats >> >> and >> >> importClassesFrom(GOstats, GOHyperGResult) >> importMethodsFrom(GOstats, summary) >> >> It sounds like your package has code >> >> require(GOstats) >> >> but that's not what you want to do -- it'll attach GOstats to the search >> path, but you want GOstats, or at least the summary methods defined in >> GOstats, available to your package without relying on the structure of >> the (user modifiable) search path. >> >> I don't know the details behind Jim's suggestion, but a certain amount >> of water has passed under the bridge since then and I'd be interested in >> knowing whether those contortions are actually necessary in an >> appropriately structured package. >> >> Martin >> >> >>> >>> Cheers, >>> >>> -Robert >>> >>> R version 2.11.1 (2010-05-31) >>> i386-pc-mingw32 >>> >>> locale: >>> [1] LC_COLLATE=English_United States.1252 >>> [2] LC_CTYPE=English_United States.1252 >>> [3] LC_MONETARY=English_United States.1252 >>> [4] LC_NUMERIC=C >>> [5] LC_TIME=English_United States.1252 >>> >>> attached base packages: >>> [1] grid stats graphics grDevices utils datasets methods >>> [8] base >>> >>> other attached packages: >>> [1] org.Mm.eg.db_2.4.1 GO.db_2.4.1 categoryCompare_0.1-1 >>> [4] biocGraph_1.10.0 Rgraphviz_1.26.0 hwriter_1.2 >>> [7] GOstats_2.14.0 RSQLite_0.9-1 DBI_0.2-5 >>> [10] graph_1.26.0 Category_2.14.0 AnnotationDbi_1.10.1 >>> [13] Biobase_2.8.0 >>> >>> loaded via a namespace (and not attached): >>> [1] annotate_1.26.0 genefilter_1.30.0 geneplotter_1.26.0 GSEABase_1.10.0 >>> [5] RBGL_1.24.0 RColorBrewer_1.0-2 splines_2.11.1 survival_2.35-8 >>> [9] tools_2.11.1 XML_3.1-0 xtable_1.5-6 >>> >>> Robert M. Flight, Ph.D. >>> Bioinformatics and Biomedical Computing Laboratory >>> University of Louisville >>> Louisville, KY >>> >>> PH 502-852-0467 >>> EM robert.flight at louisville.edu >>> EM rflight79 at gmail.com >>> >>> Williams and Holland's Law: >>> If enough data is collected, anything may be proven by >>> statistical methods. >>> >>> _______________________________________________ >>> Bioconductor mailing list >>> Bioconductor at stat.math.ethz.ch >>> https://stat.ethz.ch/mailman/listinfo/bioconductor >>> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor >> >> >> -- >> Martin Morgan >> Computational Biology / Fred Hutchinson Cancer Research Center >> 1100 Fairview Ave. N. >> PO Box 19024 Seattle, WA 98109 >> >> Location: Arnold Building M1 B861 >> Phone: (206) 667-2793 >> -- James W. MacDonald, M.S. Biostatistician Douglas Lab University of Michigan Department of Human Genetics 5912 Buhl 1241 E. Catherine St. Ann Arbor MI 48109-5618 734-615-7826 ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

hi Robert, could you try to add: summary <- getGeneric("summary") right before you make the summary call to the GOHyperGResult in your function? your problem sounds similar to one i found earlier this year and for which Seth Falcon found this workaround, you can take a look at the thread here: https://stat.ethz.ch/pipermail/bioconductor/2010-January/031211.html cheers, robert. On Fri, 2010-07-09 at 10:36 -0400, Robert M. Flight wrote: > Thanks to both Martin and James for the suggestions, but I give up. > I've tried adding the stuff to the NAMESPACE file that Martin > suggested, and that doesn't seem to work. However, I can't figure out > where or how I would add the kluge that James suggests, as this isn't > required in GOstats and it figures it out fine. > > I know I can access what I need using the slots of the object, I just > figured that I would use the methods already available. > > For the record, determining how to go from a simple function with > "require" to a package that has access to the right functions and > methods is a real pain, and the documentation is none too stupendous > on how to do that. > > Thanks, > -Robert > > Robert M. Flight, Ph.D. > Bioinformatics and Biomedical Computing Laboratory > University of Louisville > Louisville, KY > > PH 502-852-0467 > EM robert.flight at louisville.edu > EM rflight79 at gmail.com > > Williams and Holland's Law: > If enough data is collected, anything may be proven by > statistical methods. > > > > On Thu, Jul 8, 2010 at 18:42, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: > > On 07/08/2010 01:56 PM, Robert M. Flight wrote: > >> This strikes me as really weird (and annoying) behavior. > >> > >> I have a GOHyperGResult, calculated using GOstats and Category from > >> which I want to obtain a summary. This summary call is within a > >> function, that I tested time and time again to verify that it was > >> working (worked yesterday, haven't changed my setup). However, now, > >> whenever I call summary on the GOHyperGResult in my function, I get > >> this (via browser(expr=TRUE) just before where I would actually use > >> it): > >> > >> R> summary(GOHyperGResultObject) > >> > >> Length Class Mode > >> 1 GOHyperGResult S4 > >> > >> However, showMethods("summary") gives the following: > >> > >> Function: summary (package base) > >> object="AnnDbBimap" > >> object="ANY" > >> object="Bimap" > >> object="DBIObject" > >> object="GOHyperGResult" > >> object="HyperGResultBase" > >> object="KEGGHyperGResult" > >> object="LinearMResultBase" > >> object="PFAMHyperGResult" > >> object="SQLiteConnection" > >> object="SQLiteDriver" > >> object="SQLiteResult" > >> > >> When outside the function (in the base workspace), I get the actual > >> summary I am after. However, when I check if there is a difference in > >> showMethods("summary"), I see the same list: > >> Function: summary (package base) > >> object="AnnDbBimap" > >> object="ANY" > >> object="Bimap" > >> object="DBIObject" > >> object="GOHyperGResult" > >> object="HyperGResultBase" > >> object="KEGGHyperGResult" > >> object="LinearMResultBase" > >> object="PFAMHyperGResult" > >> object="SQLiteConnection" > >> object="SQLiteDriver" > >> object="SQLiteResult" > >> > >> The object in the base workspace is a save of the object being > >> generated in my function, so I know it is not because they are > >> different objects. I thought this might due to installing a new > >> package (KEGGgraph was the last one I installed), but even after > >> removing and restarting the same behavior continues. > >> > >> If anyone could shed some light on this behavior, I would really, > >> really appreciate it, because I can't see why this is happening. My > >> function is in a package, do I need to explicitly import the "summary" > >> method from GOstats in the NAMESPACE? I already have GOstats in the > >> require, and it loads the package. > > > > If your function is in a package, then yes, you should in the > > DESCRIPTION file > > > > Imports: GOstats > > > > and > > > > importClassesFrom(GOstats, GOHyperGResult) > > importMethodsFrom(GOstats, summary) > > > > It sounds like your package has code > > > > require(GOstats) > > > > but that's not what you want to do -- it'll attach GOstats to the search > > path, but you want GOstats, or at least the summary methods defined in > > GOstats, available to your package without relying on the structure of > > the (user modifiable) search path. > > > > I don't know the details behind Jim's suggestion, but a certain amount > > of water has passed under the bridge since then and I'd be interested in > > knowing whether those contortions are actually necessary in an > > appropriately structured package. > > > > Martin > > > > > >> > >> Cheers, > >> > >> -Robert > >> > >> R version 2.11.1 (2010-05-31) > >> i386-pc-mingw32 > >> > >> locale: > >> [1] LC_COLLATE=English_United States.1252 > >> [2] LC_CTYPE=English_United States.1252 > >> [3] LC_MONETARY=English_United States.1252 > >> [4] LC_NUMERIC=C > >> [5] LC_TIME=English_United States.1252 > >> > >> attached base packages: > >> [1] grid stats graphics grDevices utils datasets methods > >> [8] base > >> > >> other attached packages: > >> [1] org.Mm.eg.db_2.4.1 GO.db_2.4.1 categoryCompare_0.1-1 > >> [4] biocGraph_1.10.0 Rgraphviz_1.26.0 hwriter_1.2 > >> [7] GOstats_2.14.0 RSQLite_0.9-1 DBI_0.2-5 > >> [10] graph_1.26.0 Category_2.14.0 AnnotationDbi_1.10.1 > >> [13] Biobase_2.8.0 > >> > >> loaded via a namespace (and not attached): > >> [1] annotate_1.26.0 genefilter_1.30.0 geneplotter_1.26.0 GSEABase_1.10.0 > >> [5] RBGL_1.24.0 RColorBrewer_1.0-2 splines_2.11.1 survival_2.35-8 > >> [9] tools_2.11.1 XML_3.1-0 xtable_1.5-6 > >> > >> Robert M. Flight, Ph.D. > >> Bioinformatics and Biomedical Computing Laboratory > >> University of Louisville > >> Louisville, KY > >> > >> PH 502-852-0467 > >> EM robert.flight at louisville.edu > >> EM rflight79 at gmail.com > >> > >> Williams and Holland's Law: > >> If enough data is collected, anything may be proven by > >> statistical methods. > >> > >> _______________________________________________ > >> Bioconductor mailing list > >> Bioconductor at stat.math.ethz.ch > >> https://stat.ethz.ch/mailman/listinfo/bioconductor > >> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor > > > > > > -- > > Martin Morgan > > Computational Biology / Fred Hutchinson Cancer Research Center > > 1100 Fairview Ave. N. > > PO Box 19024 Seattle, WA 98109 > > > > Location: Arnold Building M1 B861 > > Phone: (206) 667-2793 > > > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor >