Re: [Rd] `@<-` modify its argument when slot is externalptr

[Lukas Stadler]

> On 18.03.2018, at 15:54, luke-tier...@uiowa.edu wrote:
> 
> x <- setClass("foo", slots = "bar")
> x <- new("foo", bar = 1)
> y <- x
> y@bar
> ##  [1] 1
> `@<-`(x, bar, 2)
> y@bar
> ##  [1] 2
> 
> Will be fixed soon in R-devel.
> 

I always assumed that this behavior is intentional, in order to make S4 
"initialize" work efficiently.

- Lukas
[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] formatting raw vectors with names

[Lukas Stadler]

I think there’s a bug concerning the formatting of raw vectors with names:

> structure(as.raw(1:3), .Names = c("a", "", "c"))
   a c 
01 02 03 
> structure(1:3, .Names = c("a", "", "c"))
   a c 
   123 

The problem is that EncodeRaw does not honor the requested width, in fact it 
doesn’t even get the width as a parameter.
An easy fix would be to change:

static void printNamedRawVector(Rbyte * x, int n, SEXP * names)
PRINT_N_VECTOR(formatRaw(x, n, ),
   Rprintf("%s%*s", EncodeRaw(x[k], ""), R_print.gap,""))

to

static void printNamedRawVector(Rbyte * x, int n, SEXP * names)
PRINT_N_VECTOR(formatRaw(x, n, ),
   Rprintf("%*s%s%*s", w - 2, "", EncodeRaw(x[k], ""), 
R_print.gap,""))

in printvector.c:314.

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Extreme bunching of random values from runif with Mersenne-Twister seed

[Lukas Stadler]

If I interpret the original message as “I think there’s something wrong with 
R's random number generator”:
Your assumption is that going from the seed to the first random number is a 
good hash function, which it isn’t.
E.g., with Mersenne Twister it’s a couple of multiplications, bit shifts, xors 
and ands, and the few bits that vary in your seed end up in the less 
significant bits of the result.
Something like the “digest” package might be what you want, it provides proper 
hash functions.

- Lukas

> On 3 Nov 2017, at 10:39, Martin Maechler  wrote:
> 
>> Tirthankar Chakravarty 
>>on Fri, 3 Nov 2017 13:19:12 +0530 writes:
> 
>> This is cross-posted from SO
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_q_47079702_1414455=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=sySSOv_y4gUrdhItlSw7q2z3RRR8JsPrnS8RhIHA9W4=mDEuT7697Im9mtm3dqOQF3Abpcn1ZsA1E_sZE-PZIGg=qm177vnypIq1tc3Km5gwocAEmlwieB9pD5jkClG0I-U=),
>>  but I now
>> feel that this needs someone from R-Devel to help
>> understand why this is happening.
> 
> Why R-devel -- R-help would have been appropriate:
> 
> It seems you have not read the help page for
> set.seed as I expect it from posters to R-devel. 
> Why would you use strings instead of integers if you *had* read it ?
> 
>> We are facing a weird situation in our code when using R's
>> [`runif`][1] and setting seed with `set.seed` with the
>> `kind = NULL` option (which resolves, unless I am
>> mistaken, to `kind = "default"`; the default being
>> `"Mersenne-Twister"`).
> 
> again this is not what the help page says; rather
> 
> | The use of ‘kind = NULL’ or ‘normal.kind = NULL’ in ‘RNGkind’ or
> | ‘set.seed’ selects the currently-used generator (including that
> | used in the previous session if the workspace has been restored):
> | if no generator has been used it selects ‘"default"’.
> 
> but as you have > 90 (!!) packages in your sessionInfo() below,
> why should we (or you) know if some of the things you did
> before or (implicitly) during loading all these packages did not
> change the RNG kind ?
> 
>> We set the seed using (8 digit) unique IDs generated by an
>> upstream system, before calling `runif`:
> 
>>seeds = c( "86548915", "86551615", "86566163",
>> "86577411", "86584144", "86584272", "86620568",
>> "86724613", "86756002", "86768593", "86772411",
>> "86781516", "86794389", "86805854", "86814600",
>> "86835092", "86874179", "86876466", "86901193",
>> "86987847", "86988080")
> 
>> random_values = sapply(seeds, function(x) {
>>  set.seed(x)
>>  y = runif(1, 17, 26)
>>  return(y)
>> })
> 
> Why do you do that?
> 
> 1) You should set the seed *once*, not multiple times in one simulation.
> 
> 2) Assuming that your strings are correctly translated to integers
>   and the same on all platforms, independent of locales (!) etc,
>   you are again not following the simple instruction on the help page:
> 
> ‘set.seed’ uses a single integer argument to set as many seeds as
> are required.  It is intended as a simple way to get quite
> different seeds by specifying small integer arguments, and also as
> .
> .
> 
> Note:   ** small ** integer 
> Why do you assume   86901193  to be a small integer ?
> 
>> This gives values that are **extremely** bunched together.
> 
>>> summary(random_values)
>>   Min. 1st Qu.  Median Mean 3rd Qu.  Max.  25.13
>> 25.36 25.66 25.58 25.83 25.94
> 
>> This behaviour of `runif` goes away when we use `kind =
>> "Knuth-TAOCP-2002"`, and we get values that appear to be
>> much more evenly spread out.
> 
>>random_values = sapply(seeds, function(x) {
>> set.seed(x, kind = "Knuth-TAOCP-2002") y = runif(1, 17,
>> 26) return(y) })
> 
>> *Output omitted.*
> 
>> ---
> 
>> **The most interesting thing here is that this does not
>> happen on Windows -- only happens on Ubuntu**
>> (`sessionInfo` output for Ubuntu & Windows below).
> 
>> # Windows output: #
> 
>>> seeds = c(
>>+ "86548915", "86551615", "86566163", "86577411",
>> "86584144", + "86584272", "86620568", "86724613",
>> "86756002", "86768593", "86772411", + "86781516",
>> "86794389", "86805854", "86814600", "86835092",
>> "86874179", + "86876466", "86901193", "86987847",
>> "86988080")
>>> 
>>> random_values = sapply(seeds, function(x) {
>>+ set.seed(x) + y = runif(1, 17, 26) + return(y) + })
>>> 
>>> summary(random_values)
>>   Min. 1st Qu.  Median Mean 3rd Qu.  Max.  17.32
>> 20.14 23.00 22.17 24.07 25.90
> 
>> Can someone help understand what is going on?
> 
>> Ubuntu
>> --
> 
>> R version 3.4.0 (2017-04-21)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 16.04.2 LTS
> 
> You have not learned to get a current version of R.
> ===> You should not write to R-devel (sorry if this may sound harsh ..)
> 
> Hint:
>   We know that  Ubuntu LTS -- by its virtue of LTS (Long Time
>   Support) will not update R.
>   But the Ubuntu/Debian pages on CRAN tell 

[Rd] range function with finite=T and logical parameters

[Lukas Stadler]

Hi!

I was wondering about the behavior of the range function wrt. logical NAs:

> range(c(0L, 1L, NA), finite=T)
[1] 0 1
> range(c(F, T, NA), finite=T)
[1] NA NA

The documentation is quite clear that "finite = TRUE includes na.rm = TRUE”, so 
that I would have assumed that these two snippets would produce the same result.

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] calling R API functions after engine shutdown

[Lukas Stadler]

If this is not considered to be safe, then I guess my message can be seen as a 
heads-up:
If R_ReleaseObject ever does something that is not safe after the R engine has 
shut down, you will start to see crashes from packages like “minqa”.
In FastR, we ended up adding a global flag that disables parts of the native 
API because of this.

- Lukas

> On 21 Sep 2017, at 17:53, Tomas Kalibera <tomas.kalib...@gmail.com> wrote:
> 
> 
> Calling R_ReleaseObject in a C++ destructor is not reliable - it can be 
> bypassed by a non-local return, such as an error. Generally in R one cannot 
> use C++ destructors reliably for anything that the R runtime wouldn't do on 
> its own in case of a non-local return.
> 
> A destructor that calls just UNPROTECT, in a way that balances out the 
> protection stack (e.g. Rcpp Shield), is safe because R runtime balances the 
> protection stack on non-local return. Destructors used in code that will 
> never call into any R API (such as in a third party library) are safe, 
> because the R runtime could not do non-local return. All other destructors 
> are a problem.
> 
> UNPROTECT will work even during R shutdown.
> 
> In some cases cleanup code that would be put in C++ destructors, if they were 
> safe with R, can instead be put into R finalizers.
> 
> Tomas
> 
> 
> 
> On 09/21/2017 04:41 PM, Lukas Stadler wrote:
>> Hi!
>> 
>> We’ve recently come across an example where a package (minqa) creates an 
>> Rcpp Function object in a static variable.
>> This causes R_ReleaseObject to be called by the destructor at a very late 
>> point in time - as part of the system exit function:
>> 
>> static Function cf("c");
>> 
>> I’m wondering if that is considered to be “safe”?
>> Is the R engine supposed to stay in a state where calls to API functions are 
>> valid, even after it has shut down?
>> It probably only ever happens with the ReleaseObject function, but even that 
>> could cause problems, e.g., with more elaborate refcounting schemes.
>> 
>> - Lukas
>> __
>> R-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=6DzVcyWX6yyD2r4eAolUQDWVUN_xc9UW6UdTto2_bao=YltTQ4tUmVFt23AnHzDGTPVCXmlUiOq1ayKJzhavePU=qibOCsqERij4Ymssp_hIfB78JDOA8v0jSYJ7ZTnCNO4=
>>  
> 
> 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] logic ops with zero-extent raw vectors

[Lukas Stadler]

Hi,

there was a change concerning logical operations about a year ago:
https://github.com/wch/r-source/commit/9e19d3e3dd5f657b5cfefe562bdd7ede2e2b8786
It's related to a discussion on this list:
https://hypatia.math.ethz.ch/pipermail/r-devel/2016-September/073068.html 


A change in logic.c:134 influences the result type of operations on zero-extent 
raw vectors.
Old behavior:
> raw(1) & raw(1)
[1] 00
> raw(0) & raw(0)
raw(0)
New behavior:
> raw(1) & raw(1)
[1] 00
> raw(0) & raw(0)
logical(0)

I'm wondering whether the logical result type was intentional, because, to me, 
the old behavior seems more consistent.

Best,
 Lukas
[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] calling R API functions after engine shutdown

[Lukas Stadler]

Hi!

We’ve recently come across an example where a package (minqa) creates an Rcpp 
Function object in a static variable.
This causes R_ReleaseObject to be called by the destructor at a very late point 
in time - as part of the system exit function:

static Function cf("c");

I’m wondering if that is considered to be “safe”?
Is the R engine supposed to stay in a state where calls to API functions are 
valid, even after it has shut down?
It probably only ever happens with the ReleaseObject function, but even that 
could cause problems, e.g., with more elaborate refcounting schemes.

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] loop compilation problem

[Lukas Stadler]

Hi!

We’ve seen a problem with the compiler in specific cases of matrix updates:

> { m <- matrix(1:4, 2) ; z <- 0; for(i in 1) { m[z <- z + 1,z <- z + 1] <- 99; 
> } ; m }
 [,1] [,2]
[1,]13
[2,]2   99

Here, it modifies element [2,2], which is unexpected.
It behaves correct without the loop:

> { m <- matrix(1:4, 2) ; z <- 0; m[z <- z + 1,z <- z + 1] <- 99 ; m }
 [,1] [,2]
[1,]1   99
[2,]24

… and without the jit:

> enableJIT(0)
[1] 3
> { m <- matrix(1:4, 2) ; z <- 0; for(i in 1) { m[z <- z + 1,z <- z + 1] <- 99; 
> } ; m }
 [,1] [,2]
[1,]1   99
[2,]24

I checked with "R Under development (unstable) (2017-08-23 r73116)”, and the 
problem is still there.

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] RIOT 2017

[Lukas Stadler]

I hope you don’t mind us using this mailing list for a small advertisement, but 
we think it is most relevant for this group:

We'd like to invite you to RIOT 2017 - the 3rd workshop on R Implementation, 
Optimization and Tooling [1].
It will take place co-located with, and during, useR! 2017 in Brussels on July 
5th.
RIOT is an excellent venue for deep technical discussions about R 
implementations, tools, optimizations and extension, and will be very 
interesting for anyone interested in what’s under the hood of R implementations.

Regards,
Lukas Stadler (Oracle), Jan Vitek (Northeastern), Alexander Bertram 
(BeDataDriven)

[1] http://riotworkshop.github.io/ <http://riotworkshop.github.io/>
[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] `[` not recognized as a primitive in certain cases.

[Lukas Stadler]

“typeof” is your friend here:

> typeof(`[`)
[1] "special"
> typeof(mc[[1]])
[1] "symbol"
> typeof(mc2[[1]])
[1] "special"

so mc[[1]] is a symbol, and thus not a primitive.

- Lukas

> On 28 Mar 2017, at 14:46, Michael Lawrence  wrote:
> 
> There is a difference between the symbol and the function (primitive
> or closure) to which it is bound.
> 
> This:
> mc2 <- as.call(list(`[`,iris,2,"Species"))
> 
> Evaluates `[` to its value, in this case the primitive object, and the
> primitive itself is incorporated into the returned call.
> 
> If you were to do this:
> mc2 <- as.call(list(quote(`[`),iris,2,"Species"))
> 
> The `[` would _not_ be evaluated, quote() would return the symbol, and
> the symbol would end up in the call.
> 
> The two forms have virtually identical behavior as long as the call
> ends up getting evaluated in the same environment.
> 
> On Tue, Mar 28, 2017 at 3:03 AM, Joris Meys  wrote:
>> Dear,
>> 
>> I have noticed this problem while looking at the following question on
>> Stackoverflow :
>> 
>> http://stackoverflow.com/questions/42894213/s4-class-subset-inheritance-with-additional-arguments
>> 
>> While going through callNextMethod, I've noticed the following odd
>> behaviour:
>> 
>> mc <- call("[",iris,2,"Species")
>> 
>> mc[[1]]
>> ## `[`
>> 
>> is.primitive(`[`)
>> ## [1] TRUE
>> 
>> is.primitive(mc[[1]])
>> ## [1] FALSE
>> # Expected to be TRUE
>> 
>> mc2 <- as.call(list(`[`,iris,2,"Species"))
>> 
>> is.primitive(mc2[[1]])
>> ## [1] TRUE
>> 
>> So depending on how I construct the call (using call() or as.call() ), the
>> function `[` is or is not recognized as a primitive by is.primitive()
>> 
>> The behaviour is counterintuitive and -unless I miss something obvious
>> here- likely to be a bug imho. I immediately admit that my C chops aren't
>> sufficient to come up with a patch.
>> 
>> Cheers
>> Joris
>> 
>> --
>> Joris Meys
>> Statistical consultant
>> 
>> Ghent University
>> Faculty of Bioscience Engineering
>> Department of Mathematical Modelling, Statistics and Bio-Informatics
>> 
>> tel :  +32 (0)9 264 61 79
>> joris.m...@ugent.be
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>> 
>>[[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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] NaN behavior of cumsum

[Lukas Stadler]

Hi!

I noticed that cumsum behaves different than the other cumulative functions 
wrt. NaN values:
> values <- c(1,2,NaN,1)
> for ( f in c(cumsum, cumprod, cummin, cummax)) print(f(values))
[1]  1  3 NA NA
[1]   1   2 NaN NaN
[1]   1   1 NaN NaN
[1]   1   2 NaN NaN

The reason is that cumsum (in cum.c:33) contains an explicit check for ISNAN.
Is that intentional?
IMHO, ISNA would be better (because it would make the behavior consistent with 
the other functions).

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] .Internal for functions in distn.R

[Lukas Stadler]

Hi,

the functions in distn.R were converted from .Internal to .External ([1], in 
2012), and to .Call ([2], in 2014).
They are still listed as .Internal in names.c, although they are not used in 
that way.

Shouldn’t they be removed?
There’s quite some simplification to be had, e.g., do_math3 could go away and 
do_math2 would be simpler.

If that makes sense (I may be missing something?), I’d be happy to create a 
patch that does this.

Best,
 Lukas

[1] 
https://github.com/wch/r-source/commit/e430853d37cda69505e7452ddceb06a2008821d2 

[2] 
https://github.com/wch/r-source/commit/34fa67ca4c1dae13ed6a2ad74af7dbb27c8f3cb2 

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] integerOneIndex/get1index/... in vector access error messages

[Lukas Stadler]

Hi!

We noticed that these error messages were changed to include the name of the 
function that causes them:
> { x<-c(1,2); x[[c("a", "b")]] }
old: “Error in x[[c("a", "b")]] : attempt to select more than one element”
new: “Error in x[[c("a", "b")]] : attempt to select more than one element in 
vectorIndex”

This is the relevant change:
https://github.com/wch/r-source/commit/5d6c765bf8b97bf872f760d06622850f43696d8b

I don’t think that a user of R is supposed to know the difference between, 
e.g., integerOneIndex and get1index, so this will confuse, rather than help, a 
user while diagnosing problems.
To be honest, this looks to me like leftover debug code...

In FastR, we try to adhere as closely as possible to GNUR in which errors are 
returned when.
Do you think that providing these “in Xyz” suffixes is important?

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Evolution of the R native interface

[Lukas Stadler]

Hi!

I hope you don’t mind me posting this call for participation - I do think the 
matter at hand is very important for the people on this list, and the people on 
this list are very important for the matter at hand.

For historical reasons, the native API provided by R for use by applications 
and packages is not as concise and consistent as is could be, and is tied into 
the internals of the implementation of the language. This makes writing native 
code components more complex than necessary, and thus increases the entry 
barrier for writing applications and packages. It also hinders evolution of the 
R runtime, because it restricts the freedom to change internal implementation 
details, and prevents alternative implementations from supporting all R 
applications and packages.

The R consortium’s infrastructure steering committee (ISC) recently decided to 
create a working group that intends to explore the future of R’s native APIs 
[1]:
“Future-proof native APIs for R: This working groups will assess current native 
API usage, gather community input, and work towards an easy-to-understand, 
consistent and verifiable API that will drive R language adoption.”

In order to do so, we are hoping to create a diverse group, inviting different 
stakeholders:
people working on the core of the R implementation and package system
R package authors and maintainers
developers of alternative implementations of the R language
people interested in R’s development for various other reasons

We’d like to answer questions like:
API evolution or API revolution?
should there be one interface covering all use cases, or multiple targeted 
interfaces?
what are the basic design principles behind the new API?
how can adoption of such an interface work?

Please let me know whether you’re interested in this - we would be glad if some 
of you would join this effort and participate in the working group.

The working group will operate via email [2], a wiki page [3] and 
teleconferences.
We also plan to have an in-person meeting at this year’s useR! conference.

Also, if you have someone in mind that should be part of the working group, 
please let us know. We may not have thought of them yet.

Best Regards,
 Lukas Stadler

[1] 
https://www.r-consortium.org/news/announcement/2016/03/r-consortium-funds-technical-initiatives-community-events-and-training
 
<https://www.r-consortium.org/news/announcement/2016/03/r-consortium-funds-technical-initiatives-community-events-and-training>
[2] http://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api 
<http://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api>
[3] https://wiki.r-consortium.org/view/R_Native_API 
<https://wiki.r-consortium.org/view/R_Native_API>


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] formatting of complex matrix

[Lukas Stadler]

While working on the printing code, my colleague Zbyněk Šlajchrt noticed that 
complex matrixes are sometimes misaligned:

> { matrix(1i,2,13) }
 [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10] [,11] [,12] [,13]
[1,] 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i
[2,] 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i

(the values in the last four columns should be prefixed by two spaces instead 
of one)
while the formatting is fine, e.g., for real values:

> { matrix(1,2,13) }
 [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10] [,11] [,12] [,13]
[1,]111111111 1 1 1 1
[2,]111111111 1 1 1 1

The problem seems to be in printarray.c:275 
(https://github.com/wch/r-source/blob/trunk/src/main/printarray.c#L275):
EncodeComplex(x[i + j * r],
wr[j] + R_print.gap, dr[j], er[j],
wi[j], di[j], ei[j], OutDec)) )

The width of the real part wr[j] + the width of the imaginary part wi[j] + 
R_print.gap doesn’t always add up to the width of the column w[j].

As far as we can see, calculating the width of the real part on the fly fixes 
the problem:
EncodeComplex(x[i + j * r],
w[j] - wi[j] - 2, dr[j], er[j],
wi[j], di[j], ei[j], OutDec)) )

Regards,
 Lukas
[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Help with libiconv problem

[Lukas Stadler]

> On 15 Mar 2016, at 0:04, Mick Jordan  wrote:
> 
> On 3/14/16 1:49 PM, Mick Jordan wrote:
>> A couple of my colleagues are having problems building R-3.2.4 on Mac OS X 
>> El Capitan somehow related to libiconv. I personally don't have any problems 
>> on either of my Macs. I'm hoping thie make log might trigger something in 
>> the readers of this list:
>> 
>> gcc -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup 
>> -single_module -multiply_defined suppress -L../../../../lib -L/usr/local/lib 
>> -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o 
>> gramLatex.o gramRd.o -L../../../../lib -lR -Wl,-framework -Wl,CoreFoundation
>> mkdir ../../../../library/tools/libs
>> installing 'sysdata.rda'
>> Warning messages:
>> 1: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") :
>>  unknown timezone 'America/Los_Angeles'
>> 2: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") :
>>  unknown timezone 'GMT'
>> 3: In strptime(paste(.leap.seconds, "23:59:60"), "%Y-%m-%d %H:%M:%S") :
>>  unknown timezone 'America/New_York'
>> dyld: lazy symbol binding failed: Symbol not found: _libiconv_open
>>  Referenced from: 
>> /Users/someone/work/abc/fastr/com.oracle.truffle.r.native/gnur/R-3.2.4/lib/libR.dylib
>>  Expected in: flat namespace
>> 
>> dyld: Symbol not found: _libiconv_open
>>  Referenced from: 
>> /Users/someone/work/abc/fastr/com.oracle.truffle.r.native/gnur/R-3.2.4/lib/libR.dylib
>>  Expected in: flat namespace
>> 
>> /bin/sh: line 1: 16127 Doneecho 
>> "tools:::sysdata2LazyLoadDB(\"./R/sysdata.rda\",\"../../../library/tools/R\")"
>> 16128 Trace/BPT trap: 5   | R_DEFAULT_PACKAGES=NULL LC_ALL=C 
>> ../../../bin/R --vanilla --slave
>> make[7]: *** [sysdata] Error 133
>> make[6]: *** [all] Error 2
>> make[5]: *** [R] Error 1
>> make[4]: *** [R] Error 1
>> make[3]: *** [R] Error 1
>> 
> This seems to be related to having a macports install of libiconv. The 
> compile step for sysutils.c puts the macport include header before 
> /usr/local/include but the link step for libR doesn't - in fact it doesn't 
> include a -L for the macport directory at all. So there is an an 
> inconsistency in the expected symbols. (Why the macport version defines 
> libiconv_open instead of iconv_open I have no idea).

FWIW, the workaround we now use is to specify -DLIBICONV_PLUG, because then all 
libiconv variations behave the same.

- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Regression in strptime

[Lukas Stadler]

Hi!

Some context for the tests Mick mentioned:
Our tests, which are part of the open-source FastR repository, consist of small 
executable R snippets.
While working on FastR, we test regularly by comparing the output generated 
when running them on FastR and GNUR.
Every difference hints at a problem in our implementation of the R language.

FastR, along with the tests, is based on a specific version or R, and every 
once in a while, we update this R version - we recently went from 3.1.3 to 
3.2.4.
This is a complex process: we implement new builtins, modify and update tests, 
etc.
During that process we need to investigate any new differences that appear, and 
that’s how the strptime issue came to our attention.

These tests could theoretically also be used to detect changes in behavior 
between R versions.
It’s not that easy, though, since the output will differ depending on operating 
systems, compilers, and configuration details.
For FastR, we actually had to choose an platform with which we want to be 
consistent, because Java, with a tighter spec than C, does not have the same 
variations.

The set of tests can be seen in this file (which is autogenerated from our 
junit tests):
https://raw.githubusercontent.com/graalvm/fastr/master/com.oracle.truffle.r.test/src/com/oracle/truffle/r/test/ExpectedTestOutput.test
It’s ~20k individual tests, partly written by hand, partly generated 
algorithmically, and partly generated by the testR project.

I’ve attached a small script that I just hacked together that runs these tests 
- it could easily be adapted to compare the output of two different R 
installations.
Do you think this could be turned into a tool useful for R core development?

- Lukas


> On 15 Mar 2016, at 11:52, Martin Maechler  wrote:
> 
>> peter dalgaard 
>>on Sat, 12 Mar 2016 19:11:40 +0100 writes:
> 
>> OK, .Internal is not necessary to reproduce oddity in this area. I also see 
>> things like (notice 1980)
>>> strptime(paste0(sample(1900:1999,80,replace=TRUE),"/01/01"), "%Y/%m/%d", 
>>> tz="CET")
>...
> 
>> The issue seems to be present in R-devel but not in (CRAN) 3.2.0
> 
> nor in R 3.2.3 (and earlier), but indeed unfortunately in 3.2.4.
> 
> This has been fixed now in  "R 3.2.4 patched"  (and R-devel of course).
> Thank you Mick, for the report...
> ...
> ...
> though I "must" add: If you do have your own tests / checks (as
> you said in the OP) and are company as big as Oracle using the
> free (in the full sense of "speech" *and* "beer") software R, 
> it would be *really* *really* courteous if you did run your test
> suite when we announce and release betas or release candidates
> ("RC") (and in the case of the upcoming yearly release in April,
> even "alphas" before them) so we, the R community and the R core
> developers could find bugs *before* release. 
> 
> Thank you -- and others, please! -- in advance for doing it next time, i.e.,
> *now*: The R web page  https://www.r-project.org/  (for a few weeks) has the 
> news
> 
> o  R version 3.3.0 (Supposedly Educational) prerelease versions will appear 
> starting Monday 2016-03-14. Final release is scheduled for Thursday 
> 2016-04-14.
> 
> Martin Maechler
> ETH Zurich (and R Core team)
> 
> 
> 
>>> On 12 Mar 2016, at 17:43 , Mick Jordan  wrote:
>>> 
>>> On 3/12/16 12:33 AM, peter dalgaard wrote:
> On 12 Mar 2016, at 00:05 , Mick Jordan  wrote:
> 
> This is definitely obscure but we had a unit test that called 
> .Internal(strptime, "1942/01/01", %Y/%m/%d") with timezone (TZ) set to 
> CET.
 Umm, that doesn't even parse. And fixing the typo, it doesn't run:
 
> .Internal(strptime, "1942/01/01", %Y/%m/%d")
 Error: unexpected SPECIAL in ".Internal(strptime, "1942/01/01", %Y/%"
> .Internal(strptime, "1942/01/01", "%Y/%m/%d")
 Error in .Internal(strptime, "1942/01/01", "%Y/%m/%d") :
 3 arguments passed to '.Internal' which requires 1
 
 
 
> In R-3.1.3 that returned "1942-01-01 CEST" which, paradoxically, is 
> correct as they evidently did strange things in Germany during the war 
> period. Java also returns the same. However, R-3.2.4 returns "1942-01-01 
> CET".
 Did you mean:
 
 pd$ r-release-branch/BUILD-dist/bin/R
 
 R version 3.2.4 Patched (2016-03-10 r70319) -- "Very Secure Dishes"
 Copyright (C) 2016 The R Foundation for Statistical Computing
 Platform: x86_64-apple-darwin13.4.0/x86_64 (64-bit)
 [...]
> strptime("1942/01/01", "%Y/%m/%d", tz="CET")
 [1] "1942-01-01 CEST"
 
 But then as you see, it does have DST on New Years Day.
 
 All in all, there is something you are not telling us.
 
 Notice that all DST information is OS dependent as it depends on which 
 version of the "Olson database" is installed.
 
 
>>> You are correct that I was sloppy with syntax for 

[Rd] deparse with parentheses for SUBSET

[Lukas Stadler]

Hi,

maybe there’s a reason for it, but the discrepancy between the handling of `[` 
and `$` in deparsing seems odd to me:
> substitute(a[1], list(a = quote(x * y)))
x * y[1]
> substitute(a$b, list(a = quote(x * y)))
(x * y)$b

The former is still executed in the right order (`*` first, then `[`), which is 
not what you’d expect looking at the deparse result.
Some code that shows the execution order:
x <- 1; y <- 1; class(y) <- "foo"; `*.foo` <- function(...) -1; expr <- 
substitute(a[1], list(a=quote(x * y))); list(expr=expr, eval=eval(expr), "x * 
y[1]"=x * y[1], "(x * y)[1]"=(x * y)[1])

The following simple fix solves the problem for me:

diff -u -r A/src/main/deparse.c B/src/main/deparse.c
--- R-devel 2/src/main/deparse.c2015-08-09 18:09:04.0 +0200
+++ R-devel/src/main/deparse.c  2016-01-04 16:15:09.0 +0100
@@ -971,7 +971,11 @@
print2buff(")", d);
break;
case PP_SUBSET:
+   if ((parens = needsparens(fop, CAR(s), 1)))
+   print2buff("(", d);
deparse2buff(CAR(s), d);
+   if (parens)
+   print2buff(")", d);
if (PRIMVAL(SYMVALUE(op)) == 1)
print2buff("[", d);
else

With this applied, the output is more consistent:
> substitute(a[1], list(a = quote(x * y)))
(x * y)[1]
> substitute(a$b, list(a = quote(x * y)))
(x * y)$b

Best Regards,
 Lukas Stadler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel