[BioC] no summary of GOHyperGResult
Robert M. Flight
rflight79 at gmail.com
Fri Jul 9 16:36:03 CEST 2010
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
>
More information about the Bioconductor
mailing list