similar to: Looking for R_Home ...

I have a problem to understand the way gc_inhibit_torture is defined. In include/Defn.h it is declared as extern, using the __MAIN__ trick this leads to a definition in main/main.c. But in main/memory.c you define (and initialize) gc_inhibit_torture again: int gc_inhibit_torture = 1; /* gets set to zero after initialisations */ Then, in e.g. unix/system.c immediately at the beginning of

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 R users we're having a problem reading a largish data file using read.table(). The file consists of 175000 lines of 4 floating pt numbers. Here's what happens: > dat_read.table('sst.dat') Error: memory exhausted (This is line 358 of src/main/memory.c). Cutting down the file to around 15000 lines allows read.table() to work OK. I edited the memory limits in Platform.h

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,

Full_Name: Richard Boyce Version: 2.1.-1 OS: Debian testing/unstable Submission from: (NULL) (128.95.123.29) While building a custom package using a modified version of Duncan's REventLoop with R version 2.1 (Debian package r-base, r-base-dev) and R source from apt-get source 2.1.1 I get the following error: $ R CMD build vjREventLoop * checking for file

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 r-devel members, I encountered a C stack limit issue, when I tried to embed R 2.5 into my application. In the R-exts document, it says:"Note that R's own front ends use a stack size of 10Mb". I desire to know: is it possible to decrease this stack size by modifying R's source code? If it's possible, which part of the source code is responsible for the issue? Thank

When using multicore-forking of the parallel package, is it possible for a child process to know that it is a fork? Something like: parallel::mclapply(1:10, FUN = function(i) { test_if_running_in_a_fork() }) I'm looking into ways to protect against further parallel processes (including threads), which not necessarily are created via the parallel:mc* API, are being spawned off recursively.

Full_Name: Murray Stokely Version: 2.10.1 OS: Linux Submission from: (NULL) (216.239.45.4) The Defn.h header includes limits.h for PATH_MAX and then checks if it hasn't been defined and if not sets something manually. Some of the R code uses PATH_MAX but a lot of other functions in unix/sys-unix.c and main/startup.c just hardcodes a limit of 256 characters. In my environment this is not

Full_Name: Venkatesh Mysore Version: R-1.7.0 OS: WindowsXP Submission from: (NULL) (216.165.110.10) While accessing Rproxy.dll repeatedly (using the code from the (D)COM example in the R website) causes a failure in the 24th iteration. R-1.6.2 does NOT give this error. This seems to be a memory management error, that might be linked to the huge leakage difference between R-1.7.0 and R-1.6.2

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

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

Hello, I do not have an account on R Bugzilla, so I will post my bug report here. I want to report a very old bug in base R *source()* function. It relates to sourcing some R scripts in UTF-8 encoding on Windows machines. For some reason if the UTF-8 script is containing cyrillic letter *"?"*, the script execution is interrupted directly on this letter (btw the same scripts are sourcing

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

Dear all: I got some error messages when I installed R-2.4.0 on Compaq Tru64 Unix V5.1B, I set the R_HOME=/shs/R and then try 'make' command after configuration and it showed "Make: Cannot open /share/make/vars.mk. Stop.",after that,I used the 'gmake' to implement. The following is my installation steps: 1. ./configure --enable-R-shlib --prefix=/shs/R MAKE=gmake (no

I am troubled by what appears to be a glitch in the current distribution, or in its installation on our system. I've traced it, and found a work- around. Is this normal? Is there a cleaner solution? The problem: During a package installation, the warning message "WARNING: ignoring environment value of R_HOME" from line 31 of <R_HOME>/bin/R is accidentally spliced into the