Re: [Bioc-devel] InteractionSet for structural variants

I would say that it depends on what operations you intend to perform on them. You can _store_ things any way you like, but the trick is to ensure that operations and manipulations on those things are consistent and meaningful. It is not obvious that there are meaningful common operations that

Re: [Rd] print.() not called when autoprinting

I don't know the answer to your question. However, here's a side issue that may be relevant. Last year, I tried creating my own ecdf object, and redefined the print method for ecdf. It worked ok in the console, interactively. However, when I tried calling the method (with autoprinting) inside an

Re: [R-pkg-devel] Check Results ERROR on Windows R release

Yes, looks like some race condition, just wait a day or two. Best, Uwe Ligges On 17.05.2019 18:52, Iñaki Ucar wrote: On Fri, 17 May 2019 at 18:05, Jarrett Phillips wrote: Hello, On submitting an update of my R package (HACSim), checks fail on r-release-windows-ix86+x86_64

Re: [R-pkg-devel] R CMD check works but with devtools::check() examples fail

On 17 May 2019 at 08:33, Rainer Krug wrote: | Interesting discussion - because I had similar issues. | | @Dirk: You are developing packages fir ages - do you probably have a template make file you could share (as I assume, you use make) which is doing all these checks? Nothing special --

Re: [Rd] ALTREP: Bug reports

Thank you very much for your answer. If I understand it correctly, for an ALTREP class, a non-deep copy only creates a new ALTREP object but refers to the same underlying SEXP as the old ALTREP object has, is it correct? But since they all share the same underlying SEXP, will change of the value

Re: [R-pkg-devel] Check Results ERROR on Windows R release

On Fri, 17 May 2019 at 18:05, Jarrett Phillips wrote: > > Hello, > > On submitting an update of my R package (HACSim), checks fail on > r-release-windows-ix86+x86_64 > > > The updated package, in addition

Re: [R-pkg-devel] Check Results ERROR on Windows R release

It looks like hacSIM imports pegas, which imports adegenet, which imports dplyr. -Winston On Fri, May 17, 2019 at 11:04 AM Jarrett Phillips wrote: > > Hello, > > On submitting an update of my R package (HACSim), checks fail on > r-release-windows-ix86+x86_64 >

[R-pkg-devel] Check Results ERROR on Windows R release

Hello, On submitting an update of my R package (HACSim), checks fail on r-release-windows-ix86+x86_64 The updated package, in addition to improving on documentation, also fixes a noLD error by replacing

[Bioc-devel] InteractionSet for structural variants

Hi all, Is there any standard recommended container for genomic structural variants? I think InteractionSet would work fine for translocation and GRanges for inversions and copy number changes, but I don't know what would be the recommended way to store them all together using standard

[Rd] Barplot & Boxplot: lim and horizontal

Dear All, I've noticed an inconsistency between boxplot & barplot regarding the interaction between switching to a horizontal graph and the limits. par(mfrow = c(2, 2)) boxplot(1:10, xlim = c(0.1, 5), ylim = c(1, 10), log = "y", horizontal=FALSE, xlab = "X", ylab = "Y") axis(1) #

Re: [Rd] nrow(rbind(character(), character())) returns 2 (as documented but very unintuitive, IMHO)

> Gabriel Becker > on Fri, 17 May 2019 01:06:11 -0700 writes: > Hi Martin, > Thanks for chiming in. Responses inline. > On Fri, May 17, 2019 at 12:32 AM Martin Maechler > wrote: >> > Gabriel Becker >> > on Thu, 16 May 2019 15:47:57 -0700

Re: [Rd] nrow(rbind(character(), character())) returns 2 (as documented but very unintuitive, IMHO)

Hi Martin, Thanks for chiming in. Responses inline. On Fri, May 17, 2019 at 12:32 AM Martin Maechler wrote: > > Gabriel Becker > > on Thu, 16 May 2019 15:47:57 -0700 writes: > > > Hi Hadley, > > Thanks for the counterpoint. Response below. > > > On Thu, May 16, 2019 at

Re: [Rd] nrow(rbind(character(), character())) returns 2 (as documented but very unintuitive, IMHO)

> Gabriel Becker > on Thu, 16 May 2019 15:47:57 -0700 writes: > Hi Hadley, > Thanks for the counterpoint. Response below. > On Thu, May 16, 2019 at 1:59 PM Hadley Wickham wrote: >> The existing behaviour seems inutitive to me. I would consider these >>

[Rd] Give update.formula() an option not to simplify or reorder the result -- request for comments

Dear All, Martin Maechler has asked me to send this to R-devel for discussion after I submitted it as an enhancement request ( https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17563). At this time, the update.formula() method always performs a number of transformations on the results,