search for: _r_check_length_1_condition_

..., FALSE) && TRUE : 'length(x) = 2 > 1' in coercion to 'logical(1)' > > > could help encourage more package maintainers to fix these bugs > > sooner. Enabling this warning by default is in line with what the > > current default behavior for _R_CHECK_LENGTH_1_CONDITION_ bugs: > > >> if (c(TRUE, FALSE)) 42 > > [1] 42 > > Warning message: > > In if (c(TRUE, FALSE)) 42 : > > the condition has length > 1 and only the first element will be used > > > which has been the case for many years. > &gt...

...& TRUE [1] TRUE Warning message: In c(TRUE, FALSE) && TRUE : 'length(x) = 2 > 1' in coercion to 'logical(1)' could help encourage more package maintainers to fix these bugs sooner. Enabling this warning by default is in line with what the current default behavior for _R_CHECK_LENGTH_1_CONDITION_ bugs: > if (c(TRUE, FALSE)) 42 [1] 42 Warning message: In if (c(TRUE, FALSE)) 42 : the condition has length > 1 and only the first element will be used which has been the case for many years. Hopefully in a not too far future, we get to a point where we can have _R_CHECK_LENGTH_1_LOGIC2_...

...TRUE : 'length(x) = 2 > 1' in coercion to 'logical(1)' >> >> > could help encourage more package maintainers to fix these bugs >> > sooner. Enabling this warning by default is in line with what the >> > current default behavior for _R_CHECK_LENGTH_1_CONDITION_ bugs: >> >> >> if (c(TRUE, FALSE)) 42 >> > [1] 42 >> > Warning message: >> > In if (c(TRUE, FALSE)) 42 : >> > the condition has length > 1 and only the first element will be used >> >> > which has...

...> In c(TRUE, FALSE) && TRUE : 'length(x) = 2 > 1' in coercion to 'logical(1)' > could help encourage more package maintainers to fix these bugs > sooner. Enabling this warning by default is in line with what the > current default behavior for _R_CHECK_LENGTH_1_CONDITION_ bugs: >> if (c(TRUE, FALSE)) 42 > [1] 42 > Warning message: > In if (c(TRUE, FALSE)) 42 : > the condition has length > 1 and only the first element will be used > which has been the case for many years. > Hopefully in a not too far future, w...

...iable is set to a ?true? > value) when && or || encounter and use arguments of length more than one. Indeed, thank you, Ben. Note (Dirk) this is not just something "by Henrik (..) as he tried to convince us all to use it more" I've activated this (and the other _R_CHECK_LENGTH_1_CONDITION_ ! ) for years (maybe not many years, it just feels like it), and *EVERY TIME* it triggers, it's been revealing a programmeR's thinko / bug / .., something where the code was clearly suboptimal and should've been improved. (Unfortunately, the bug has often been in packages, and sometimes...

On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Gabriel Becker > >>>>> on Sat, 2 Nov 2019 12:37:08 -0700 writes: > > > I agree that we can be careful and narrow and still see a > > nice improvement in behavior. While Herve's point is valid > > and I understand his

...ain, correct. In the mean time, thanks to Tomas Kalibera, my small change has been tested on all of CRAN and Bioc (Software) packages R CMD check <pkg> but no '--as-cran' nor any environment variable settings such as ((strongly recommended by me for package developers !)) _R_CHECK_LENGTH_1_CONDITION_=true _R_CHECK_LENGTH_1_LOGIC2_=verbose >From the package checks, and my own checks I've started noticing only today, that indeed, the _R_CHECK_LENGTH_1_CONDITION_=true environment variable setting --- stemming more or less directly from an R-devel (mailing list) proposal by Hen...

...#39;||' and '&&' should always return a scalar logical and neither TRUE nor FALSE can be returned. /Henrik PS. This is in the same vein as https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if _R_CHECK_LENGTH_1_CONDITION_=true

...when && or || encounter and use arguments of length more than > one. > > Indeed, thank you, Ben. > > Note (Dirk) this is not just something > "by Henrik (..) as he tried to convince us all to use it more" > > I've activated this (and the other > _R_CHECK_LENGTH_1_CONDITION_ ! ) > for years (maybe not many years, it just feels like it), and *EVERY TIME* > it triggers, it's been revealing a programmeR's thinko / bug / .., > something where the code was clearly suboptimal and should've been > improved. > (Unfortunately, the bug has often been i...

...if(inherits(obj, "<classname>")) > > instead. Second this one. But, soon (*) the former will at least give the correct answer when length(class(obj)) == 1 and produce an error otherwise. So, several of these cases will be caught at run-time in a near future. (*) When _R_CHECK_LENGTH_1_CONDITION_=true becomes the default behavior - hopefully by R 3.5.0. > > Martin > > > > > On Tue, Jan 30, 2018 at 3:47 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > > >> On 01/30/2018 02:50 PM, Michael Lawrence wrote: > >> > >>>...

Thanks for the feedback Dirk. I sent my follow-up before I saw it. Looking at the source code, it appears that there is no options() call to turn this on. Nor does "R --help" reveal a command line option. How then does a user turn this on outside of the R CMD check envirionment, so as to chase things like this down? The fact that 1. renaming my function makes the error go away, 2.

?On 30/08/2018, 20:15, "R-devel on behalf of Hadley Wickham" <r-devel-bounces at r-project.org on behalf of h.wickham at gmail.com> wrote: On Thu, Aug 30, 2018 at 10:58 AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Joris Meys > >>>>> on Thu, 30 Aug 2018 14:48:01 +0200 writes: >

...neither TRUE nor FALSE can > > be returned. > > > > /Henrik > > > > PS. This is in the same vein as > > https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html > > - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if > > _R_CHECK_LENGTH_1_CONDITION_=true > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > http://hadley.nz > > ______________________________________________ > R-devel at r-pro...

...>> one. >> >> Indeed, thank you, Ben. >> >> Note (Dirk) this is not just something >> "by Henrik (..) as he tried to convince us all to use it more" >> >> I've activated this (and the other >> _R_CHECK_LENGTH_1_CONDITION_ ! ) >> for years (maybe not many years, it just feels like it), and *EVERY TIME* >> it triggers, it's been revealing a programmeR's thinko / bug / .., >> something where the code was clearly suboptimal and should've been >> improved. >>...

...yDate(Sys.Date())) class(d) == "Date" # is FALSE (hence of length 1) inherits(d, "Date") # is TRUE > So, several of these cases will be caught at run-time in a > near future. Maybe. But all the others are still wrong, as I show above. Martin > (*) When _R_CHECK_LENGTH_1_CONDITION_=true becomes the default > behavior - hopefully by R 3.5.0. >> >> Martin

...hould always return a scalar logical and neither TRUE nor FALSE can > be returned. > > /Henrik > > PS. This is in the same vein as > https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html > - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if > _R_CHECK_LENGTH_1_CONDITION_=true > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://hadley.nz

...hould always return a scalar logical and neither TRUE nor FALSE can > be returned. > > /Henrik > > PS. This is in the same vein as > https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html > - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if > _R_CHECK_LENGTH_1_CONDITION_=true > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000...

...should always return a scalar logical and neither TRUE nor FALSE can be returned. /Henrik PS. This is in the same vein as https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if _R_CHECK_LENGTH_1_CONDITION_=true ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

...ical and neither TRUE nor FALSE can >> be returned. >> >> /Henrik >> >> PS. This is in the same vein as >> https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html >> - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if >> _R_CHECK_LENGTH_1_CONDITION_=true >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > >

I just meant that the minimal contract for as.list() appears to be that it returns a VECSXP. To the user, we might say that is.list() will always return TRUE. I'm not sure we can expect consistency across methods beyond that, nor is it feasible at this point to match the semantics of the methods package. It deals in "class space" while as.list() deals in "typeof() space".