search for: langsxps

Full_Name: David Bauer Version: 1.9 OS: Linux Submission from: (NULL) (160.91.245.8) In the file gram.y, the xxsubscript function generates a LANGSXP with another LANGSXP as its CDR. I believe that this is a mistake and that the second LANGSXP should be a LISTSXP. The inputs a1, a3 are parameters to the subscript function (a2), and as such they should be in a dotted-pair list. David Bauer

Full_Name: Ed Borasky Version: 1.8.1 OS: Windows XP Professional Submission from: (NULL) (208.252.96.195) R 1.8.1 seems to be running into a memory allocation problem in the "aggregate" function. I have a rather large dataset (14 columns by 223,000 rows -- almost 40 megabytes) and a script that performs some processing on it. The system is a 768 MB Pentium 4. Here's the console

Hello R-helpers, I tried to do "make test" , and it is failing: data() Error: stack overflow ?data Error: Stack overflow data(rivers) Error: incorrect tag type R also initially it balked at: apropos("\\\\[") So, I skipped it :-) This stuff is working on R-0.50-a4 that I have. Anyone built R-0.60.1 on hpux?? Best regards, Osman

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

Dear all, I have written a little R program to convert images. See below. Within the loop over j (the filenames) memory consumption grows constantly. rm( ... ) inside the loop did not help. Memory does not grow if I remove the writeBin statements between the two #-------- marks. But obviously this is not solution I want... Thanks for any advice. Manfred Baumstark P.S. As I'm new to R:

[some de-capitalization of *SXP done manually by mailing list maintainer ; the originally was caught as potential spam. MM] I have a little R program that crashes with the message xmalloc: out of virtual memory The code has a repeat{} loop that watches the sizes of some files. When there's an increase it updates things by reading the last 65 lines of each file, doing some

Dear list, I am trying to implement a publish-subscribe mechanism in for an embedded R interpreter. But somehow my registered closures seem to get collected by the GC, even though I have protected them. I have reducted my code to the following sample. Sorry if it is a little verbose. The first couple of call of calls still work, but at some point one of the callbacks (callback1 in my

Hello, (This is follow up from this thread: http://www.nabble.com/execution-time-of-.packages-td22304833.html but with a different focus) I am often confused by the result of the profiler, when a loop is involved. Consider these two scripts: script1: Rprof( ) x <- numeric( ) for( i in 1:10000){ x <- c( x, rnorm(10) ) } Rprof( NULL ) print( summaryRprof( ) ) script2:

Hello, I am writing an R/Go interoperability tool[1] that work similarly to Rcpp; the tool takes packages written in Go and performs the necessary Go type analysis to wrap the Go code with C and R shims that allow the Go code to then be called from R. The system is largely complete (with the exception of having a clean approach to handling generalised attributes in the easy case[2] - the less

Hi all, I have a problem of Rf_initEmbeddedR function. I've tried with: try { int Argc1 = 1; char *Argv1[] = {"Rtest_1"}; int Argc2 = 1; char *Argv2[] = {"Rtest_2"}; // Init R(first) Rf_initEmbeddedR(Argc1, Argv1); // R package load SEXP e = R_NilValue; SEXP r = R_NilValue; PROTECT(e =

Full_Name: Simon Anders Version: 2.6.2 OS: Ubuntu Linux Submission from: (NULL) (86.22.75.91) This is a rather minor "documentation bug", certainly not at all urgent. The manual "Writing R extensions" explains in section 5.10 ("Evaluating R expressions from C") how to use the eval function. Without going into much details, an example is given how to build up a

Hello All, I tried the sample code from the help. Although '{' is assigned to 'do', the call syntaxes for 'do' and '{' are not the same ('do' has ','s, but '{' has line breaks). I guess there is a difference in parsing the code block of 'do' and the code block of '{'. Could you please let me know some internal details so that

But it is not taken 'verbatim from src/main/print.c' (at least not in that version of R), and the code is not run with USE_RINTERNALS defined when write-barrier checking is enabled. The example has been updated to match the current code in 2.7.0 alpha. On Sun, 30 Mar 2008, sanders at fs.tum.de wrote: > Full_Name: Simon Anders > Version: 2.6.2 > OS: Ubuntu Linux >

Hi I'm trying to implement something similar to the following R snippet using C. I seem to have hit the wall on accessing class slots using C. library(fPortfolio) lppData <- 100 * LPP2005.RET[, 1:6] ewSpec <- portfolioSpec() nAssets <- ncol(lppData) setWeights(ewSpec) <- rep(1/nAssets, times = nAssets) ewPortfolio <- feasiblePortfolio( data = lppData, spec = ewSpec,

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

Hi Consider the following example: f <- function(expr) g(expr) g <- function(expr) { ? h(expr) } h <- function(expr) { ? expr # evaluation happens here ? i(expr) } i <- function(expr) { ? expr # already evaluated, no costs here ? invisible() } rprof <- tempfile() Rprof(rprof) f(replicate(1e2, sample.int(1e4))) Rprof(NULL) cat(readLines(rprof), sep = "\n") #>

Happy new year to all; A few days ago, I posted similar problem. At that time, I found out that our R program had been 32-bit compiled, not 64-bit compiled. So the R program has been re-installed in 64-bit and run the same job, reading in 150 Affymetrix U133A v2 CEL files and perform dChip processing. However, the memory problem happened again. Since the amount of physical memory is 64GB, I think

Simon, Ah, thank you! quiet right. For anyone searching for this in the future, I changed my init fuction to: ---------- SNIP ---------------- void init_r() { SEXP aperm_function; /* this is our version of Rf_initEmbeddedR where we disable stack checking */ const char *init_argv[] = {"MyFront", "--vanilla", "--slave"}; Rf_initialize_R(sizeof

The general principle is that R packages are only allowed to use what is documented in the R help (? command) and in Writing R Extensions. The former covers what is allowed from R code in extensions, the latter mostly what is allowed from C code in extensions (with some references to Fortran). If you are implementing a Go interface for writing R packages, such Go interface should thus only