[Rd] An argument promise containing bytecode?

Dear all, I was playing around with some C code that inspects argument promises and I noticed that forwarded arguments sometimes contain bytecode in the PRCODE component. E.g. if I have a nested call like this: f <- function(x) x g <- function(x) f(x) g(1+1) and inspect the value of “x”

Re: [Rd] An argument promise containing bytecode?

lled > Just-In-Time (JIT) compilation - see ?enablleJIT in R, it is enabled by > default, so the function will be compiled on second use. > > Cheers, > Simon > > > >> On Mar 7, 2021, at 11:12 PM, Taras Zakharko wrote: >> >> Dear all, >> >>

Re: [Rd] 1954 from NA

Hi Adrian, Have a look at vctrs package — they have low-level primitives that might simplify your life a bit. I think you can get quite far by creating a custom type that stores NAs in an attribute and utilizes vctrs proxy functionality to preserve these attributes across different operations.

[Rd] S3 dispatch does not work for generics defined inside an environment

Dear all, I have a generic function and a bunch of methods defined in a separate environment. Here is a reduced example: env <- local({ # define the generic function and the method myfun <- function(x) UseMethod("myfun") myfun.myclass <- function(x) print("called myfun.myclas

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

g __S3MethodsTable__ into .GlobalEnv (which is my topenv here). I can open a bug report, but I would like to wait for some more comments. Best, Taras > On 30 Jun 2021, at 12:39, Joshua Ulrich wrote: > > On Wed, Jun 30, 2021 at 5:17 AM Duncan Murdoch > wrote: >> >

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

un) else topenv(environment(genfun)) in order to match the behavior of do_usemethod() Best, Taras > On 30 Jun 2021, at 12:51, Taras Zakharko wrote: > > @Duncan: .S3method() calls registerS3method() with appropriate environmental > argument under the good, so that’s not the probl

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

isFALSE(Sys.getenv("_R_S3_METHOD_LOOKUP_USE_TOPENV_AS_DEFENV_”)) >> environment(genfun) else topenv(environment(genfun)) >> in order to match the behavior of do_usemethod() >> Best, >> Taras >>> On 30 Jun 2021, at 12:51, Taras Zakharko wrote: >>> &

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

Thanks Duncan, I will submit a bug report to R core then. Best, Taras > On 30 Jun 2021, at 14:16, Duncan Murdoch wrote: > > On 30/06/2021 7:37 a.m., Taras Zakharko wrote: >> Thats not how I read the code? Consider this snippet from registerS3method: >> genfun <- ge

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

to FALSE, it > shouldn't need to make any changes. > > Duncan Murdoch > > On 30/06/2021 9:20 a.m., Taras Zakharko wrote: >> Thanks Duncan, I will submit a bug report to R core then. >> Best, >> Taras >>> On 30 Jun 2021, at 14:16, Duncan Murdoch wr

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

Hi Greg, That was my original plan as well, but managing and deploying dozens of little packages that are all under active development is a nightmare even with devtools. Just too much overhead, not to mention that coming up with names that would not have namespace conflicts was getting silly.

Re: [Rd] On read.csv and write.csv

Stephen, I am sure one can find a lot of small issues and inconsistencies with R and it’s standard library. It has to support a lot of legacy cruft and the design process — especially in the early days — focused on getting things done rather than delivering a standard library of immaculate qua

Re: [Rd] S3 dispatch does not work for generics defined inside an environment

Thanks Johannes, I was aware of the modules package (it was not suitable for my needs unfortunately), but I did not know about box… somehow I managed to completely miss it in my search (embarrassing, really). My own package offers similar functionality to box, but is designed to closely fol

[Rd] JIT compiler does not compile closures with custom environments

I have encountered a behavior of R’s JIT compiler that I can’t quite figure out. Consider the following code: f_global <- function(x) { for(i in 1:1) x <- x + 1 x } f_env <- local({ function(x) { for(i in 1:1) x <- x + 1 x } }) compiler::ena

Re: [Rd] JIT compiler does not compile closures with custom environments

onvenient as JIT, but it gets the job done... > > Duncan Murdoch > > On 18/08/2021 10:33 a.m., Duncan Murdoch wrote: >> On 18/08/2021 9:00 a.m., Taras Zakharko wrote: >>> I have encountered a behavior of R’s JIT compiler that I can’t quite figure >>> out. Consider the

Re: [Rd] [External] JIT compiler does not compile closures with custom environments

Thanks for the explanation, Luke! I’ll keep this behavior in mind. > On 18 Aug 2021, at 16:45, luke-tier...@uiowa.edu wrote: > > On Wed, 18 Aug 2021, Duncan Murdoch wrote: > >> On 18/08/2021 9:00 a.m., Taras Zakharko wrote: >>> I have encountered a behavior of R’

Re: [Rd] string concatenation operator (revisited)

Great summary, Avi. String concatenation cold be trivially added to R, but it probably should not be. You will notice that modern languages tend not to use “+” to do string concatenation (they either have a custom operator or a special kind of pattern to do it) due to practical issues such an

Re: [Rd] string concatenation operator (revisited)

, or build it directly from expressions). — Taras > On 7 Dec 2021, at 12:06, Simon Urbanek wrote: > > > >> On Dec 7, 2021, at 22:09, Taras Zakharko > <mailto:taras.zakha...@uzh.ch>> wrote: >> >> Great summary, Avi. >> >> String conca

Re: [Rd] String interpolation [Was: string concatenation operator (revisited)]

n would have to happen at a point where it is >> not expected since we can assume today that CHAR() doesn't evaluate. If it's >> just construct that needs some function call to turn it into a real string, >> then that's (from user's perspective) no dif

Re: [Rd] [External] hashtab implementation

Since this topic has came up, may I dare to add some other comments? - it would be great if fast hash computation would be exposed at the R level (existing implementations such as rlang and digest rely on serialisation which adds unnessesry overhead), that would be very useful for many applicat

Re: [Rd] Floating point issue

puzzling indeed. Thanks for the references. > > So in this case, the different results are not due to the architecture (M1 > aka ARM64) but to the system/implementation. > >> On 19 Jul 2022, at 14:22, Taras Zakharko > <mailto:taras.zakha...@uzh.ch>> wrote: >>

[Rd] parent.frame(n) produces different result from sys.frame(sys.parent(n))

Dear all, The documentation states that parent.frame(n) is equivalent to sys.frame(sys.parent(n)) but I have discovered a case where they produce different results. Before I submit a bug report I thought it would be good to run it by the R community in case it’s (somehow?) expected behaviour.

Re: [Rd] parent.frame(n) produces different result from sys.frame(sys.parent(n))

s here, but the > use of evalq and sys.parent makes me think these issues: > > https://bugs.r-project.org/show_bug.cgi?id=17849 > https://bugs.r-project.org/show_bug.cgi?id=15531 > > are possibly related. > > Best, > > B. > > > > On Wednesday, Septem

[Rd] A delayedAssign() variant for quoted expressions

It is sometimes useful to create a promise using a constructed expression, but delayedAssign will always substitute the expression argument. I am currently using this pattern to achieve this: expr <- bquote(…) eval(call("delayedAssign", x, expr, eval.env = eval_env)) But it would be nice if bas