Re: CRAN package slider
>>>>> Kurt Hornik writes:
Sorry, my fault, comes from doing too many things at once.
Indeed, in r-patched
x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
x$mon <- c(0L, NA)
x
as.Date(x)
still gives
R> as.Date(x)
[1] "2019-01-30" "1970-01-01"
whereas in r-devel it gives
R> as.Date(x)
[1] "2019-01-30" NA
So we need to find the patch and then apply it for r-patched (and maybe
also for the Debian packages).
Best
-k
>>>>> Martin Maechler writes:
> Interesting. I have
> R version 4.2.2 Patched (2022-11-06 r83317) -- "Innocent and Trusting"
> for which
R> x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
R> x$mon <- c(0L, NA)
R> x
> [1] "2019-01-30 UTC" NA
> Hmm ...
> Best
> -k
>>>>> 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: