search for: listsxp

On Fri, 5 Jul 2024 15:27:50 +0800 Kevin Ushey <kevinushey at gmail.com> wrote: > A common idiom in the R sources is to convert objects between LANGSXP > and LISTSXP by using SET_TYPEOF. However, this is soon going to be > disallowed in packages. Would you mind providing an example where a package needs to take an existing LISTSXP and convert it to a LANGSXP (or vice versa)? I think that Luke Tierney intended to replace the uses of SET_TYPEOF(allocList(...)...

Hi, A common idiom in the R sources is to convert objects between LANGSXP and LISTSXP by using SET_TYPEOF. However, this is soon going to be disallowed in packages. From what I can see, there isn't currently a direct way to convert between these two object types using the available API. At the R level, one can convert calls to pairlists with: > as.call(pairlist(as.symbol(&qu...

...code to avoid having to duplicate the garbage collection mechanics in Go with the obvious risks of error and possible behaviour skew in the future). In doing this work I have some questions that I have not been able to find answers for in the R-ints doc or hadley/r-internals. 1. In R-ints, the LISTSXP SEXP type CDR is said to hold "usually" LISTSXP or NULL. What does the "usually" mean here? Is it possible for the CDR to hold values other than LISTSXP or NULL, and is this?NULL NILSXP or C NULL? I assume that the CAR can hold any type of?SEXP, is this c...

Full_Name: David Bauer Version: 1.9 OS: Linux Submission from: (NULL) (160.91.245.8) In the file gram.y, the xxsubscript function generates a LANGSXP with another LANGSXP as its CDR. I believe that this is a mistake and that the second LANGSXP should be a LISTSXP. The inputs a1, a3 are parameters to the subscript function (a2), and as such they should be in a dotted-pair list. David Bauer --- gram.y.orig 2003-11-15 05:40:35.000000000 -0500 +++ gram.y 2004-07-06 13:45:10.000000000 -0400 @@ -731,11 +731,11 @@...

...e = 13, obj = 0, named = 2, gp = 0, mark = 1, debug = 0, trace = 0, fin = 0, gcgen = 0, gccls = 1}, attrib = 0x508818, gengc_next_node = 0x6db278, gengc_prev_node = 0x8442b8, u = {primsxp = { offset = 2}, symsxp = {pname = 0x2, value = 0x230002acc2, internal = 0x21000090}, listsxp = {carval = 0x2, cdrval = 0x230002acc2, tagval = 0x21000090}, envsxp = {frame = 0x2, enclos = 0x230002acc2, hashtab = 0x21000090}, closxp = {formals = 0x2, body = 0x230002acc2, env = 0x21000090}, promsxp = {value = 0x2, expr = 0x230002acc2, env = 0x21000090}}} #0...

...where nesting */ /* needs to be taken care of. */ To continue on this approach, and follow up on these FIXMEs, I need to understand some of the internal functions like CAR, CDR, and combinations thereof. I found the definition of CAR in src/include/Defn.h as: #define CAR(e) ((e)->u.listsxp.carval) But where is u.listsxp.carval defined? For that matter, where is the Scheme/LISP interpreter? Is there a roadmap? list of where the different pieces of R reside? Jim Robison-Cox ____________ Department of Math Sciences | | phone: (406)...

...the > garbage collection mechanics in Go with the obvious risks of error and > possible behaviour skew in the future). > > In doing this work I have some questions that I have not been able to > find answers for in the R-ints doc or hadley/r-internals. > > 1. In R-ints, the LISTSXP SEXP type CDR is said to hold "usually" > LISTSXP or NULL. What does the "usually" mean here? Is it possible > for the CDR to hold values other than LISTSXP or NULL, and is > this?NULL NILSXP or C NULL? I assume that the CAR can hold any type >...

Hello, I've created this class: setClass("example", representation ( size = "numeric", id = "character" ) ) Suppose I create a new instance of this class: > x <- new("example", 4, "id_value") This creates an S4 object with two slots. Am I correct in thinking that slots are "filled" by SEXPs?

...>>> and >>> possible behaviour skew in the future). >>> >>> In doing this work I have some questions that I have not been able >>> to >>> find answers for in the R-ints doc or hadley/r-internals. >>> >>> 1. In R-ints, the LISTSXP SEXP type CDR is said to hold >>> "usually" >>> LISTSXP or NULL. What does the "usually" mean here? Is it >>> possible >>> for the CDR to hold values other than LISTSXP or NULL, and >>> is >>> this NUL...

...c0f0 13 INTSXP g0c0 [NAM(7)] matter vector (mode=3, len=3, mem=0) Here is what I get without a wrapper: > fc1 <- structure(y, class="factor", levels=levels(x)) > .Internal(inspect(fc1)) @7fb0cae66408 13 INTSXP g0c2 [OBJ,NAM(2),ATT] (len=3, tl=0) 1,1,2 ATTRIB: @7fb0ce771868 02 LISTSXP g0c0 [] TAG: @7fb0c80043d0 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] "class" (has value) @7fb0c9fcbe90 16 STRSXP g0c1 [NAM(7)] (len=1, tl=0) @7fb0c80841a0 09 CHARSXP g1c1 [MARK,gp=0x61] [ASCII] [cached] "factor" TAG: @7fb0c8004050 01 SYMSXP g1c0 [MARK,NAM(7),LCK,gp=0...

...(1,2,3) > > .Internal(inspect(a)) > @0x000000002384f530 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3 > > attr(a,"dim")=c(1,3) > > .Internal(inspect(a)) > @0x000000002384f530 14 REALSXP g0c3 [NAM(1),ATT] (len=3, tl=0) 1,2,3 > ATTRIB: > @0x0000000023864b58 02 LISTSXP g0c0 [] > TAG: @0x00000000044b1a90 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] "dim" > (has value) > @0x000000002384cb48 13 INTSXP g0c1 [NAM(7)] (len=2, tl=0) 1,3 > *This would cause a duplication, even though the function test does nothing.* > > test<-function(x) x...

...ggregate(duration, list(Delta), length) > colnames(pseudo.hist) <- c("Delta", "N") > detach(profiles) > gc() used (Mb) gc trigger (Mb) Ncells 701188 18.8 2683553 71.7 Vcells 1447712 11.1 8201413 62.6 > memory.profile() NILSXP SYMSXP LISTSXP CLOSXP ENVSXP PROMSXP LANGSXP 1 7228 244243 3949 495 773 113819 SPECIALSXP BUILTINSXP CHARSXP LGLSXP INTSXP 207 1177 283663 4661 0 0 49 REALSXP CPLXSX...

...SE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP g0c0 [MARK,ATT] @604998 01 SYMSXP g0c0 [MARK,LCK,gp=0x5000] "{" (has value) ATTRIB: @cc9570 02 LISTSXP g0c0 [MARK] TAG: @60dd70 01 SYMSXP g0c0 [MARK,LCK,gp=0x4000] "srcref" (has value) @15a65d8 19 VECSXP g0c1 [MARK] (len=1, tl=0) @10f3dd0 13 INTSXP g0c3 [OBJ,MARK,ATT] (len=8, tl=0) 1,15,1,15,15,... ATTRIB: @cc9618 02 LISTSXP g0c0 [MARK] TAG: @60dde0 01 SYM...

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

...all the attributes. This is exactly what an example in the R Extensions manual section 4.11.2 "Inspecting R objects when debugging" does, but the code there doesn't work, presumably because the R internals have changed since it was written. Specifically, I get (gdb) p $a->u.listsxp.tagval->u.symsxp.pname->u.vecsxp.type.c Error: There is no member named vecsxp. where $a was set to be the attrib member of an SEXP. Could someone let me know what needs to be fixed for this to work? I imagine it's a typecast, but I haven't been able to put it together. (An examp...

Dear all, I have written a little R program to convert images. See below. Within the loop over j (the filenames) memory consumption grows constantly. rm( ... ) inside the loop did not help. Memory does not grow if I remove the writeBin statements between the two #-------- marks. But obviously this is not solution I want... Thanks for any advice. Manfred Baumstark P.S. As I'm new to R:

...containing the value >> 4. One doesn't really have to know the detailed representation, but one >> can find out from >> >> > .Internal(inspect(eg)) >> @df70e48 25 S4SXP g0c0 [OBJ,NAM(2),gp=0x10,ATT] >> ATTRIB: >> @df70ef0 02 LISTSXP g0c0 [] >> TAG: @769258 01 SYMSXP g1c0 [MARK] "size" >> @c0f6db8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 4 >> TAG: @15b0228 01 SYMSXP g1c0 [MARK,NAM(2)] "id" >> @c0f6178 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0) >> @1...

...status major 1 minor 6.0 year 2002 month 10 day 01 language R ----------------- At the beginning ------------- --- gc() returns: used (Mb) gc trigger (Mb) Ncells 254150 6.8 467875 12.5 Vcells 408499 3.2 886807 6.8 --- memory.profile() returns: NilSXP SymSXP ListSXP CloSXP EnvSXP PromSXP LangSXP SpecialSXP 1 4919 128880 1440 13 18 63607 59 BUILTINSXP CHARSXP LGLSXP - - INTSXP REALSXP CPLXSXP STRSXP 513 37178 1712 0 0 237 9047 8 10201 DOTSXP ANYSXP VECSXP EXPRSXP - EXTPTRSXP WEAKREFSXP 1 0...

...ata in it. However, this requires twice the amount of space (and time), and we're running out of memory when doing concurrent analysis. What I'd would like to do is: - "patch" the SEXP returned to R so that DATAPTR() points directly to the required address. - create a normal LISTSXP in the package, which holds a reference to all these objects, so that GC never takes place. - turn these objects read-only, or, at least, ensure that they are never free()d or remalloc()ed. overwriting the contents is not a critical issue. Would that approach work? Are there any alternative...

My understanding is that R will not make copies of lists if there is only one reference to the object. However, I've encountered a case where R does make copies, even though (I think) there should be only one reference to the object. I hope that someone could shed some light on why this is happening. I'll start with a simple example. Below, x is a list with one element, and changing that