[Rd] range() for Date and POSIXct could respect `finite = TRUE`

[Davis Vaughan via R-devel]

Hi all,

I noticed that `range.default()` has a nice `finite = TRUE` argument,
but it doesn't actually apply to Date or POSIXct due to how
`is.numeric()` works.

```
x <- .Date(c(0, Inf, 1, 2, Inf))
x
#> [1] "1970-01-01" "Inf""1970-01-02" "1970-01-03" "Inf"

# Darn!
range(x, finite = TRUE)
#> [1] "1970-01-01" "Inf"

# What I want
.Date(range(unclass(x), finite = TRUE))
#> [1] "1970-01-01" "1970-01-03"
```

I think `finite = TRUE` would be pretty nice for Dates in particular.

As a motivating example, sometimes you have ranges of dates
represented by start/end pairs. It is fairly natural to represent an
event that hasn't ended yet with an infinite date. If you need to then
compute a sequence of dates spanning the full range of the start/end
pairs, it would be nice to be able to use `range(finite = TRUE)` to do
so:

```
start <- as.Date(c("2019-01-05", "2019-01-10", "2019-01-11", "2019-01-14"))
end <- as.Date(c("2019-01-07", NA, "2019-01-14", NA))
end[is.na(end)] <- Inf

# `end = Inf` means that the event hasn't "ended" yet
data.frame(start, end)
#>startend
#> 1 2019-01-05 2019-01-07
#> 2 2019-01-10Inf
#> 3 2019-01-11 2019-01-14
#> 4 2019-01-14Inf

# Create a full sequence along all days in start/end
range <- .Date(range(unclass(c(start, end)), finite = TRUE))
seq(range[1], range[2], by = 1)
#>  [1] "2019-01-05" "2019-01-06" "2019-01-07" "2019-01-08" "2019-01-09"
#>  [6] "2019-01-10" "2019-01-11" "2019-01-12" "2019-01-13" "2019-01-14"
```

It seems like one option is to create a `range.Date()` method that
unclasses, forwards the arguments on to a second call to `range()`,
and then reclasses?

```
range.Date <- function(x, ..., na.rm = FALSE, finite = FALSE) {
  .Date(range(unclass(x), na.rm = na.rm, finite = finite), oldClass(x))
}
```

This is similar to how `rep.Date()` works.

Thanks,
Davis Vaughan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] range() for Date and POSIXct could respect `finite = TRUE`

[Paul McQuesten]

A tiny nit-pick: Seems to me that end date = NA would mean the event has
not yet ended, whilst Inf would mean that the event is known to never
terminate, ie: an eternal fact, or physical law.

On Fri, Apr 28, 2023 at 10:12 AM Davis Vaughan via R-devel <
r-devel@r-project.org> wrote:

> Hi all,
>
> I noticed that `range.default()` has a nice `finite = TRUE` argument,
> but it doesn't actually apply to Date or POSIXct due to how
> `is.numeric()` works.
>
> ```
> x <- .Date(c(0, Inf, 1, 2, Inf))
> x
> #> [1] "1970-01-01" "Inf""1970-01-02" "1970-01-03" "Inf"
>
> # Darn!
> range(x, finite = TRUE)
> #> [1] "1970-01-01" "Inf"
>
> # What I want
> .Date(range(unclass(x), finite = TRUE))
> #> [1] "1970-01-01" "1970-01-03"
> ```
>
> I think `finite = TRUE` would be pretty nice for Dates in particular.
>
> As a motivating example, sometimes you have ranges of dates
> represented by start/end pairs. It is fairly natural to represent an
> event that hasn't ended yet with an infinite date. If you need to then
> compute a sequence of dates spanning the full range of the start/end
> pairs, it would be nice to be able to use `range(finite = TRUE)` to do
> so:
>
> ```
> start <- as.Date(c("2019-01-05", "2019-01-10", "2019-01-11", "2019-01-14"))
> end <- as.Date(c("2019-01-07", NA, "2019-01-14", NA))
> end[is.na(end)] <- Inf
>
> # `end = Inf` means that the event hasn't "ended" yet
> data.frame(start, end)
> #>startend
> #> 1 2019-01-05 2019-01-07
> #> 2 2019-01-10Inf
> #> 3 2019-01-11 2019-01-14
> #> 4 2019-01-14Inf
>
> # Create a full sequence along all days in start/end
> range <- .Date(range(unclass(c(start, end)), finite = TRUE))
> seq(range[1], range[2], by = 1)
> #>  [1] "2019-01-05" "2019-01-06" "2019-01-07" "2019-01-08" "2019-01-09"
> #>  [6] "2019-01-10" "2019-01-11" "2019-01-12" "2019-01-13" "2019-01-14"
> ```
>
> It seems like one option is to create a `range.Date()` method that
> unclasses, forwards the arguments on to a second call to `range()`,
> and then reclasses?
>
> ```
> range.Date <- function(x, ..., na.rm = FALSE, finite = FALSE) {
>   .Date(range(unclass(x), na.rm = na.rm, finite = finite), oldClass(x))
> }
> ```
>
> This is similar to how `rep.Date()` works.
>
> Thanks,
> Davis Vaughan
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] range() for Date and POSIXct could respect `finite = TRUE`

[Tim Taylor]

A tiny nit-pick nit-pick: I'd take NA to mean the finish date is missing 
and you know neither whether the event has finished or if it has 
finished at all :-)


Either way the proposed method seems sensible.

Tim

On 28/04/2023 16:29, Paul McQuesten wrote:

A tiny nit-pick: Seems to me that end date = NA would mean the event has
not yet ended, whilst Inf would mean that the event is known to never
terminate, ie: an eternal fact, or physical law.

On Fri, Apr 28, 2023 at 10:12 AM Davis Vaughan via R-devel <
r-devel@r-project.org> wrote:


Hi all,

I noticed that `range.default()` has a nice `finite = TRUE` argument,
but it doesn't actually apply to Date or POSIXct due to how
`is.numeric()` works.

```
x <- .Date(c(0, Inf, 1, 2, Inf))
x
#> [1] "1970-01-01" "Inf""1970-01-02" "1970-01-03" "Inf"

# Darn!
range(x, finite = TRUE)
#> [1] "1970-01-01" "Inf"

# What I want
.Date(range(unclass(x), finite = TRUE))
#> [1] "1970-01-01" "1970-01-03"
```

I think `finite = TRUE` would be pretty nice for Dates in particular.

As a motivating example, sometimes you have ranges of dates
represented by start/end pairs. It is fairly natural to represent an
event that hasn't ended yet with an infinite date. If you need to then
compute a sequence of dates spanning the full range of the start/end
pairs, it would be nice to be able to use `range(finite = TRUE)` to do
so:

```
start <- as.Date(c("2019-01-05", "2019-01-10", "2019-01-11", "2019-01-14"))
end <- as.Date(c("2019-01-07", NA, "2019-01-14", NA))
end[is.na(end)] <- Inf

# `end = Inf` means that the event hasn't "ended" yet
data.frame(start, end)
#>startend
#> 1 2019-01-05 2019-01-07
#> 2 2019-01-10Inf
#> 3 2019-01-11 2019-01-14
#> 4 2019-01-14Inf

# Create a full sequence along all days in start/end
range <- .Date(range(unclass(c(start, end)), finite = TRUE))
seq(range[1], range[2], by = 1)
#>  [1] "2019-01-05" "2019-01-06" "2019-01-07" "2019-01-08" "2019-01-09"
#>  [6] "2019-01-10" "2019-01-11" "2019-01-12" "2019-01-13" "2019-01-14"
```

It seems like one option is to create a `range.Date()` method that
unclasses, forwards the arguments on to a second call to `range()`,
and then reclasses?

```
range.Date <- function(x, ..., na.rm = FALSE, finite = FALSE) {
   .Date(range(unclass(x), na.rm = na.rm, finite = finite), oldClass(x))
}
```

This is similar to how `rep.Date()` works.

Thanks,
Davis Vaughan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Karolis Koncevičius]

I was building a package that uses the new generic @ and kept having errors 
with “roxygen2” documentation. “roxygen2” generated NAMESPACE added 
`@.newclass` as a newly exported function, not as a S3method.

At first I thought this must be a bug in roxygen2 and they lag behind the new 
developments in R. But after some investigation I found that “roxygen2” is 
using tools:::.get_internal_S3_generis() to decide if the method should be 
exported as S3method or not. For some reason “@<-“ is listed in there, but “@“ 
is not.

Am I missing some context, or is this an oversight?

Kind regards,
Karolis Koncevicius
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Karolis Koncevičius]

This issue might go deeper - I was not successful in passing R CMD checks for 
the usage files. R CMD check kept showing errors for `@` declarations, even 
thou they were identical to `$` declarations (which passed fine).

Seems like the usage check functions are not prepared for `@` - also in 
tools:::.S3_method_markup_regexp

> On Apr 28, 2023, at 10:34 PM, Karolis Koncevičius 
>  wrote:
> 
> I was building a package that uses the new generic @ and kept having errors 
> with “roxygen2” documentation. “roxygen2” generated NAMESPACE added 
> `@.newclass` as a newly exported function, not as a S3method.
> 
> At first I thought this must be a bug in roxygen2 and they lag behind the new 
> developments in R. But after some investigation I found that “roxygen2” is 
> using tools:::.get_internal_S3_generis() to decide if the method should be 
> exported as S3method or not. For some reason “@<-“ is listed in there, but 
> “@“ is not.
> 
> Am I missing some context, or is this an oversight?
> 
> Kind regards,
> Karolis Koncevicius

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Gabriel Becker]

Karolis,

It seems likely, without having looked myself, that you could be correct
about the issue, but it does seem worth noting that both of the functions
you have mentioned are not exported, and thus not part of the API that
extension packages are allowed to use and rely on.

If retrieving the list of "internal S3 generics" is something package and
user code is allowed to do, the real fix seems to go beyond what you're
suggesting, to actually providing an API entry point that gives the
relevant information (maybe in an identical form to how those internal
functions do so, maybe not). If it's not, for some principled reason,
something R-core wants to support package and user code doing, then the
fact that the new thing doesn't work automatically with roxygen2 would
become the roxygen maintainers' job to fix or document.

I do not know whether R-core feels this is something packages/users should
be able to do; both decisions strike me as possible, to be honest,
depending on details I don't know and/or am not privy to.

Best,
~G

On Fri, Apr 28, 2023 at 1:49 PM Karolis Koncevičius <
karolis.koncevic...@gmail.com> wrote:

> This issue might go deeper - I was not successful in passing R CMD checks
> for the usage files. R CMD check kept showing errors for `@` declarations,
> even thou they were identical to `$` declarations (which passed fine).
>
> Seems like the usage check functions are not prepared for `@` - also in
> tools:::.S3_method_markup_regexp
>
> > On Apr 28, 2023, at 10:34 PM, Karolis Koncevičius <
> karolis.koncevic...@gmail.com> wrote:
> >
> > I was building a package that uses the new generic @ and kept having
> errors with “roxygen2” documentation. “roxygen2” generated NAMESPACE added
> `@.newclass` as a newly exported function, not as a S3method.
> >
> > At first I thought this must be a bug in roxygen2 and they lag behind
> the new developments in R. But after some investigation I found that
> “roxygen2” is using tools:::.get_internal_S3_generis() to decide if the
> method should be exported as S3method or not. For some reason “@<-“ is
> listed in there, but “@“ is not.
> >
> > Am I missing some context, or is this an oversight?
> >
> > Kind regards,
> > Karolis Koncevicius
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Karolis Koncevičius]

Thank you for such a quick reply, Gabriel,

I am not too familiar with the package tools, so cannot speak too confidently, 
but below is how I see the issue currently.

The issue is not for external packages to rely on unexported functions from 
tools::, rather the issue is that 'R CMD check —as-cran' runs those functions 
from tools:: in order to check the validity of Rd files (from any package). R 
4.3.0 added @ as internal S3 generic. However, package tools does not recognise 
it as valid in Rd files and throws errors when it sees S3 method declared for @ 
in the Rd usage lines.

So any package that will try to use @ generic will run into the issue, without 
attempting to use internal S3 functions in their code, but during the R CMD 
check step.

Hope I am being clearer now, and not missing something important (all these 
things: both @ as generic and tools:: package are quite new to me),
Karolis K.

> On Apr 29, 2023, at 12:38 AM, Gabriel Becker  wrote:
> 
> Karolis,
> 
> It seems likely, without having looked myself, that you could be correct 
> about the issue, but it does seem worth noting that both of the functions you 
> have mentioned are not exported, and thus not part of the API that extension 
> packages are allowed to use and rely on.
> 
> If retrieving the list of "internal S3 generics" is something package and 
> user code is allowed to do, the real fix seems to go beyond what you're 
> suggesting, to actually providing an API entry point that gives the relevant 
> information (maybe in an identical form to how those internal functions do 
> so, maybe not). If it's not, for some principled reason, something R-core 
> wants to support package and user code doing, then the fact that the new 
> thing doesn't work automatically with roxygen2 would become the roxygen 
> maintainers' job to fix or document. 
> 
> I do not know whether R-core feels this is something packages/users should be 
> able to do; both decisions strike me as possible, to be honest, depending on 
> details I don't know and/or am not privy to.
> 
> Best,
> ~G 
> 
> On Fri, Apr 28, 2023 at 1:49 PM Karolis Koncevičius 
> mailto:karolis.koncevic...@gmail.com>> wrote:
>> This issue might go deeper - I was not successful in passing R CMD checks 
>> for the usage files. R CMD check kept showing errors for `@` declarations, 
>> even thou they were identical to `$` declarations (which passed fine).
>> 
>> Seems like the usage check functions are not prepared for `@` - also in 
>> tools:::.S3_method_markup_regexp
>> 
>> > On Apr 28, 2023, at 10:34 PM, Karolis Koncevičius 
>> > mailto:karolis.koncevic...@gmail.com>> 
>> > wrote:
>> > 
>> > I was building a package that uses the new generic @ and kept having 
>> > errors with “roxygen2” documentation. “roxygen2” generated NAMESPACE added 
>> > `@.newclass` as a newly exported function, not as a S3method.
>> > 
>> > At first I thought this must be a bug in roxygen2 and they lag behind the 
>> > new developments in R. But after some investigation I found that 
>> > “roxygen2” is using tools:::.get_internal_S3_generis() to decide if the 
>> > method should be exported as S3method or not. For some reason “@<-“ is 
>> > listed in there, but “@“ is not.
>> > 
>> > Am I missing some context, or is this an oversight?
>> > 
>> > Kind regards,
>> > Karolis Koncevicius
>> 
>> __
>> R-devel@r-project.org  mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Should '@" now be listed in tools:::.get_internal_S3_generics() ?

[Karolis Koncevičius]

A more concrete example in order to correct my vague messages below.

Writing an R package that uses `@` and `@<-` as S3 generics. Line from manual 
pages in .Rd files:

\method{@}{newclass}(object, name) <- value

Throws this error during R CMD check —as-cran

Bad \usage lines found in documentation object ’code’:
  method{@}{newclass}(object, name) <- value

This error is due to tools::checkDocFiles eventually calling 
tools:::.S3_method_markup_regexp and not finding `@` as a valid for S3.
This error is gone if we adjust tools:::.S3_method_markup_regexp to pass for 
‘@‘ by adding ‘\\@‘ to regexp.

Please note that this now is not dependant on using or not using roxygen2
KK.

> On Apr 29, 2023, at 12:53 AM, Karolis Koncevičius 
>  wrote:
> 
> Thank you for such a quick reply, Gabriel,
> 
> I am not too familiar with the package tools, so cannot speak too 
> confidently, but below is how I see the issue currently.
> 
> The issue is not for external packages to rely on unexported functions from 
> tools::, rather the issue is that 'R CMD check —as-cran' runs those functions 
> from tools:: in order to check the validity of Rd files (from any package). R 
> 4.3.0 added @ as internal S3 generic. However, package tools does not 
> recognise it as valid in Rd files and throws errors when it sees S3 method 
> declared for @ in the Rd usage lines.
> 
> So any package that will try to use @ generic will run into the issue, 
> without attempting to use internal S3 functions in their code, but during the 
> R CMD check step.
> 
> Hope I am being clearer now, and not missing something important (all these 
> things: both @ as generic and tools:: package are quite new to me),
> Karolis K.
> 
>> On Apr 29, 2023, at 12:38 AM, Gabriel Becker  wrote:
>> 
>> Karolis,
>> 
>> It seems likely, without having looked myself, that you could be correct 
>> about the issue, but it does seem worth noting that both of the functions 
>> you have mentioned are not exported, and thus not part of the API that 
>> extension packages are allowed to use and rely on.
>> 
>> If retrieving the list of "internal S3 generics" is something package and 
>> user code is allowed to do, the real fix seems to go beyond what you're 
>> suggesting, to actually providing an API entry point that gives the relevant 
>> information (maybe in an identical form to how those internal functions do 
>> so, maybe not). If it's not, for some principled reason, something R-core 
>> wants to support package and user code doing, then the fact that the new 
>> thing doesn't work automatically with roxygen2 would become the roxygen 
>> maintainers' job to fix or document. 
>> 
>> I do not know whether R-core feels this is something packages/users should 
>> be able to do; both decisions strike me as possible, to be honest, depending 
>> on details I don't know and/or am not privy to.
>> 
>> Best,
>> ~G 
>> 
>> On Fri, Apr 28, 2023 at 1:49 PM Karolis Koncevičius 
>> mailto:karolis.koncevic...@gmail.com>> wrote:
>>> This issue might go deeper - I was not successful in passing R CMD checks 
>>> for the usage files. R CMD check kept showing errors for `@` declarations, 
>>> even thou they were identical to `$` declarations (which passed fine).
>>> 
>>> Seems like the usage check functions are not prepared for `@` - also in 
>>> tools:::.S3_method_markup_regexp
>>> 
>>> > On Apr 28, 2023, at 10:34 PM, Karolis Koncevičius 
>>> > mailto:karolis.koncevic...@gmail.com>> 
>>> > wrote:
>>> > 
>>> > I was building a package that uses the new generic @ and kept having 
>>> > errors with “roxygen2” documentation. “roxygen2” generated NAMESPACE 
>>> > added `@.newclass` as a newly exported function, not as a S3method.
>>> > 
>>> > At first I thought this must be a bug in roxygen2 and they lag behind the 
>>> > new developments in R. But after some investigation I found that 
>>> > “roxygen2” is using tools:::.get_internal_S3_generis() to decide if the 
>>> > method should be exported as S3method or not. For some reason “@<-“ is 
>>> > listed in there, but “@“ is not.
>>> > 
>>> > Am I missing some context, or is this an oversight?
>>> > 
>>> > Kind regards,
>>> > Karolis Koncevicius
>>> 
>>> __
>>> R-devel@r-project.org  mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] save.image Non-responsive to Interrupt

[Dario Strbenac via R-devel]

Hello,

Could save.image() be redesigned so that it promptly responds to Ctrl+C? It 
prevents the command line from being used for a number of hours if the contents 
of the workspace are large.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel