Re: [Rd] [OT] old news on the home page
> On Mon, 15 Jan 2007 17:01:47 +0100, > Antonio, Fabio Di Narzo (AFDN) wrote: > Hi all. > I've noticed that on the R homepage: > http://www.r-project.org/ > one can read, as the latest news: > " R version 2.4.0 has been released on 2006-10-03." > and can't find any citation of the 2.4.1 release of the last 18 december. Thanks a lot for the hint, fixed in SVN (will automatically go online later today). Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.stat.uni-muenchen.de/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R_ParseVector API change
Dear R developers, just a quick question: I noted that R_ParseVector () has gained an additional parameter (since SVN rev. 3). Since R_ParseVector () is part of the public API, I'm wondering, whether this API change was intentional or not. Either way is fine with me, but in order to make sure the next release of RKWard will be compilable with R 2.5.0, I'd like to make sure, whether or not the change is here to stay. Regards Thomas Friedrichsmeier pgpkvniKL3of2.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_ParseVector API change
Thomas, On Jan 17, 2007, at 12:53 PM, Thomas Friedrichsmeier wrote: > Dear R developers, > > just a quick question: I noted that R_ParseVector () has gained an > additional parameter (since SVN rev. 3). Since R_ParseVector > () is part of the public API, I'm wondering, whether this API > change was intentional or not. Yes, it was intentional (added support for keep.source I believe). Duncan, you may want to add the API change to NEWS - it's not mentioned there. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_ParseVector API change
On 1/17/2007 12:53 PM, Thomas Friedrichsmeier wrote: > Dear R developers, > > just a quick question: I noted that R_ParseVector () has gained an additional > parameter (since SVN rev. 3). Since R_ParseVector () is part of the > public API, I'm wondering, whether this API change was intentional or not. > Either way is fine with me, but in order to make sure the next release of > RKWard will be compilable with R 2.5.0, I'd like to make sure, whether or not > the change is here to stay. The change was accidental (I forgot that R_ParseVector was in the API when I made it), but I think it will stay. Setting the value of this parameter to R_NilValue gets the old behaviour. Setting it to some other SEXP will have that SEXP recorded as the srcfile attribute of source references. I think the description above is the level of detail of the implementation that it's safe to work with. The particular format of source references could change. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] uninformative error message in R CMD check (PR#9459)
I just saw the following using R version 2.4.1 (2006-12-18) in
output from R CMD check.
* checking Rd files ... WARNING
Error in as.vector(x, mode) : invalid argument 'mode'
Execution halted
See the chapter 'Writing R documentation files' in manual 'Writing R
Extensions'.
In looking at the help page (the only one in the package so far) I noticed
that there was no details section even though I wrote one. The problem
was a missing close curly, that is, I had
\details{
Blah, blah, blah.
\value{
A list
}
I don't know whether it is possible to have an actually informative
error message, but it would be nice if possible. The error went away
and the package checked OK when I added the close curly
\details{
Blah, blah, blah.
}
\value{
A list
}
--
Charles Geyer
Professor, School of Statistics
University of Minnesota
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9444)
On Tuesday, 16. January 2007 12:46, Duncan Murdoch wrote:
> On 1/16/2007 5:26 AM, Arne Henningsen wrote:
> > [...]
> > Is there any reason for deparse() to add spaces around "+", "-", and "*"
> > operators but not around "/" operators?
> > R> deparse(parse( text = "a+b-c*d/e" ))
> > [1] "expression(a + b - c * d/e)"
>
> I don't know, but it has been like that for the complete history of the
> source code in the repository (almost 10 years). I suppose someone thought
>
> a + b - c * d /
> e
>
> would look ugly (even though they were happy to put one of the other
> operators at the end of the line).
What do the other developeRs and useRs think about this?
> This makes me quite reluctant to
> change it: people get upset about changes to the look of their old
> scripts, because they trigger spurious check errors.
Is it possible to add an option to specify whether "/" operators should be
treated like "+", "-", and "*" operators or not?
Arne
> Duncan Murdoch
>
> The fact that it isn't the one you want doesn't mean it needs
> to be listed as an outstanding issue in the bug reporting system.
> >>>
> >>> Okay. Where can I list "minor" wishes?
> >>
> >> On your to-do list?
> >
> > Yes, that's a good idea!
> > This is my patch of /src/main/names.c:
> >
> > --- names.c.orig2007-01-16 11:03:24.0 +0100
> > +++ names.c 2007-01-16 10:30:43.0 +0100
> > @@ -149,7 +149,7 @@
> > {"+", do_arith, PLUSOP, 1, 2, {PP_BINARY, PREC_SUM,0}},
> > {"-", do_arith, MINUSOP,1, 2, {PP_BINARY, PREC_SUM,0}},
> > {"*", do_arith, TIMESOP,1, 2, {PP_BINARY, PREC_PROD, 0}},
> > -{"/", do_arith, DIVOP, 1, 2, {PP_BINARY2, PREC_PROD, 0}},
> > +{"/", do_arith, DIVOP, 1, 2, {PP_BINARY, PREC_PROD, 0}},
> > {"^", do_arith, POWOP, 1, 2, {PP_BINARY2, PREC_POWER, 1}},
> > {"%%", do_arith, MODOP, 1, 2, {PP_BINARY2, PREC_PERCENT,0}},
> > {"%/%", do_arith, IDIVOP, 1, 2, {PP_BINARY2, PREC_PERCENT,0}},
> >
> > (I have removed some blanks so that each line fits in a single line)
> >
> > Now I get:
> > R> deparse(parse( text = "a+b-c*d/e" ))
> > [1] "expression(a + b - c * d / e)"
> >
> > Does this patch has any negative side effects?
> >
> > "make check" fails, but AFAIK this is just because of different positions
> > of line breaks:
> > [...]
> > running code in 'reg-tests-2.R' ... OK
> > comparing 'reg-tests-2.Rout'
> > to './reg-tests-2.Rout.save' ...3639,3640c3639,3640
> > < aov(formula = dep.variable ~ f1 * f2 + Error(subject / (f1 +
> > < f2)), data = sample.df)
> > ---
> >
> >> aov(formula = dep.variable ~ f1 * f2 + Error(subject/(f1 + f2)),
> >> data = sample.df)
> >
> > 3693,3694c3693,3694
> > < aov(formula = dep.variable ~ f1 * f2 + Error(subject / (f2 +
> > < f1)), data = sample.df)
> > ---
> >
> >> aov(formula = dep.variable ~ f1 * f2 + Error(subject/(f2 + f1)),
> >> data = sample.df)
> >
> > make[3]: *** [reg-tests-2.Rout] Fehler 1
> > [...]
> >
> >> Duncan Murdoch
> >
> > Thank you for all your hints,
> > Arne
--
Arne Henningsen
Department of Agricultural Economics
University of Kiel
Olshausenstr. 40
D-24098 Kiel (Germany)
Tel: +49-431-880 4445
Fax: +49-431-880 1397
[EMAIL PROTECTED]
http://www.uni-kiel.de/agrarpol/ahenningsen/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] encoding issues even w/o accents
An earlier thread (in 10/2006) discussed encoding issues in the context of R data and the desire to represent accented characters. It matters in another setting: the output generated by R and the seemingly order character "'" (single quote). In particular, R CMD check runs test code and compares the generated output to a saved file of expected output. This does not work reliably across encoding schemes. This is unfortunate, since it seems the "expected output" files will necessarily be wrong for someone. The problem for me was triggered by the single-quote character "'". On my older systems, this is encoded by 0x27, a perfectly fine ASCII character. That is on a Debian GNU/Linux system with LANG=en_US. On a newer system I have LANG=en_US.UTF-8. I don't recall whether this was a deliberate choice on my part, or simply reflects changing defaults for the installer. (Note the earlier thread referred to the Debian-derived Ubuntu systems as having switched to UTF-8). Under UTF-8 the same character is encoded in the 3-byte sequence 0xE28098 (which seems odd; I thought the point of UTF-8 was that ASCII was a legitimate subset). The coefficient printing methods in the stats package use the single-quote in the key explaining significance levels: Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 I suppose one possible work-around for R CMD check would be to set the encoding to some standard value before it runs tests, but that has some drawbacks. It doesn't work for packages needing a different encoding (but perhaps the package could specify an encoding to use by default?)(*), It will leave the output files looking weird on systems with a different encoding. It will get messed up if one generates the files under the wrong encoding. And none of this addresses stuff beyond the context of output file comparison in R CMD check. Any thoughts? Ross Boylan * From the R Extensions document, discussing the DESCRIPTION file: If the `DESCRIPTION' file is not entirely in ASCII it should contain an `Encoding' field specifying an encoding. This is currently used as the encoding of the `DESCRIPTION' file itself, and may in the future be taken as the encoding for other documentation in the package. Only encoding names `latin1', `latin2' and `UTF-8' are known to be portable. I would not expect that the test output files be considered "documentation," but I suppose that's subject to interpretation. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
