Re: [Bioc-devel] Merging git mirror and previous git repo ?

This situation is complicated due to deficiencies in git-svn. The safest (and most limiting) thing to do is to git clone https://github.com/sneumann/mtbls2/ update_remotes.sh git checkout devel Then restrict all further development to the `devel` branch, sync it with SVN via `git svn

Re: [Bioc-devel] Merging git mirror and previous git repo ?

Hi Robert, On Sa, 2015-09-19 at 01:14 +, Robert M. Flight wrote: > I think the simplest course is to leave your remote as is, and not use > the Bioconductor mirror as a true remote. Great, I like this approach. > Instead, keep using the git-svn bridge to push to Bioconductor. And > put

[Bioc-devel] (crazy) copy-on-modification bug in GenomicFeatures

An anonymous student found this. PREP library(GenomicFeatures) library(TxDb.Hsapiens.UCSC.hg19.knownGene) EXAMPLE txdb <- TxDb.Hsapiens.UCSC.hg19.knownGene seqlevels(txdb, force=TRUE) <- c("chr22") gr <- GRanges(seqnames = "chr22", ranges = IRanges(start = 1, end = 52330658)) gr.trans.chr22 <-

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

On Mon, Sep 21, 2015 at 2:48 PM, Duncan Murdoch wrote: > On 21/09/2015 4:50 PM, Hervé Pagès wrote: >> Hi, >> >> Note that one significant change to read.dcf() that happened since R >> 3.0.2 is the addition of support for arbitrary long lines (commit >> 63281), which

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

On 09/21/2015 02:48 PM, Duncan Murdoch wrote: On 21/09/2015 4:50 PM, Hervé Pagès wrote: Hi,at Note that one significant change to read.dcf() that happened since R 3.0.2 is the addition of support for arbitrary long lines (commit 63281), which never worked: dcf <- paste(c("aa: ",

Re: [Bioc-devel] Proper way of documenting a BiocGenerics generics with extended prototypes

On 09/21/2015 10:39 AM, Hervé Pagès wrote: On 09/21/2015 02:06 AM, Christian Arnold wrote: Hi Jim, Kasper, and Hervé, thanks a lot for the quick answer. For some reason, I was under the impression that I have to use exactly the original prototype from the generics, but I didn't fully realize

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

Here's an update: I checked the ChangeLog for R, and it seems like readDCF was changed in 3.0.2. I went on a whim and copied src/main/dcf.c from R 2.15.3 over to 3.2.2, and R compiled fine and install.packages now work for me. This is probably not ideal, but it at least makes R usable on AIX

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

On 21/09/2015 1:49 PM, Vinh Nguyen wrote: > Here's an update: > > I checked the ChangeLog for R, and it seems like readDCF was changed > in 3.0.2. I went on a whim and copied src/main/dcf.c from R 2.15.3 > over to 3.2.2, and R compiled fine and install.packages now work for > me. > > This is

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

Hi there, I just wanted to follow up on this readDCF issue with install.packages on AIX on R 3.*. I'm happy to help try potential solutions or debug if anyone could point me in the right direction. To re-cap, it appears readDCF is segfault'ing since R 3.* on AIX. This was not the case up until

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

Hi, Note that one significant change to read.dcf() that happened since R 3.0.2 is the addition of support for arbitrary long lines (commit 63281), which never worked: dcf <- paste(c("aa: ", rep(letters, length.out=1)), collapse="") writeLines(dcf, "test.dcf")

Re: [Rd] Long vectors: Missing values and R_xlen_t?

On Mon, Sep 21, 2015 at 11:20 AM, Simon Urbanek wrote: > > On Sep 20, 2015, at 3:06 PM, Henrik Bengtsson > wrote: > >> Is there a missing value constant defined for R_xlen_t, cf. NA_INTEGER >> (== R_NaInt == INT_MIN) for int(eger)? If

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

On 09/21/2015 01:50 PM, Hervé Pagès wrote: Hi, Note that one significant change to read.dcf() that happened since R 3.0.2 is the addition of support for arbitrary long lines (commit 63281), which never worked: dcf <- paste(c("aa: ", rep(letters, length.out=1)), collapse="")

Re: [Rd] segfault with readDCF on R 3.1.2 on AIX 6.1 when using install.packages

On 21/09/2015 4:50 PM, Hervé Pagès wrote: > Hi, > > Note that one significant change to read.dcf() that happened since R > 3.0.2 is the addition of support for arbitrary long lines (commit > 63281), which never worked: > >dcf <- paste(c("aa: ", rep(letters, length.out=1)), collapse="") >

[Rd] Long vectors: Missing values and R_xlen_t?

Is there a missing value constant defined for R_xlen_t, cf. NA_INTEGER (== R_NaInt == INT_MIN) for int(eger)? If not, is it correct to assume that missing values should be taken care/tested for before coercing from int or double? Thank you, Henrik __

Re: [Bioc-devel] Proper way of documenting a BiocGenerics generics with extended prototypes

Hi Christian, This has not much to do with roxygen. 'R CMD check' complains that your "counts" method doesn't have the arguments that your man page says it has. Your method is defined with arguments (object, ...) but the \usage section in the man page says it has arguments (object, type,

Re: [R-pkg-devel] Help with Package creation

Hi Mohammad, You don’t really say but I’m guessing your error is when checking the package? I think you should take the message at face value. It appears the randomForest package is not available from the libraries R knows about at the time of whatever it is your doing. R CMD check will not go

Re: [Bioc-devel] Proper way of documenting a BiocGenerics generics with extended prototypes

It sounds like everything is working, apart from roxygen 2. This is the right way to do this; there are many examples; for example findOverlaps for GenomicRanges, GenomicRanges which support ignore.strand which is not an argument to the generic; see below. You may have to discuss this with the

Re: [Bioc-devel] Proper way of documenting a BiocGenerics generics with extended prototypes

Hi Jim, Kasper, and Hervé, thanks a lot for the quick answer. For some reason, I was under the impression that I have to use exactly the original prototype from the generics, but I didn't fully realize I can extend this arbitrarily as long as the original arguments - object and ... in this