Re: CRAN package slider
>>>>> Kurt Hornik
>>>>> on Wed, 9 Nov 2022 12:17:00 +0100 writes:
>>>>> Davis Vaughan writes:
> Many thanks for your detective work.
> Turns out that this is actually already fixed in R-patched.
> Martin: can you perhaps quickly identify the patch which fixes this?
Hmm... I don't think it's fixed in R-patched.
I see (in my version of R-patched which is very rarely *not* up-to-date):
> x$mon <- c(0L, NA)
> x
[1] "2019-01-30 UTC" NA
> as.Date(x)
[1] "2019-01-30" "1970-01-01"
> R.version.string
[1] "R version 4.2.2 Patched (2022-11-06 r83308)"
>
If I am right and this is *not* yet ported to R 4.2.2 patched,
I do agree that we should port the patch / fix the problem for
R 4.2.2 patched.
I don't have time for more for the next couple of hours.
Martin
> Dirk: could you perhaps consider to apply that patch and redo the Debian
> 4.2.2 packages?
> Best
> -k
>> One last thing. I have confirmed that this was a bug that was introduced in
>> R 4.2.2, but has since been patched in R-devel.
>> Is that something that can be fixed in R 4.2.2 Patched (I'm not sure how
>> that works)?
>> ```
>> x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
>> x
>> #> [1] "2019-01-30 UTC" "2019-01-31 UTC"
>> # Make the 2nd element NA by setting one of the fields to NA
>> x$mon <- c(0L, NA)
>> x
>> #> [1] "2019-01-30 UTC" NA
>> # R 4.2.1
>> as.Date(x)
>> #> [1] "2019-01-30" NA
>> # R 4.2.2
>> as.Date(x)
>> #> [1] "2019-01-30" "1970-01-01"
>> # R-devel, 2022-11-07 r83308
>> as.Date(x)
>> #> [1] "2019-01-30" NA
>> ```
>> This has practical implications for lubridate users that update to R 4.2.2
>> but stay on lubridate 1.8.0, as this code no longer works. Luckily we can
>> tell users to just update to lubridate 1.9.0 if they have issues, which
>> works on all the R versions in question:
>> ```
>> library(lubridate)
>> i <- as.Date("2019-01-30")
>> i
>> #> [1] "2019-01-30"
>> # R 4.2.2, lubridate 1.8.0
>> i + months(1)
>> #> [1] "1970-01-30"
>> # R 4.2.2, lubridate 1.9.0 (the NA is correct behavior)
>> i + months(1)
>> #> [1] NA
>> ```
>> Thanks all,
>> Davis
>> On Tue, Nov 8, 2022 at 6:04 PM Davis Vaughan <davis@posit.co> wrote:
>>> Oh, and just as I send this I think I have figured it out!
>>>
>>> I'm seeing this on the debian log:
>>>
>>> ```
>>> Setting up r-cran-lubridate (1.8.0+dfsg-1+b1) ..
>>> ```
>>>
>>> Meaning that Debian is installing a version of lubridate that is
>>> technically out of date now, as lubridate 1.9.0 landed on CRAN 2 days ago
>>> (I assume CRAN is also installing an outdated version).
>>>
>>> If you run my lubridate reprex from above with:
>>> - rocker/r-base image with released R 4.2.2 (2022-10-31)
>>> - lubridate 1.8.0
>>>
>>> then you get:
>>>
>>> ```
>>> library(lubridate)
>>> i <- as.Date("2019-01-30") + months(-3:0)
>>> i + months(1)
>>> #> [1] "2018-11-30" "2018-12-30" "2019-01-30" "1970-01-30"
>>> ```
>>>
>>> which clearly isn't right in that 4th slot, it should be `NA`.
>>>
>>> This has to do with this R-devel bug which I thought was fixed before
>>> 4.2.2 went out? But it seems like I can reproduce this in R 4.2.2 which
>>> makes me think somehow it slipped through:
>>>
>>> ```
>>> x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
>>> x
>>> #> [1] "2019-01-30 UTC" "2019-01-31 UTC"
>>>
>>> # Looks like NA in the 2nd slot
>>> x$mon <- c(0L, NA)
>>> x
>>> #> [1] "2019-01-30 UTC" NA
>>>
>>> # But this borks it completely!
>>> as.Date(x)
>>> #> [1] "2019-01-30" "1970-01-01"
>>> ```
>>>
>>> I can't reproduce this in R-devel 2022-11-07 r83308, the `as.Date()` call
>>> there correctly gives me `NA` in the 2nd slot.
>>>
>>> lubridate happened to switch to using timechange as a backend in the last
>>> release, and it probably changes the internal code in such a way that it
>>> now happens to avoid this bug, which is why we don't see it on R 4.2.2 with
>>> lubridate 1.9.0.
>>>
>>> So I think CRAN and Debian just need to rerun these checks with lubridate
>>> 1.9.0, and in the meantime I will go ahead and send in a patch release of
>>> slider to fix the strict-prototype warnings.
>>>
>>> -Davis
>>>
>>> On Tue, Nov 8, 2022 at 5:30 PM Davis Vaughan <davis@posit.co> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I fixed the strict-prototypes warnings here
>>>> https://github.com/DavisVaughan/slider/pull/175
>>>> (BTW, did you see Lionel's message about this on r-package-devel?
>>>> https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008589.html)
>>>>
>>>> I have slider ready to go, but can't reproduce the issues seen on the
>>>> CRAN machines and on the Debian autopkgtest. I've tried a number of things,
>>>> including:
>>>>
>>>> - Using the rocker/r-base image with released R 4.2.2 (2022-10-31), where
>>>> I tried to run tests on the slider_0.2.2.tar.gz downloaded from CRAN with R
>>>> CMD check and on the actual source code of slider pulled from GitHub with
>>>> devtools::check()
>>>> - Submitting slider to win-devel, where it comes back clean
>>>> - Checking it locally on my own Mac, of course, with various versions of
>>>> R including the exact r83217 revision it seems to be failing with on CRAN
>>>>
>>>> Those tests should have errored earlier in
>>>> `check_endpoints_cannot_be_na()` where a missing value check is run, but
>>>> somehow it is bypassed and is then erroring on the next check, which checks
>>>> that all values are in ascending order. So my guess is that it has
>>>> something to do with lubridate and this month addition, which should always
>>>> result in a missing value in the 4th element, but that must not be the case
>>>> somehow (here are the expected results):
>>>>
>>>> ```
>>>> library(lubridate)
>>>> i <- as.Date("2019-01-30") + months(-3:0)
>>>> i + months(1)
>>>> #> [1] "2018-11-30" "2018-12-30" "2019-01-30" NA
>>>> ```
>>>>
>>>> If anyone can reproduce the test failures themselves, I'd be grateful if
>>>> you could help me figure out what I might be missing here. I'm very
>>>> motivated to try and get this fixed for CRAN.
>>>>
>>>> -Davis
>>>>
>>>> On Tue, Nov 8, 2022 at 6:30 AM Kurt Hornik <Kurt.Hornik@wu.ac.at> wrote:
>>>>
>>>>> Davis,
>>>>>
>>>>> Please see
>>>>>
>>>>> <https://cran.r-project.org/web/checks/check_results_slider.html>
>>>>>
>>>>> Unfortunately, in addition to the new strict-prototypes compilation
>>>>> warnings in r-devel we also have test ERRORs for the Debian r-patched
>>>>> and r-release checks, which also materialize in the autopkgtest checks
>>>>> for the r-cran-slider package and thus currently prevent the migration
>>>>> of the new R 4.2.2 Debian packages from unstable to testing, see
>>>>>
>>>>> <https://tracker.debian.org/pkg/r-base>
>>>>>
>>>>> My hope is that this can be overridden quickly to get the Debian
>>>>> packages migrated to testing, but in any case, can you please fix the
>>>>> ERRORs (and ideally also the compilation warnings) as quickly as
>>>>> possible?
>>>>>
>>>>> Best
>>>>> -k
>>>>>
>>>>
>> [[alternative HTML version deleted]]
Reply to: