Re: [Rd] function-like macros undefined
On Tue, 15 Mar 2005 18:58:32 -0800, Vadim Ogranovich [EMAIL PROTECTED] wrote : Hi, Somehow function-like macros from Rinternals.h are not defined when I include the file. foo.c ## #include R.h #include Rinternals.h #ifndef NILSXP #error(NILSXP) #endif #ifndef INTEGER #error(INTEGER) #endif ### When compiled: vor/src% gcc -I/usr/local/lib/R/include -g -O2 -c foo.c -o foo.o foo.c:11:2: #error (INTEGER) Note that NILSXP is defined. This is true for some other function-like macros, e.g. RAW() The definition of INTEGER is wrapped in #ifdef USE_RINTERNALS and there's this comment in Defn.h: /* To test the write barrier used by the generational collector, define TESTING_WRITE_BARRIER. This makes the internal structure of SEXPRECs visible only inside of files that explicitly define USE_RINTERNALS, and all uses of SEXPREC fields that do not go through the appropriate functions or macros will become compilation errors. Since this does impose a small but noticable performance penalty, code that includes Defn.h (or code that explicitly defines USE_RINTERNALS) can access a SEXPREC's fields directly. */ To read about the reasons for the write barrier, see http://www.stat.uiowa.edu/~luke/R/barrier.html Duncan Murdoch Did anyone come across such a problem? version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major2 minor0.1 year 2004 month11 day 15 language R OS: suse.9.2_64 Note also that R doesn't recognize this is Suse, it says x86_64-unknown-linux-gnu. Hope this is not a problem. Thanks, Vadim [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Write Barrier: was: [Rd] function-like macros undefined
Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; iLENGTH(x); ++i) SET_VECTOR_ELT(x, i, xIPtr[i]+1); is the recommended way of doing it. However it seems that only the very first call to SET_VECTOR_ELT, i.e. the one that corresponds to i=0, is strictly necessary. For example, and this is my question, the following should be perfectly safe: SET_VECTOR_ELT(x, 0, xIPtr[0]); for (i=0; iLENGTH(x); ++i) ++xIPtr[i]; Admittedly this looks a bit odd and breaks if LENGTH(x) is zero, but it illustrates the point. * Now, if the above variation is safe, maybe there is a macro that simply marks atomic SEXP-s, i.g. integers and doubles, for modification? * The Write Barrier document has a section Changing the Representation of String Vectors. Is this something which is in works, or planned, for future versions? It would be great if it were, this should give R considerable speed boost. Thanks, Vadim __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: Write Barrier: was: [Rd] function-like macros undefined
On Mar 16, 2005, at 1:34 PM, Vadim Ogranovich wrote: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that Please correct me if I'm wrong, but I thought that the write barrier applies to assignments of SEXP values only (from the doc: ... must be used for all assignments of SEXP pointers ... - note it says of, not to). When dealing with REAL/INTEGER, I believe it's still safe to use INTEGER(x)[0]=... IMHO that's logical, too, because primitive types have no 'age' to be inherited when using ggc. Cheers, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: Write Barrier: was: [Rd] function-like macros undefined
Your original question was about macro-like functions. INTEGER is available to internal R code as a macro; it is also available as a function. Code in packages that uses standard hearders will see the function, which is declared as int *(INTEGER)(SEXP x); I have no idea why you wanted to check whether INTEGER is a macro or not. The value returned is a pointer to the raw int data which you can (ab)use like any other such pointer. On Wed, 16 Mar 2005, Vadim Ogranovich wrote: Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; iLENGTH(x); ++i) SET_VECTOR_ELT(x, i, xIPtr[i]+1); The declaration of SET_VECTOR_ELT is SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v); Your compiler had better complain about your third argument. is the recommended way of doing it. However it seems that only the very first call to SET_VECTOR_ELT, i.e. the one that corresponds to i=0, is strictly necessary. For example, and this is my question, the following should be perfectly safe: SET_VECTOR_ELT(x, 0, xIPtr[0]); for (i=0; iLENGTH(x); ++i) ++xIPtr[i]; Admittedly this looks a bit odd and breaks if LENGTH(x) is zero, but it illustrates the point. * Now, if the above variation is safe, maybe there is a macro that simply marks atomic SEXP-s, i.g. integers and doubles, for modification? Vectors of non-SEXP objects are not a problem--that is why REAL, INTEGER, etc are available as functions to access the raw data pointers. Only vectors of SEXP's (i.e. generic and character vector objects) need to go through the write barrier. * The Write Barrier document has a section Changing the Representation of String Vectors. Is this something which is in works, or planned, for future versions? It would be great if it were, this should give R considerable speed boost. This was considered at the time but is not on the table now. luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: Write Barrier: was: [Rd] function-like macros undefined
Luke, My actual problem was with the RAW() macro, it is not available as a function. I used INTEGER as an illustration because it was in the same group of macros, I guess I shouldn't have. Thank you for your other comments. I was confused, somehow I thought that in 2.0.x ALL access, even to the atomic vectors, should be done via macros/functions. Thanks, Vadim -Original Message- From: Luke Tierney [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 16, 2005 11:08 AM To: Vadim Ogranovich Cc: r-devel@stat.math.ethz.ch Subject: Re: Write Barrier: was: [Rd] function-like macros undefined Your original question was about macro-like functions. INTEGER is available to internal R code as a macro; it is also available as a function. Code in packages that uses standard hearders will see the function, which is declared as int *(INTEGER)(SEXP x); I have no idea why you wanted to check whether INTEGER is a macro or not. The value returned is a pointer to the raw int data which you can (ab)use like any other such pointer. On Wed, 16 Mar 2005, Vadim Ogranovich wrote: Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; iLENGTH(x); ++i) SET_VECTOR_ELT(x, i, xIPtr[i]+1); The declaration of SET_VECTOR_ELT is SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v); Your compiler had better complain about your third argument. is the recommended way of doing it. However it seems that only the very first call to SET_VECTOR_ELT, i.e. the one that corresponds to i=0, is strictly necessary. For example, and this is my question, the following should be perfectly safe: SET_VECTOR_ELT(x, 0, xIPtr[0]); for (i=0; iLENGTH(x); ++i) ++xIPtr[i]; Admittedly this looks a bit odd and breaks if LENGTH(x) is zero, but it illustrates the point. * Now, if the above variation is safe, maybe there is a macro that simply marks atomic SEXP-s, i.g. integers and doubles, for modification? Vectors of non-SEXP objects are not a problem--that is why REAL, INTEGER, etc are available as functions to access the raw data pointers. Only vectors of SEXP's (i.e. generic and character vector objects) need to go through the write barrier. * The Write Barrier document has a section Changing the Representation of String Vectors. Is this something which is in works, or planned, for future versions? It would be great if it were, this should give R considerable speed boost. This was considered at the time but is not on the table now. luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: Write Barrier: was: [Rd] function-like macros undefined
On Wed, 16 Mar 2005, Vadim Ogranovich wrote: My actual problem was with the RAW() macro, it is not available as a function. I used INTEGER as an illustration because it was in the same group of macros, I guess I shouldn't have. It *is* available in R-devel, soon to be 2.1.0: the function was overlooked for 2.0.x. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] function-like macros undefined
Hi, Somehow function-like macros from Rinternals.h are not defined when I include the file. foo.c ## #include R.h #include Rinternals.h #ifndef NILSXP #error(NILSXP) #endif #ifndef INTEGER #error(INTEGER) #endif ### When compiled: vor/src% gcc -I/usr/local/lib/R/include -g -O2 -c foo.c -o foo.o foo.c:11:2: #error (INTEGER) Note that NILSXP is defined. This is true for some other function-like macros, e.g. RAW() Did anyone come across such a problem? version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major2 minor0.1 year 2004 month11 day 15 language R OS: suse.9.2_64 Note also that R doesn't recognize this is Suse, it says x86_64-unknown-linux-gnu. Hope this is not a problem. Thanks, Vadim [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
