[Rd] .net and R
Hi, is it possible to call R functions from visual studio .net such as c#? - [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .net and R
On Sat, 23 Feb 2008, Yuan Jian wrote: > Hi, > is it possible to call R functions from visual studio .net such as c#? Yes. [If you want to know 'how', please study 'Writing R Extensions'.] > - > > [[alternative HTML version deleted]] Please study the posting guide which asked you not to send HTML. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling R_PreserveObject from embedded R
> Hello. This is my first post to the list, so first I'd like to thank > everybody for making and mantaining such a great product as R. > I'm writting a native binding to R from Dolphin Smalltalk. I've followed up > the examples of the documentation showing how to run R embedded, and I got > it partially working. However, I have a problem with the reference handling > of the R objects. > I've followed this strategy: every time I call a function in R and it > answers me a SEXP, I called R_PreserveObject(sexp), and wrap it with a > Smalltalk object. Whenever the Smalltalk object dies, I release the R object > by calling R_ReleaseObject(sexp). > This seems to handle well the life cycle, but makes the running process to > use a growing and a never ending amount of memory. Actually, after > experimenting a while, I isolated the problem to iterate over a loop which > all it does is create an expresion for a number, call PreserveObject and > call ReleaseObject, and that alone makes the memory to grow indefinitely. > I couldn't find any comment about this behaviour. Is there something I'm > missing ? Martin, I am working with code taking a similar approach (from Python), and I do not seem to observe what you are experiencing. When I initialize the embeded R with the "--verbose" flag, and initialize disposable objects from a loop in Python, R outputs lines such as the ones below: 11.8 Mbytes of vectors used (40%) Garbage collection 536 = 307+159+70 (level 0) ... 7.1 Mbytes of cons cells used (38%) 19.4 Mbytes of vectors used (65%) Garbage collection 537 = 307+160+70 (level 1) ... 7.1 Mbytes of cons cells used (38%) 11.8 Mbytes of vectors used (40%) > I'm running the embedded R-2.6.2 binaries for Windows in a WindowsXP sp2 > environment. I am currently working on Linux. > I've also implemented another strategy, which keeps a global list in R, and > instead of calling R_PreserveObject, it inserts the SEXP in the list. This > made the memory usage problem to go away, but the performance is noticeably > worst compared with the other strategy, and is not as elegant as the first > one neither, so I was hoping to be able to use the first strategy. The first strategy appears is something similar, if I understood it right (there is a global SEXP object called R_PreciousList in memory.c). > I'll appreciate any comment about what might be going on. May be try the "--verbose" flag ? > Thanks in advance. > > Best regards. > martin > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] level of mutability for the type of a SEXP
2008/2/22, Prof Brian Ripley <[EMAIL PROTECTED]>: > On Tue, 19 Feb 2008, Laurent Gautier wrote: > > > Dear list, > > > > I am writing C code to interface with R, and I would like to know the > > level of mutability for the type of a SEXP. > > > > I see that there is a macro/function TYPEOF(), and that it can be used > > as an l-value, as well as a macro/function SET_TYPEOF(). > > > The macros are not available to user code, so TYPEOF is not available to > use as an l-value. > Is the general rule that no macro is available to user code ? > > My question is "should the type be considered immutable, or it can it > > change after the SEXP has been created and used for a while ?". > > > > I understand that a call to TYPEOF will not perform any conversion, > > and my question is only about being sure that once the type of a given > > SEXP is set it cannot change. > > > It is SEXPRECs that have types, and their type can be changed and in a few > cases is in R's internal code. You should only change type between > SEXPREC types with the same structure, e.g. from VECSXP to EXPRSXP or > DOTSXP to LISTSXP. I am unaware of any examples where this happens that > involve a SEXPREC pointed to by a SEXP not in the internal code concerned. Thanks for your answer. As you point it out, I overlooked the fact that a SEXP is merely a pointer, and therefore will not change type. I systematically looked for usages of TYPEOF/SET_TYPEOF in the base code, and I could only find use of the macros beyond shortly after the instantiation of a new object. > Since a SEXP is a pointer, the type of the SEXPREC it points to can change > (as which SEXPREC it is can) and frequently does -- that is one way > arguments are coerced. > > The R Internals manual has the details of the SEXPRECs and their > structure. I will read more about them. > I don't see the value of knowing though. Anyone who needs to ask about R > internals should regard the arguments passed to .Call/.External calls as > read-only and also assume that there is no simultaneous evaluation going > on that might change them. My purpose is not to write C code called from R, but to make an interface between a scripting language and an embedded R. The reason for my question is that I would like to type a little R objects accessed from that foreign language, and would not like to see their type change along the evaluation of R code, and without the pointer from the scripting language knowing. The pass-by-value paradigm should not make such things possible, but I was considering that C-level memory optimization tricks could be recycling part of object structures (I may or may not be worth the effort, my little knowledge of SEXPRECs did not give any hint). Thanks, Laurent > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] print.logLik
I have a vector of logLik values that I'd like to return and it would be nice if the the print method didn't run them together. Could I make a plea for using sep = " ", rather than sep = "" in print.logLik? url:www.econ.uiuc.edu/~rogerRoger Koenker email [EMAIL PROTECTED] Department of Economics vox:217-333-4558University of Illinois fax:217-244-6678Champaign, IL 61820 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] patch: two minor debugging-related pointer protection stack issues (PR#10832)
Full_Name: John Brzustowski
Version: R-devel trunk and R-2.4.0
OS: linux
Submission from: (NULL) (76.10.152.79)
Here are two minor potential issues in pointer protection stack (PPS) code which
could arise in debugging R with valgrind. Only the second could possibly cause
a problem in normal use of R, and only under laughably implausible
circumstances.
(1) valgrind is given a wrong address when it is told to mark the reserved "red
zone" portion of the PPS as "no access". This might generate spurious access
errors while debugging under valgrind.
(2) unprotect_ptr always does one more copy than necessary when collapsing the
slot of the pointer it is unprotecting. This is but a trivial performance
penalty unless the PPS is full, in which case it causes a read of the first word
in the PPS red zone. If issue (1) were corrected, that would trigger a spurious
valgrind error.
If all of the following were to occur:
a) the PPS overflowed
b) the cleanup code filled the PPS red zone
c) unprotect_ptr was called from the cleanup code while the PPS red zone was
full
and
d) the memory malloc'd for the PPS occupied the very end of a readable
segment
with fewer than sizeof(SEXP) trailing guard bytes
then a segfault would result. (You are laughing at this point, right?)
In any case, here is a patch against R-devel trunk:
Index: trunk/src/main/memory.c
===
--- trunk/src/main/memory.c (revision 44589)
+++ trunk/src/main/memory.c (working copy)
@@ -1557,7 +1557,7 @@
R_Suicide("couldn't allocate memory for pointer stack");
R_PPStackTop = 0;
#if VALGRIND_LEVEL > 1
-VALGRIND_MAKE_NOACCESS(R_PPStackTop+R_PPStackSize,PP_REDZONE_SIZE);
+VALGRIND_MAKE_NOACCESS(R_PPStack+R_PPStackSize,PP_REDZONE_SIZE);
#endif
vsfac = sizeof(VECREC);
R_VSize = (((R_VSize + 1)/ vsfac));
@@ -2329,11 +2329,11 @@
} while ( R_PPStack[--i] != s );
/* OK, got it, and i is indexing its location */
-/* Now drop stack above it */
+/* Now drop stack above it, if any */
-do {
- R_PPStack[i] = R_PPStack[i + 1];
-} while ( i++ < R_PPStackTop );
+while (++i < R_PPStackTop) {
+ R_PPStack[i - 1] = R_PPStack[i];
+}
R_PPStackTop--;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] print.logLik
> "rk" == roger koenker <[EMAIL PROTECTED]> > on Sat, 23 Feb 2008 10:34:41 -0600 writes: rk> I have a vector of logLik values that I'd like to return and it would rk> be nice rk> if the the print method didn't run them together. Could I make a plea rk> for rk> using sep = " ", rather than sep = "" in print.logLik? well, "yes" to the plea to make the method ameanable to better printing of *several* values, but "no" to just changing sep there: We'd want to implement a change which is compatible for the usual cases of having only one value and your propsal would change all those outputs as well. Wouldn't you even prefer to see something like 'log.Lik' 12.3, 7.89, 34.2 (df = 3) i.e., with "," between the values? Regards, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] print.logLik
Commas would be fine especially if there were spaces too, as in your example. I was just trying to suggest something mimimalist ;-) Cheers, Roger On Feb 23, 2008, at 11:21 AM, Martin Maechler wrote: >> "rk" == roger koenker <[EMAIL PROTECTED]> >>on Sat, 23 Feb 2008 10:34:41 -0600 writes: > >rk> I have a vector of logLik values that I'd like to return and > it would >rk> be nice >rk> if the the print method didn't run them together. Could I > make a plea >rk> for >rk> using sep = " ", rather than sep = "" in print.logLik? > > well, "yes" to the plea to make the method ameanable to better > printing of *several* values, > but "no" to just changing sep there: > We'd want to implement a change which is compatible > for the usual cases of having only one value > and your propsal would change all those outputs as well. > > Wouldn't you even prefer to see something like > >'log.Lik' 12.3, 7.89, 34.2 (df = 3) > > i.e., with "," between the values? > > Regards, > Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Aliasing a function
A simple way to alias a function is to do : g <- function(a = 1, b = 2, c = 3) a + b * c f <- function(...) g(...) but formals (etc) is no longer very helpful. Is there an easy way to programmatically create: f <- function(a=1, b=2, c=3) g(a=a, b=b, c=c) This comes up in ggplot2 where I alias many functions to hide the fact that I'm using proto in the background, and I'd like the aliased functions to be a little more user friendly in terms of revealing what are valid arguments (and also to match up with the rdoc files which I am building). Any ideas? Thanks, Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Aliasing a function
Dear Hadley, Why not just f <- g ? Regards, John John Fox, Professor Department of Sociology McMaster University Hamilton, Ontario, Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > project.org] On Behalf Of hadley wickham > Sent: February-23-08 5:40 PM > To: R-devel > Subject: [Rd] Aliasing a function > > A simple way to alias a function is to do : > > g <- function(a = 1, b = 2, c = 3) a + b * c > f <- function(...) g(...) > > but formals (etc) is no longer very helpful. Is there an easy way to > programmatically create: > > f <- function(a=1, b=2, c=3) g(a=a, b=b, c=c) > > This comes up in ggplot2 where I alias many functions to hide the fact > that I'm using proto in the background, and I'd like the aliased > functions to be a little more user friendly in terms of revealing what > are valid arguments (and also to match up with the rdoc files which I > am building). > > Any ideas? > > Thanks, > > Hadley > > -- > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Aliasing a function
formals can be used like this: f <- g formals(f) <- pairlist(a=1,b=2,c=3) On Sat, Feb 23, 2008 at 5:40 PM, hadley wickham <[EMAIL PROTECTED]> wrote: > A simple way to alias a function is to do : > > g <- function(a = 1, b = 2, c = 3) a + b * c > f <- function(...) g(...) > > but formals (etc) is no longer very helpful. Is there an easy way to > programmatically create: > > f <- function(a=1, b=2, c=3) g(a=a, b=b, c=c) > > This comes up in ggplot2 where I alias many functions to hide the fact > that I'm using proto in the background, and I'd like the aliased > functions to be a little more user friendly in terms of revealing what > are valid arguments (and also to match up with the rdoc files which I > am building). > > Any ideas? > > Thanks, > > Hadley > > -- > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Aliasing a function
I assume he wants to be able to change the formals although its confusing since the example uses the same formals in both cases. On Sat, Feb 23, 2008 at 6:32 PM, John Fox <[EMAIL PROTECTED]> wrote: > Dear Hadley, > > Why not just f <- g ? > > Regards, > John > > > John Fox, Professor > Department of Sociology > McMaster University > Hamilton, Ontario, Canada L8S 4M4 > 905-525-9140x23604 > http://socserv.mcmaster.ca/jfox > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > project.org] On Behalf Of hadley wickham > > Sent: February-23-08 5:40 PM > > To: R-devel > > Subject: [Rd] Aliasing a function > > > > A simple way to alias a function is to do : > > > > g <- function(a = 1, b = 2, c = 3) a + b * c > > f <- function(...) g(...) > > > > but formals (etc) is no longer very helpful. Is there an easy way to > > programmatically create: > > > > f <- function(a=1, b=2, c=3) g(a=a, b=b, c=c) > > > > This comes up in ggplot2 where I alias many functions to hide the fact > > that I'm using proto in the background, and I'd like the aliased > > functions to be a little more user friendly in terms of revealing what > > are valid arguments (and also to match up with the rdoc files which I > > am building). > > > > Any ideas? > > > > Thanks, > > > > Hadley > > > > -- > > http://had.co.nz/ > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Aliasing a function
On Sat, Feb 23, 2008 at 5:52 PM, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > I assume he wants to be able to change the > formals although its confusing since the example > uses the same formals in both cases. Yes, that was an important point that I forgot to mention! Thanks for the pointer to formals but it doesn't work in this case: function (a = 1, b = 2, c = 3) g(...) > f(c=5) Error in f(c = 5) : '...' used in an incorrect context Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
