[Rd] Parts of test in datetime3.R not working
In test file datetime3.R, one call to stopifnot() has an argument named "expr"
which should probably be "exprs". There are three tests wrapped in braces of
which only the last one, "omitted 195 entries", is currently checked.
Proposed patch:
--- tests/datetime3.R (revision 84544)
+++ tests/datetime3.R (working copy)
@@ -45,7 +45,7 @@
c2 <- capture.output(print(dt, max = 6))
writeLines(tail(cc, 4))
writeLines(c2)
-stopifnot(expr = {
+stopifnot(exprs = {
grepl("omitted 151 entries", tail(cc, 1))
!anyDuplicated(tail(cc, 2))
grepl("omitted 195 entries", tail(c2, 1))
--
Best regards,
Mikko
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Improvement to documentation in dput.Rd
If the "Matrix" package is attached, 'example(dget)' fails: > library(Matrix) > example(dget) dget> fil <- tempfile() dget> ## Write an ASCII version of function mean to our temp file dget> dput(mean, fil) dget> ## And read it back into 'bar' dget> bar <- dget(fil) Error in initialize(value, ...) : '...' used in an incorrect context A possible fix would be to use 'dput(base::mean, fil)' instead of 'dput(mean, fil)' in src/library/base/man/dput.Rd . -- Mikko Korpela __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in grep.Rd
There is a small typo in file 'src/library/base/man/grep.Rd'.
Current text:
## collation order is aAbBcCdEe ...
Suggested text ("D" instead of "E"):
## collation order is aAbBcCdDe ...
Best regards,
- Mikko Korpela
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible encoding bug in sub()
I noticed that sub() gives unexpected results for the following test
case. In the test case, the (initial) input is ASCII but the
replacements are UTF-8. The first sub() produces an UTF-8 result with
an "unknown" Encoding. This makes the result garbled in Windows (no
UTF-8 locale there). The second sub() produces a correct result,
although for some reason it is converted to the native Encoding in
Windows.
I think the best result would be UTF-8 output marked as such.
foo <- c("a", "b")
foo <- sub("a", "\u00e4", foo)
print(Encoding(foo))
## [1] "unknown" "unknown"
foo <- sub("b", "\u00f6", foo)
print(Encoding(foo))
## [1] "unknown" "unknown" # Windows
## [1] "unknown" "UTF-8" # Linux
print(foo)
## [1] "ä" "ö"# Windows
## [1] "ä" "ö" # Linux
The output of sessionInfo() for both test systems follows.
> sessionInfo()
R version 3.5.1 Patched (2018-11-28 r75713)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=Finnish_Finland.1252 LC_CTYPE=Finnish_Finland.1252
[3] LC_MONETARY=Finnish_Finland.1252 LC_NUMERIC=C
[5] LC_TIME=Finnish_Finland.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.5.1
> sessionInfo()
R Under development (unstable) (2018-12-08 r75801)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/libf77blas.so.3.10.3
LAPACK: /home/mikko/root_R-devel-r75801/lib/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=fi_FI.UTF-8 LC_NUMERIC=C
[3] LC_TIME=fi_FI.UTF-8LC_COLLATE=fi_FI.UTF-8
[5] LC_MONETARY=fi_FI.UTF-8LC_MESSAGES=fi_FI.UTF-8
[7] LC_PAPER=fi_FI.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=fi_FI.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.6.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible encoding bug in sub()
Thanks for the confirmation. The bug report is now online at
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17509
- Mikko
-Original Message-
From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
Sent: Monday, December 10, 2018 12:09 PM
To: Korpela Mikko (MML)
Cc: r-devel@r-project.org
Subject: Re: [Rd] Possible encoding bug in sub()
>>>>> Korpela Mikko (MML)
>>>>> on Sat, 8 Dec 2018 18:42:30 + writes:
> I noticed that sub() gives unexpected results for the following test
> case. In the test case, the (initial) input is ASCII but the
> replacements are UTF-8. The first sub() produces an UTF-8 result with
> an "unknown" Encoding. This makes the result garbled in Windows (no
> UTF-8 locale there). The second sub() produces a correct result,
> although for some reason it is converted to the native Encoding in
> Windows.
> I think the best result would be UTF-8 output marked as such.
> foo <- c("a", "b")
> foo <- sub("a", "\u00e4", foo)
> print(Encoding(foo))
> ## [1] "unknown" "unknown"
> foo <- sub("b", "\u00f6", foo)
> print(Encoding(foo))
> ## [1] "unknown" "unknown" # Windows
> ## [1] "unknown" "UTF-8" # Linux
> print(foo)
> ## [1] "ä" "ö"# Windows
> ## [1] "ä" "ö" # Linux
I can confirm the problem on Windows,
also for a recent version of R-devel.
Why not filing this as a proper bug report at R's bugzilla?
There's still no certainty that it will be fixed quickly, but the bug PR's
there are less easily forgotten.
Martin
> The output of sessionInfo() for both test systems follows.
>> sessionInfo()
> R version 3.5.1 Patched (2018-11-28 r75713)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
> Matrix products: default
> locale:
> [1] LC_COLLATE=Finnish_Finland.1252 LC_CTYPE=Finnish_Finland.1252
> [3] LC_MONETARY=Finnish_Finland.1252 LC_NUMERIC=C
> [5] LC_TIME=Finnish_Finland.1252
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> loaded via a namespace (and not attached):
> [1] compiler_3.5.1
>> sessionInfo()
> R Under development (unstable) (2018-12-08 r75801)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.1 LTS
> Matrix products: default
> BLAS: /usr/lib/x86_64-linux-gnu/libf77blas.so.3.10.3
> LAPACK: /home/mikko/root_R-devel-r75801/lib/R/lib/libRlapack.so
> locale:
> [1] LC_CTYPE=fi_FI.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=fi_FI.UTF-8LC_COLLATE=fi_FI.UTF-8
> [5] LC_MONETARY=fi_FI.UTF-8LC_MESSAGES=fi_FI.UTF-8
> [7] LC_PAPER=fi_FI.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=fi_FI.UTF-8 LC_IDENTIFICATION=C
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PDF generation issue from manual page
Hi Neonira!
The \blacktriangleright macro is defined in LaTeX package "amssymb". According
to Writing R Extensions (section 2.6 Mathematics), "only basic LaTeX can be
used, there being no provision to specify LaTeX style files such as the AMS
extensions" (in Rd files).
Best,
- Mikko
-Alkuperäinen viesti-
Lähettäjä: R-devel Puolesta neonira Arinoem
Lähetetty: tiistai 11. helmikuuta 2020 15.57
Vastaanottaja: r-devel
Aihe: [Rd] PDF generation issue from manual page
Hi R gurus
Got an issue risen by CRAN about using unknown characters from Latex.
Here is the error message
*Check: PDF version of manual, Result: WARNING LaTeX errors when creating
PDF version. This typically indicates Rd problems. LaTeX errors found:
! Undefined control sequence.\blacktriangleright *
* l.237 STRATUM $\blacktriangleright
$ LAYER\_3 ! Undefined control sequence.
\blacktriangleright *
* l.239 PHASING $\blacktriangleright
$ RUN ! Undefined control sequence.\blacktriangleright
*
* l.241 INTENT $\blacktriangleright
$ FEEDBACK*
I understand that the \blacktriangleright is an unknown control sequence from
latex ... and that sounds strange to me, as I uses it often in vignettes
without any issue so far.
In the incriminated manual page, the code generating this sequence is the
following
*\ifelse{latex}{\out{$\blacktriangleright$}}{\ifelse{html}{\out{▶}}{\u25b6}}*
I am wondering what is wrong and how to circumvent such issue.
Yours ideas and hints welcome
Best.
Neonira
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] make check fails due to NA / NaN mismatch
It seems there is a problem in tests/d-p-q-r-tst-2.R (R-devel r79091): NA / NaN mismatch is not allowed by a test on lines 590--592, but the comment suggests otherwise. A run of "make check" fails there when tested on a Raspberry Pi with Raspberry Pi OS (based on Debian Buster): all 'NaN' is expected, but all 'NA' is returned when testing the function 'rf()' with 'ia == 1'. Best regards, Mikko Korpela Maanmittauslaitos | National Land Survey of Finland Opastinsilta 12 C, 00520 Helsinki, Finland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make check fails due to NA / NaN mismatch
Thank you for the introduction to these recent changes, Martin.
I think this was the second time I ran "make check" on that platform (Raspberry
Pi 32-bit), and the first time (some months ago) it worked fine. So, that makes
it kind of "suddenly", although I must say that my use of "make check" is very
irregular.
I compared code before and after the split you are referring to. The test in
question changed in the process:
This is a snippet of "tests/d-p-q-r-tests.R" (lines 1030--1034) at revision
79079, just before the split:
if(!inherits(R$warning, "simpleWarning")) cat(" .. did *NOT* give a warning! ")
if(!(identical(R$value, expected))) { ## allow NA/NaN mismatch in these cases
for now:
if(!(dist %in% c("beta","f","t") && all(is.na(R$value
cat(" .. not giving expected NA/NaN's ")
}
The corresponding piece of code in "tests/d-p-q-r-tst-2.R" (lines 588--591)
after the split, at revision 79080, is:
if(!inherits(R$warning, "simpleWarning")) stop(" .. did *NOT* give a warning! ")
if(!(identical(R$value, expected))) { ## allow NA/NaN mismatch in these cases
for now:
stop(" .. not giving expected NA/NaN's ")
}
where the test is less forgiving, both with respect to the conditions and the
type of "nag" (cat vs stop).
- Mikko
-Alkuperäinen viesti-
Lähettäjä: Martin Maechler
Lähetetty: maanantai 31. elokuuta 2020 10.44
Vastaanottaja: Korpela Mikko (MML)
Kopio: r-devel
Aihe: Re: [Rd] make check fails due to NA / NaN mismatch
>>>>> Korpela Mikko (MML)
>>>>> on Mon, 31 Aug 2020 06:23:59 + writes:
> It seems there is a problem in tests/d-p-q-r-tst-2.R (R-devel r79091): NA
/ NaN mismatch is not allowed by a test on lines 590--592, but the comment
suggests otherwise. A run of "make check" fails there when tested on a
Raspberry Pi with Raspberry Pi OS (based on Debian Buster): all 'NaN' is
expected, but all 'NA' is returned when testing the function 'rf()' with 'ia ==
1'.
Thank you, Mikko.
Note that I've recently split off the tests/d-p-q-r-tst-2.R file
from from the previously longer tests/d-p-q-r-tests.R file,
mostly in order to drop the 'R CMD Rdiff .. *.Rout.save' testing from those
parts.
However the *test* you mention has been in R's tests (in the
tests//d-p-q-r-tests.R file) for a very long time, AFAICS.
So, I am a bit puzzled: What you write seems to indicate that this is a new
failure, but that is just one "between the lines"
interpretation, so let me ask to clarify:
Is it the first time you're running 'make check' on that platform and get that
error?
or is it a platform you've been running 'make check' on R-devel for a while and
only now you "suddenly" get that error?
Best,
Martin
> Best regards,
> Mikko Korpela
> Maanmittauslaitos | National Land Survey of Finland
> Opastinsilta 12 C, 00520 Helsinki, Finland
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Printing Unicode escapes with 6 digits may be problematic
A recent R-devel commit introduces a change in the way non-printable Unicode
characters are shown as an escape code. Whereas large code points were
previously printed using an escape code of 8 hexadecimal digits, with initial
zeros, the present code (tested with R-devel r79623 on Ubuntu Linux) only
prints 6 hex digits. I think this may be problematic: it is now possible that R
prints a character string which is not valid when reused as an input. See the
following example.
"\U{16FE4}1"
# [1] "\U016fe41"
"\U016fe41"
# Error: invalid \U value 16fe41 (line 1)
Best regards,
- Mikko Korpela
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing Unicode escapes with 6 digits may be problematic
I see that this was only a passing issue. R-devel r79638 and greater (also
tested with r79801) print six digits inside curly brace delimiters, like so:
"\U{016fe4}1" (using the example below). This ensures compatibility between
output and input.
- Mikko
-Alkuperäinen viesti-
Lähettäjä: R-devel Puolesta Korpela Mikko (MML)
Lähetetty: maanantai 14. joulukuuta 2020 11.51
Vastaanottaja: r-devel
Aihe: [Rd] Printing Unicode escapes with 6 digits may be problematic
A recent R-devel commit introduces a change in the way non-printable Unicode
characters are shown as an escape code. Whereas large code points were
previously printed using an escape code of 8 hexadecimal digits, with initial
zeros, the present code (tested with R-devel r79623 on Ubuntu Linux) only
prints 6 hex digits. I think this may be problematic: it is now possible that R
prints a character string which is not valid when reused as an input. See the
following example.
"\U{16FE4}1"
# [1] "\U016fe41"
"\U016fe41"
# Error: invalid \U value 16fe41 (line 1)
Best regards,
- Mikko Korpela
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typos in ?regex
I found three little typos in the ?regex manual. Apologies for the lack of a diff, as the utility is not (yet) installed on this machine. 1. "There is a also" should probably be "There is also". 2. In the list of functions following "This section covers the regular expressions"..., "grep" appears twice. The other one should probably be "grepl". 3. In the "See Also" entry for TRE documentation, there is a spurious closing parenthesis. - Mikko -- Mikko Korpela Chief Expert, Valuations National Land Survey of Finland Opastinsilta 12 C, FI-00520 Helsinki, Finland +358 50 462 6082 www.maanmittauslaitos.fi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible bug in package installation when R_ICU_LOCALE is set
On a Windows computer (other platforms not tested), installing a
package from source may fail if the environment variable R_ICU_LOCALE
is set, depending on the package and the locale.
For example, after setting R_ICU_LOCALE to "fi_FI",
install.packages("seriation", type = "source")
(package version 1.2-3) fails with the following error:
** preparing package for lazy loading
Error in set_criterion_method("dist", "AR_events", criterion_ar_events, :
could not find function "set_criterion_method"
Error : unable to load R code in package 'seriation'
Package "Epi" (version 2.24) fails similarly:
** preparing package for lazy loading
Error in eval(exprs[i], envir) : object 'Relevel.default' not found
Error : unable to load R code in package 'Epi'
Whether R_ICU_LOCALE is set before R is launched or during the session
doesn't matter: installation of these two example packages fails
either way. If R_ICU_LOCALE is unset, calling
icuSetCollate(locale = "fi_FI")
is harmless. Browsing through the R manuals, I did not find warnings
against using R_ICU_LOCALE, or any indication why package installation
should fail with the variable being set. About the collation order of R
code files, "Writing R Extensions" says:
> The default is to collate according to the 'C' locale.
I interpret this (and the surrounding text) as a "promise" to package
developers that no matter what the end user does, the developer should
be able to rely on the collation order being 'C' unless the developer
defines another order.
> sessionInfo()
R version 3.4.3 Patched (2018-02-03 r74231)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=Finnish_Finland.1252 LC_CTYPE=Finnish_Finland.1252
[3] LC_MONETARY=Finnish_Finland.1252 LC_NUMERIC=C
[5] LC_TIME=Finnish_Finland.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.3 tools_3.4.3
--
Mikko Korpela
Chief Expert, Valuations
National Land Survey of Finland
Opastinsilta 12 C, FI-00520 Helsinki, Finland
+358 50 462 6082
www.maanmittauslaitos.fi
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in src/extra/tzone/registryTZ.c
I stumbled upon a typo in a time zone name: Irtutsk should be Irkutsk.
A patch is attached. I also checked that this is the only bug of its
kind in this file, i.e., all the other Olson time zones occurring in
the file can also be found in Unicode Common Locale Data Repository.
- Mikko Korpela
Index: src/extra/tzone/registryTZ.c
===
--- src/extra/tzone/registryTZ.c(revision 74465)
+++ src/extra/tzone/registryTZ.c(working copy)
@@ -303,7 +303,7 @@
{ L"Russia Time Zone 4", "Asia/Yekaterinburg" },
{ L"Russia Time Zone 5", "Asia/Novosibirsk" },
{ L"Russia Time Zone 6", "Asia/Krasnoyarsk" },
-{ L"Russia Time Zone 7", "Asia/Irtutsk" },
+{ L"Russia Time Zone 7", "Asia/Irkutsk" },
{ L"Russia Time Zone 8", "Asia/Yakutsk" },
{ L"Russia Time Zone 9", "Asia/Magadan" },
{ L"Russia Time Zone 10", "Asia/Srednekolymsk" },
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible \uxxx typos in documents
I found a few occurrences of "\uxxx" which should probably have
one more "x". A patch follows:
Index: doc/manual/R-ints.texi
===
--- doc/manual/R-ints.texi (revision 74580)
+++ doc/manual/R-ints.texi (working copy)
@@ -1277,11 +1277,11 @@
we have to a universal format. For those that do not (for example those
lacking a powerful enough @code{iconv}), it is likely that they work in
Latin-1, the old @R{} assumption. Then the parser can return a
-UTF-8-encoded string if it encounters a @samp{\uxxx} escape for a
+UTF-8-encoded string if it encounters a @samp{\u} escape for a
Unicode point that cannot be represented in the current charset. (This
needs MBCS support, and was only enabled@footnote{See define
@code{USE_UTF8_IF_POSSIBLE} in file @file{src/main/gram.c}.} on
-Windows.) This is enabled for all platforms, and a @samp{\uxxx} or
+Windows.) This is enabled for all platforms, and a @samp{\u} or
@samp{\U} escape ensures that the parsed string will be marked
as UTF-8.
Index: src/library/base/man/iconv.Rd
===
--- src/library/base/man/iconv.Rd (revision 74580)
+++ src/library/base/man/iconv.Rd (working copy)
@@ -95,7 +95,7 @@
Some of the implementations have interesting extra encodings: for
example GNU \samp{libiconv} allows \code{to = "C99"} to use
- \code{\\uxxx} escapes for non-ASCII characters.
+ \code{\\u} escapes for non-ASCII characters.
}
\section{Byte Order Marks}{
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in package installation when R_ICU_LOCALE is set
(Belated) thanks for the confirmation, Ista. I just reported this issue on the
R bug tracker:
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17412
Best regards,
- Mikko
-Alkuperäinen viesti-
Lähettäjä: Ista Zahn [mailto:istaz...@gmail.com]
Lähetetty: 7. helmikuuta 2018 17:05
Vastaanottaja: Korpela Mikko (MML)
Kopio: r-devel@r-project.org
Aihe: Re: [Rd] Possible bug in package installation when R_ICU_LOCALE is set
I can reproduce this on Linux, so it is not Windows-specific.
> sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux
Matrix products: default
BLAS/LAPACK: /usr/lib/libopenblas_haswellp-r0.2.20.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
LC_TIME=en_US.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.3 rmsfact_0.0.3 tools_3.4.3cowsay_0.5.0 fortunes_1.5-4
On Wed, Feb 7, 2018 at 8:38 AM, Korpela Mikko (MML)
wrote:
> On a Windows computer (other platforms not tested), installing a
> package from source may fail if the environment variable R_ICU_LOCALE
> is set, depending on the package and the locale.
>
> For example, after setting R_ICU_LOCALE to "fi_FI",
>
> install.packages("seriation", type = "source")
>
> (package version 1.2-3) fails with the following error:
>
> ** preparing package for lazy loading
> Error in set_criterion_method("dist", "AR_events", criterion_ar_events, :
> could not find function "set_criterion_method"
> Error : unable to load R code in package 'seriation'
>
> Package "Epi" (version 2.24) fails similarly:
>
> ** preparing package for lazy loading
> Error in eval(exprs[i], envir) : object 'Relevel.default' not found
> Error : unable to load R code in package 'Epi'
>
> Whether R_ICU_LOCALE is set before R is launched or during the session
> doesn't matter: installation of these two example packages fails
> either way. If R_ICU_LOCALE is unset, calling
>
> icuSetCollate(locale = "fi_FI")
>
> is harmless. Browsing through the R manuals, I did not find warnings
> against using R_ICU_LOCALE, or any indication why package installation
> should fail with the variable being set. About the collation order of
> R code files, "Writing R Extensions" says:
>
>> The default is to collate according to the 'C' locale.
>
> I interpret this (and the surrounding text) as a "promise" to package
> developers that no matter what the end user does, the developer should
> be able to rely on the collation order being 'C' unless the developer
> defines another order.
>
>> sessionInfo()
> R version 3.4.3 Patched (2018-02-03 r74231)
> Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64
> (build 7601) Service Pack 1
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=Finnish_Finland.1252 LC_CTYPE=Finnish_Finland.1252 [3]
> LC_MONETARY=Finnish_Finland.1252 LC_NUMERIC=C [5]
> LC_TIME=Finnish_Finland.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.3 tools_3.4.3
>
> --
> Mikko Korpela
> Chief Expert, Valuations
> National Land Survey of Finland
> Opastinsilta 12 C, FI-00520 Helsinki, Finland
> +358 50 462 6082
> www.maanmittauslaitos.fi
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
