Re: [Rd] Choices to remove `srcref` (and its buddies) when serializing objects

> I think one could implement hashing on the fly without any > serialization, similarly to how identical works, but I am not aware of > any existing implementation We have one in vctrs but it's not exported: https://github.com/r-lib/vctrs/blob/main/src/hash.c The main use is vectorised hashing:

Re: [Rd] removeSource() vs. function literals

If you can afford a dependency on rlang, `rlang::zap_srcref()` deals with this. It's recursive over expression vectors, calls (including calls to `function` and their hidden srcref arg), and function objects. It's implemented in C for efficiency as we found it to be a bottleneck in some application

Re: [Rd] Making headers self-contained for static analysis

On 3/16/23, Lionel Henry wrote: > Hello, > > I started using clangd to get better static analysis and code > refactoring tooling with the R sources (using eglot-mode in Emacs, it > just works once you've generated a `compile_commands.json` file with > `bear make all`). I notic

Re: [Rd] isNamespaceLoaded() while the namespace is loading

Hello, We've run into this issue multiple times and it's often a head scratcher when it happens. We are using workarounds but it would be great to fix this for R 4.3. Would an R core member have time to review the patch that we supplied in https://bugs.r-project.org/show_bug.cgi?id=18489 ? Best,

[Rd] Making headers self-contained for static analysis

Hello, I started using clangd to get better static analysis and code refactoring tooling with the R sources (using eglot-mode in Emacs, it just works once you've generated a `compile_commands.json` file with `bear make all`). I noticed that the static analyser can't understand several header files

Re: [Rd] R_GetCurrentEnv() not working as intended

Hello, This function currently does not work when called from `.Call()`. This is reported with a patch at https://bugs.r-project.org/show_bug.cgi?id=17839 In the meantime, you can use this stopgap implementation: https://github.com/tidyverse/purrr/blob/55c9a8ab8788d878ce9e8e80b867139e46d15395/sr

Re: [Rd] R extension memory leak detection question

> Still, memory leaks are possible if the program forgets about a > pointer to some piece of memory no longer needed, and keeps that > pointer in say some global structure. Such memory leaks would not be > found using address sanitizer. We had a few cases of this in the past. Given the difficulty

Re: [Rd] sys.call() 's srcref doesn't match the language

Hello, The source references are useful for debugging tools because they allow linking to call sites in the source files. I agree the output can be confusing. Perhaps this could be fixed by tweaking the print method for calls. If the deparsed call doesn't match the srcref, both could be displayed

Re: [Rd] eval and Calling Frames

Hi Brodie, I wouldn't use the rlang tests as a measure of backward compatibility. Your patch changes the structure of the `parent.frame()` hierarchy, which is likely to be disruptive with packages that do weird NSE stuff (and so, not rlang ;-p). Currently things are set up so that the parent frame

Re: [Rd] Minor Infelicity in Printing of Objects Nested in Lists

Hello, The main reason for resetting the tagbuf in `print.default()` and other entry points to the print routine is that it is currently not reset on exit. Creating a context to reset it on exit to its last value might work. This should be done in the entry points rather than in print-value-rec th

Re: [Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

> Shield res(Rcpp_fast_eval(Rf_lang2(asEnvironmentSym, x), R_GlobalEnv)); The call should be protected before evaluation though. So more like: Shield call(Rf_lang2(asEnvironmentSym, x)); return Rcpp_fast_eval(call, R_GlobalEnv); Best, Lionel On 3/23/20, Dirk Eddelbuettel wrote: > > > On 23 Mar

Re: [Rd] new bquote feature splice does not address a common LISP @ use case?

Hi Jan, In the lisp code you provide the operators are parsed as simple symbols in a pairlist. In the R snippet, they are parsed as left-associative binary operators of equal precedence. If you unquote a call in the right-hand side, you're artificially bypassing the left-associativity of these ope

Re: [Rd] Profiling: attributing costs to place of invocation (instead of place of evaluation)?

There's a patch under review: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17595 Best, Lionel On 2/26/20, Kirill Müller wrote: > Hi > > > Consider the following example: > > f <- function(expr) g(expr) > g <- function(expr) { >   h(expr) > } > h <- function(expr) { >   expr # evaluation

Re: [Rd] [External] Re: should base R have a piping operator ?

On 7 Oct 2019, at 18:17, Tierney, Luke wrote: > Here is a stylized example: The previous value of the binding should only be restored if it existed: g <- function(x, y) { rlang::scoped_bindings(xx = x, .env = parent.frame()) y get("xx") + 10 } # Good g(1, 2) #> [1] 11 # Still good? g(1,

Re: [Rd] [External] Re: should base R have a piping operator ?

Hi Kevin, > On 7 Oct 2019, at 18:42, Kevin Ushey wrote: > > My understanding is that the '.' placeholder is used so that the magrittr > pipe can be adapted to functions that aren't endomorphic or otherwise easily > pipeable. I would argue that: > > 1. Users could just create their own pipable

Re: [Rd] [External] Re: should base R have a piping operator ?

> On 7 Oct 2019, at 17:04, Tierney, Luke wrote: > > Think about what happens if an > argument in a pipe stage contains a pipe. (Not completely > unreasonable, e.g. for a left_join). It should work exactly as it does in a local environment. ``` `%foo%` <- function(x, y) { env <- parent.fra

Re: [Rd] should base R have a piping operator ?

> On 7 Oct 2019, at 15:36, Duncan Murdoch wrote: > > I think that could be done after parsing at run-time, as described in my > earlier message. Good point. > P.S. Were you just using |> to save typing, or is there a proposal to add a > new operator to the language? That would need pars

Re: [Rd] should base R have a piping operator ?

> > On 7 Oct 2019, at 13:47, Duncan Murdoch wrote: > > On 07/10/2019 4:22 a.m., Lionel Henry wrote: >> Hi Gabe, >>> There is another way the pipe could go into base R that could not be >>> done in package space and has the potential to mitigate some prett

Re: [Rd] should base R have a piping operator ?

Hi Gabe, > There is another way the pipe could go into base R that could not be > done in package space and has the potential to mitigate some pretty > serious downsides to the pipes relating to debugging I assume you're thinking about the large stack trace of the magrittr pipe? You don't need a

Re: [Rd] quiet namespace load is noisy

Hello, I think `quietly` should only silence normal masking messages intended for users and providing information about normal behaviour, such as masking. This is not the case here as the message is about overriding of S3 methods, which has global effect and is rather problematic. It may change b

Re: [Rd] [External] Mitigating Stalls Caused by Call Deparse on Error

We also have a few other suggestions and wishes about backtrace storage and display on the one hand, and display of constructed calls on the other hand. Perhaps it would be better to open a different wishlist item for traceback() to keep the discussions focused? FWIW I think deparsing backtraces l

Re: [Rd] R-Forge > GitHub?

t via R-Forge. There > must be a recommended migration process. > > > I could create a separate version of this package on GitHub, but all > the history would be lost. > > > Thanks again, > Spencer Graves > > > On 2019-06-26 10:35, Lionel

Re: [Rd] R-Forge > GitHub?

> On 26 Jun 2019, at 17:25, Duncan Murdoch wrote: > > R-Forge is mirrored on Github; see https://github.com/rforge/ecdat, for > example. That shows 418 commits in its history; presumably that's the full > R-forge history. I think that's newer than Michael Friendly's gist. > > So I suspect

Re: [Rd] print.() not called when autoprinting

Hi Martin, > On 22 May 2019, at 03:50, Martin Maechler wrote: > > I'm pretty sure that all teaching and documentation about S and R > has suggested that print(f) and auto-printing should result in > the same output _ AFAIR also for S4 objects I agree with the principle that autoprint and pri

Re: [Rd] print.() not called when autoprinting

FWIW it was the intention of the patch to make printing of unclassed functions consistent with other base types. This was documented in the "patch 3" section: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17398 I think we need a general way to customise auto-printing for base types and even

Re: [Rd] Bug in print.default: dispatches to global show instead of methods::show

Hello, This is already fixed in r-devel, I think by this commit: https://github.com/wch/r-source/commit/b59a1526085d1b4375b184d35118c6fd6f003912#diff-12de104c9320556f0e99da345c6fb259

Re: [Rd] Fwd: Re: Best practices in developing package:

> On 1 févr. 2018, at 06:51, Therneau, Terry M., Ph.D. > wrote: > > A second is that I care a lot about documentation so my help files are > fairly long, so much so that the advantage of having the documentation of an > argument > "close" to the declaration of said argument is lost. Good poin

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

On 31 janv. 2018, at 09:08, Gabriel Becker wrote: > it *actively discourages* the bits it doesn't directly support. It may be discouraging to include Rd syntax in roxygen docs but only because the LaTeX-like syntax of Rd is burdensome, not because of roxygen. It is still handy to have inlined Rd

Re: [Rd] issue with promises for time parameter of rep()

Here is the same issue with closures: g <- function(n) { missing(n) } f <- function(n, force) { if (force) { tryCatch(n, error = function(...) NULL) } g(n) } g(`_x`) #> [1] FALSE f(`_x`, force = FALSE) #> [1] FALSE f(`_x`, forc

Re: [Rd] side-effect of calling functions via `::`

e in fact it's immediately clear which symbol is meant. I believe the > compiler should be able to fix that so in principle it shouldn't make a > difference performance wise. > > Cheers, > Simon > > >> On Sep 1, 2017, at 8:03 AM, Martin Maechler >> w

Re: [Rd] side-effect of calling functions via `::`

A package should probably never register a S3 method unless it owns either the generic or the class. Here `formula.tools` owns neither. Instead of registering the method, it should export it like a regular function. This way S3 dispatch is based on lexical scoping rather than session-wide side effe

Re: [Rd] Possible repeat{} / break function bug in R 3.4.1

gt; > It is a bug in the byte-code compiler. I will fix > Tomas > > On 08/23/2017 09:22 AM, Lionel Henry wrote: >> I don't think that's a bug. source() uses eval(), and eval() creates a >> new function-like context frame. In a way expecting `break` to work >>

Re: [Rd] Possible repeat{} / break function bug in R 3.4.1

I don't think that's a bug. source() uses eval(), and eval() creates a new function-like context frame. In a way expecting `break` to work inside source() is like expecting `break` to cross stack frames: my_break <- function() break repeat(my_break()) Lionel > On 23 août 2017, at 09:17,

Re: [Rd] attributes on symbols

It's probably better to make it a runtime error, but note that it's not necessarily a bad idea to add attributes to singleton symbols. Those are used in Emacs Lisp for a variety of purposes. They just need strong conventions (part of that is that in Emacs many symbols are prefixed with a "namespace

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

> Third, there's a lot of nonstandard evaluation going on in all these > packages. Using them inside your own functions requires serious attention > (eg the difference between aes() and aes_() in ggplot2). Actually, even > though I definitely see the merits of these packages in data analysis, the >

Re: [Rd] potential bug in attribute handling for externalptr

This is expected behaviour, pointers are an uncopyable type, just like environments: env <- new.env() env #> structure(env, foo = "bar") env #> #> attr(,"foo") #> [1] "bar" On Fri, Apr 14, 2017 at 11:27 PM, Patrick Perry wrote: > Is the following expected behavior? > > > mkext <- inline::cf

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

ML> For the uqs() thing, expanding calls like that is somewhat orthogonal ML> to NSE. It would be nice in general to be able to write something like ML> mean(x, extra_args...) without resorting to do.call(mean, c(list(x), ML> extra_args)). This is not completely true because splicing is necessari

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

RN> There is an opportunity cost to grabbing the presently-unused unary @ RN> operator for this I don't think this is the case because the parser has to interpret `@` in formal argument lists in a different way than in function calls. Besides, it'd make sense to set up these annotations with a b