similar to: confusing all.equal output

I believe the wording goes back to Martin Maechler many moons ago (AFAICT towards the end of the last millennium.) We might leave it to him to change it? - Peter D. > On 2 Mar 2023, at 19:30 , avi.e.gross at gmail.com wrote: > > I think if you step back, you can ask what the purpose of an error message > is and who designs it. > > Is the message for the developer or others

Trace adds something to the body of the function, so it does make sense that it doesn't. Whether traced functions still technically meet the definition of standard s3 generic or not is, I suppose, up for debate, but I would say that they should, I think. As before, if desired I can work on a patch for this if desired, or someone on R-core can just take care of it if that is easier. Best, ~G

Please note that this is documented in ?trace. "fun" is matched to what, it is a _name_ of the function to be traced, which is traced in the top-level environment. I don't know why it was designed this way, but it is documented in detail, and hence the expected behavior. Debugging is often, and also in R, implemented in the core. Tracing is implemented on top without specific

Dear R-devel, I found this behavior disturbing, if `1 + f()` is called, `sys.call()` called inside of `f` will return a quoted `f()` with a "srcref" that prints "1 + f()". I don't know which one is good but I don't think they can be correct at the same time. Here's a reproducible example: f <- function(){ sc <- sys.call() print(sc) attr(sc,

>>>>> Gabriel Becker writes: > I added that so I can look at the proposed fix and put it or something > similar in bugzilla for review final review. > Apologies for the oversight. Fixed now with - while(as.character(bdexpr[[1L]]) == "{") + while(is.call(bdexpr) && (as.character(bdexpr[[1L]]) == "{")) (the suggested fix does not work on

Dear R-devel, I don't think this is expected : foo <- function() "hello" trace2 <- function(fun) trace(fun, quote(print("!!!"))) base::fun # Object with tracing code, class "functionWithTrace" # Original definition: # function() "hello" # # ## (to see the tracing code, look at body(object)) `untrace()` has the same behavior. This is

Do I understand correctly that we don't want Rd files to be valid latex ? This seems odd to me. I see that `tools::parse_Rd()` doesn't like `\verb!foo!` so maybe roxygen2 is actually doing the right thing (as opposed to just trying to) ? `parse_Rd() ` is probably what I need indeed, for some reason I hadn't found it, so that should fix my own issue here thanks a lot. Le ven. 21 juil.

I am probably mistaken but it looks to me like the design of much of the data.frame infrastructure not only does not insist you give columns names, but even has all kinds of options such as check.names and fix.empty.names https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/data.frame During the lifetime of a column, it can get removed, renamed, transfomed in many ways and so on. A

Surprisingly this invalid latex syntax is still formatted "right" in the html output. On a closer look it seems like roxygen2 introduces those, when using markdown backtick quoting, if the quoted content is not syntactic. For instance: #' `c(c(1)` #' `c(c(1))` Will convert the first line to `\verb{c(c(1)}` and the second to `\code{c(c(1))}`. I've opened a ticket there FYI:

>>>>> Gabriel Becker >>>>> on Thu, 2 Mar 2023 14:37:18 -0800 writes: > On Thu, Mar 2, 2023 at 2:02?PM Antoine Fabri > <antoine.fabri at gmail.com> wrote: >> Thanks and good point about unspecified behavior. The way >> it behaves now (when it doesn't ignore) is more >> consistent with data.frame() though so I

Dear R-devel, utils::isS3stdGeneric tries to subset the body of the function it's fed, primitives don't like that because they don't have a body, identity doesn't like it either because it's body is a symbol. According to the doc, any function is a legal input. See below: identity #> function (x) #> x #> <bytecode: 0x0000000013d6da28> #> <environment:

? Fri, 21 Jul 2023 15:14:09 +0200 Antoine Fabri <antoine.fabri at gmail.com> ?????: > On a closer look it seems like roxygen2 introduces those, when using > markdown backtick quoting, if the quoted content is not syntactic. For > instance: > > #' `c(c(1)` > #' `c(c(1))` > > Will convert the first line to `\verb{c(c(1)}` and the second to >

Hi John, Thanks, but the Bizzaro pipe comes with many flaws though : * It's not a single operator * It has a different precedence * It cannot be used in a subcall * The variable assigned to must be on the right * It doesn't trigger indentation when going to the line * It creates/overwrite a `.` variable in the worksace. And it doesn't deal gracefully with some lazy evaluation edge

On Thu, Mar 2, 2023 at 2:02?PM Antoine Fabri <antoine.fabri at gmail.com> wrote: > Thanks and good point about unspecified behavior. The way it behaves now > (when it doesn't ignore) is more consistent with data.frame() though so I > prefer that to a "warn and ignore" behaviour: > > data.frame(a = 1, b = 2, 3) > > #> a b X3 > > #> 1 1 2 3

Dear all, The help for `?install.packages` decribes, in the `pkg` argument description : > If this is missing, a listbox of available packages is presented where possible in an interactive R session. In fact running it with a missing argument triggers an error : install.packages() > Error in install.packages : argument "pkgs" is missing, with no default What however

Dear R-devel, The doc of exists, get and get0 is unambiguous, x should be an object given as a character string. However these accept longer inputs. It can lead an uncareful user to think these functions are vectorized when they're not, and generally lets through bugs that one might have preferred to trigger earlier failure. ``` r exists("d") #> [1] FALSE exists(c("c",

Dear R-devel, The most popular piping operator sits in the package `magrittr` and is used by a huge amount of users, and imported /reexported by more and more packages too. Many workflows don't even make much sense without pipes nowadays, so the examples in the doc will use pipes, as do the README, vignettes etc. I believe base R could have a piping operator so packages can use a pipe in

Dear r-devel, I was surprised to see that saveRDS() and readRDS() work quite well with environments, see below: ``` z <- 3 # in global env y <- new.env() y$a <- 1 x <- new.env(parent = y) x$b <- 2 saveRDS(x, "x.RDS") # in a new session x <- readRDS("x.RDS") y <- parent.env(x) x$b #> [1] 2 y$a #> [1] 1 parent.env(y) #> <environment:

The "good reason" is all the tooling in R doesn't work with subfolders and would have to be rewritten. All the package check and build stuff. And that's assuming you don't want to change the basic flat package structure - for example to allow something like `library(foo)` to attach a package and `library(foo.bar)` to attach some subset of package `foo`. That would require

I noticed the recent commit to R-dev (r79434). Is this wise? I've often used get() in constructions like for (j in ls()) if (is.numeric(x <- get(j))) ... (and often interactively, rather than in a package) Am I to understand that get(j) will now be equivalent to `j` even if j is a string referring putatively to another object? On Sat, 14 Nov 2020 at 01:34, <luke-tierney at