[BioC] no summary of GOHyperGResult

Robert Castelo robert.castelo at upf.edu
Fri Jul 9 18:05:02 CEST 2010


Kudos to Seth who figured out the fix!

robert.

On Fri, 2010-07-09 at 11:44 -0400, Robert M. Flight wrote:
> That appears to have fixed it Robert, thank you. Now on to the next
> error (isn't debugging fun)!
> 
> -Robert
> 
> On Fri, Jul 9, 2010 at 11:03, Robert Castelo <robert.castelo at upf.edu> wrote:
> > 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
> >>
> >
> >
>



More information about the Bioconductor mailing list