similar to: Please avoid direct use of NAMED and SET_NAMED macros

Hi Jiefei and Duncan, I suspect what is likely happening is that one of ENSURE_NAMEDMAX or MARK_NOT_MUTABLE are being hit for x. These used to set named to 3, but now set it to 7 (ie the previous and current NAMEDMAX value, respectively). Because these are macros rather than C functions, its not easy to figure out why one of them is being invoked from do_isvector (a cursory exploration

The build system rolled up R-3.5.0.tar.gz (codename "Joy in Playing") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.5.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard

The build system rolled up R-3.5.0.tar.gz (codename "Joy in Playing") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.5.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard

Can someone please set me straight on why getattrib0 calls SET_NAMED on the SEXP it returns? For example the line : SET_NAMED(CAR(s), 2); appears near the end of getattrib0 here : https://svn.r-project.org/R/trunk/src/main/attrib.c <https://svn.r-project.org/R/trunk/src/main/attrib.c> getattrib() is just reading the value. Shouldn't NAMED be bumped if and when the result of

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 <szwjf08 at gmail.com> wrote: > > If that is the case and you are 100% sure the reference number should be 1 > for your variable *y*, my solution is to call *SET_NAMED *in C++ to reset > the

Hi, I just found a strange increase in the reference number and I'm wondering if there is any reason for it, here is the code. > a=c(1,2,3) > .Internal(inspect(a)) @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3 > is.vector(a) [1] TRUE > .Internal(inspect(a)) @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(7)] (len=3, tl=0) 1,2,3 The variable *a* initially has one

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 transition to reference counting has been in progress for a number of years. Some older notes on this are

Hi All, Well I finally have found the time to get svn working and I have successfully built my own tuned atlas (multi-threaded version) libs and have both the r-devel and r-patched trees building daily on my box. The problem is I still do not have a good idea of the layout and design of R, and typically I "learn by doing" by trying to fix a bug that hits me. Unfortunately ;-)

luke's demonstration of external references, at www.stat.umn.edu/~luke/file_0.0-0.tar.gz (accessible through the developer page) causes a segfault on solaris 2.8 as soon as library(file) is attempted. it runs fine on RH 7.2. the segfault on solaris occured for R 1.5.1 and 1.6 (8-25 image) a quick poke at gdb (which i can only get running for R 1.6, though this bug report is for 1.5.1)

Re ENSURE_NAMEDMAX, I am unsure but think this happens in (src/eval.c at 492): static SEXP forcePromise(SEXP e) { ??? if (PRVALUE(e) == R_UnboundValue) { ??? /* ... SNIP ...*/ ??? val = eval(PRCODE(e), PRENV(e)); ??? /* ... SNIP ...*/ ??? SET_PRSEEN(e, 0); ?? ?SET_PRVALUE(e, val); ?? ?ENSURE_NAMEDMAX(val);???????????????? <<<<<<< HERE ?? ?SET_PRENV(e, R_NilValue); ??? } ???

This is very exciting news. Luke, thank you for all your work on this - I know it's been a long journey. All the best, Henrik On Tue, Dec 3, 2019 at 8:04 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > 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,

Experimenting with altrep objects and v3 serialization, I discovered a possible bug. Calling DATAPTR on a compact_intseq object returns a pointer to the expanded integer sequence in memory. If you modify this data, the object values appear to be changed. However, if the compact_intseq object is then serialized (with version=3), only the original integer sequence info is written. For example,

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 set the value of an ALTREP is through a pointer, which will require that the ALTREP data is in memory. Is it on purpose? Will there be any plan to

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 set the value of an ALTREP is through a pointer, which will > require that

This wouldn't actually work at present as evaluating a promise always sets NAMED to 2. With reference counting it would work so might be worth considering when we switch. Going forward it would be best to use MAYBE_REFERENCED to test whether a duplicate is needed -- this macro is defined appropriately whether R is compiled to use NAMED or reference counting. Best, luke On Fri, 21 Aug 2015,

Does R have a function like the S/S++ unset() function? unset(name) would remove 'name' from the current evaluation frame and return its value. It allowed you to safely avoid some memory copying when calling .C or .Call. E.g., suppose you had C code like #include <R.h> #include <Rinternals.h> SEXP add1(SEXP pX) { int nProtected = 0; int n = Rf_length(pX);

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-tierney at uiowa.edu wrote: > 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

I think the explanation of the NAMED field in the R Internals document is incorrect. In Section 1.1.2, it says: The named field is set and accessed by the SET_NAMED and NAMED macros, and take values 0, 1 and 2. R has a `call by value' illusion, so an assignment like b <- a appears to make a copy of a and refer to it as b. However, if neither a nor b are subsequently

I have encountered a strange behavior of the str function - it seems to modify the object that is displayed. Probably I'm using something unsupported (objects consisting just of an external reference), but still I'm curious as of why this happens. I create (in C code) EXTPTRSXP and associate a class to it via SET_CLASS. Such objects works fine until it's passed to str as the

Hello, I?m experimenting with ALTREP and was wondering if there is a preferred way to create an ALTREP wrapper vector without using .Internal(wrap_meta(?)), which R CMD check doesn?t like since it uses an .Internal() function. I was trying to create a factor that used an ALTREP integer, but attempting to set the class and levels attributes always ended up duplicating and materializing the