similar to: Spam filter on r-bugs

I've been hacking at the JitterBug sources a little, so that it should work better with mailing lists. It has been running with the core team list for a while and seems to be OK. I will now move the forwarding address to the r-devel list where it really belongs. I hope this will make it easier for people outside the core team to contribute to the development of R by participating in the

I've been hacking at the JitterBug sources a little, so that it should work better with mailing lists. It has been running with the core team list for a while and seems to be OK. I will now move the forwarding address to the r-devel list where it really belongs. I hope this will make it easier for people outside the core team to contribute to the development of R by participating in the

Here's a number of items that came up in connection with my course for medical ph.d. students this week: boxplot(): - deals ungracefully with empty groups and factor levels not present in grouping variable. - no indication of what variable is being plotted data.entry() (mostly W95 rseptbeta problems) - Entry of first variable name doesn't take before 2nd

The machine that runs the r-bugs website seems to have gone belly-up some time yesterday. The e-mail interface should still work. (No jokes about "Ascension Day", please, I can make up those myself!) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45)

The bug repository will be down briefly (I hope), due to a hardware upgrade. -p -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

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

In order not to have more items in the BUGS list than necessary, I've gone through the list of open bugs and removed some of them for reasons given below: (Note that nothing really dies on R-bugs it just moves into trashcan, wishlist, or Something-fixed, so if you complain loudly enough they can be picked up again.) *Graphics* Remove three reports on panel.first() (2 + 1 answer with a

If I'm not mistaken, "bundle" is really only useful as a concept for distribution and installation. You distribute and install a bundle, but load the individual packages when you want to use them. Once you install the bundle, you won't see the name of the bundle in the list of installed packages, but you see the constituent packages, and those are what you load when you want to

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 .... > >

TASK: problem with "glm" with binomial errors STATUS: Open FROM: p.dalgaard@kubism.ku.dk in glm(,binomial) it's possible that loss of significant digits make expected values 0 or 1 even though there's no divergence of the fit. (Happened to me with menarche data, infants and grown-ups included) [ Need the example data. Glm needs a

Faheem Mitha <faheem@email.unc.edu> writes: > Dear Dr. Dalgaard, > > I am sending this message only to you since it is probably not of general > interest. Forward it to anyone you like. > > Congratulations to the R development team on the release of version 1.0.0 > of R. If you will excuse me asking, I was wondering if there are any plans > to release a rpm of

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.

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 can confirm this bug has been solved, by the expedient of removing the incorrect functions! I think the simplest way to get a bug closed is to send the correction to the original reporter for confirmation, then as Peter suggests send a follow-up to R-bugs. On Fri, 6 Apr 2001 p.dalgaard@biostat.ku.dk wrote: > Paul Gilbert <pgilbert@bank-banque-canada.ca> writes: > > > Peter

OK folks, We're warming up to the release of R-2.0.0 on Oct. 4 (aka 2004-10-04). There will be two weeks of alpha releases followed by two weeks of beta releases, starting today. The releases are made available via CRAN in http://cran.r-project.org/src/base-prerelease and the first one is there already. In case of urgency or CRAN failure, the releases will also be found at

The release schedule has now been set with a release date on April 18. The detailed procedure can be found at http://developer.r-project.org/ (it is not quite there yet, but will appear after a short propagation delay.) The main point for non-developers is that we start making alpha tarballs on March 21 and beta tarballs on April 4. Only very simple and/or critical bugs are fixed in the last