similar to: Why does an empty vector occupy 40 bytes?

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

Hi, Again, sorry for the length of this post. Once I get my new office I will get a website set up on my work machine and will simply post a link to the log since I doubt many people are truly interested in these logs. To further analyze what is happening, I added my own routine in main.c called DEBUG_SET_NAMED and then redefined the SET_NAMED macro to use it and then rebuilt R. I

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

Hi, To speed up reading of large (few million lines) CSV files I am writing custom read functions (in C). By timing various approaches I figured out that one of the bottlenecks in reading character fields is the mkChar() function which on each call incurs a lot of garbage-collection-related overhead. I wonder if there is a "vectorized" version of mkChar, say mkChar2(char **, int

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

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, I want to write a package where I would use shared memory for some vectors Any suggestion is appreciated... I wonder if the right approach would be to modify add a modified version of the allocVector(SEXPTYPE type, int length) function specifically shared_mem_id = shmget(shared_mem_key, SHM_SIZE, IPC_CREAT);

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

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

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)

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

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

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

Hi, Is there any way to determine frame size in bits or bytes of encoded frame in WB mode for given quality? That is I need to know how many bits encoded frame will occupy in RTP packet. I see SPEEX_SUBMODE_BITS_PER_FRAME request, but it works like this only for NB mode, and for WB mode it return size of WB "subframe" (?) only. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM

How can I suppress this warning? > options(warn = -10) > list(1,2,3,) Warning: a final empty element has been omitted the part of the args list of 'list' being evaluated was: (1, 2, 3, ) [[1]] [1] 1 [[2]] [1] 2 [[3]] [1] 3 > suppressWarnings(list(1,)) Warning: a final empty element has been omitted the part of the args list of 'list' being evaluated was: (1, )

This is admittedly minor, and you shouldn't have repeated names in a data frame anyway, but: df <- data.frame(1:3, 1:3, 1:3) # Ok setNames(df, c("x", "y", "")) # Not ok setNames(df, c("x", "", "")) Hadley -- http://hadley.nz

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

> Hi, > > Ady wrote: > > I fear we would get slightly off-topic. > > Yep. Since the TAILS ISO is supposed to not grow over 2 GiB > for now, it seems best to just use -h 128 -s 32 in order to > stay near to traditions. > > > ----------------------------------------------------------- > Summary: > > The alignment to cylinder size is a core feature of

I have a data set of roughly 700MB which during processing grows up to 2G ( I'm using a 4G linux box). After the work is done I clean up (rm()) and the state is returned to 700MB. Yet I find I cannot run the same routine again as it claims to not be able to allocate memory even though gcinfo() claims there is 1.1G left. At the start of the second time ===============================