similar to: More on bug 7924

Hi, everyone. I'm trying to debug an R-module, 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,

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

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

Dear Rdevelers, ? ? ?The following struct is in the Rinternals.h. I want to know ?the meanings of labels or names like "gp,mark,obj,named,trace....." . TKS! struct sxpinfo_struct { ? ? SEXPTYPE type ? ? ?: ?5;/* ==> (FUNSXP == 99) %% 2^5 == 3 == CLOSXP ? ? * -> warning: `type' is narrower than values ? ? * ? ? ? ? ? ? ?of its type ? ? * when SEXPTYPE was an enum

I haven' t touched R for some 18 months, and so I have no idea if this is a recent problems or not; but it certainly did not segfault two years ago. Since it has been crashing (segfault) under 'make check-all' for over a month, I reckon I'll have to look at it myself, to have it fixed. I have been having the ' --enable-memory-profiling --enable-strict-barrier

I'm trying to track down a bug in some experimental code, where an object's attribute is getting messed up. This means I'd like to examine R objects while within gdb. One of the things I'd like to do is to examine the names of all the attributes. This is exactly what an example in the R Extensions manual section 4.11.2 "Inspecting R objects when debugging" does,

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

On 2nd thought, I think a better fix to the segfault is something like this: --- a/src/main/memory.c +++ b/src/main/memory.c @@ -3444,6 +3444,8 @@ R_xlen_t (XTRUELENGTH)(SEXP x) { return XTRUELENGTH(CHK2(x)); } int (IS_LONG_VEC)(SEXP x) { return IS_LONG_VEC(CHK2(x)); } const char *(R_CHAR)(SEXP x) { + if(!x) + error("de-referncing null. Check the validity of your data.");

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

somewhat related to a previous discussion [1] on how 'names<-' would sometimes modify its argument in place, and sometimes produce a modified copy without changing the original, here's another example of how it becomes visible to the user when r makes or doesn't make a copy of an object: x = NULL dput(x) # NULL class(x) = 'integer' # error: invalid

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

I will shortly be releasing a new version of pqR (you can get a test version from pqR-project.org now - scroll to the bottom of the page). One new feature in this version requires adding a bit to the flags written out when data is serialized. I thought I'd let you know about this so as to avoid any possible conflicts. The new feature is that a few R objects are defined as constants, which

There seems to be a latent flaw in the definition of struct SEXPREC in Rinternals.h, which likely doesn't cause problems now, but could if the relative sizes of data types changes. The SEXPREC structure contains a union that includes a primsxp, symsxp, etc, but not a vecsxp. However, in allocVector in memory.c, zero-length vectors are allocated using allocSExpNonCons, which appears to

Hello, For the BUILTINSXP and SPECIALSXP types, the R Internals page documents "An integer giving the offset into the table of primitives/.Internals. " What macro gives me the value of this integer? I guess something like this would work had R_USEINTERNALS been defined v->u.primsxp.offset (where v is a SEXP of either of the above types). What is the portable version? Thank you

Hi Morgan, My solutions might not be the best one(I believe it's not), but it should work for your question. 1. Have you considered Rf_duplicate function? If you want to change the value of `a` and reset it later, you have to have a duplication somewhere for resetting it. Instead of changing the value of `a` directly, why not changing the value of a duplicated `a`? So you do not have to

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

Thank you for your reply Jiefei. I think in theory your solution should work. I'll have to give them a try. On Mon, 4 Nov 2019 23:41 Wang Jiefei, <szwjf08 at gmail.com> wrote: > Hi Morgan, > > My solutions might not be the best one(I believe it's not), but it should > work for your question. > > 1. Have you considered Rf_duplicate function? If you want to change

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