[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