On 08/01/2013 07:39 PM, Vincent Carey wrote:
> and, continuing on this important new resource, shouldn't the 
> following work?
>
> > class(x)
> [1] "AnnotationHub"
> attr(,"package")
> [1] "AnnotationHub"
> > x
> class: AnnotationHub
> length: 7855
> filters: none
> hubUrl: http://annotationhub.bioconductor.org/ah
> snapshotVersion: 2.13; snapshotDate: 2013-06-26
> hubCache: /Users/stvjc/.AnnotationHub
> > keys(x, keytype="Description")
>
> Enter a frame number, or 0 to exit
>
>  1: keys(x, keytype = "Description")
>  2: keys(x, keytype = "Description")
>  3: .local(x, keytype, ...)
>  4: .keys(snapshotUrl(x), keytype)
>  5: unique(.parseJSON(url))
>  6: .parseJSON(url)
>  7: tryCatch({
>     tmp <- tempfile()
>     if (getOption("AnnotationHub.debug", FAL
>  8: tryCatchList(expr, classes, parentenv, handlers)
>  9: tryCatchOne(expr, names, parentenv, handlers[[1]])
> 10: value[[3]](cond)
>
> i'd also suggest that ahinfo() return an object, not end with a message.
>

Actually, I added an argument the other day to let it do that, although 
I don't expect most people will need the argument.  So if you want the 
metadata as a list you can do this:

library(AnnotationHub)
ah = AnnotationHub()

ahinfo(ah, 
path="goldenpath.hg19.encodeDCC.wgEncodeUwTfbs.wgEncodeUwTfbsMcf7CtcfStdPkRep1.narrowPeak_0.0.1.RData", 
returnMeta=TRUE)

And it returns a list object instead of just displaying a pretty 
message.  I am currently using this to automagically add the metadata 
onto GRanges and GRangesList objects when you ask for them.


   Marc


> > sessionInfo()
> R version 3.0.1 Patched (2013-06-02 r62857)
> Platform: x86_64-apple-darwin10.8.0/x86_64 (64-bit)
>
> locale:
> [1] 
> en_US.US-ASCII/en_US.US-ASCII/en_US.US-ASCII/C/en_US.US-ASCII/en_US.US-ASCII
>
> attached base packages:
> [1] parallel  stats     graphics  grDevices datasets  utils     tools
> [8] methods   base
>
> other attached packages:
> [1] AnnotationHub_1.1.8  IRanges_1.19.19  BiocGenerics_0.7.3
> [4] BiocInstaller_1.11.4 weaver_1.27.0  codetools_0.2-8
> [7] digest_0.6.3
>
> loaded via a namespace (and not attached):
> [1] AnnotationDbi_1.23.18 Biobase_2.21.6        DBI_0.2-7
> [4] GenomicRanges_1.13.35 rjson_0.2.12  RSQLite_0.11.4
> [7] stats4_3.0.1          XVector_0.1.0
>
>
>
> On Thu, Aug 1, 2013 at 8:46 PM, Kasper Daniel Hansen 
> <kasperdanielhansen@gmail.com <mailto:kasperdanielhansen@gmail.com>> 
> wrote:
>
>     Hijacking the thread to discuss TAB completion as well.
>
>     hub = AnnotationHub()
>     hub$<TAB>
>     #  looks good, let me try goldenpath
>     hub$goldenpath.<TAB>
>     hub$goldenpath.a ... [59] hub$goldenpath.b ... [110]
>     hub$goldenpath.c ... [257] hub$goldenpath.d ... [242]
>     hub$goldenpath.e ... [51] hub$goldenpath.f ... [88]
>     hub$goldenpath.g ... [85] hub$goldenpath.h ... [5005]
>     hub$goldenpath.l ... [18] hub$goldenpath.m ... [250]
>     hub$goldenpath.nomLeu ... [23] hub$goldenpath.o ... [68]
>     hub$goldenpath.p ... [175] hub$goldenpath.r ... [78]
>     hub$goldenpath.s ... [87] hub$goldenpath.t ... [55]
>     hub$goldenpath.vicPac1.database. ... [14]
>     hub$goldenpath.xenTro ... [34]
>
>     This is a bit useless, since mostly I see single letters.  I would
>     suggest
>     the following
>
>     First, the names tend to be super long.  So don't start the
>     examples with
>     the entire path, like
>       hub$goldenpath.a
>     but perhaps something like
>     "current selection: goldenpath.
>     a.. [59]
>     b.. [110]
>     etc, so that goldenpath is only listed once.  That way, the
>     suggestions are
>     shorter and it is clearer what the choices are between (at least I
>     think
>     that is the case)
>
>     Now, when I go down the list to
>     hub$goldenpath.hg19.encodeDCC.wgEncode
>
>     I get
>
>     Possible completions are:
>     hub$goldenpath.hg19.encodeDCC.wgEncodeA ... [176]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeBroadHistone.wgEncodeBroadHistone
>     ...
>     [280]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeC ... [1041]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeDukeAffyExon.wgEncodeDukeAffyExon
>     ...
>     [107]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeGencodeV4.wgEncodeGencode
>     ... [4]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeHaib ... [736]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeOpenChrom ... [193]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeRikenCage.wgEncodeRikenCage
>     ... [108]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeS ... [452]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeU ... [1394]
>
>     But for example, for wgEncodeA, it turns out that there are only
>     two real
>     choices:
>     hub$goldenpath.hg19.encodeDCC.wgEncodeAffyRnaChip.wgEncodeAffyRnaChip
>     ...
>     [52]
>     hub$goldenpath.hg19.encodeDCC.wgEncodeAwgDnaseUniform.wgEncodeAwgDnase
>     ...
>     [124]
>
>     but I can't really see this.
>
>     Anyway, I know this is hard to program, but right now it is a bit
>     hard to
>     explore using the TAB completion.  Perhaps this can all be fixed
>     by having
>     more suggestions (there is probably a limited to how many
>     suggestions to
>     show).  In this particular case, with this many choices of
>     resources, I
>     guess I would rather have (many) more suggestions than fewer.
>
>     At the end I just did
>       print(names(hub))
>     and looked at that, which is probably not what we want.
>
>     Best,
>     Kasper
>
>
>
>     On Thu, Aug 1, 2013 at 8:35 PM, Kasper Daniel Hansen <
>     kasperdanielhansen@gmail.com
>     <mailto:kasperdanielhansen@gmail.com>> wrote:
>
>     > Technically yes, since I can do
>     >
>     > function(path) {
>     >   `[[`(hub, path)
>     > }
>     >
>     > Still, I think it does make sense to have something a bit more
>     standard (I
>     > find the `[[` to be a bit unusual, but that may be colored by how I
>     > program).
>     >
>     > Retrieving multiple resources in a single call, like
>     >   paths = names(hub)[1:10]
>     > is going to be used a lot, I predict.
>     >
>     > Kasper
>     >
>     >
>     >
>     > On Thu, Aug 1, 2013 at 8:14 PM, Marc Carlson <mcarlson@fhcrc.org
>     <mailto:mcarlson@fhcrc.org>> wrote:
>     >
>     >> Hi Kasper,
>     >>
>     >> I think you could just do the following:
>     >>
>     >> ah[["goldenpath.hg19.**encodeDCC.wgEncodeUwTfbs.**
>     >> wgEncodeUwTfbsMcf7CtcfStdPkRep**1.narrowPeak_0.0.1.RData"]]
>     >>
>     >> Instead of using $ like usual:
>     >>
>     >> ah$goldenpath.hg19.encodeDCC.**wgEncodeUwTfbs.**
>     >> wgEncodeUwTfbsMcf7CtcfStdPkRep**1.narrowPeak_0.0.1.RData
>     >>
>     >>
>     >> Does that solve your problem?
>     >>
>     >>
>     >>   Marc
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> On 07/31/2013 06:14 PM, Kasper Daniel Hansen wrote:
>     >>
>     >>> I was wrong about ahinfo.  Is there an exposed interface to
>     getting the
>     >>> result of a path, assuming the path is a character vector.  I
>     see I can
>     >>> do
>     >>>    AnnotationHub:::.getResource(**hub, path)
>     >>> with hub an AnnotationHub and path a character vector.
>     >>>
>     >>> Such an interface would be extremely useful.
>     >>>
>     >>>
>     >>> On Wed, Jul 31, 2013 at 9:02 PM, Kasper Daniel Hansen <
>     >>> kasperdanielhansen@gmail.com
>     <mailto:kasperdanielhansen@gmail.com>> wrote:
>     >>>
>     >>>  About ?AnnotationHub (package version 1.1.8)
>     >>>>
>     >>>> All the functions whose values are described under "Value"
>     are not
>     >>>> described under "Usage".  All the functions listed under
>     "Usage" are not
>     >>>> described under "Value".
>     >>>>
>     >>>> The ahinfo (which seems to be a key function for doing things
>     >>>> programmatically) is not described under either "usage" or
>     "value".
>     >>>>
>     >>>> The examples are great though.
>     >>>>
>     >>>> Best,
>     >>>> Kasper
>     >>>>
>     >>>>          [[alternative HTML version deleted]]
>     >>>
>     >>> ______________________________**_________________
>     >>> Bioconductor mailing list
>     >>> Bioconductor@r-project.org <mailto:Bioconductor@r-project.org>
>     >>>
>     https://stat.ethz.ch/mailman/**listinfo/bioconductor<https://stat.ethz.ch/mailman/listinfo/bioconductor>
>     >>> Search the archives: http://news.gmane.org/gmane.**
>     >>>
>     science.biology.informatics.**conductor<http://news.gmane.org/gmane.science.biology.informatics.conductor>
>     >>>
>     >>
>     >> ______________________________**_________________
>     >> Bioconductor mailing list
>     >> Bioconductor@r-project.org <mailto:Bioconductor@r-project.org>
>     >>
>     https://stat.ethz.ch/mailman/**listinfo/bioconductor<https://stat.ethz.ch/mailman/listinfo/bioconductor>
>     >> Search the archives: http://news.gmane.org/gmane.**
>     >>
>     science.biology.informatics.**conductor<http://news.gmane.org/gmane.science.biology.informatics.conductor>
>     >>
>     >
>     >
>
>             [[alternative HTML version deleted]]
>
>     _______________________________________________
>     Bioconductor mailing list
>     Bioconductor@r-project.org <mailto:Bioconductor@r-project.org>
>     https://stat.ethz.ch/mailman/listinfo/bioconductor
>     Search the archives:
>     http://news.gmane.org/gmane.science.biology.informatics.conductor
>
>


	[[alternative HTML version deleted]]

