[Bioc-devel] IGV - a new package in preparation

Cook, Malcolm MEC at stowers.org
Fri Mar 9 21:33:58 CET 2018


Hello,

Jumping in the conversation perhaps late.

If it helps the effort, below are some IGV related R functions I've used in the past to good effect communicating with IGV running on local/remote host and issuing GOTO and Save Snapshot commands.

They use utils::write.socket

One things that helped my experience greatly was ensuring socket always gets closed.

################################################################################
### IGV Interaction
################################################################################

library(functional)

OKCmd.socket<-function(socket,cmds,OK="^OK\\s*"){
  ## PURPOSE: write each cmd in <cmds>, a character vector, to the
  ## <socket> (appending newlines), warning for those that don't
  ## return <OK> (such as IGV responds)
  lapply(cmds,function(cmd) {
    write.socket(socket,paste(cmd,"\n"))
    result=read.socket(socket)
    if(1 != regexpr(OK,result))
      warning(OK,' was expected in OKCmd.socket while executing [',cmd,'] but received [',result,']')
    result
  })
}

IGV.make.socket<-
  ## PURPOSE: a version of make.socket which abides to IGV's default
  ## port convention.
  Curry(make.socket,port=60151)

IGV.tell<-function(cmds,...) {
  ## PURPOSE: send all the <cmds> to IGV on port determined by <...>,
  ## warning if unexpected IGV response, and being careful to cleanup
  ## by closing the socket.
  message(cmds)
  with(list(s=IGV.make.socket(...)),{
    on.exit(close.socket(s))
    OKCmd.socket(s,cmds)
  })}

attr(IGV.tell,'ex')<-function(){
  IGV.tell('goto B52','myComputer.myInstitute.org')
  IGV.tell('goto chr4:1234:12345')
  }

sanitize.path<-function(path) {
   ## YMMV
    path<-gsub('%','',path,perl=TRUE)
    path<-gsub('\\|',' by ',path,perl=TRUE) # good choice?
    path<-gsub('[\\,]','',path,perl=TRUE)
    path<-gsub('\\/','\\;',path,perl=TRUE)
    path<-gsub('\\n',' ',path,perl=TRUE)
    path
}

IGVSaveSnapshots<-structure(
    function (region
              ,dir='./'
              ,filename=gsub(':','@',sanitize.path(region))
              ,type='png'
              ,filepath=sprintf('%s.%s',filename,type)
              ,...) {
        ## PURPOSE: create snapshots of <region> in <dir> in IGV socket
        ## behind host/port in ....  NB: the dir must be relative to the
        ## host on which IGV is running, which may not exist on localhost.
        IGV.cmds.gosnap<-function(x,filepath)
            c(sprintf("goto %s",x)
              ,sprintf("snapshot %s" ,filepath)
              )
        IGV.tell(c(
            sprintf("snapshotDirectory %s",dir)
            ,mapply(IGV.cmds.gosnap,region,filepath)
            )
           ,...)
      sprintf("%s/%s",dir,filepath)
    },ex=function(){
        ## 1) Take two snapshots using IGV running on remote host
        IGVSaveSnapshots(dir='/Volumes/Users/lab_project/SR_Prot_projects/iClip/myGenes/'
                         ,c('ns1'        # can be a gene name...
                            ,'X:123-1234' # ...or locus
                            )
                         ,'M0050U1ZE6')
        IGVSaveSnapshots(dir='\\\\ion\\projects\\mec\\ShilatifardLab\\analysis\\fec\\triptolide\\fig'
                         ,region=c(
                              ## can be...:
                              'chrX:123-1234' # ...a locus
                                        #,'ASNS'         # .. a gene name...
                              )
                         ,type='svg'
                         ,'LA10MJDPKM5.sgc.loc')
    })

~malcolm_cook at stowers.org

 > -----Original Message-----
 > From: Bioc-devel <bioc-devel-bounces at r-project.org> On Behalf Of Paul
 > Shannon
 > Sent: Friday, March 09, 2018 1:58 PM
 > To: Michael Lawrence <lawrence.michael at gene.com>
 > Cc: Gabe Becker <becker.gabe at gene.com>; bioc-devel at r-project.org; Paul
 > Shannon <pshannon at systemsbiology.org>
 > Subject: Re: [Bioc-devel] IGV - a new package in preparation
 > 
 > Thanks, Michael.
 > 
 > httpuv, to which Hector made crucial contributions, makes it easy to send
 > data directly between R and the browser, using websockets.   I resort to
 > files, however, because when the data, rendered as json, exceeds 500k, the
 > websocket hangs.  I never identified the weak spot.   Some Juypter
 > developers recently had good luck with binary websocket data exchange.  I
 > am cautious, though, about pushing limits and using the latest websocket
 > extension, and found the fallback to local files quite adequate for now.
 > 
 > I’ll look at ucsc.R.
 > 
 > - Paul
 > 
 > 
 > > On Mar 9, 2018, at 11:48 AM, Michael Lawrence
 > <lawrence.michael at gene.com> wrote:
 > >
 > > Couple of things:
 > >
 > > 1) Check out epivizr and the surrounding infrastructure (maybe Hector can
 > chime in). It's able to serve up data directly from R; would be nice if we
 > could do that with IGV, instead of writing out to files. That would require it
 > to talk to some standard API, like the old DAS.
 > >
 > > 2) The rtracklayer API is in rtracklayer/R/browser.R. See ucsc.R for how
 > that is implemented for UCSC.
 > >
 > > On Fri, Mar 9, 2018 at 9:59 AM, Paul Shannon
 > <pshannon at systemsbiology.org> wrote:
 > > Thanks, Levi. Your comments, and Gabe’s are very helpful, getting me to
 > consider things I have overlooked.
 > >
 > > Support for GenomicRanges is essential, as you and Gabe point out.
 > >
 > > In all cases IGV will convert a GRanges object to an appropriate track, then
 > write it out as a temporary file.  igv supports bed, gff, gff3, gtf, wig, bigWig,
 > bedGraph, bam, vcf, and seg formats, and a variety of sources:  files via
 > http, google cloud storage, GA4GH; recent limited support has been
 > provided for direct javascript data.   Maybe someday AnnotationHub?
 > >
 > > GenomicRanges as I understand them are very flexible, not subclassed
 > into types as are track formats.  So I propose that in many cases it will be he
 > user’s responsibility to specify track type, call the appropriate constructor,
 > maybe specify column names so that the right scores can be extracted from
 > the mcols - whose names are, so far as I know, are not standardized.
 > >
 > > If the GRanges object is too big - greater than a densely packed
 > megabase, for instance, igv works best if the track file is indexed and served
 > up by an index- and CORS-savvy webserver.   Thus the IGV should politely
 > fail - or at least issue a warning -  when encounters big tracks.  This “too big”
 > threshold may change over time.
 > >
 > > Reading through Michael’s rtracklayer vignette I came across this:
 > >
 > >    The rtracklayer package currently interfaces with the UCSC web-based
 > genome browser.
 > >    Other packages may provide drivers for other genome browsers through
 > a plugin system.
 > >
 > > Can anyone (maybe Michael himself?) comment on how I can evaluate an
 > rtracklayer plugin strategy for igv?
 > >
 > >  - Paul
 > >
 > >
 > > > On Mar 9, 2018, at 4:15 AM, Levi Waldron
 > <lwaldron.research at gmail.com> wrote:
 > > >
 > > > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon
 > <pshannon at systemsbiology.org> wrote:
 > > > Thanks, Gabe.
 > > >
 > > > You make an excellent point: bioc objects get first class support.  In
 > some instance, base R data types deserve that also, and data.frames lead
 > the list for me, being useful, concise, universally available, expressive.
 > > >
 > > > So perhaps not “data.frames replaced by” but “accompanied by”
 > appropriate bioc data types?
 > > >
 > > >  - Paul
 > > >
 > > > Definitely +1 for supporting GenomicRanges, including what's in
 > genome() and mcols(). There's a demo of an rtracklayer -> GRanges -> UCSC
 > genome browser workflow in the rtracklayer vignette that I've made use of.
 > I wouldn't necessarily say *don't* support data.frame, but I would certainly
 > encourage Bioc users to import data with rtracklayer instead of generic
 > read* functions, and to take advantage of the vast AnnotationHub and
 > OrganismDbi-based annotations which provide GenomicRanges objects.
 > > >
 > > > Thanks and looking forward to it!
 > > >
 > >
 > > _______________________________________________
 > > Bioc-devel at r-project.org mailing list
 > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
 > >
 > >
 > 
 > _______________________________________________
 > Bioc-devel at r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/bioc-devel


More information about the Bioc-devel mailing list