track.splice

[mskilab]

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

[KhagayN]

would it be a good idea to include it in gTrack? and since it relies on read.bam, wouldn't bamUtils be a good place for it?

[mskilab]

well it relies on both, so if we include in one package then we have to add
a dependency to the other

actually gTrack supports bams and ucsc formats, so it will need to depend
on bamUtils.

so let's keep in gTrack

On Wed, Mar 30, 2016 at 8:13 PM, Khagay Nagdimov notifications@github.com
wrote:

would it be a good idea to include it in gTrack? and since it relies on
read.bam, wouldn't bamUtils wouldn't be a good place for it?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#7 (comment)

[KhagayN]

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

[imielinski]

Let’s wait to see what Jeremiah thinks

On March 30, 2016 at 8:30:26 PM, Khagay Nagdimov (notifications@github.commailto:notifications@github.com) wrote:

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-203695704

This electronic message is intended for the use of the named recipient only, and may contain information that is confidential, privileged or protected from disclosure under applicable law. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or use of the contents of this message including any of its attachments is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and destroy all copies of this message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.

[walaj]

What if we did it the other way around. gTrack is most exciting / closest to release, and I don't want to have to release bamUtils ahead of it just for one function. We can switch it into a later release of gTrack later (and thus the bamUtils dependency), since adding functions is not a problem for backwards compatibility.

On Mar 31, 2016, at 4:54 AM, Marcin Imielinski notifications@github.com wrote:

Let’s wait to see what Jeremiah thinks

On March 30, 2016 at 8:30:26 PM, Khagay Nagdimov (notifications@github.commailto:notifications@github.com) wrote:

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-203695704

This electronic message is intended for the use of the named recipient only, and may contain information that is confidential, privileged or protected from disclosure under applicable law. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or use of the contents of this message including any of its attachments is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and destroy all copies of this message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[mskilab]

Ok sounds fine in principle regarding waiting for later releases
that depend on bamUtils

Kind of a letdown though if we can't show an example with plotting reads.
This was one big use case e.g. plotting discordant pair clusters around
rearrangements. Is there a way to implement that without read.bam or
Rsamtools? Can our examples use external packages that our package does not
depend on?

Eventually I'd like to work in direct bam compatibility - i.e. let bam path
be a file input. Right now we have a user make their own granges and then
wrap a gTrack around that object

On Thursday, March 31, 2016, Jeremiah Wala notifications@github.com wrote:

What if we did it the other way around. gTrack is most exciting / closest
to release, and I don't want to have to release bamUtils ahead of it just
for one function. We can switch it into a later release of gTrack later
(and thus the bamUtils dependency), since adding functions is not a problem
for backwards compatibility.

On Mar 31, 2016, at 4:54 AM, Marcin Imielinski <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Let’s wait to see what Jeremiah thinks

On March 30, 2016 at 8:30:26 PM, Khagay Nagdimov (
notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');<mailto:
notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>) wrote:

ah okay and then I'll add read.bam to bamUtils and add the dependency of
bamUtils in gTrack?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub<
https://github.com/mskilab/gTrack/issues/7#issuecomment-203695704>

This electronic message is intended for the use of the named recipient
only, and may contain information that is confidential, privileged or
protected from disclosure under applicable law. If you are not the intended
recipient, or an employee or agent responsible for delivering this message
to the intended recipient, you are hereby notified that any reading,
disclosure, dissemination, distribution, copying or use of the contents of
this message including any of its attachments is strictly prohibited. If
you have received this message in error or are not the named recipient,
please notify us immediately by contacting the sender at the electronic
mail address noted above, and destroy all copies of this message. Please
note, the recipient should check this email and any attachments for the
presence of viruses. The organization accepts no liability for any damage
caused by any virus transmitted by this email.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#7 (comment)

[walaj]

Yeah, I see what you mean regarding the examples. Even if it's in "suggests", it won't make it onto CRAN without having all the dependent and suggested packages on their as well... May be that we just try and release bamUtils before gUtils, even we have the bandwidth to get this ready.

[mskilab]

ok sounds good ..

One interim option would be to use Rsamtools in the examples, i.e. using
their native bam access with whatever is the bulky syntaxx

This would be uglier but would avoid having to get bamUtils ready. It
would add an Rsamtools dependency to gTrack, but that dependency would be
in our plan anyway (whether directly or indirectly)

Another option is add read.bam back to gUtils - which would add an
Rsamtools dependency to gUtils. I could see reasons for not wanting to do
that .. but maybe not the worst thing

On Thu, Mar 31, 2016 at 12:47 PM, Jeremiah Wala notifications@github.com
wrote:

Yeah, I see what you mean regarding the examples. Even if it's in
"suggests", it won't make it onto CRAN without having all the dependent and
suggested packages on their as well... May be that we just try and release
bamUtils before gUtils, even we have the bandwidth to get this ready.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#7 (comment)

[KhagayN]

just to summarize - should we keep read.bam in BamUtils and release that package. Then, include BamUtils as a dependency in gTrack before gTrack release.

[mskilab]

yes I think so

…

On Mon, Dec 5, 2016 at 3:00 PM, Khagay Nagdimov ***@***.***> wrote: just to summarize - keep read.bam in BamUtils and release that package. Then, include BamUtils as a dependency in gTrack before gTrack release. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL-0kSPmfwdV-dr40aAUD2NZm9Bv2xRAks5rFG1dgaJpZM4H8Rrp> .