mskilab-org / gtrack Goto Github PK

these are not being exposed in the tests, so code is falsely passing travisCI

after installing gTrack, draw.backbones is not appearing as a possible argument for gTrack.

There are cases where seqlengths(gr.reduce(gr)) == seqlengths(gr) returns FALSE for all seqlevels.

This page will store name changes to gTrack parameters. Changes made might help users remember parameters. I propose that every word be separated by a period.

Old Name | New Name

name | title

where should we put this?

I like keeping it gTrack - I think it shows off gTrack very nicely, however it relies on read.bam, so we have a little dependency crisis

otherwise we should at least put into skitools

For example, when plotting a gGraph, this doesn't do anything:

gg$set(cex.label = 2)

And hence we need to do this currently:

plot(gg$gtrack(cex.label = 2))

Propose removing this. Not sure what the issue is with having "chr" in the seqinfo, and it seems like if there is a problem, a more general solution should be used (e.g. manipulate seqinfo however you like on your own, and then set with seqinfo<- )

gTrack has typically plotted ranges with a different definition of widths than GRanges. e.g. a range of [4,5] is width 1 in gTrack and width 2 in GRanges. This can cause strange behavior and odd looking plots when looking at small genomes where single base-pairs make a difference.

I have changed the code so that gTrack now defines width the same as GRanges. This means that the x-axis had to be shifted by 0.5 as below, and GRanges-width 1 ranges now plot to "cover" that base:

mdat <- matrix(sample(10, 4, replace=TRUE), ncol=2, nrow=2)
mdat[upper.tri(mdat)] <- mdat[lower.tri(mdat)]
gr <- GRanges(c(1,1), IRanges(c(5,6), width=1), strand=c("+","-"))

gr <- GRanges(1, IRanges(c(5), width=1), strand=c("+"))

Doing some debugging on this fix, will check in soon.

Thank you, that worked to install JaBbA with Gurobi! However, I am now trying to run it on the simple example provided and I'm running into some problems.

1. The first time I run it with jba ${JABBA_PATH}/junctions.vcf ${JABBA_PATH}/coverage.txt --gurobi TRUE, it doesn't find the segmentation, so it runs segmentation, it saves the seg.rds file, but then it gives an error:

" .....
JaBbA 2023-10-16 16:29:56.631185: No segmentation provided, so performing segmentation using CBS
JaBbA 2023-10-16 16:29:56.694123: Segmentation finished
.....
JaBbA 2023-10-16 16:29:58.848608: Built gGraph with 82 nodes, 104 edges, purity 0.6, and ploidy 1.93
Error in !is.null(formatting(object)$y.field) && !is.na(formatting(object)$y.field) :
'length = 2' in coercion to 'logical(1)'
Calls: suppressPackageStartupMessages ... validObject -> anyStrings -> isTRUE -> validityMethod
"

2. Then, if I run it the second time, since it has the segmentation file it uses it, it seems to work fine, it creates the jaba.simple.gg.rds file, but then it gives some plotting errors:

" ...
Generating figures
JaBbA 2023-10-16 16:46:15.355457: Something wrong with plotting JaBbA results. Please try it later.
JaBbA 2023-10-16 16:46:15.382705: Something wrong with plotting JaBbA simplified results. Please try it later.
..."

Thank you for your help!

Originally posted by @mandronescu in mskilab-org/JaBbA#94 (comment)

Looks like there is some code to check for y.field being length > 1 in "initialize". Should we maintain this? Looks like it just re-creates length(y.field) .Objects

This doesn't work: https://raw.githubusercontent.com/mskilab/gTrack/master/gTrack.pdf

Fix/add details soon

Marcin, can you activate this webhook so that the docs rebuild automatically? Need admin access to the repos to do this.

Instructions:
http://read-the-docs.readthedocs.org/en/latest/webhooks.html

That karyogram method takes a bands parameter: karyogram = function(file = NULL, hg19 = TRUE, bands = TRUE, arms = TRUE, tel.width = 2e6, ... ). Setting this flag to FALSE triggers the following error:

>  karyogram_gt_no_bands = karyogram(hg19 = TRUE, bands = FALSE)
Error in .normarg_seqnames2(seqnames, seqinfo) :
'seqnames' contains sequence names with no entries in 'seqinfo'

When arms are also set to FALSE, this triggers a different error:

>   karyogram_gt_no_arms = karyogram(hg19 = TRUE, bands = FALSE, arms = FALSE)
Error in attributes(.Data) <- c(attributes(.Data), attrib) : 
  'names' attribute [24] must be the same length as the vector [0]

I keep getting this error when trying to install gTrack in R 3.6.1. Any idea why?
I was able to install and load gUtils just fine.

devtools::install_github('mskilab/gTrack')
Downloading GitHub repo mskilab/gTrack@master
Error: Failed to install 'gTrack' from GitHub:
Could not find tools necessary to compile a package
Call pkgbuild::check_build_tools(debug = TRUE) to diagnose the problem.

Anyone know the right way to do this? It looks like the method is being exported in the NAMESPACE file, and it shows up as accepting a gTrack with a showMethods('plot') call, but its not detecting gTrack when I build gTrack as a package rather than source (If I source gTrack.R directly, plot(g) works). If I attach as package, it errors with this when trying to call base::plot:

Error in as.double(y) :
cannot coerce type 'S4' to vector of type 'double'

Any thoughts?

I noticed that there is code to loop through "windows" in plot, where each windows is a GRangesList. What is the reason why there would be a GRangesList of windows, as opposed to an st-reduced GRanges specifying the coordinates to plot on? Can we just make these GRanges with no window loop?

varbase func. is fully commented in gTrack. Should I remove it and include it in bamUtils b/c it deals with cigar data.

There are a lot of heavy data files that are used in the examples, that could be moved from the repos to a space online. I updated gTrack.R to now pull the gencode.composite.rds from the web rather than locally.

If we're OK with this, let me know and I'll clean the repos of these files (including from past commits, otherwise git rm doesn't really do much). The catch is that after cleaning, you'll need to delete and reclone the repos, or else the old heavy files will get back in.