similar to: sQuote() on zero-length inputs

I'm writing SQL queries, and it's very handy to be able to use sQuote for string parameter values. It makes me wish that I could use an sQuote-like function for enclosing column names and other identifiers in backticks, i.e., select `foo` from `table`. Obviously I can do this with paste(), I'm just asking for syntactic sugar. Oh, a buglet: the sQuote help page, See Also section, the

Does anyone have comments on the new wording here? Suggested: The Title field should be in title case. Current version is: (xxx) In title case this would be: (Xxx) Hoping R core will see this here and magically adopt it, otherwise I'll try posting it to the r bugs site ... =================================================================== --- src/library/tools/R/QC.R (revision

Dear all When comparing sQuote("text") and dQuote("text") on MacOS X and Linux FC4 I get an inconsistent behavior (using the new release version R-2.6.0): sQuote: On Mac I get the correct result "'text'", but on FC4 the incorrect result "`text?". dQuote: On Mac I get the correct result "\"text\"", but on FC4 the incorrect

> Date: Sat, 8 Jun 2024 19:16:22 -0400 > From: Ben Bolker <bbolker at gmail.com> > > The ASAN errors occur *even if the zero-length object is not actually > accessed*/is used in a perfectly correct manner, i.e. it's perfectly > legal in base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, > ncol = 0)`, whereas doing the

The ASAN errors occur *even if the zero-length object is not actually accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`, whereas doing the equivalent in Rcpp will (now) lead to an ASAN error. i.e., these are *not* previously cryptic out-of-bounds accesses that are now being

On Sat, 8 Jun 2024, Ben Bolker wrote: > The ASAN errors occur *even if the zero-length object is not actually > accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in > base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`, > whereas doing the equivalent in Rcpp will (now) lead to an ASAN error. > > i.e., these are *not*

IMHO, this should be changed in both Rcpp and downstream packages: 1. Rcpp could check for out-of-bounds accesses in cases like these, and emit an R warning / error when such an access is detected; 2. The downstream packages unintentionally making these out-of-bounds accesses should be fixed to avoid doing that. That is, I think this is ultimately a bug in the affected packages, but Rcpp could

Sorry to ask about a bit drifted topic, but will there be an alternative API to DATAPTR? > DATAPTR is not in the API and can't be at least in this form I believe it's vital for ALTREP to return the pointer to the expanded version of a SEXP just like the implementation in base R does [1]. At least, VECSXP has no other measure to expose the pointer if I understand correctly. Best,

>>>>> Fox, John >>>>> on Fri, 22 Feb 2019 17:40:15 +0000 writes: > Dear Martin and Ben, I agree that a warning is a good idea > (and perhaps that wasn't clear in my response to Ben's > post). > Also, it would be nice to correct the omission in the help > file, which as far as I could see doesn't mention that a

Dear Martin and Ben, I agree that a warning is a good idea (and perhaps that wasn't clear in my response to Ben's post). Also, it would be nice to correct the omission in the help file, which as far as I could see doesn't mention that a contrast-generating function (as opposed to its quoted name) can be an element of the contrasts.arg list. Best, John > -----Original

A change to R-devel (SVN r86629 or https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250 has changed the handling of pointers to zero-length objects, leading to ASAN issues with a number of Rcpp-based packages (the commit message reads, in part, "Also define STRICT_TYPECHECK when compiling inlined.c.") I'm interested in discussion from the

> On 9 Jan 2025, at 05:56, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > > On 1/8/25 17:26, Ben Bolker wrote: >> Thanks, that makes sense. >> >> I guess if it never worked for integers (or hasn't worked in a long time, at least) then it doesn't need to be fixed/changed ... > > Still you found out that the type check and use of

Mara Averick noticed some oddities in the mtcars data set: https://twitter.com/dataandme/status/1033341784959709184 I propose the following patch. While anyone with access to JSTOR could dig in and find this information themselves, it would seem a friendly gesture to include it ... cheers Ben Bolker =================================================================== --- mtcars.Rd

>>>>> Ben Bolker >>>>> on Thu, 21 Feb 2019 08:18:51 -0500 writes: > On Thu, Feb 21, 2019 at 7:49 AM Fox, John <jfox at mcmaster.ca> wrote: >> >> Dear Ben, >> >> Perhaps I'm missing the point, but contrasts.arg is documented to be a list. From ?model.matrix: "contrasts.arg: A list, whose entries are

Ah, I spoke too soon. I started putting the demo code into a test suite and ran one check with valgrind and ? sure enough ? there's def more issues (a cpl functions) than the overt/easy ones (and, I went back to the check results page and, also sure enough, they're there, too). They look to be fairly straightforward to resolve but it's going to take a bit longer than "this

Thanks, that makes sense. I guess if it never worked for integers (or hasn't worked in a long time, at least) then it doesn't need to be fixed/changed ... cheers Ben On 2025-01-08 11:20 a.m., Ivan Krylov wrote: > On Wed, 8 Jan 2025 10:57:47 -0500 > Ben Bolker <bbolker at gmail.com> wrote: > >> I haven't done the archaeology to figure out when this

On 1/8/25 17:26, Ben Bolker wrote: > Thanks, that makes sense. > > ? I guess if it never worked for integers (or hasn't worked in a long > time, at least) then it doesn't need to be fixed/changed ... Still you found out that the type check and use of REAL() in the function is in wrong order. Instead of "REAL() can only be applied to a 'numeric', not a

Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the

[Please keep r-help in the cc: list] I don't quite know how to interpret the difference between specifying effort as an offset vs. as weights; I would have to spend more time thinking about it/working through it than I have available at the moment. I don't know that specifying effort as weights is *wrong*, but I don't know that it's right or what it is doing: if I were

Kevin, Maybe also look at what air quality monitoring is being done in area. https://cran.r-project.org/web/packages/RAQSAPI/vignettes/RAQSAPIvignette.html Depends what and how near, but might be something relevant there? Karl Dr Karl Ropkins Transport Studies | Environment | University of Leeds ------------------------------ Message: 2 Date: Tue, 12 Dec 2023 07:52:59 -0800 From: Bert Gunter