similar to: R-beta: Memory Management in R-0.50-a4

On Thu, Jan 15, 2015 at 3:55 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > Just wanted to start a discussion on whether R could ship with more > appropriate GC parameters. I've been doing a number of similar measurements, and have come to the same conclusion. R is currently very conservative about memory usage, and this leads to unnecessarily poor performance on

>>>>> Peter Haverty <haverty.peter at gene.com> >>>>> on Mon, 19 Jan 2015 08:50:08 -0800 writes: > Hi All, This is a very important issue. It would be very > sad to leave most users unaware of a free speedup of this > size. These options don't appear in the R --help > output. They really should be added there. Indeed,

Hi All, This is a very important issue. It would be very sad to leave most users unaware of a free speedup of this size. These options don't appear in the R --help output. They really should be added there. Additionally, if the garbage collector is working very hard, might it emit a note about better setting for these variables? It's not really my place to comment on design philosophy,

This is my first question to this list and possibly a bit dumb, but anyway: Can anybody tell me, where, e.g. in the "unix" reference release a DEFINITION of char * R_Home can be found? Via Defn.h the "extern" DECLARATION is everywhere, but when I derived a somewhat other main() program my linker complained about the missing definition. Thomas Hoffmann.

Just wanted to start a discussion on whether R could ship with more appropriate GC parameters. Right now, loading the recommended package Matrix leads to: > library(Matrix) > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 1076796 57.6 1368491 73.1 1198505 64.1 Vcells 1671329 12.8 2685683 20.5 1932418 14.8 Results may vary, but here R needed 64MB of N cells and 15MB

When I use the -v I can modify the size of the heap, as assessed by gc(), but the -n key seems to be without effect ? On a machine with 48 mB ram I can load the libraries without problem, but on my own 36 mB ram machine, I get dynload problems with the larger, eg survival4. Any suggestions ? Troels -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list

When I use the -v I can modify the size of the heap, as assessed by gc(), but the -n key seems to be without effect ? On a machine with 48 mB ram I can load the libraries without problem, but on my own 36 mB ram machine, I get dynload problems with the larger, eg survival4. Any suggestions ? Troels -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list

Dear All Problem with ext3 fs on 3ware 9500S controller: Dec 7 05:59:50 stams kernel: EXT3-fs error (device sda1): ext3_add_entry: bad entry in directory #145998372: rec_len is smaller than minim al - offset=0, inode=0, rec_len=0, name_len=0 Dec 7 05:59:50 stams kernel: Aborting journal on device sda1. Dec 7 05:59:50 stams kernel: ext3_abort called. Dec 7 05:59:50 stams kernel: EXT3-fs

In what way is this a bug in R? It looks like a bug in the package, and as Defn.h is not part of R's API any packge using it is `at risk' (and cannot be installed in a binary-only installation, or even an installed version of R). In particular, Defn,.h depends on config.h, and it seems you installed a binary version of R and used separate sources. I would suggest building R from

Dear All can someone confirm this bug please ? I am using Thunderbird 1.07, TB 1.5.0.4, Horde/IMP webmail as test clients, all running on FC4. Server is 1.0RC6 on CentOS 4 with maildir-sep set to ';' To reproduce: In your favourite mail client: 1. Create a top-level mail folder "atest" 2. Rename "atest" to "atest-extra" (basically

Dear list, Tadashi Kadowaki has developed a pdf device package that allows to add hyperlinks and popups to (currently) text, mtext and rect calls. The package passes R CMD check (minor warnings) and compiles on MacOS X and GNU/Linux, but we do not succeed in building the package for Windows. The current version of the package can be checked out as svn checkout

Dear All I have a test system where I am trying out 1.1.4 On the old 1.0rc6 (!) system I had edited: src/lib-storage/index/maildir/mail-storage.h to change: #define MAILDIR_FS_SEP ';' #define MAILDIR_FS_SEP_S ";" so I can get some mail folder hierarchy and '.'s in folder names - this all worked perfectly. Under 1.1.4 the MAILDIR_FS_SEP lines are no longer present.

As I mentioned in my previous message about speeding up evalList, I've been looking at ways to speed up the R interpreter. One sees in the code many, many calls of PROTECT, UNPROTECT, and related functions, so that seems like an obvious target for optimization. Indeed, I've found that one can speed up the interpreter by about 10% by just changing these. The functions are actually macros

I've been running a binary installation (kindly provided by Jan de Leeuw) on mac G4, but was inspired this morning to try to install 1.7.0 on the G4 as well as on my desktop solaris box. This worked smoothly on my solaris system but on the G4 the make dies shortly after compiling lapack with: /usr/bin/libtool: internal link edit command failed make[4]: *** [libRlapack.dylib] Error 1 make[3]:

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

Hi all, > It would be better to use the XO_LIB_XAPIAN macro provided by > xapian-core instead of writing your own code to probe for > xapian-config. > > Everything from line 3 to line 18 of your current configure.ac could be > replaced with just: > > XO_LIB_XAPIAN > > If you've installed xapian-core then the macro should just be > found automatically. I

Hope I am not sounding too much like a broken record - as far as 64-bit build on AIX is concerned. ** Short - 32-bit builds complete normally, 64-bit builds stop at "installing 'sysdata.rda'" with message: Error: Line starting 'Package: tools ...' is malformed! Execution halted *** Longer... I could file a bug - Importance, showstopper - but I would prefer to better

Hi, I would like to be able to create new environments from package C code. AFAICT, this isn't allowed since both NewEnvironment and R_NewHashedEnv are declared in Defn.R. If exposing this isn't controvertial, I would submit a patch. However, I'm not sure where the declarations should go (Rdefines.h?) and whether they need to change to Rf_*. + seth

Hi! I've been trying to compile R with gcc version 3.4.2 on a box running Solaris 2.6. I keep on hitting this error during the compile: gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -std=gnu99 -c dynload.c -o dynload.o In file included from dynload.c:33: ../../src/include/Defn.h:943: error: parse error before "mbstate_t" make[3]: ***

> On Dec 23, 2016, at 18:36, David Blaikie <dblaikie at gmail.com> wrote: > > > >> On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). >> >> Firstly, why