Re: [Rd] [External] Re: Patches for CVE-2024-27322

That should do it Sent from my iPad On Apr 30, 2024, at 9:57 AM, Iñaki Ucar wrote:  Many thanks both. I'll wait for Luke's confirmation to trigger the update with the backported fix. Iñaki On Tue, 30 Apr 2024 at 12:42, Dirk Eddelbuettel mailto:e...@debian.org>> wrote: On 30 April 2024 at

Re: [Rd] [External] Re: rpois(9, 1e10)

R uses the C 'int' type for its integer data and that is pretty much universally 32 bit these days. In fact R wont' compile if it is not. That means the range for integer data is the integers in [-2^31, +2^31). It would be good to allow for a larger integer range for R integer objects, and

Re: [Rd] switch to reference counting in R-devel

R-devel has been switched to use reference counting by default with r77508. Building with -DSWITCH_TO_NAMED goes back to the NAMED mechanism. Best, luke On Sun, 24 Nov 2019, luke-tier...@uiowa.edu wrote: > Baring any unforeseen issues R-devel will switch in about a week from > the NAMED

[Rd] switch to reference counting in R-devel

Baring any unforeseen issues R-devel will switch in about a week from the NAMED mechanism to reference counting for determining when objects can be safely mutated in base C code. This is expected to have minimal impact on packages not using unsupported coding practices in their C code. The

Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects

to check for identical strings. CHARSXPs are almost always cached but they are not guaranteed to be, and the caching strategy might change in the future. Best, luke > I cannot do similarly for S4 classes, thus asking for some API for that. > > On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke wrote: &

Re: [Rd] [External] R C api for 'inherits' S3 and S4 objects

On Fri, 1 Nov 2019, Jan Gorecki wrote: > Dear R developers, > > Motivated by discussion about checking inheritance of S3 and S4 > objects (in head matrix/array topic) I would light to shed some light > on a minor gap about that matter in R C API. > Currently we are able to check inheritance for

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

avoiding ... Best, luke On Mon, 7 Oct 2019, Tierney, Luke wrote: > On Mon, 7 Oct 2019, Lionel Henry wrote: > >> >> >>> On 7 Oct 2019, at 17:04, Tierney, Luke wrote: >>> >>> Think about what happens if an >>> argument in a pipe stage

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

to you. I can't see the cost/benefit calculation justifying having it in base. Best, luke On Mon, 7 Oct 2019, Lionel Henry wrote: > 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 i

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

On Mon, 7 Oct 2019, Lionel Henry wrote: > > >> 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

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

On Mon, 7 Oct 2019, 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 pretty >> serious downsides to the pipes relating to debugging > > I assume you're thinking about the large

Re: [Rd] [External] REprintf could be caught by tryCatch(message)

ssible then to request a new function to R C API "message" > that would equivalent to R "message" function? Similarly as we now > have C "warning" and C "error" functions. > > Best, > Jan > > On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke

Re: [Rd] [External] REprintf could be caught by tryCatch(message)

On Sun, 15 Sep 2019, Jan Gorecki wrote: > Dear R-devel community, > > There appears to be an inconsistency in R C API about the exceptions > that can be raised from C code. > Mapping of R C funs to corresponding R functions is as follows. > > error-> stop > warning -> warning > REprintf ->

Re: [Rd] [External] Missing function Rf_findFun3

Best, luke > > Best, > > Laurent > > On Sun, Sep 8, 2019, 8:27 AM Tierney, Luke wrote: > On Sat, 7 Sep 2019, Laurent Gautier wrote: > > > Hi, > > > > > > The function `Rf_findFun3` is declared in >

Re: [Rd] [External] Missing function Rf_findFun3

On Sat, 7 Sep 2019, Laurent Gautier wrote: > Hi, > > > The function `Rf_findFun3` is declared in > `$(R CMD CONFIG HOME)/lib/R/include/Rinternals.h` > but appears to be missing from R's shared library (R.so). > > Is this an oversight? No. This is not part of the API supported for use in

Re: [R-pkg-devel] [External] Re: Farming out methods to other packages

You could have your default method handle the cases you can handle; if you want that to dispatch you can use something like recover_data.default <- function(object, ...) default_recover_data(object, ...) default_recover_data <- function(object, ...) UseMethod("default_recover_data")

Re: [Rd] [External] Questions regarding ALTREP_SET_ELT APIs

On Tue, 30 Jul 2019, Wang Jiefei wrote: > Hi all, > > I'm wondering if there is any way to define a `SET_ELT` function for an > ALTREP class? I see there are ` ALTINTEGER_SET_ELT` etc. functions exported > in Rinternal.h, but there is no corresponding ALTREP APIs to define them. > The only way to

Re: [Rd] [External] Re: Any plans for ALTREP lists (VECSXP)?

If one of you wanted to try to create a patch to support ALTREP generic vectors here are some notes: The main challenge I am aware of (there might be others): Allowing DATAPTR to return a writable pointer would be too dangerous because the GC write barrier needs to see all mutations. So it would

Re: [Rd] [External] Any plans for ALTREP lists (VECSXP)?

Eventually, but probably not in the next release. There are many more issues to think through for vectors where the elements can be arbitrary R object, and I don't think there will be time for that soon given other issues on the table. Best, luke On Tue, 23 Jul 2019, Bemis, Kylie wrote: >

Re: [Rd] [External] Re: ALTREP wrappers and factors

On Fri, 19 Jul 2019, Gabriel Becker wrote: > Hi Jiefei and Kylie, > > Great to see people engaging with the ALTREP framework and identifying > places we may need more tooling. Comments inline. > > On Thu, Jul 18, 2019 at 12:22 PM King Jiefei wrote: > >> >> If that is the case and you are 100%

Re: [Rd] [External] What is the best way to determine the version of an `.rds`?

Can you add a wishlist item to bugzilla? Thanks, luke On Mon, 15 Jul 2019, Jennifer Bryan wrote: > Hi, > > I am writing a test that consults the serialization version of an `.rds` > file. > > An attractive way to get this is: > > tools:::get_serialization_version() # reports just version > >

Re: [Rd] [External] Re: Unexpected behaviour when comparing (==) long quoted expressions

On Tue, 16 Jul 2019, Martin Maechler wrote: >> Daniel Chen >> on Fri, 12 Jul 2019 13:53:21 -0500 writes: > >> Hi everyone: >> I’m one of the interns at RStudio this summer working on a project that >> helps teachers grade student code. I found an unexpected behaviour with

Re: [Rd] [External] Potential bug with data.frame replacement

Thanks for the report. The buffer overflow should be fixed in R-patched and R-devel. Best, luke On Sun, 14 Jul 2019, Benjamin Jean-Marie Tremblay wrote: > Dear R-devel, > > I have encountered a crash-inducing scenario and would like to enquire as to > whether this would be considered a bug. To

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

in .Traceback causes > problems I'm not anticipating, then that's different.  > Is that the case? > > Best, > > Brodie. > > [1]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17580 > > On Sunday, July 14, 2019, 8:52:45 AM EDT, Tierney, Luke > wrote: > > >

Re: [Rd] [External] Re: Possible bug in `class<-` when a class-specific '[[.' method is defined

Pasting the entire example into RStudio and hitting return to evaluate does not show this. Evaluating the finall line to print counttt separately does. Looks like RStudio is calling `[[` on your object when examining the environment for the Environment panel. If this concerns you then you should

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

This is probably best viewed in the context of other issue with displaying calls, such as issues arising from calls constructed in non-standard evaluation contexts. Might be good to move to a wishlist item in bugzilla. Best, luke On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote: > When

Re: [Rd] [External] Re: Suggested Patch: Library returns matching installed packages when typo present

On Fri, 21 Jun 2019, Henrik Bengtsson wrote: >> On 6/21/19 10:56 AM, Tierney, Luke wrote: >> [...] >> Something that would be useful and is being considered is having a >> mechanism for registering default condition handlers. This would allow >> the condition to be r

Re: [Rd] [External] Suggested Patch: Library returns matching installed packages when typo present

Thanks for the suggestion. However I don't think it is the right way to go. I also don't care for what install.packages() does. Signaling a warning and then an error means someone has to catch both the error and the warning, or suppress the warning, in order to handle the error programmatically.

Re: [Rd] [External] Re: R C API resize matrix

On Mon, 17 Jun 2019, Simon Urbanek wrote: > Matrix is just a vector with the dim attribute. Assuming it is not referenced > by anyone, you can set any values to the dim attribute. As for the vector, > you can use SET_LENGTH() to shorten it - but I'm not sure how official it is > - it was

Re: [R-pkg-devel] [External] Re: try() in R CMD check --as-cran

A simplified version without a package: Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_"="abort,verbose") tryCatch(1:3 || 1, error = identity) Running this aborts the session since it calls R_Suicide without first signaling a condition to try any available handlers. Should be easy to change, but I don't

Re: [Rd] [External] undefined symbol errors when compiling package using ALTREP API

; added. >> >> Best, >> ~G >> >> On Tue, Jun 4, 2019 at 2:22 PM Mark Klik wrote: >> >>> thanks for clearing that up, so these methods are actually not meant to be >>> exported on Windows and OSX? >>> Some of the ALTREP methods that n

Re: [Rd] [External] undefined symbol errors when compiling package using ALTREP API

On Tue, 4 Jun 2019, Mark Klik wrote: > Hello, > > I'm developing a package (lazyvec) that makes full use of the ALTREP > framework (R >= 3.6.0). > One application of the package is to wrap existing ALTREP vectors in a new > ALTREP vector and pass all calls from R to the contained object. The >

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

On Wed, 22 May 2019, Lionel Henry wrote: > 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

Re: [Rd] [External] make running on.exit expr uninterruptible

suspendInterrupts has dynamic extent, so you need to make sure it covers the entire computation. Defining your f like this is one option: f <- function() { ff <- function() { on.exit(cntr_on.exit <<- cntr_on.exit + 1L) cntr_f <<- cntr_f + 1L ## allowInterrupts(...

Re: [Rd] [External] Patch to replace "his" in Writing R Extensions

Thanks. Addressed in r76559 (trunk) and r76560 (R-3-6-branch). Best, luke On Tue, 21 May 2019, Maëlle SALMON via R-devel wrote: > Dear R-devel team, > > Many thanks for the great resource that is "Writing R Extensions"! > > I noticed two occurrences of "his", one to refer to the R package

Re: [Rd] [External] most robust way to call R API functions from a secondary thread

Your analysis looks pretty complete to me and your solutions seems plausible. That said, I don't know that I would have the level of confidence yet that we haven't missed an important point that I would want before going down this route. Losing stack checking is risky; it might be eventually

Re: [Rd] [External] ALTREP: Bug reports

On Thu, 16 May 2019, 介非王 wrote: > Hello, > > I have encountered two bugs when using ALTREP APIs. > > 1. STDVEC_DATAPTR > > From RInternal.h file it has a comment: > > /* ALTREP support */ >> void *(STDVEC_DATAPTR)(SEXP x); > > > However, this comment might not be true, the easiest way to verify

Re: [Rd] [External] Re: ALTREP: Design concept of alternative string

On Fri, 10 May 2019, 介非王 wrote: > Hi Gabriel, > > Thanks for your explanation, I totally understand that it is almost > impossible to change the data structure of STRSXP. However, what I'm > proposing is not about changing the internal representation, but rather > about how we design and use the

Re: [Rd] [External] Re: Background R session on Unix and SIGINT

A Simon pointed out the interrupt is recorded but not processed until a safe point. When reading from a fifo or pipe R runs non-interactive, which means is sits in a read() system call and the interrupt isn't seen until sometime during evaluation when a safe checkpoint is reached. When reading

Re: [Rd] [External] Status of R_unif_index

Seems reasonable, done now. Best, luke On Fri, 22 Mar 2019, Ralf Stubner wrote: > Dear List, > > section "6.3 Random number generation" of WRE [1] lists unif_rand(), > norm_rand() and exp_rand() as the interface to R's RNG. Now > R_ext/Random.h also has > >double R_unif_index(double); > >

Re: [Rd] [External] Re: stopifnot -- eval(*) inside for()

On Mon, 1 Apr 2019, Martin Maechler wrote: >> Suharto Anggono Suharto Anggono via R-devel >> on Sun, 31 Mar 2019 15:26:13 + writes: > >> Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' >> inside 'for' makes compiled version behave like >> non-compiled

Re: [Bioc-devel] [External] different generator for random integers in R-devel

Use RNGversion("3.5.0") instead. Best, luke On Tue, 19 Mar 2019, Stadler, Michael wrote: > Dear maintainers of the BioC build system > > I have a shy questions regarding R-devel versions on the build machines: > > Currently, these use different versions of R-devel:  > malbec2 | Linux ...   |

Re: [Rd] bug: sample( x, size, replace = TRUE, prob= skewed.probs) produces uniform sample

This is now fixed in R-devel. Best, luke On Sun, 3 Mar 2019, Berry, Charles wrote: > When `length( skewed.probs ) > 200' uniform samples are generated in R-devel. > > R-3.5.1 behaves as expected. > > `epsilon` can be a lot bigger than illustrated and still the uniform > distribution is

Re: [Rd] bug: sample( x, size, replace = TRUE, prob= skewed.probs) produces uniform sample

Thanks. We'll need to look into how best to address this. Best, luke On Sun, 3 Mar 2019, Berry, Charles wrote: > When `length( skewed.probs ) > 200' uniform samples are generated in R-devel. > > R-3.5.1 behaves as expected. > > `epsilon` can be a lot bigger than illustrated and still the

Re: [Rd] issue with sample in R 3.6.0.

Thanks; fixed now in R-devel. Not an issue on Linux/Mac OS but is on 64-bit Windows, where sizeof(long) is 4. Best, luke On Fri, 1 Mar 2019, Joseph Wood wrote: > Hello, > > I think there is an issue in the sampling rejection algorithm in R 3.6.0. > > The do_sample2 function in

Re: [Rd] Intermittent crashes with inset `[<-` command

Fixed in R-devel and R-patched. Best, luke On Wed, 27 Feb 2019, Tierney, Luke wrote: > Thanks for the report. Should be fixed shortly. > > Best, > > luke > > On Tue, 26 Feb 2019, Brian Montgomery via R-devel wrote: > >> The following code crashes after about 300 i

Re: [Rd] Intermittent crashes with inset `[<-` command

On Tue, 26 Feb 2019, Brian Montgomery via R-devel wrote: > The following code crashes after about 300 iterations on my  > x86_64-w64-mingw32 machine on R 3.5.2 --vanilla.   > Others have duplicated this (see  > https://github.com/tidyverse/magrittr/issues/190 if necessary), but I don't > know

Re: [Rd] Intermittent crashes with inset `[<-` command

Thanks for the report. Should be fixed shortly. Best, luke On Tue, 26 Feb 2019, Brian Montgomery via R-devel wrote: > The following code crashes after about 300 iterations on my  > x86_64-w64-mingw32 machine on R 3.5.2 --vanilla.   > Others have duplicated this (see  >

Re: [Rd] bias issue in sample() (PR 17494)

Becker wrote: >>>> Luke, >>>> >>>> I'm happy to help with this. Its great to see this get tackled (I've >>>> cc'ed >>>> Kelli Ottoboni who helped flag this issue). >>>> >>>> I can prepare a patch for the RNGkind re

[Rd] bias issue in sample() (PR 17494)

Before the next release we really should to sort out the bias issue in sample() reported by Ottoboni and Stark in https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf and filed aa a bug report by Duncan Murdoch at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17494. Here are

Re: [Rd] Object.size() should not visit every element for alt-rep strings, or there should be an altstring_objectsize_method

You should really take this up with RStudio. Calling object.size on every top level assignment as they appear to do is a bad idea, even without ALTREP. object.size is only a cheap operation for simple atomic vectors. For anything with recursive sturcture it needs to walk the object, so the effort

Re: [Bioc-devel] Rprintf in a multi-threaded environment

No functions in the R API are safe to call from any thread other than the R main thread. -- Many may need to allocate from the R heap (more as ALTREP evaolves) and that is not thread safe; -- Many (and with some compilation options nearly all) can signal an error, and the subsequent jump

Re: [Rd] Objectsize function visiting every element for alt-rep strings

On Mon, 21 Jan 2019, Martin Maechler wrote: >> Travers Ching >> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > >> I have a toy alt-rep string package that generates >> randomly seeded strings. example: library(altstringisode) >> x <- altrandomStrings(1e8) head(x) [1] >>

Re: [Rd] Compiler + stopifnot bug

Should be fixed in r75946. Best, luke On Fri, 4 Jan 2019, Tierney, Luke wrote: > Thanks for the reports. Will look into it soon and report back. > > Luke > > Sent from my iPhone > >> On Jan 3, 2019, at 2:15 PM, Martin Morgan wrote: >> >> For what it's

Re: [Rd] Compiler + stopifnot bug

Thanks for the reports. Will look into it soon and report back. Luke Sent from my iPhone > On Jan 3, 2019, at 2:15 PM, Martin Morgan wrote: > > For what it's worth this also introduced > >> df = data.frame(v = package_version("1.2")) >> rbind(df, df)$v > [[1]] > [1] 1 2 > >

Re: [Bioc-devel] Aliasing `]` breaks BiocCheck::BiocCheck() version 1.18.0

r closures") >> 8: makeUsageCollector(fun, ...) >> 7: collectUsage(fun, enterGlobal = enter) >> 6: findGlobals(value) >> 5: FUN(X[[i]], ...) >> 4: lapply(objs, FUN = function(obj) { >> value = env[[obj]] >> if (is.function(value)) >>

Re: [Bioc-devel] Aliasing `]` breaks BiocCheck::BiocCheck() version 1.18.0

N(X[[i]], ...) > 4: lapply(objs, FUN = function(obj) { > value = env[[obj]] > if (is.function(value)) > findGlobals(value) > else character(0) > }) > 3: findLogicalRdir(pkgname, c("T", "F")) > 2: checkCodingPractice(package_di

Re: [Bioc-devel] Aliasing `]` breaks BiocCheck::BiocCheck() version 1.18.0

codetools already checks only closures in checkUsageENv and hande checkUsagePackage, so this is anissue on the Bioc side. Best, luke On Tue, 18 Dec 2018, Tierney, Luke wrote: > Codetools should probably be ignoring those. Will have a look > > Sent from my iPhone > >> On Dec

Re: [Bioc-devel] Aliasing `]` breaks BiocCheck::BiocCheck() version 1.18.0

Codetools should probably be ignoring those. Will have a look Sent from my iPhone > On Dec 18, 2018, at 6:54 AM, Shepherd, Lori > wrote: > > Can you please open an issue for this so we don't lose track of it - > > https://github.com/Bioconductor/BiocCheck/issues > > > > Lori Shepherd > >

Re: [Rd] STRING_IS_SORTED claims as.character(1:100) is sorted

Thanks. Fixed in R_devel and R-patched. [STRING_IS_SORTED was not yet used anywhere so this did not affect any computations.] Best, luke On Thu, 15 Nov 2018, Michael Sannella via R-devel wrote: > If I have loaded the C code: >SEXP altrep_STRING_IS_SORTED(SEXP x) >{ >return

Re: [Rd] v3 serialization of compact_intseq altrep should write modified data

Try this C code: SEXP set_intseq_data(SEXP x) { if (MAYBE_SHARED(x)) error("Oops, not supposed to do this!"); void* ptr = DATAPTR(x); ((int*)ptr)[3] = 1234; return R_NilValue; } Lots of things will break if you modify objects that have been marked as immutable (and

Re: [Rd] unlockEnvironment()?

On Wed, 10 Oct 2018, William Dunlap via R-devel wrote: > R lets one lock an environment with both an R function, > base::lockEnvironment, and a C function, R_LockEnvironment, but, as far as > I can tell, no corresponding function to unlock an environment. Is this > omission on principle or just

Re: [Rd] R_ext/Altrep.h should be more C++-friendly

Thanks for the suggestion. Committed in R_devel. Best, luke On Mon, 8 Oct 2018, Michael Sannella wrote: > I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think > it needs two changes: > > 1. add the same __cplusplus check as most of the other header files: >     #ifdef 

Re: [Rd] bug with OutDec option and deferred_string altrep object

This is now fixed in R-devel. Will port to R_patched in due course. R_inspect also now handles pairlists ending with dotted pairs. Best, luke On Tue, 9 Oct 2018, Tierney, Luke wrote: > Thanks for the report. The approach you outlines below should work -- > I'll look into it. > > Be

Re: [Rd] bug with OutDec option and deferred_string altrep object

Thanks for the report. The approach you outlines below should work -- I'll look into it. Best, luke On Mon, 8 Oct 2018, Michael Sannella wrote: > While implementing R's new 'altrep' functionality in the TERR engine, > I discovered a bug in R's 'deferred_string' altrep object: it is not > using

Re: [Rd] Fwd: Bug report: cbind with numeric and raw gives incorrect result

Thanks for the report and patch. Fixed in R-devel and R_patched. Best, luke On Tue, 25 Sep 2018, brodie gaslam via R-devel wrote: > > > For what it's worth the following patch fixes that particular problem on my > system.  I have not checked very carefully to make sure this does not cause >

Re: [Rd] Bias in R's random integers?

Not sure what should happen theoretically for the code in vseq.c, but I see the same pattern with the R generators I tried (default, Super-Duper, and L'Ecuyer) and with with bash $RANDOM using N <- 1 X1 <- replicate(N, as.integer(system("bash -c 'echo $RANDOM'", intern = TRUE))) X2 <-

Re: [Rd] cannot destroy connection (?) created by readLines in a tryCatch

Your guess is wrong. More when I have a sensible keyboard Sent from my iPhone On Dec 15, 2017, at 10:21 AM, Gabriel Becker > wrote: On Thu, Dec 14, 2017 at 12:17 PM, Gábor Csárdi > wrote:

Re: [Rd] Storage of byte code-compiled functions in sysdata.rda

Can you provide a complete reproducible example? Sent from my iPhone > On May 1, 2016, at 6:51 AM, Peter Ruckdeschel > wrote: > > Hi r-devels, > > we are seeing a new problem with our packages RobAStRDA (just new on CRAN, > thanks > to Uwe and Kurt!) and

Re: [Rd] Making parent.env- an error for package namespaces and package imports

I'll look into it Sent from my iPhone On Oct 17, 2014, at 1:13 AM, Karl Millar kmil...@google.com wrote: I'd like to propose a change to the R language so that calling 'parent.env-' on a package namespace or package imports is a runtime error. Currently the documentation warns that it's