[Rd] 'R CMD build --binary BUNDLE' and Windows
'R CMD build --binary BUNDLE' and Windows. When using R version 2.9.0 beta for 'R CMD build --binary CoCo' on Windows only the first package of the 'Contains' field of the bundle DESCRIPTION file ends up in the zip file. (Same result for the bundle 'VR' by R version 2.9.0 beta.) The check of the CoCo bundle version 0.1.7.5 by R version 2.9.0 beta is OK (on my machine), see attached 00check.log. The zip-file is OK by versions 2.6.0, 2.6.2, 2.7.2, and 2.8.0 of R. Regards, Jens Henrik Badsberg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in R-ints.texi's description of P_ macro
I think there are some missing words in "R Internals"'s description of
the P_ macro.
It currently has "A macro as a wrapper for ngettext", which I think
ought to be
something like "The macro P_ may be used as a wrapper for ngettext".
The following patch also makes the 2 alternate definitions of P_ have
the same argument names,
StringS and StringP. Expanding the S and P to Singular and Plural,
would be more descriptive.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
Index: doc/manual/R-ints.texi
===
--- doc/manual/R-ints.texi (revision 48294)
+++ doc/manual/R-ints.texi (working copy)
@@ -2149,17 +2149,18 @@
@noindent
from @file{src/main/errors.c}.
-A macro
+The @code{P_} macro
@example
#ifdef ENABLE_NLS
#define P_(StringS, StringP, N) ngettext (StringS, StringP, N)
#else
-#define P_(String, StringP, N) (N > 1 ? StringP: String)
+#define P_(StringS, StringP, N) (N > 1 ? StringP: StringS)
#endif
@end example
@noindent
+may be used
as a wrapper for @code{ngettext}: however in some cases the preferred
approach has been to conditionalize (on @code{ENABLE_NLS}) code using
@code{ngettext}.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in R-ints.texi's description of P_ macro
William Dunlap wrote:
I think there are some missing words in "R Internals"'s description of
the P_ macro.
It currently has "A macro as a wrapper for ngettext", which I think
ought to be
something like "The macro P_ may be used as a wrapper for ngettext".
The following patch also makes the 2 alternate definitions of P_ have
the same argument names,
StringS and StringP. Expanding the S and P to Singular and Plural,
would be more descriptive.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
Index: doc/manual/R-ints.texi
===
--- doc/manual/R-ints.texi (revision 48294)
+++ doc/manual/R-ints.texi (working copy)
@@ -2149,17 +2149,18 @@
@noindent
from @file{src/main/errors.c}.
-A macro
+The @code{P_} macro
@example
#ifdef ENABLE_NLS
#define P_(StringS, StringP, N) ngettext (StringS, StringP, N)
#else
-#define P_(String, StringP, N) (N > 1 ? StringP: String)
+#define P_(StringS, StringP, N) (N > 1 ? StringP: StringS)
#endif
@end example
@noindent
+may be used
as a wrapper for @code{ngettext}: however in some cases the preferred
approach has been to conditionalize (on @code{ENABLE_NLS}) code using
@code{ngettext}.
OK, committed.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-alpha/R-beta builds on Alpha platform failing with compiler error
On 4 April 2009 at 16:34, Dirk Eddelbuettel wrote: | On 4 April 2009 at 23:21, Peter Dalgaard wrote: | | Dirk Eddelbuettel wrote: | | > Per https://buildd.debian.org/build.php?pkg=r-base, we see the Alpha platform | | > having trouble with deriv.c : | | > | | > gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -mieee-with-inexact -fpic -std=gnu99 -O3 -pipe -g -c deriv.c -o deriv.o | | > deriv.c: In function 'simplify': | | > deriv.c:267: error: unrecognizable insn: | | > (insn 2103 64 65 9 ../../src/include/Rinlinedfuns.h:86 (set (reg:DI 2 $2) | | > (const:DI (plus:DI (label_ref:DI 68) | | > (const_int 24 [0x18] -1 (insn_list:REG_LABEL_OPERAND 68 (nil))) | | > deriv.c:267: internal compiler error: in extract_insn, at recog.c:2001 | | > Please submit a full bug report, | | > with preprocessed source if appropriate. | | > See for instructions. | | > make[4]: *** [deriv.o] Error 1 | | > | | > This could of course be a bug in gcc. Does anybody have insights into | | > anything that may have changed here? | | | | I think it is by definition a bug in gcc... | | | | It is usually rather hopeless to work around this sort of issue by | | source code changes. Have you tried reducing the optimization level? | | No, not yet. Let me try that for the next beta. Change made. And tested on one the Alpha machines available to Debian -- it does build with -O2 so that's what the next upload will use. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] history function does not work correctly (PR#13645)
Full_Name: Joseph Adler Version: 2.8.1 OS: Mac OS X 10.5.6 Submission from: (NULL) (71.142.93.52) According to the help file, the history() function is supposed to show recent command history. However, it does not do this in the current Mac OS X version. Instead, the history function appears to simply show the contents of the file ~/.Rhistory. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
