similar to: Feature freeze for R-1.5.0

The core team has decided to release R 1.5.0 on April 29th. Somewhat earlier than maybe expected, but we realized that we needed a phase-shift away from our usual cycle with main releases in June and December since it was placing feature freezes just when several members were in a creative phase due to end of teaching. The roadmap is as follows April 8 feature freeze on r-base April 15 code

As of 19:00 GMT we'll declare a feature freeze on the set of recommended packages. We will then have one week to ferret out as many problems as we can before final code freeze and platform testing. At the same time R-base is code-frozen, i.e. only critical bugs will be fixed. If you want to help making R 1.5.0 as bug-free as possible, it could be a good idea to install the set of

The planned release of R 1.1.0 will be next Thursday. The development version is going into feature freeze tomorrow, meaning that we'll only do testing and fix simple bugs during the next week. Those of you who prefer to find bugs before releases instead of afterwards may want to try it out and tell us what crawls out. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_

The release countdown for R 1.8.0 has now entered the beta phase. Apart from a change of name of the daily snapshots, this means that there we are now in feature freeze, i.e. we will not add features or change the API from now on. We will try to fix bugs and documentation errors though. The same thing is assumed for the group of recommended packages that we ship with the release. Code freeze is

There's a directory on CRAN containing the current snapshots of the set of recommended packages. They will not be finaly feature-frozen until Monday, but you might want to check them out anyway. If you have wget, the easiest way to get the complete set is probably wget -r http://cran.r-project.org/src/contrib/1.5.0/Recommended followed by .../R CMD INSTALL

The release of version 2.3.0 has been scheduled for April 24, 2006. The first alpha release should be available later today, once I have reviewed the build scripts. The detailed release schedule is as follows March 27: Declare start of release process. The build process is assumed to be essentially in place at this time. There is a "grand feature" freeze (minor tweaks

We have now (actually a few days ago) declared a "Grand Feature Freeze" on the development sourcs, meaning that we might still add functionality and fix bugs, but we will not do any further major changes. It should be noted that there has been a couple of quite big changes compared to the 1.6.x series, notably namespaces and the methods package. Also, many more packages are now loaded

For the benefit of package maintainers (and others) we thought it would be a good idea to publish the release schedule well ahead this time. The plan follows below. Not everyone in R-core has had a chance to complain, but I'm off to the ISI tomorrow, so I thought it had better be done now. Platform testing has been a major problem with the previous releases. For some reason, people with

I'm trying to make a habit of announcing upcoming releases on r-devel, to give package maintainers a chance of staying in sync, and to encourage everyone to report bugs in the prerelease versions. So: R-1.3.1 is scheduled for release on August 31st. In order to be able to get a solid round of testing on different platforms, maintainers of the group of recommended packages are requested to

Kjetil Kjernsmo <kjetil.kjernsmo@astro.uio.no> writes: > On 8 Nov 2000, Peter Dalgaard BSA wrote: > > >I'm not at all happy with this: > > > >Solaris : > >> range(sapply(1:2000, function(n) mean(rpois(10000, 15.0)))) > >[1] 15.0524 15.3403 > > Hm, OK, so it isn't just me.... I guess it is time to file a bug report, > should I do it,

I agree with the the comments below on "Numerical recipes". We developed some commercial software using the code and tried to get a licence. They never responded to our corresponce :-) We also mailed them fixes to some bugs !!! but never heard anything. So we threw their code away and wrote our own... it was a waste of time using the book. Kim On Thursday, 25 November 1999 6:41,

For small datasets it would be useful to be able to copy a block of data from a spreadsheet then toggle over to R and just paste it in. If it's possible, having read.table access the clipboard (e.g. x <- read.table(file="clipboard", ...) would do the trick. Of course, exporting to a file and the reading into R is pretty easy but usring the clipboard would save a couple extra

bhoel@server.python.net (Berthold Höllmann) writes: > Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes: > > > I've rolled up R-1.0.0.tgz a short while ago. > > > I've build R-1.0.0 on my > > >uname -a > Linux pchoel 2.2.14 #3 Mit Jan 5 08:57:39 MET 2000 i686 unknown > > box. Calling "make check" fails with .... > >

bhoel@server.python.net (Berthold Höllmann) writes: > Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes: > > > I've rolled up R-1.0.0.tgz a short while ago. > > > I've build R-1.0.0 on my > > >uname -a > Linux pchoel 2.2.14 #3 Mit Jan 5 08:57:39 MET 2000 i686 unknown > > box. Calling "make check" fails with .... > >

Matthew Wiener <mcw@ln.nimh.nih.gov> writes: > t1 <- data.frame(matrix(rnorm(16), nc=4)) > t1$X1 <- 1 > t1$X2 <- 2 > print(t1) > Error: dim<- length of dims do not match the length of object Well, it is prototype-compatible. Splus 5.3 does likewise. A way out is t1<-data.frame(unclass(t1)) However, we do seem to have a bug in the area: > t1 <-

Matthew Wiener <mcw@ln.nimh.nih.gov> writes: > t1 <- data.frame(matrix(rnorm(16), nc=4)) > t1$X1 <- 1 > t1$X2 <- 2 > print(t1) > Error: dim<- length of dims do not match the length of object Well, it is prototype-compatible. Splus 5.3 does likewise. A way out is t1<-data.frame(unclass(t1)) However, we do seem to have a bug in the area: > t1 <-

The machine that serves r-bugs.biostat.ku.dk has been taken off the net. A new machine is planned to replace it, but we need to reconfigure the DNS, which is not going to happen until Monday. The mail interface should still work. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark

The machine that serves r-bugs.biostat.ku.dk has been taken off the net. A new machine is planned to replace it, but we need to reconfigure the DNS, which is not going to happen until Monday. The mail interface should still work. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark

Thanks to Peter Dalgaard and Suchandra Thapa for answering my question! Before I settle on a particular option, I'd like to ask one more question if I may: Are there any practical advantages to compiling R to 64-bit vs 32-bit? Regards, Andy > -----Original Message----- > From: Peter Dalgaard BSA [mailto:p.dalgaard at biostat.ku.dk] > Sent: Thursday, April 18, 2002 4:19 PM > To:

Just to update: What I originally thought was a glm problem appears to be a memory problem that occurs only when R is compiled with the DEC C compiler. Some variables that are still in use get clobbered during garbage collection. No problems if I compile with gcc though. I've made some attempts to see if I can identify a specific compiler optimization that is responsible, but so far no luck.