In {bit64}, we overhauled our seq() method in the development version. This wound up subtly breaking {nanotime} because previously we had by <- as.integer64(by) and had dropped that during refactoring if is.integer64(by), which is TRUE for nanoduration.
See r-lib/bit64#297 and r-lib/bit64#299. (TBC: this will not affect the CRAN status of {nanotime} and has been fixed in devel)
It did make me pause and wonder if {nanotime} should also do something here; there is a / method for (nanoduration, integer64), after all:
|
##' @rdname nanoduration |
|
setMethod("/", c("nanoduration", "integer64"), |
|
function(e1, e2) { |
|
new("nanoduration", as.integer64(S3Part(e1, strictS3=TRUE) / e2)) |
|
}) |
E.g., even after stitching up seq(), we still get the error from doing something equivalent directly:
as.integer64(2^32L) / as.nanoduration("00:00:01")
# Error in as.integer64(2^32L)/as.nanoduration("00:00:01") :
# invalid operand types
as.integer64(2^32L) / as.integer64(as.nanoduration("00:00:01"))
# [1] 4.294967
I don't have enough context to proceed, though, so I'm pausing here to file the issue & check your preference. Happy to file any preferred PR, of course.
In {bit64}, we overhauled our
seq()method in the development version. This wound up subtly breaking {nanotime} because previously we hadby <- as.integer64(by)and had dropped that during refactoring ifis.integer64(by), which isTRUEfornanoduration.See r-lib/bit64#297 and r-lib/bit64#299. (TBC: this will not affect the CRAN status of {nanotime} and has been fixed in devel)
It did make me pause and wonder if {nanotime} should also do something here; there is a
/method for(nanoduration, integer64), after all:nanotime/R/nanoduration.R
Lines 444 to 448 in e2486c4
E.g., even after stitching up
seq(), we still get the error from doing something equivalent directly:I don't have enough context to proceed, though, so I'm pausing here to file the issue & check your preference. Happy to file any preferred PR, of course.