search for: sxpinfo

...un on 5 objects of type 13,16,10,3 and with the last one being a type 6. In all cases, but the type 6 object, named was set to 2. For the type 6 object, named was set to 1 Breakpoint 1, DEBUG_SET_NAMED (x=0x85cfd8, v=2) at ../../../r-devel/r-devel/R/src/main/main.c:1444 1444 (x->sxpinfo.named) = v; $1 = 0x85cfd8 $2 = {sxpinfo = {type = 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...

Hi all, Why is the object size of an empty vector 40 bytes? (At least in 64-bit R.) object.size(integer(0)) # 40 bytes Reading R internals, it looks like it should be: * 4 bytes: sxpinfo header (= 32 bits) * 8 bytes: pointer to attributes * 8 bytes: pointer to next node * 8 bytes: pointer to previous node * 4 bytes: length * 4 bytes: true length = 36 bytes Where are the extra 4 bytes coming from? What have I missed? I thought it might be for memory alignment, but if it was padde...

...RSXP)) error("%s() can only be applied to a '%s', not a '%s'", "CHAR", "CHARSXP", type2char(TYPEOF(x))); return (const char *)CHAR(x); It is a fairly obvious fix to a bug since include/Rinternals.h:#define TYPEOF(x) ((x)->sxpinfo.type) and it was trying to de-reference "0->sxpinfo.type" (under --enable-strict-barrier I think). So there. While I subscribe to R-devel, I switched off delivery, so please CC if a response is required.

...plied to a '%s', not a '%s'", ? ? >? ? ? ? ? ? ???"CHAR", "CHARSXP", type2char(TYPEOF(x))); ? ? >? ? ? return (const char *)CHAR(x); ? ? > It is a fairly obvious fix to a bug since ? ? > include/Rinternals.h:#define TYPEOF(x) ((x)->sxpinfo.type) ? ? > and it was trying to de-reference "0->sxpinfo.type" (under ? ? > --enable-strict-barrier I think). Thank you? Hin-Tak! I did not yet try to reproduce the segfault, and I am not the expert here.? Just some remarks and a follow up question: Typically, the...

Dear list, On a follow up from my previous email, I am now trying to allocate vectors of length larger than 32-bit in C. >From the R internals documentation, I read that: "The sxpinfo header is defined as a 32-bit C structure..." and "A SEXPREC is a C structure containing the 32-bit header..." The question is: does the INTSXP allow vectors larger than 32-bit? A test example: //### int *p_temp; SEXP root = PROTECT(allocVector(VECSXP, 5)); long long int veryla...

...le, written in C, and I'm using gdb for this. How can I print "standard" R objects from within C code? BTW, I'm familiar with the advice to use R_PV given in Writing R Extensions, but it's not working for me. E.g., I get (gdb) p R_PV(x) $1 = void and yet (gdb) p *x $2 = {sxpinfo = {type = 16, obj = 0, named = 0, gp = 0, mark = 0, debug = 0, trace = 0, spare = 0, gcgen = 0, gccls = 1}, attrib = 0x608f98, gengc_next_node = 0xa82328, gengc_prev_node = 0xa822c8, u = {primsxp = {offset = 1}, symsxp = { pname = 0x1, value = 0x146fb50, internal = 0x2000000a}, listsxp = {c...

...9; # fine class(x) = 'foo' # error: attempt to set an attribute on NULL how come? the behaviour can obviously be explained by looking at the source code (hardly surprisingly, because it is as it is because the source is as it is), and referring to the NAMED property (i.e., the sxpinfo.named field of a SEXPREC struct). but can the *design* be justified? can the apparent incoherences visible above the interface be defended? why should the first example above be unable to produce an empty integer vector? why is it possible to set a class attribute, but not a names attribute,...

And I can confirm it with platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 1 minor 7.0 year 2003 month 04 day 16 language R so it is not a Windows issue. Cheers, Robert Cunningham Duncan

Hello, Doing typeof() on an object appears to reset the "named" field in its sxpinfo header to 2, which can change the way that subsequent subassignment operations are carried out: X <- 1:5e7 .Internal(inspect(X)) # @4eeb0008 13 INTSXP g0c7 [NAM(1)] (len=50000000, tl=0) 1,2,3,4,5,... system.time(X[1] <- 9L) # user system elapsed # 0 0 0 typeof(X) .I...

I am grateful for the advice of Douglas Bates on my earlier problem in making R-0.62.1, but I'm afraid I'm still having problems.... I have been installing the various updates to R for quite some time on my alpha, and it is only now that I have been having really severe problems. The three or 4 versions before 0.61.1 installed without error. For 0.61.1 I needed to install GNU make. For

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 ;-)

...e doesn't seem to be an immediate shortage of bits. The relevant declarations in serialize.c are as follows: /* * Type/Flag Packing and Unpacking * * To reduce space consumption for serializing code (lots of list * structure) the type (at most 8 bits), several single bit flags, * and the sxpinfo gp field (LEVELS, 16 bits) are packed into a single * integer. The integer is signed, so this shouldn't be pushed too * far. It assumes at least 28 bits, but that should be no problem. */ #define IS_OBJECT_BIT_MASK (1 << 8) #define HAS_ATTR_BIT_MASK (1 << 9) #define HAS_TAG_BI...

On Fri, 09 May 2003 11:34:08 +0300, Bernd Ebersberger <bernd.ebersberger@vtt.fi> wrote: >dear R-tists, > >i am experiencing a problem with the data editor in the windows version of >R 1.6.1 envoked with the command 'fix'. > >the data editor changes the size of large data frames. I can confirm this in the current R-patched. I'll take a look. It might be that

Dear all, It seems that textConnection() can trigger a segmentation fault. The following script (using two large loops) makes this bug reproducible: for (i in 1:10000) { z=textConnection(NULL,open='w') for (j in 1:100) { write(runif(1)*1e6,file=z) write('\n',file=z) } close(z) } The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest R-devel