Skip to content

typeof(getOption("warn")) is "integer" instead of "double" in R unstable (2019-09-27 r77229)? Reproducible?

5 messages · @osp@m m@iii@g oii @itieid-im@de, Duncan Murdoch, Tomas Kalibera

Original
@osp@m m@iii@g oii @itieid-im@de
# 
Hi,

I have a failing unit test in my package tryCatchLog on the CRAN build infrastructure
(https://cran.r-project.org/web/checks/check_results_tryCatchLog.html)
with "R Under development (unstable) (2019-09-27 r77229)"
and the unit tests just ensures consistent behaviour of R (not of my package) as a precondition:

The failing unit test is caused by
but it should be
I have no build infrastructure for dev and want to find out if this is caused by
- my mistake
- changes in the R dev version
- the new C compilers used (correlates with the failing unit test)

Can somebody (having the R dev version available) please help me and answer the result of
using "R Under development (unstable) (2019-09-27 r77229)" or newer?

Thanks a lot and sorry for the "noise"!

Jurgen

PS: These R (dev) versions did work as expected (returning "double") but were also using older C compilers:
- R Under development (unstable) (2019-09-20 r77199)
- R Under development (unstable) (2019-09-22 r77202)
- R Under development (unstable) (2019-09-25 r77217)
- R version 3.6.1 Patched (2019-09-25 r77224)
- R version 3.6.1 (2019-07-05)
- R version 3.6.0 beta (2019-04-15 r76395)
- R version 3.5.3 (2019-03-11)
- R version 3.5.2 (2018-12-20)
Duncan Murdoch
#
On 29/09/2019 7:55 a.m., nospam at altfeld-im.de wrote:
This is related to this bug fix:

CHANGES IN R 3.6.1 patched BUG FIXES

     ?options(warn=1e11)? is an error now, instead of later leading to C 
stack overflow because of infinite recursion.

which occurred in rev 77226.  It explicitly coerces the warn value to 
integer.
It is changes in the dev and patched versions, and also your mistake: 
your test shouldn't be so stringent.  The docs don't say that the value 
has to be a double; in fact, they suggest it should be a whole number 
value (talking about 0, 1, "2 or more", not about what would happen with 
options(warn = pi/2), for example.

In older versions, options(warn = pi/2) is treated the same as 
options(warn = 1), and in the new version, it is displayed as 1 as well.

Duncan Murdoch
@osp@m m@iii@g oii @itieid-im@de
# 
Thanks a lot for pointing out the reason
(and yes, I am testing quite to stringent in this case - it's my old testing disease ;-)

For other readers:

The R-devel NEWS is a good source to find possible change reasons:

https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
On Sun, 2019-09-29 at 08:33 -0400, Duncan Murdoch wrote:
Duncan Murdoch
#
On 29/09/2019 12:12 p.m., nospam at altfeld-im.de wrote:
And if you want to follow along, you can get it as an RSS feed from 
<http://developer.r-project.org/RSSfeeds.html>.  If you don't know what 
an RSS feed is, see feedly.com.

Duncan Murdoch
Tomas Kalibera
#
On 9/29/19 6:12 PM, nospam at altfeld-im.de wrote:
Please note that it is not a good practice to test for these things in 
unit tests. Every system has some specified (or "documented" - in R) 
behavior, and then some unspecified. Programs must not depend on the 
unspecified behavior. If your programs do, then they should be fixed not 
to do so. If they do not, then there is no point in testing whether the 
unspecified behavior changed or seems to have changed. Also the 
existence of these tests often wastes time of the people who find out 
when these tests start failing (can be your time, but also CRAN, RCore 
or anyone else's). It is of course a good thing to check inputs in 
functions, e.g. in the actual code that uses an "option", to the point 
that is needed for correct execution of the code, but that neither that 
check nor the code should expect more than what is specified.

Best
Tomas