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_c...@stowers.org > -----Original Message----- > From: Bioc-devel <bioc-devel-boun...@r-project.org> On Behalf Of Paul > Shannon > Sent: Friday, March 09, 2018 1:58 PM > To: Michael Lawrence <lawrence.mich...@gene.com> > Cc: Gabe Becker <becker.g...@gene.com>; bioc-devel@r-project.org; Paul > Shannon <pshan...@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.mich...@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 > <pshan...@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.resea...@gmail.com> wrote: > > > > > > On Thu, Mar 8, 2018 at 12:29 AM, Paul Shannon > <pshan...@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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel