Re: [Rd] [RFC] A case for freezing CRAN

To me it boils down to one simple question: is an update to a package on CRAN more likely to (1) fix a bug, (2) introduce a bug or downward incompatibility, or (3) add a new feature or fix a compatibility problem without introducing a bug? I think the probability of (1) | (3) is much greater t

Re: [Rd] [RFC] A case for freezing CRAN

On Tue, Mar 18, 2014 at 3:24 PM, Jeroen Ooms wrote: > ## Summary > > Extending the r-release cycle to CRAN seems like a solution that would > be easy to implement. Package updates simply only get pushed to the > r-devel branches of cran, rather than r-release and r-release-old. > This separates d

Re: [Rd] [RFC] A case for freezing CRAN

I don't see why CRAN needs to be involved in this effort at all. A third party could take snapshots of CRAN at R release dates, and make those available to package users in a separate repository. It is not hard to set a different repository than CRAN as the default location from which to obta

Re: [Rd] [RFC] A case for freezing CRAN

Our experience in Bioconductor is that this is a pretty hard problem. What the OP presumably wants is some guarantee that all packages on CRAN work well together. A good example is when Rcpp was updated, it broke other packages (quick note: The Rcpp developers do a incredible amount of work to de

Re: [Rd] [RFC] A case for freezing CRAN

Piling on: On 19 March 2014 at 07:52, Joshua Ulrich wrote: | There is nothing preventing you (or anyone else) from creating | repositories that do what you suggest. Create a CRAN mirror (or more | than one) that only include the package versions you think they | should. Then have your productio

Re: [Rd] [RFC] A case for freezing CRAN

> What would be more useful in terms of reproducibility is the capability of > installing a specific version of a package from a repository using > install.packages(), which would require archiving older versions in a > coordinated fashion. I know CRAN archives old versions, but I am not aware > if

Re: [Rd] [RFC] A case for freezing CRAN

using the identical version of each CRAN package. The bioconductor project uses similar policies. While I agree that this can be an issue, I don't think it is fair to compare CRAN to BioC. Unless things have changed, the latter has a more rigorous barrier to entry which includes buy in of vari

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 5:52 AM, Duncan Murdoch wrote: > I don't see why CRAN needs to be involved in this effort at all. A third > party could take snapshots of CRAN at R release dates, and make those > available to package users in a separate repository. It is not hard to set > a different rep

Re: [Rd] [RFC] A case for freezing CRAN

What about having this purpose met with something like an expansion of R-Forge? We could have packages submitted to R-Forge rather than CRAN, and people who wanted the latest could get it from R-Forge. If changes I make on R-Forge break a reverse dependency, emails explaining the proble

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 12:59 PM, Jeroen Ooms wrote: > On Wed, Mar 19, 2014 at 5:52 AM, Duncan Murdoch > wrote: > >> I don't see why CRAN needs to be involved in this effort at all. A third >> party could take snapshots of CRAN at R release dates, and make those >> available to package users in

Re: [Rd] [RFC] A case for freezing CRAN

Dear list, I'm curious what people would think of a more modest proposal at this time: State the version of the dependencies used by the package authors when the package was built. Eventually CRAN could enforce such a statement be present in the description. We encourage users to declare the ver

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 7:00 AM, Kasper Daniel Hansen wrote: > Our experience in Bioconductor is that this is a pretty hard problem. > > What the OP presumably wants is some guarantee that all packages on CRAN work > well together. Obviously we can not guarantee that all packages on CRAN work to

Re: [Rd] [RFC] A case for freezing CRAN

Hi, On 03/19/2014 07:00 AM, Kasper Daniel Hansen wrote: Our experience in Bioconductor is that this is a pretty hard problem. What's hard and requires a substantial amount of human resources is to run our build system (set up the build machines, keep up with changes in R, babysit the builds, a

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich wrote: > > The suggested solution is not described in the referenced article. It > was not suggested that it be the operating system's responsibility to > distribute snapshots, nor was it suggested to create binary > repositories for specific operat

[Rd] Memcheck: Invalid read of size 4

Hi the list, One of my package has a memory issue that I do not manage to understand. The Memtest notes is here: Here is the message that I get from Memtest --- 8< ~ Fast KmL ~ ==27283== Invalid read of size 4

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms wrote: > On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich > wrote: >> >> The suggested solution is not described in the referenced article. It >> was not suggested that it be the operating system's responsibility to >> distribute snapshots, nor was it

Re: [Rd] [RFC] A case for freezing CRAN

- Original Message - > From: "Joshua Ulrich" > To: "Jeroen Ooms" > Cc: "r-devel" > Sent: Wednesday, March 19, 2014 2:59:53 PM > Subject: Re: [Rd] [RFC] A case for freezing CRAN > > On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms > wrote: > > On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulri

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 2:59 PM, Joshua Ulrich wrote: > > So implementation isn't a problem. The problem is that you need a way > to force people not to be able to use different package versions than > what existed at the time of each R release. I said this in my > previous email, but you remove

Re: [Rd] Memcheck: Invalid read of size 4

On 19 Mar 2014, at 22:58 , Christophe Genolini wrote: > Hi the list, > > One of my package has a memory issue that I do not manage to understand. The > Memtest notes is here: > > > Here is the message that I get from Memtest >

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 5:16 PM, Jeroen Ooms wrote: > On Wed, Mar 19, 2014 at 2:59 PM, Joshua Ulrich > wrote: >> >> So implementation isn't a problem. The problem is that you need a way >> to force people not to be able to use different package versions than >> what existed at the time of each

Re: [Rd] [RFC] A case for freezing CRAN

On 03/19/2014 02:59 PM, Joshua Ulrich wrote: On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms wrote: On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich wrote: The suggested solution is not described in the referenced article. It was not suggested that it be the operating system's responsibility

Re: [Rd] [RFC] A case for freezing CRAN

Weighting in. FWIW, I find the proposal conceptually quite interesting. For package developers, it does not have to be a frustration to have to wait a new version of R to release their code. Anticipated frustration was my initial reaction. Thinking about this more, I think this could be changed

[Rd] possible bug: graphics::image seems to ignore getOption("preferRaster")

the details section of ?image says: If useRaster is not specified, raster images are used when the getOption("preferRaster") is true, the grid is regular and either dev.capabilities("raster") is "yes" or it is "non-missing" and there are no missing values. but in my experience this is never

Re: [Rd] [RFC] A case for freezing CRAN

"What am I overlooking?" That this is already available and possible in R today, but perhaps not widely used. Developers do tend to only include a lower bound if they include any bounds at all on package dependencies. As I mentioned elsewhere, R packages often aren't "built" against other R packa

Re: [Rd] [RFC] A case for freezing CRAN

Given that R is (has) moved to a 12 month release cycle, I don't want to either i) wait a year to get new packages (or allow users to use new versions of my packages), or ii) have to run R-devel just to use new packages. (or be on R-testing for that matter). People then will start finding ways aro

Re: [Rd] [RFC] A case for freezing CRAN

On Mar 19, 2014, at 18:42, Joshua Ulrich wrote: > On Wed, Mar 19, 2014 at 5:16 PM, Jeroen Ooms > wrote: >> On Wed, Mar 19, 2014 at 2:59 PM, Joshua Ulrich >> wrote: >>> >>> So implementation isn't a problem. The problem is that you need a way >>> to force people not to be able to use diffe

Re: [Rd] [RFC] A case for freezing CRAN

Michael, I think the issue is that Jeroen wants to take that responsibility out of the hands of the person trying to reproduce a work. If it used R 3.0.x and packages A, B and C then it would be trivial to to install that version of R and then pull down the stable versions of A B and C for that ve

[Rd] modifying data in a package

I've tweaked Rmpi and want to have some variables that hold data in the package. One of the R files starts mpi.isend.obj <- vector("list", 500) #mpi.request.maxsize()) mpi.isend.inuse <- rep(FALSE, 500) #mpi.request.maxsize

Re: [Rd] [RFC] A case for freezing CRAN

On Mar 19, 2014, at 22:17, Gavin Simpson wrote: > Michael, > > I think the issue is that Jeroen wants to take that responsibility out > of the hands of the person trying to reproduce a work. If it used R > 3.0.x and packages A, B and C then it would be trivial to to install > that version of R

Re: [Rd] [RFC] A case for freezing CRAN

On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt wrote: > Reading this thread again, is it a fair summary of your position to say > "reproducibility by default is more important than giving users access to the > newest bug fixes and features by default?" It's certainly arguable, but I'm > not

Re: [Rd] [RFC] A case for freezing CRAN

On Mar 19, 2014, at 22:45, Jeroen Ooms wrote: > On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt > wrote: >> Reading this thread again, is it a fair summary of your position to say >> "reproducibility by default is more important than giving users access to >> the newest bug fixes and feature

Re: [Rd] [RFC] A case for freezing CRAN

I think what you really want here is the ability to easily identify and sync to CRAN snapshots. The easy way to do this is setup a CRAN mirror, but back it up with version control, so that it's easy to reproduce the exact state of CRAN at any given point in time. CRAN's not particularly large and

Re: [Rd] [RFC] A case for freezing CRAN

On Mar 19, 2014, at 7:45 PM, Jeroen Ooms wrote: > On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt > wrote: >> Reading this thread again, is it a fair summary of your position to say >> "reproducibility by default is more important than giving users access to >> the newest bug fixes and featu

Re: [Rd] [RFC] A case for freezing CRAN

- Original Message - > From: "David Winsemius" > To: "Jeroen Ooms" > Cc: "r-devel" > Sent: Wednesday, March 19, 2014 11:03:32 PM > Subject: Re: [Rd] [RFC] A case for freezing CRAN > > > On Mar 19, 2014, at 7:45 PM, Jeroen Ooms wrote: > > > On Wed, Mar 19, 2014 at 6:55 PM, Michael We

Re: [Rd] modifying data in a package [a solution]

On Wed, 2014-03-19 at 19:22 -0700, Ross Boylan wrote: > I've tweaked Rmpi and want to have some variables that hold data in the > package. One of the R files starts > mpi.isend.obj <- vector("list", 500) #mpi.request.maxsize()) >