Re: CRAN package slider
>>>>> 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: