You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
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
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?
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)
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.
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
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)
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.
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>
.
Activity
KhagayN commentedon Mar 31, 2016
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 commentedon Mar 31, 2016
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:
KhagayN commentedon Mar 31, 2016
ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?
imielinski commentedon Mar 31, 2016
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 commentedon Mar 31, 2016
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.
mskilab commentedon Mar 31, 2016
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:
walaj commentedon Mar 31, 2016
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 commentedon Mar 31, 2016
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:
KhagayN commentedon Dec 5, 2016
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 commentedon Dec 6, 2016