Re: [Rd] timezone tests and R-devel
On Fri, Oct 23, 2020 at 11:10 AM Sebastian Meyer wrote: > Yes, you are absolutely right and I'm pretty sure this will be fixed in > one way or another. > > IMO, the failing test should simply use all.equal.POSIXt's new argument > check.tzone=FALSE. > I agree that this is a simple fix and I am wondering why it hasn't been implemented. I will request access to bugzilla so I can file a bug report. Best, Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug report for make check
I would like to request access to bugzilla to file a bug report on make check for R-devel. Following changes to all.equal.POSIXt, make check now reports an error if the environment variable TZ is set to TZ="US/Eastern" (and likely other values). This can be addressed by using the argument check.tzone=FALSE in the call to all.equal.POSIXt in reg-tests-2.R. A patch has been posted by Sebastian Meyer in the R-devel thread "timezone tests and R-devel". -- Best, Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug report for make check
Dear Kasper, if you want to submit a bug via bugzilla, please first read https://www.r-project.org/bugs.html and you will learn there that there is an email address to use when asking for an account, not all R-devel mailing list readers need to read that. Moreover, I can see you already have an account in R bugzilla. Moreover, bugs can be reported also on R-devel mailing list and this has been reported already several times, we are working on it, it is not clear what is the right way to fix this. Thanks for your patience, Tomas On 10/30/20 11:24 AM, Kasper Daniel Hansen wrote: I would like to request access to bugzilla to file a bug report on make check for R-devel. Following changes to all.equal.POSIXt, make check now reports an error if the environment variable TZ is set to TZ="US/Eastern" (and likely other values). This can be addressed by using the argument check.tzone=FALSE in the call to all.equal.POSIXt in reg-tests-2.R. A patch has been posted by Sebastian Meyer in the R-devel thread "timezone tests and R-devel". __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug report for make check
Thanks, I'm going to shut up then. Despite having been reported multiple times, it was not at all clear to me that this was being worked on with the intention of addressing make check - that is one of the limitations of the communication system we use. Best, Kasper On Fri, Oct 30, 2020 at 11:38 AM Tomas Kalibera wrote: > Dear Kasper, > > if you want to submit a bug via bugzilla, please first read > > https://www.r-project.org/bugs.html > > and you will learn there that there is an email address to use when > asking for an account, not all R-devel mailing list readers need to read > that. > > Moreover, I can see you already have an account in R bugzilla. > > Moreover, bugs can be reported also on R-devel mailing list and this has > been reported already several times, we are working on it, it is not > clear what is the right way to fix this. > > Thanks for your patience, > Tomas > > On 10/30/20 11:24 AM, Kasper Daniel Hansen wrote: > > I would like to request access to bugzilla to file a bug report on make > > check for R-devel. > > > > Following changes to all.equal.POSIXt, > >make check > > now reports an error if the environment variable TZ is set to > >TZ="US/Eastern" > > (and likely other values). This can be addressed by using the argument > > check.tzone=FALSE in the call to all.equal.POSIXt in reg-tests-2.R. A > patch > > has been posted by Sebastian Meyer in the R-devel thread "timezone tests > > and R-devel". > > > > -- Best, Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Change to I() in R 4.1
On 10/29/20 23:08, Pages, Herve wrote:
...
>
> I can think of 2 ways to move forward:
>
> 1. Keep I()'s current implementation but suppress the warning. We'll
> make the necessary adjustments to DataFrame() to repair columns supplied
> as I() objects. Note that we would still be in the situation where
> I() objects break validObject() but we've been in that situation for
> years and so far we've managed to work around it. However this doesn't
> mean that validObject() shouldn't be fixed. Note that print(I())
> would also need to be fixed (it says "" which is
> misleading). Anyways, these 2 issues are separated from the main issue
> and can be dealt with later.
1b. A variant of the above could be to use the old implementation for S4
objects only:
I <- function(x)
{
if (isS4(x)) {
structure(x, class = unique.default(c("AsIs", oldClass(x
} else {
`class<-`(x, unique.default(c("AsIs", oldClass(x
}
}
That is probably a good compromise for now.
I would also suggest that the "package" attribute of the S4 class be
kept around so the code that we use to restore the original object has a
way to restore it exactly, including its full class specification. Right
now, and also with the previous implementation, we cannot do that
because attr(class(x), "package") is lost. So something like this:
I <- function(x)
{
if (isS4(x)) {
x_class <- class(x)
new_classes <- c("AsIs", x_class)
attr(new_classes, "package") <- attr(x_class, "package")
structure(x, class=new_classes)
} else {
`class<-`(x, unique.default(c("AsIs", oldClass(x
}
}
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: Change to I() in R 4.1
On Fri, 30 Oct 2020, Pages, Herve wrote:
On 10/29/20 23:08, Pages, Herve wrote:
...
I can think of 2 ways to move forward:
1. Keep I()'s current implementation but suppress the warning. We'll
make the necessary adjustments to DataFrame() to repair columns supplied
as I() objects. Note that we would still be in the situation where
I() objects break validObject() but we've been in that situation for
years and so far we've managed to work around it. However this doesn't
mean that validObject() shouldn't be fixed. Note that print(I())
would also need to be fixed (it says "" which is
misleading). Anyways, these 2 issues are separated from the main issue
and can be dealt with later.
1b. A variant of the above could be to use the old implementation for S4
objects only:
I <- function(x)
{
if (isS4(x)) {
structure(x, class = unique.default(c("AsIs", oldClass(x
} else {
`class<-`(x, unique.default(c("AsIs", oldClass(x
}
}
That is probably a good compromise for now.
Not really. The underlying problem is that class<- and attributes<-
(which is what structure() uses) handle the 'class' attribute
differently, and that needs to be fixed. I don't have a strong opinion
on what either should do, but they should do the same thing.
It's probably worth re-thinking the I() mechanism. ?Modifying the
value, whether by changing the class or an attribute, is going to be
brittle. A little less so for an attribute, but using an attribute
rules out dispatch on the AsIs property.
Best,
luke
I would also suggest that the "package" attribute of the S4 class be
kept around so the code that we use to restore the original object has a
way to restore it exactly, including its full class specification. Right
now, and also with the previous implementation, we cannot do that
because attr(class(x), "package") is lost. So something like this:
I <- function(x)
{
if (isS4(x)) {
x_class <- class(x)
new_classes <- c("AsIs", x_class)
attr(new_classes, "package") <- attr(x_class, "package")
structure(x, class=new_classes)
} else {
`class<-`(x, unique.default(c("AsIs", oldClass(x
}
}
Thanks,
H.
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: Change to I() in R 4.1
On 10/30/20 10:48, luke-tier...@uiowa.edu wrote:
> On Fri, 30 Oct 2020, Pages, Herve wrote:
>
>>
>> On 10/29/20 23:08, Pages, Herve wrote:
>> ...
>>>
>>> I can think of 2 ways to move forward:
>>>
>>> 1. Keep I()'s current implementation but suppress the warning. We'll
>>> make the necessary adjustments to DataFrame() to repair columns supplied
>>> as I() objects. Note that we would still be in the situation where
>>> I() objects break validObject() but we've been in that situation for
>>> years and so far we've managed to work around it. However this doesn't
>>> mean that validObject() shouldn't be fixed. Note that print(I())
>>> would also need to be fixed (it says "" which is
>>> misleading). Anyways, these 2 issues are separated from the main issue
>>> and can be dealt with later.
>>
>> 1b. A variant of the above could be to use the old implementation for S4
>> objects only:
>>
>> I <- function(x)
>> {
>> if (isS4(x)) {
>> structure(x, class = unique.default(c("AsIs", oldClass(x
>> } else {
>> `class<-`(x, unique.default(c("AsIs", oldClass(x
>> }
>> }
>>
>> That is probably a good compromise for now.
>
> Not really. The underlying problem is that class<- and attributes<-
> (which is what structure() uses) handle the 'class' attribute
> differently, and that needs to be fixed. I don't have a strong opinion
> on what either should do, but they should do the same thing.
This is why I'm calling this a compromise. Many Bioconductor packages
are broken right now so this would at least repair them and restore an
important feature of the DataFrame() constructor, while at the same time
preserve the speedup for all non-S4 objects that Martin was after when
he changed I()'s implementation.
>
> It's probably worth re-thinking the I() mechanism. ?Modifying the
> value, whether by changing the class or an attribute, is going to be
> brittle. A little less so for an attribute, but using an attribute
> rules out dispatch on the AsIs property.
Which was my 2nd proposal. It rules out dispatch but it's not clear why
you would rely on dispatch for something like this.
Anyways, I personally have no preferences as long as I()'s warning
goes away and attr(class(), "package") can somehow be propagated.
Thanks,
H.
>
> Best,
>
> luke
>
>>
>> I would also suggest that the "package" attribute of the S4 class be
>> kept around so the code that we use to restore the original object has a
>> way to restore it exactly, including its full class specification. Right
>> now, and also with the previous implementation, we cannot do that
>> because attr(class(x), "package") is lost. So something like this:
>>
>> I <- function(x)
>> {
>> if (isS4(x)) {
>> x_class <- class(x)
>> new_classes <- c("AsIs", x_class)
>> attr(new_classes, "package") <- attr(x_class, "package")
>> structure(x, class=new_classes)
>> } else {
>> `class<-`(x, unique.default(c("AsIs", oldClass(x
>> }
>> }
>>
>> Thanks,
>> H.
>>
>>
>>
>
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
