similar to: match.arg confusion (PR#921)

[sys.function fails sometimes (sorry, our mail system decide to throw away the original mail)] Yes, I bumped into something similar recently. The problem is that we only actually store the call in the context structure, not the function, so sys.function has to grab the call, take the 1st element, and reevaluate it in the parent frame. It is quite easy to think up examples where a second

This one may not strictly be a bug, and it was certainly my fault, but it took me a while to track it down and it is rather strange: funOne <- function(x) { funTwo <- 1:10 funTwo(x) } funTwo <- function(v) 2*v funOne(5) # answer is 10 as expected # now a different definition for funTwo with a match.arg funTwo <- function(v, foo=c("small", "large")) { foo

Hi All, I have a few small questions about the usage of the C findVar( ) function when used in C code called with '.Call'. In my case I create an R function with an argument. This function calls some C code in which I use findVar( ) to retrieve the values from the argument. Ofcourse normally I would just give the values as argument to .Call, but in my project I need to use findVar for

>>>>> "JonR" == Jonathan Rougier <J.C.Rougier@durham.ac.uk> writes: JonR> ... By the way, I have `solve' JonR> methods for triangular matrices and variance matrices -- would JonR> you be interested? { Jonathan, I hope it's okay if I CC this to R-devel; this must be of a wider interest } Ye.e..s; for triangular ones,

Hello. In the writing of my OCaml-R binding, I'm sort of confused when it comes to the use of the PROTECT and UNPROTECT macros. Basically, I have C stub functions that are in charge of calling R for everything. Here's a simple example: > CAMLprim value r_findvar (value symbol) { > /* The findVar function is defined in envir.c. It looks up a symbol > in an environment.

> On 27 Mar 2016, at 22:05 , Mick Jordan <mick.jordan at oracle.com> wrote: > > As I understand > https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html > sys.function(n) returns the function associated with stack frame n. > Since frame 0 is defined as .GlobalEnv which is not associated with a > function, I would expect this to always return NULL.

Full_Name: Ben K. Version: 1.7.1 OS: Win 2000 Submission from: (NULL) (208.243.20.222) This C code doesn't crash: void init(SEXP rho, int *o){ SEXP vars = findVar(install("vars"), rho); } It's called using: vars <-as.data.frame(NULL) vars$delta <-7 dyn.load("c_fns.dll") print(.C("init",.GlobalEnv,o=as.integer(3))$o) However, this

Documentation and other bugs with postscript(): 1. This code crashes R (it asks for a font that isn't there): postscript() plot(0:1,0:1) text(0.5,0.5,'crash',font=6) The bug appears to be in the FixupFont routine in plot.c; on line 236, it checks that the font number is in the range 1..32. Later this crashes PostScriptStringWidth in devPS.c, because only fonts numbered 1..5

Dear list, I have been using "findVar" (defined in src/main/envir.c) happily and would like to use "findFun". However I have trouble when the name searched cannot be found: while "findVar" returns R_UnboundValue, "findFun" does not (the 4 last lines of "findFun" are copied below). error(_("could not find function

Slowly making progress with Active Directory integration. I have Samba 3.0.2 as an ADS member, and I can see shares, including user home directories. My linux boxes run Debian unstable, and use the PAM and NSS LDAP backends, against an Active Directory on Windows 2000 SP4, using the MS Services For Unix V2.0 schema updates. PAM-authenticated login, ssh etc. all work fine, although I did have to

Dear all, when working on a project with embedded R, I found out that R-2.0.0 causes a problem where older versions worked OK. Rf_findVar(...) causes the following error when used to find a generic function (such as print): fun = Rf_findVar(...); R_tryEval(fun, ...); Error in function (object, ...) : Invalid generic function in usemethod Alternatively, using Rf_findFun(...) seems OK in this

I've been inspired to look at the R source code by some strange timing results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and

On 3/27/16 2:46 PM, peter dalgaard wrote: >> On 27 Mar 2016, at 22:05 , Mick Jordan <mick.jordan at oracle.com> wrote: >> >> As I understand >> https://stat.ethz.ch/R-manual/R-devel/library/base/html/sys.parent.html >> sys.function(n) returns the function associated with stack frame n. >> Since frame 0 is defined as .GlobalEnv which is not associated with

Hi, I'm wondering if this code from the "Writing R Extensions" manual is really safe: SEXP mkans(double x) { SEXP ans; PROTECT(ans = allocVector(REALSXP, 1)); REAL(ans)[0] = x; UNPROTECT(1); return ans; } double feval(double x, SEXP f, SEXP rho) { defineVar(install("x"), mkans(x), rho);

I found this tracing a bug when experimenting with a new sort() function using match.arg(). It was triggered because mosaicplot.default(.) has an argument called `sort' and calls itself the sort() function in which I was using match.arg()... Here is (input for) a small clean example : #### bad match.arg() // sys.function() bug : #### MM, 22.3.2002 callme <- function(a = 1, mm =

Hi all, I am using R-3.0.1 under Linux platform to embed R into my C++ code. I am facing an error while executing more than 1 R-expressions parallelly. I am executing round(X) and abs(X) parallelly on a set of 50 input rows which resulted in segmentation fault after getting the following errors. Error: unprotect_ptr: pointer not found Error: argument to 'findVar' is not an environment

If I do > example(lm) ... > mycoef <- function(object, ...) UseMethod("coef", object) > mycoef(lm.D9) Error in mycoef(lm.D9) : no applicable method for "coef" which is pretty surprising, as coef has a default method. After a bit of digging, this comes from do_usemethod having defenv = environment where the generic was defined */ defenv =

Hey all. As in general it's a bad idea to allow an event handler to generate an event, and as comments in the code seem to suggest this isn't the intention either, I was wondering about recursion in getGraphicsEvent(). In main/gevents.c, both doMouseEvent() and doKeybd() have the following line; dd->gettingEvent = FALSE; /* avoid recursive calls */ And they reset it to TRUE

Here's an update of my rawConnection() implementation. In addition to providing a raw version of textConnection(), this fixes two existing issues with textConnection(): one is that the current textConnection() implementation carries around unprotected SEXP pointers, the other is a performance problem due to prolific copying of the output buffer as output is accumulated line by line. This new

Commit-ID: 4a84d61a24296b8253b3f8f7c86ee28df53e2f3b Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=4a84d61a24296b8253b3f8f7c86ee28df53e2f3b Author: David S. Miller <davem at davemloft.net> AuthorDate: Wed, 17 Aug 2011 09:31:17 +0800 Committer: maximilian attems <max at stro.at> CommitDate: Mon, 2 Jul 2012 10:46:37 +0200 [klibc] [SHELL] Allow building