Re: [R-pkg-devel] testing coercion

2018-12-06 Thread Kevin Coombes
Thanks for the suggestion. But it may not be quite expressive enough; I
think I will instead use

 > ifelse(getRversion() < "3.6.0",
 >   ! canCoerce(wv, "double"),   # fails in older versions
 >  canCoerce(wv, "double"))  # works in newer versions

That way, when I update the package six months from now, I might have a
chance of remembering what was going on.

Best,
   Kevin

On 12/6/2018 11:41 AM, Sebastian Meyer wrote:
> Hi Kevin,
>
> I think using
>
>> canCoerce(wv, "double") || getRversion() < "3.6.0"
> could solve the issue of an inconsistent test result and is descriptive.
>
> Best regards,
>
>   Sebastian
>
>
> Am 06.12.18 um 16:59 schrieb Kevin Coombes:
>>   Hi,
>>
>> A package I recently submitted to CRAN includes an S4 class that defines a
>> method to coerce from that class to a numeric vector, basically through
>>
>>>   setAs("myClass", "numeric", function(from) from@psi)
>> Being perhaps overly compulsive about trying to test everything while
>> documenting behavior, my accompanying test script includes these lines:
>>
>>> try( as.numeric(wv) )# should fail
>>> canCoerce(wv, "numeric")   # returns TRUE
>>> canCoerce(wv, "double") # gets a complaint from CRAN incoming pretest
>> The complaint on the last line arises because
>> + in the current version of R, the answer is FALSE
>> + in the development version of R, the answer is TRUE
>> The change is (probably) documented on the R-devel daily news from 04 Sept
>> 2018, which lists
>>
>> Bug Fix:  as(1L, "double") now does coerce (PR#17457)
>>
>> So, here's my question. Do I remove this test (and thus lose my
>> documentation of how the method behaves) in order to get the incoming
>> precheck to stop whinging? Or do I tell the CRAN maintainers to not worry
>> about the test changing, since it's due to a core bug fix, and promise to
>> change my saved test results when the devel version becomes current? (Even
>> though the fixed results will then show up as wrong in the "oldrel" tests.)
>>
>> Best,
>>Kevin
>>
>>  [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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


Re: [R-pkg-devel] testing coercion

2018-12-06 Thread Sebastian Meyer
Hi Kevin,

I think using

> canCoerce(wv, "double") || getRversion() < "3.6.0"

could solve the issue of an inconsistent test result and is descriptive.

Best regards,

Sebastian


Am 06.12.18 um 16:59 schrieb Kevin Coombes:
>  Hi,
> 
> A package I recently submitted to CRAN includes an S4 class that defines a
> method to coerce from that class to a numeric vector, basically through
> 
>>  setAs("myClass", "numeric", function(from) from@psi)
> 
> Being perhaps overly compulsive about trying to test everything while
> documenting behavior, my accompanying test script includes these lines:
> 
>> try( as.numeric(wv) )# should fail
>> canCoerce(wv, "numeric")   # returns TRUE
>> canCoerce(wv, "double") # gets a complaint from CRAN incoming pretest
> 
> The complaint on the last line arises because
> + in the current version of R, the answer is FALSE
> + in the development version of R, the answer is TRUE
> The change is (probably) documented on the R-devel daily news from 04 Sept
> 2018, which lists
> 
> Bug Fix:  as(1L, "double") now does coerce (PR#17457)
> 
> So, here's my question. Do I remove this test (and thus lose my
> documentation of how the method behaves) in order to get the incoming
> precheck to stop whinging? Or do I tell the CRAN maintainers to not worry
> about the test changing, since it's due to a core bug fix, and promise to
> change my saved test results when the devel version becomes current? (Even
> though the fixed results will then show up as wrong in the "oldrel" tests.)
> 
> Best,
>   Kevin
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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