Re: [Rd] Depends: R (>= 4.1) for packages that use |> and \(...)

On Wed, Mar 5, 2025 at 8:04 AM Serguei Sokol via R-devel < r-devel@r-project.org> wrote: > Le 05/03/2025 à 14:47, Hadley Wickham a écrit : > > Unfortunately your test generates a false positive for httr2 ( > > https://cran.r-project.org/web/checks/check_results_ht

Re: [Rd] Depends: R (>= 4.1) for packages that use |> and \(...)

Unfortunately your test generates a false positive for httr2 ( https://cran.r-project.org/web/checks/check_results_httr2.html) and other tidyverse packages where we use the base pipe in examples, but carefully disable them for older versions of R. Hadley On Thu, Feb 6, 2025 at 9:18 AM Ivan Krylov

Re: [Rd] binary R packages for GNU/Linux

> > > > The proprietary Package Manager (PPM) from Posit ( > https://packagemanager.posit.co/client/#/) does offer binary packages for > GNU/Linux, but the usage of this service is restricted in ways that go > against the principles of open source ( > https://posit.co/about/posit-service-terms-of-u

Re: [Rd] clarifying and adjusting the C API for R

Thanks for working on this Luke! We appreciate your efforts to make it easier to tell what's in the exported API and we're very happy to work with you on any changes needed to tidyverse/r-lib packages. Hadley On Thu, Jun 6, 2024 at 9:47 AM luke-tierney--- via R-devel < r-devel@r-project.org> wrot

[Rd] Segfault when parsing UTF-8 text with srcrefs

Hi all, When I run the following code, R segfaults: text <- "×" srcfile <- srcfilecopy("test.r", text) parse(textConnection(text), srcfile = srcfile) It doesn't segfault if text is ASCII, or it's not wrapped in textConnection, or srcfile isn't set. Hadley -- http://hadley.nz [[altern

Re: [Rd] Is ALTREP "non-API"?

A few more thoughts based on a simple question: how do you determine the length of a vector? Rf_length() is used in example code in R-exts, but I don't think it's formally documented anywhere (although it's possible I missed it). Is using in an example sufficient to consider a function to be part

Re: [Rd] Is ALTREP "non-API"?

> > > > >>> That is not true at all - the presence of header does not constitute > >> declaration of something as the R API. There are cases where internal > >> functions are in the headers for historical or other reasons since the > >> headers are used both for the internal implementation and pack

Re: [Rd] Is ALTREP "non-API"?

> > > > > > ALTREP is part of the official R api, as illustrated by the presence of > > > src/include/R_ext/Altrep.h. Everything declared in the header files in > that > > > directory is official API AFAIK (and I believe that is more definitive > than > > > the manuals). > > > > > > > That is not t

Re: [Rd] Is ALTREP "non-API"?

On Mon, Apr 22, 2024 at 5:14 PM Simon Urbanek wrote: > > > > On Apr 22, 2024, at 7:37 PM, Gabriel Becker > wrote: > > > > Hi Yutani, > > > > ALTREP is part of the official R api, as illustrated by the presence of > > src/include/R_ext/Altrep.h. Everything declared in the header files in > that >

Re: [Rd] Improving user-friendliness of S4 dispatch failure when mis-naming arguments?

Hi Michael, I can't help with S4, but I can help to make sure this isn't a problem with S7. What do you think of the current error message? Do you see anything obvious we could do to improve? library(S7) dbGetQuery <- new_generic("dbGetQuery", c("conn", "statement")) dbGetQuery(connection = NULL

Re: [Rd] A demonstrated shortcoming of the R package management system

Hi Dirk, Do you think it's worth also/instead considering a fix to S4 to avoid this caching issue in future R versions? (This is top of my for me as we consider the design of S7, and I recently made a note to ensure we avoid similar problems there: https://github.com/RConsortium/OOP-WG/issues/317

Re: [Rd] replicate evaluates its second argument in wrong environment

On Monday, February 15, 2021, David Winsemius wrote: > > On 2/15/21 1:10 PM, Hadley Wickham wrote: > >> This is a nice example of the motivation for tidy evaluation — since >> enquo() captures the environment in which the promise should be >> evaluated, there's no

Re: [Rd] replicate evaluates its second argument in wrong environment

This is a nice example of the motivation for tidy evaluation — since enquo() captures the environment in which the promise should be evaluated, there's no need for an additional explicit argument. library(rlang) replicate2 <- function (n, expr, simplify = "array") { exnr <- enquo(expr) sapply

Re: [Rd] New pipe operator and gg plotz

Another option is https://github.com/hadley/ggplot1 🤣 Hadley On Wed, Dec 9, 2020 at 1:24 PM Duncan Murdoch wrote: > > Looks like Sergio Oller took your ambitious approach: > https://github.com/zeehio/ggpipe. It hasn't been updated since 2017, so > there may be some new things in ggplot2 that are

Re: [Rd] New pipe operator

I just wanted to pipe in here (HA HA) to say that I agree with Kevin. I've never loved the complicated magrittr rule (which has personally tripped me up a couple of times) and I think the compact inline function syntax provides a more general solution. It is a bit more typing, and it will require a

Re: [Rd] Including full text of open source licenses in a package

On Saturday, September 12, 2020, Hugh Parsonage wrote: > Perhaps I have misread that excerpt from WRE, but my read is that > package authors should not duplicate GNU COPYING, since it is present > in all R distributions already when using GPL-2 and friends. It > doesn't apply to packages distrib

[Rd] Including full text of open source licenses in a package

Hi all, R-exts currently requests that package authors don't include copies of standard licenses: > Whereas you should feel free to include a license file in your source > distribution, please do > not arrange to install yet another copy of the GNU COPYING or COPYING.LIB > files but > refer to

Re: [Rd] some questions about R internal SEXP types

On Tue, Sep 8, 2020 at 4:12 AM Tomas Kalibera wrote: > > > The general principle is that R packages are only allowed to use what is > documented in the R help (? command) and in Writing R Extensions. The > former covers what is allowed from R code in extensions, the latter > mostly what is allowed

Re: [Rd] object.size vs lobstr::obj_size

On Fri, Mar 27, 2020 at 4:01 PM Hervé Pagès wrote: > > > On 3/27/20 12:00, Hadley Wickham wrote: > > > > > > On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès > <mailto:hpa...@fredhutch.org>> wrote: > > > > Hi Tomas, > > > > On

Re: [Rd] object.size vs lobstr::obj_size

On Fri, Mar 27, 2020 at 11:08 AM Tomas Kalibera wrote: > On 3/27/20 4:39 PM, Hervé Pagès wrote: > > Hi Tomas, > > > > On 3/27/20 07:01, Tomas Kalibera wrote: > >> they provide an over-approximation > > > > They can also provide an "under-approximation" (to say the least) e.g. > > on reference obj

Re: [Rd] object.size vs lobstr::obj_size

On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès wrote: > Hi Tomas, > > On 3/27/20 07:01, Tomas Kalibera wrote: > > they provide an over-approximation > > They can also provide an "under-approximation" (to say the least) e.g. > on reference objects where the entire substance of the object is ignored

Re: [Rd] Rebuilding and re-checking of downstream dependencies on CRAN Mac build machines

If I do install.packages("dplyr", type = "source"), I see: Installing package into ‘/Users/hadley/R’ (as ‘lib’ is unspecified) trying URL 'https://cran.rstudio.com/src/contrib/dplyr_0.8.5.tar.gz' Content type 'application/x-gzip' length 1378766 bytes (1.3 MB) ==

Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]

On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler 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

Re: [Rd] improving the performance of install.packages

If this is the behaviour you are looking for, you might like to try pak (https://pak.r-lib.org) # Create a temporary library path <- tempfile() dir.create(path) .libPaths(path) pak::pkg_install("scales") #> → Will install 8 packages: #> colorspace (1.4-1), labeling (0.3), munsell (0.5.0), R6 (2

Re: [Rd] Puzzled about a new method for "[".

For what it's worth, I don't think this strategy can work in general, because a class might have attributes that depend on its data/contents (e.g. https://vctrs.r-lib.org/articles/s3-vector.html#cached-sum). I don't think these are particularly common in practice, but it's dangerous to assume that

Re: [Rd] nrow(rbind(character(), character())) returns 2 (as documented but very unintuitive, IMHO)

The existing behaviour seems inutitive to me. I would consider these invariants for n vector x_i's each with size m: * nrow(rbind(x_1, x_2, ..., x_n)) equals n * ncol(rbind(x_1, x_2, ..., x_n)) equals m Additionally, wouldn't you expect rbind(x_1[i], x_2[i]) to equal rbind(x_1, x_2)[, i, drop = F

Re: [Rd] Discrepancy between is.list() and is(x, "list")

On Wed, Mar 27, 2019 at 6:27 PM Abs Spurdle wrote: > > > the prison made by ancient design choices > > That prison of ancient design choices isn't so bad. > > I have no further comments on object oriented semantics. > However, I'm planning to follow the following design pattern. > > If I set the c

Re: [Rd] Discrepancy between is.list() and is(x, "list")

I would recommend reading https://adv-r.hadley.nz/base-types.html and https://adv-r.hadley.nz/s3.html. Understanding the distinction between base types and S3 classes is very important to make this sort of question precise, and in my experience, you'll find R easier to understand if you carefully d

[Rd] An update on the vctrs package

Hi all, I wanted to give you an update on vctrs () since I last bought it up here in August. The biggest change is that I now have a much clearer idea of what vctrs is! I’ll summarise that here, and point you to the documentation if you’re interested in learning more. I’m

Re: [Rd] True length - length(unclass(x)) - without having to call unclass()?

For the new vctrs::records class, I implemented length, names, [[, and [[<- myself in https://github.com/r-lib/vctrs/blob/master/src/fields.c. That lets me override the default S3 methods while still being able to access the underlying data that I'm interested in. Another option that avoids (that

Re: [Rd] build package with unicode (farsi) strings

On Thu, Aug 30, 2018 at 2:11 AM Thierry Onkelinx wrote: > > Dear Farid, > > Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641"). The full > code table is available at https://www.utf8-chartable.de It's a little easier to do this with code: letters_fa <- c('الف','ب','پ','ت','ث','ج',

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

On Thu, Aug 30, 2018 at 10:58 AM Martin Maechler wrote: > > > Joris Meys > > on Thu, 30 Aug 2018 14:48:01 +0200 writes: > > > On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth > > wrote: > >> Note that `||` and `&&` have never been symmetric: > >> > >> TRUE || stop() # re

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

I think this is an excellent idea as it eliminates a situation which is almost certainly user error. Making it an error would break a small amount of existing code (even if for the better), so perhaps it should start as a warning, but be optionally upgraded to an error. It would be nice to have a f

Re: [Rd] Where does L come from?

Thanks for the great discussion everyone! Hadley On Sat, Aug 25, 2018 at 8:26 AM Hadley Wickham wrote: > > Hi all, > > Would someone mind pointing to me to the inspiration for the use of > the L suffix to mean "integer"? This is obviously hard to google for, > a

Re: [Rd] conflicted: an alternative conflict resolution strategy

>> conflicted applies a few heuristics to minimise false positives (at the >> cost of introducing a few false negatives). The overarching goal is to >> ensure that code behaves identically regardless of the order in which >> packages are attached. >> >> - A number of packages provide a function t

[Rd] Where does L come from?

Hi all, Would someone mind pointing to me to the inspiration for the use of the L suffix to mean "integer"? This is obviously hard to google for, and the R language definition (https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Constants) is silent. Hadley -- http://hadley.nz __

Re: [Rd] conflicted: an alternative conflict resolution strategy

On Fri, Aug 24, 2018 at 4:28 AM Joris Meys wrote: > > Dear Hadley, > > There's been some mails from you lately about packages on R-devel. I would > argue that the appropriate list for that is R-pkg-devel, as I've been told > myself not too long ago. People might get confused and think this is ab

Re: [Rd] conflicted: an alternative conflict resolution strategy

On Thu, Aug 23, 2018 at 3:46 PM Duncan Murdoch wrote: > > First, some general comments: > > This sounds like a useful package. > > I would guess it has very little impact on runtime efficiency except > when attaching a new package; have you checked that? It adds one extra element to the search pa

[Rd] conflicted: an alternative conflict resolution strategy

Hi all, I’d love to get your feedback on the conflicted package, which provides an alternative strategy for resolving ambiugous function names (i.e. when multiple packages provide identically named functions). conflicted 0.1.0 is already on CRAN, but I’m currently preparing a revision (

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

Since you're already using bang-bang ;) library(rlang) dots1 <- function(...) as.list(substitute(list(...)))[-1L] dots2 <- function(...) as.list(substitute(...())) dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]] dots4 <- function(...) exprs(...) bench::mark( dots1(1+2, "a", rno

Re: [Rd] vctrs: a type system for the tidyverse

On Thu, Aug 9, 2018 at 4:26 PM jan Vitek wrote: > > > I'm now confident that I > > can avoid using "type" by itself, and instead always use it in a > > compound phrase (like type system) to avoid confusion. That leaves the > > `.type` argument to many vctrs functions. I'm considering change it to

Re: [Rd] vctrs: a type system for the tidyverse

> > As Gabe mentioned (and you've explained about) the term "type" > > is really confusing here. As you know, the R internals are all > > about SEXPs, TYPEOF(), etc, and that's what the R level > > typeof(.) also returns. As you want to use something slightly > > different, it should be different

Re: [Rd] vctrs: a type system for the tidyverse

On Thu, Aug 9, 2018 at 7:54 AM Joris Meys wrote: > > Hi Hadley, > > my point actually came from a data analyst point of view. A character > variable is something used for extra information, eg the "any other ideas?" > field of a questionnaire. A categorical variable is a variable describing > c

Re: [Rd] vctrs: a type system for the tidyverse

On Thu, Aug 9, 2018 at 3:57 AM Joris Meys wrote: > > I sent this to Iñaki personally by mistake. Thank you for notifying me. > > On Wed, Aug 8, 2018 at 7:53 PM Iñaki Úcar wrote: > > > > > For what it's worth, I always thought about factors as fundamentally > > characters, but with restrictions:

Re: [Rd] vctrs: a type system for the tidyverse

>> So we say that a >> factor `x` has finer resolution than factor `y` if the levels of `y` >> are contained in `x`. So to find the common type of two factors, we >> take the union of the levels of each factor, given a factor that has >> finer resolution than both. > > I'm not so sure. I think a mo

Re: [Rd] vctrs: a type system for the tidyverse

> > I now have a better argument, I think: > > > If you squint your brain a little, I think you can see > > that each set of automatic coercions is about increasing > > resolution. Integers are low resolution versions of > > doubles, and dates are low resolution versions of >

Re: [Rd] vctrs: a type system for the tidyverse

>>> Method dispatch for `vec_c()` is quite simple because associativity and >>> commutativity mean that we can determine the output type only by >>> considering a pair of inputs at a time. To this end, vctrs provides >>> `vec_type2()` which takes two inputs and returns their common type >>> (repres

Re: [Rd] vctrs: a type system for the tidyverse

I do want to emphasise that it's a type system, not a oo system, in that coercions are not defined by superclass/subclass relationships. > More thoughts inline. > > On Mon, Aug 6, 2018 at 9:21 AM, Hadley Wickham wrote: >> >> Hi all, >> >> I wanted to share with

[Rd] vctrs: a type system for the tidyverse

Hi all, I wanted to share with you an experimental package that I’m currently working on: vctrs, . The motivation for vctrs is to think deeply about the output “type” of functions like `c()`, `ifelse()`, and `rbind()`, with an eye to implementing one strategy throug

Re: [Rd] Is NULL a vector?

On Mon, Jul 23, 2018 at 2:17 PM, Duncan Murdoch wrote: > On 23/07/2018 3:03 PM, Hadley Wickham wrote: >> >> Hi all, >> >> Would you generally consider NULL to be a vector? > > > According to the language definition (in the doc directory), it is not: > &

[Rd] Is NULL a vector?

Hi all, Would you generally consider NULL to be a vector? Base R functions are a little inconsistent: ## In favour ``` r identical(as.vector(NULL), NULL) #> [1] TRUE identical(as(NULL, "vector"), NULL) #> [1] TRUE # supports key vector vector generics length(NULL) #> [1] 0 NULL[c(3, 4, 5)] #>

Re: [Rd] Testing for vectors

On Sat, Jul 7, 2018 at 11:19 PM, Gabe Becker wrote: > Hadley, > > > On Sat, Jul 7, 2018 at 1:32 PM, Hadley Wickham wrote: >> >> On Sat, Jul 7, 2018 at 1:50 PM, Gabe Becker wrote: >> > Hadley, >> > >> >> >> >> I was thinking prima

Re: [Rd] Testing for vectors

On Sat, Jul 7, 2018 at 3:48 PM, Ott Toomet wrote: > Thanks, Hadley for bringing this up:-) > > I am teaching R and I can suggest 5 different definitions of 'vector': > > a) vector as a collection of homogeneous objects, indexed by [ ] (more > precisely atomic vector). Sometimes you hear that in R

Re: [Rd] Testing for vectors

On Sat, Jul 7, 2018 at 1:50 PM, Gabe Becker wrote: > Hadley, > >> >> I was thinking primarily of completing the set of is.matrix() and >> is.array(), or generally, how do you say: is `x` a 1d dimensional >> thing? > > > Can you clarify what you mean by dimensionality sense and specifically 1d > he

Re: [Rd] Testing for vectors

On Sat, Jul 7, 2018 at 12:54 PM, Duncan Murdoch wrote: > On 07/07/2018 1:20 PM, Hadley Wickham wrote: >> >> Hi all, >> >> Is there are base function that I've missed that tests if an object is >> a vector in the dimensionality sense, rather than the data s

[Rd] Testing for vectors

Hi all, Is there are base function that I've missed that tests if an object is a vector in the dimensionality sense, rather than the data structure sense? i.e. something that checks is.null(dim(x)) ? is.vector() is trivially disqualified since it also checks for the presence of non-names attribut

Re: [Rd] Subsetting the "ROW"s of an object

On Fri, Jun 8, 2018 at 2:09 PM, Berry, Charles wrote: > > >> On Jun 8, 2018, at 1:49 PM, Hadley Wickham wrote: >> >> Hmmm, yes, there must be some special case in the C code to avoid >> recycling a length-1 logical vector: > > > Here is a version that (I

Re: [Rd] Subsetting the "ROW"s of an object

s 46.3ms On Fri, Jun 8, 2018 at 12:31 PM, Berry, Charles wrote: > > >> On Jun 8, 2018, at 11:52 AM, Hadley Wickham wrote: >> >> On Fri, Jun 8, 2018 at 11:38 AM, Berry, Charles wrote: >>> >>> >>>> On Jun 8, 2018, at 10:37 AM, Hervé Pagè

Re: [Rd] Subsetting the "ROW"s of an object

matrix(raw(0), nrow = 5, ncol = 0)[1:3, TRUE] : >>(subscript) logical subscript too long > > OK. But this is easy enough to handle. > >> >> H. >> >> On 06/08/2018 10:29 AM, Hadley Wickham wrote: >>> I suspect this will have suboptimal performance since the

Re: [Rd] Subsetting the "ROW"s of an object

I suspect this will have suboptimal performance since the TRUEs will get recycled. (Maybe there is, or could be, ALTREP, support for recycling) Hadley On Fri, Jun 8, 2018 at 10:16 AM, Berry, Charles wrote: > > >> On Jun 8, 2018, at 8:45 AM, Hadley Wickham wrote: >> >>

[Rd] Subsetting the "ROW"s of an object

Hi all, Is there a better to way to subset the ROWs (in the sense of NROW) of an vector, matrix, data frame or array than this? subset_ROW <- function(x, i) { nd <- length(dim(x)) if (nd <= 1L) { x[i] } else { dims <- rep(list(quote(expr = )), nd - 1L) do.call(`[`, c(list(quote(

Re: [Rd] download.file does not process gz files correctly (truncates them?)

On Tue, May 8, 2018 at 8:15 AM, Hadley Wickham wrote: > On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera > wrote: >> On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: >>> >>> Also, as mentioned in my >>> https://stat.ethz.ch/pipermail/r-devel/2012-August/0

Re: [Rd] download.file does not process gz files correctly (truncates them?)

On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera wrote: > On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: >> >> Also, as mentioned in my >> https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when >> not specifying the mode argument, the default on Windows is mode = "w" >> *except* for

Re: [Rd] length of `...`

On Thu, May 3, 2018 at 9:50 AM, Duncan Murdoch wrote: > On 03/05/2018 11:18 AM, Duncan Murdoch wrote: >> >> On 03/05/2018 11:01 AM, William Dunlap via R-devel wrote: >>> >>> In R-3.5.0 you can use ...length(): >>> > f <- function(..., n) ...length() >>> > f(stop("one"), stop("two"), stop("

Re: [Rd] length of `...`

On Thu, May 3, 2018 at 8:28 AM, Hadley Wickham wrote: > On Thu, May 3, 2018 at 8:00 AM, Gabe Becker wrote: >> As of 3.5.0 the ...length() function does exactly what you are asking for. >> Before that, I don't know of an easy way to get the length without >> evaluatio

Re: [Rd] length of `...`

On Thu, May 3, 2018 at 8:18 AM, Duncan Murdoch wrote: > On 03/05/2018 11:01 AM, William Dunlap via R-devel wrote: >> >> In R-3.5.0 you can use ...length(): >>> f <- function(..., n) ...length() >>> f(stop("one"), stop("two"), stop("three"), n=7) >>[1] 3 >> >> Prior to that substitute()

Re: [Rd] length of `...`

On Thu, May 3, 2018 at 8:00 AM, Gabe Becker wrote: > As of 3.5.0 the ...length() function does exactly what you are asking for. > Before that, I don't know of an easy way to get the length without > evaluation via R code. There may be one I'm not thinking of though, I > haven't needed to do this m

Re: [Rd] predict.glm returns different results for the same model

On Fri, Apr 27, 2018 at 7:28 AM, Duncan Murdoch wrote: > On 27/04/2018 9:25 AM, Hadley Wickham wrote: >> >> Hi all, >> >> Very surprising (to me!) and mystifying result from predict.glm(): the >> predictions vary depending on whether or not I use ns() or

[Rd] predict.glm returns different results for the same model

Hi all, Very surprising (to me!) and mystifying result from predict.glm(): the predictions vary depending on whether or not I use ns() or splines::ns(). Reprex follows: library(splines) set.seed(12345) dat <- data.frame(claim = rbinom(1000, 1, 0.5)) mns <- c(3.4, 3.6) sds <- c(0.24, 0.35) dat$wi

[Rd] Base R examples that write to current working directory

Hi all, Given the recent CRAN push to prevent examples writing to the working directory, is there any interest in fixing base R examples that write to the working directory? A few candidates are the graphics devices, file.create(), writeBin(), writeChar(), write(), and saveRDS(). I'm sure there ar

Re: [Rd] Best practices in developing package: From a single file

On Thu, Feb 1, 2018 at 4:29 AM, Duncan Murdoch wrote: > On 31/01/2018 6:59 AM, Duncan Murdoch wrote: >> >> On 30/01/2018 11:39 PM, Hadley Wickham wrote: > > [ lots deleted ] >>> >>> Personally, I don't find writing in comments any harder than writing &

Re: [Rd] Best practices in developing package: From a single file

>> There is package.skeleton() in base R as you already mentioned. It drove >> me >> bonkers that it creates packages which then fail R CMD check, so I wrote a >> wrapper package (pkgKitten) with another helper function (kitten()) which >> calls the base R helper and then cleans up it---but otherwi

Re: [Rd] Best practices in developing package: From a single file

On Tue, Jan 30, 2018 at 4:55 PM, Duncan Murdoch wrote: > On 30/01/2018 4:30 PM, Kenny Bell wrote: >> >> In response to Duncan regarding the use of roxygen2 from the point of view >> of a current user, I believe the issue he brings up is one of correlation >> rather than causation. > > > Could be.

Re: [Rd] R CMD check warning about compiler warning flags

On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley wrote: > On 20/12/2017 17:42, Winston Chang wrote: >> >> On recent builds of R-devel, R CMD check gives a WARNING when some >> compiler warning flags are detected, such as -Werror, because they are >> non-portable. This appears to have been added

Re: [Rd] Small performance bug in [.Date

> Yes, at least so it looks in src/main/objects.c > > Also, we had a very similar change a while ago : > > r65926 | luke | 2014-06-12 15:54:38 +0200 (Thu, 12. Jun 2014) | 2 Zeilen > Geänderte Pfade: >M src/library/base/R/

[Rd] Small performance bug in [.Date

Hi all, I think there's an unnecessary line in [.Date which has a considerable impact on performance when subsetting large dates: x <- Sys.Date() + 1:1e6 microbenchmark::microbenchmark(x[1]) #> Unit: microseconds #> expr min lq mean median uq max neval #> x[1] 920.65

Re: [Rd] [WISH / PATCH] possibility to split string literals across multiple lines

On Fri, Jun 16, 2017 at 1:14 PM, Gábor Csárdi wrote: > On Fri, Jun 16, 2017 at 7:04 PM, Radford Neal wrote: >>> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: >>> >>> > I like the idea of string literals, but the C/C++ way clearly does not >>> > work. The Python/Julia way might, i.e.: >>> > >>> > """th

Re: [Rd] [WISH / PATCH] possibility to split string literals across multiple lines

>> I don't think it is reasonable to change the parser this way. This is >> currently valid R code: >> >> a <- "foo" >> "bar" >> >> and with the new syntax, it is also valid, but with a different >> meaning. Or you can even consider >> >> a <- "foo" >> bar %>% func() %>% print() >> >> etc. >> >> I

Re: [Rd] [WISH / PATCH] possibility to split string literals across multiple lines

On Wed, Jun 14, 2017 at 8:48 AM, Simon Urbanek wrote: > As I recall this has been discussed at least a few times (unfortunately I'm > traveling so can't check the references), but the justification was never > satisfactory. > > Personally, I wouldn't mind string continuation supported since it m

Re: [Rd] A few suggestions and perspectives from a PhD student

> There are tradeoffs. As demonstrated above, the pipe is clearly > inferior in that it is doing a lot of complicated stuff under the > hood, and when you try to traceback() through the call stack you have > to sift through all that complicated stuff. That's a pretty big > drawback in my opinion.

Re: [Rd] RFC: (in-principle) native unquoting for standard evaluation

On Mon, Mar 20, 2017 at 8:00 AM, Hadley Wickham wrote: > On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal wrote: >> Michael Lawrence (as last in long series of posters)... >> >>> Yes, it would bind the language object to the environment, like an >>> R-level promis

Re: [Rd] RFC: (in-principle) native unquoting for standard evaluation

On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal wrote: > Michael Lawrence (as last in long series of posters)... > >> Yes, it would bind the language object to the environment, like an >> R-level promise (but "promise" of course refers specifically to just >> _lazy_ evaluation). >> >> For the uqs()

Re: [Rd] RFC: (in-principle) native unquoting for standard evaluation

Would this return a quosure? (i.e. a single sided formula that captures both expression and environment). That's the data structure we've adopted in tidyeval as it already has some built in support. Hadley On Friday, March 17, 2017, Michael Lawrence wrote: > Interesting idea. Lazy and non-stand

Re: [Rd] RFC: (in-principle) native unquoting for standard evaluation

What would you propose for the unquote-splice operator? Hadley On Friday, March 17, 2017, Jonathan Carroll wrote: > (please be gentle, it's my first time) > > I am interested in discussions (possibly reiterating past threads -- > searching didn't turn up much) on the possibility of supporting s

Re: [Rd] can we override "if" in R?

On Sun, Mar 5, 2017 at 8:13 PM, Gábor Csárdi wrote: > Because the S3 class system is very informal. E.g. if you happen to > have an `if.whatever` function, that will be automatically a method of > your generic. For example: x <- structure(1:10, class = "test") t(x) #> #> One Sample t-test #> #>

Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

> But, how you propose a warning-to-error transition should be made > without wreaking havoc? Just flip the switch in R-devel and see CRAN > and Bioconductor packages break overnight? Particularly Bioconductor > devel might become non-functional (since at times it requires > R-devel). For my own

Re: [Rd] How to handle INT8 data

To summarise this thread, there are basically three ways of handling int64 in R: * coerce to character * coerce to double * store in double There is no ideal solution, and each have pros and cons that I've attempted to summarise below. ## Coerce to character This is the easiest approach if the

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham wrote: >> >> One possibility would also be to consider a "numbers-only" or >> >> rather "same type"-only {e.g., would also work for characters} >> >> version. >> >>

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

> >> One possibility would also be to consider a "numbers-only" or > >> rather "same type"-only {e.g., would also work for characters} > >> version. > > > I don't know what you mean by these. > > In the mean time, Bob Rudis mentioned dplyr::if_else(), > which is very relevant, th

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

; > On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham wrote: >> >> When it was being actively worked on, it had the advantage of existing. >> >> Hadley >> >> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell wrote: >> > Why is the described system preferable

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

When it was being actively worked on, it had the advantage of existing. Hadley On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell wrote: > Why is the described system preferable to Julia? > > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard wrote: > >> >> On 05 Aug 2016, at 06:41 , Andrew Judson wrote: >>

Re: [Rd] String encoding problem

>>> I'm not sure what should happen here, but that's not a legal string in a >>> UTF-8 locale, so it's not too surprising that things go wonky. >> >> Here's bit more context on how I got that sequence of bytes: >> >> x <- "こんにちは" >> y <- iconv(x, to = "Shift-JIS") >> Encoding(y) >> y >> >> I did th

Re: [Rd] String encoding problem

On Thu, Jul 7, 2016 at 10:11 AM, Duncan Murdoch wrote: > On 07/07/2016 10:57 AM, Hadley Wickham wrote: >> >> If you print: >> >> "\xc9\x82\xbf" >> >> you get >> >> "\u0242\xbf" >> >> But if you try and evaluate

[Rd] String encoding problem

If you print: "\xc9\x82\xbf" you get "\u0242\xbf" But if you try and evaluate that string you get: > "\u0242\xbf" Error: mixing Unicode and octal/hex escapes in a string is not allowed (Probably will only happen on mac/linux with default utf-8 encoding) Hadley -- http://hadley.nz __

Re: [Rd] recursion problem using do.call(rbind, list(..,,..))

Hi Martin, I think this is a general problem with any function that does dispatch on ... - I think for well-defined behaviour you always need to dispatch on pairs, folding/reducing (like in your code) to get a single value. The downside of this approach is obviously performance: for n inputs, you

Re: [Rd] S3 dispatch for S4 subclasses only works if variable "extends" is accessible from global environment

This might be too big a change - but is it worth reconsidering the behaviour of Rscript? Maybe the simplest fix would be simply to always load the methods package. (I think historically it didn't because loading methods took a long time, but that is no longer true) Hadley On Tue, Apr 19, 2016 at

Re: [Rd] (no) circular dependency

In that scenario, I would expect that QCA would suggest Venn and Venn would suggest QCA. Then there's no circular dependency problem. Hadley On Fri, Apr 8, 2016 at 6:59 AM, Adrian Dușa wrote: > Hi Mark, > > Uhm... sometimes this is not always possible. > For example I have a package QCA which pr

Re: [Rd] Suggested dependencies in context of R CMD check

On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: > Dear R team, > > Are suggested dependencies mandatory in context of `R CMD check` when > using env var `_R_CHECK_FORCE_SUGGESTS_=FALSE`? > > Suggested dependencies are nice because are optional. > But that feature often isn't valid when trying t

Re: [Rd] Data frame printing buglet when multiple empty column names

On Tue, Mar 1, 2016 at 12:48 PM, Martin Maechler wrote: >>>>>> Hadley Wickham >>>>>> on Tue, 1 Mar 2016 09:12:00 -0600 writes: > > > This is admittedly minor, and you shouldn't have repeated names in a > > data fra

[Rd] Data frame printing buglet when multiple empty column names

This is admittedly minor, and you shouldn't have repeated names in a data frame anyway, but: df <- data.frame(1:3, 1:3, 1:3) # Ok setNames(df, c("x", "y", "")) # Not ok setNames(df, c("x", "", "")) Hadley -- http://hadley.nz __ R-devel@r-project.or

  1   2   3   4   5   6   7   8   >