[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