similar to: Meta information in packages in pre-2.0.0

Filing on R-bugs (DTL's reply started a new PR). -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ---------- Forwarded message

Thanks, Prof. Ripley. I downloaded the new admin.R and used that in place of one in R-2.0.0 build directory. The compile went fine. So, for the record, R-2.0.0 + Prof. Ripley's fixed admin.R compiles fine on "alphapca56-unknown-linux-gnu". ---- [rajiv@localhost rajiv]$ R R : Copyright 2004, The R Foundation for Statistical Computing Version 2.0.0 (2004-10-04), ISBN

I used the packaged "MinGW-2.0.0-3.exe" exactly as specified on http://www.stats.ox.ac.uk/pub/Rtools/ - in fact I used these recommendations throughout. According to the release notes MinGW version 2.0.0 contains the following list of packages: GCC-3.2-core-20020817-1 binutils-2.13-20020903-1 mingw-runtime-2.2 w32api-2.0 gdb-5.1.1-1 make-3.79.1-20010722 (binary renamed as mingw32-make)

As from R 2.0.0, R CMD check has not flagged .C etc calls without a PACKAGE argument in packages with a namespace. Unfortunately that was based on too optimistic assumptions. 1) The mechanism to find the DLL from the namespace only works if the DLL is declared via a useDynLib declaration in NAMESPACE (and only if there is one such declaration). This is checked in R-devel. 2) In 2.1.1, the

[I'm diverting this to R-devel, as I believe my questions are more appropriate for that.] > From: Prof Brian Ripley [snip] > Luke Tierney recommends removing the NAMESPACE file during > development of > a package if you need frequent access to debug/change its functions. But isn't that a bit troublesome if there is a shared object to be loaded in the NAMESPACE file? If I

Thanks, Peter, and Prof. Ripley. My efforts last night was mostly futile except that it told me about the embedded newline in Built field. Prof. Ripley: how do I get your fixes? Can I just download R-2.0.0-patched? Rajiv -------- Rajiv Prasad Scientist, Hydrology Group Pacific Northwest National Laboratory, P.O. Box 999, MSIN K9-33 Richland, WA 99352 Voice: (509) 375-2096 Fax: (509) 372-6089

Duncan, I don't know what we want, but it is not a simple matter of documenting what .dynLibs currently does. What I see as bugs are 1) the inconsistent names and types of the components returned by .dynLibs(). 2) the inconsistent inclusion or not of R_X11 in the list returned by .dynLibs(). 3) the inclusion of static info (base) by library.dynam(). 4) including loadable modules

The major changes for R 2.0.0 are now in place, and we have provided a set of notes for package maintainers at http://developer.r-project.org/200update.txt on both changes needed and new opportunities. The main thing which needs to be done is to revise the DESCRIPTION file, in particular to ensure the Depends: field is accurate. We do run daily checks over all the CRAN packages. See

Please do as we ask (repeatedly) and study the help page before posting. 'family' is a separate argument, not part of loess.control, as the help page correctly documents. If you use cars.lo2 <- loess(dist ~ speed, cars, family = "symmetric", control = loess.control(surface = "direct", iterations = 20)) cars.lo2$pars$iterations it prints *20*, as it is

Dear Prof. Ripley, thks for your response and no, I have not looked at 2.0.0 beta version; blame on me, but I could not spare time by now for doing so; instead I looked at: http://cran.r-project.org/doc/manuals/fullrefman.pdf as well as on my local one in: 'rw1091/doc/manual/refman.pdf'. Hopefully this clarified things; thks for taking your time and patience. Best, Bernhard >

(1) I do read the posting guide (the fact that I missread o missunderstood something does not imply not reading) (2) I could change NAs to 0 (I know) but I have previously (older versions of R and SQL*Plus) used the same select with the "right" output (namely with 0s). (3) AFAIK "strange" is not a negative remark and does not seem to me at the very least but that is always a

>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk> >>>>> on Fri, 30 May 2008 22:34:28 +0100 (BST) writes: BDR> I think it is ESS that is parsing this as a help BDR> request (so it can divert it to an ESS buffer). BDR> Looks like this is an ESS issue, not an R one. yes, indeed, hence much more belonging the ESS-help

Thank you for the patch. To clarify: this is not a bug. ?.C says The mapping of the types of R arguments to C or Fortran arguments in '.C' or '.Fortran' is R C Fortran integer int * integer numeric double * double precision - or - float * real complex Rcomplex * double complex

On Wed, 13 Oct 2004, Duncan Temple Lang wrote: > Prof Brian Ripley wrote: > > On Wed, 13 Oct 2004, Liaw, Andy wrote: > > > > > > > On a slightly different topic: In R-2.0.0, packages with NAMESPACE no > > > longer need to use the package= argument in .C/.Fortran. Does that mean if > > > I remove those arguments, I should put R version >=

This has been in the R-admin manual for a least a week, and I reported it here earlier than that. R 2.0.0 alpha does not allow f2c on 64-bit platforms. It's all been dealt with quite awhile ago .... On Sun, 12 Sep 2004 ivo_welch-rstat8783@mailblocks.com wrote: > > from the gentoo folks, on f2c problems with R on 64bit platforms: > > "Config and me finally found the

> From: Prof Brian Ripley <ripley at stats.ox.ac.uk> > Date: June 17, 2004 12:15:01 PM CEST > To: Meinhard Ploner <meinhardploner at gmx.net> > Cc: r-help at stat.math.ethz.ch > Subject: Re: [R] packages & data-sets > > On Thu, 17 Jun 2004, Meinhard Ploner wrote: > >> It's possible to create a package with functions and data, >> from which

> From: Duncan Temple Lang > > Prof Brian Ripley wrote: > > On Wed, 13 Oct 2004, Liaw, Andy wrote: > > > > > > > On a slightly different topic: In R-2.0.0, packages with > NAMESPACE no > > > longer need to use the package= argument in .C/.Fortran. > Does that mean if > > > I remove those arguments, I should put R version >=

On Wed, 5 Oct 2005 Hallgeir.Grinde at elkem.no wrote: > Yes. > so (x1*x2*x3*x4*x5*x6*x7*x8)^2 = (x1+x2+x3+x4+x5+x6+x7+x8)^8 ? Yes in the sense that the simplified formula given by terms() is the same. > and there is a difference in > (x1*x2*x3*x4*x5*x6*x7*x8)^2 > and > (x1*x2*x3*x4*x5*x6*x7*x8) > althoug the resulting formulas are the same, or? The first is reduced to the

Well, "integer" is also a storage.mode in R. It is not immediately clear which meaning the help page uses. I guess some extra elaboration would be helpful. Anyway, thank you for the clarification, Vadim > -----Original Message----- > From: Prof Brian Ripley [mailto:ripley@stats.ox.ac.uk] > Sent: Tuesday, March 22, 2005 9:54 AM > To: Vadim Ogranovich > Cc:

As we have seen from PR#6846, we don't document much what happens to NAs in plot functions. The formula interfaces do seem to be a bit of a mess, as they call model.frame and so some (but only some) of them pick up the options() setting of na.action. This means that for example pairs(~ x +y + z) and pairs(cbind(x, y, z)) may well treat NAs differently, depending on the value of