Re: [Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Romain Francois]

> Le 23 mars 2020 à 22:55, Dirk Eddelbuettel  a écrit :
> 
> On 23 March 2020 at 17:07, Ben Bolker wrote:
> | Or is there a way I can use Shield() since this an Rcpp-based project
> | anyway?
> 
> Yes you can, and I would recommend it.
> 
> Example from Rcpp itself, file Environment.h:
> 
>  Shield res(Rcpp_fast_eval(Rf_lang2(asEnvironmentSym, x), R_GlobalEnv));

This is not safe. The call made by Rf_lang2() needs to be protected here. 

> For Rcpp_fast_eval, you may still need to #define RCPP_USE_UNWIND_PROTECT
> before including Rcpp.h; as I recall we were seeing too many side effects in
> other packages when globally enabling it.  Or you can play it safe and simply
> use Rcpp_eval.
> 
> This really was more of a rcpp-devel question.
> 
> Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> 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] What is the best way to loop over an ALTREP vector?

[Romain Francois]

Thanks for these comments. I should alter the blog post or write some follow 
up. 

This was a weekend blog post that only benefited from a short time of research 
research. I’m glad people find it useful, but I’m sure a detailed documentation 
of the features from the authors would be more useful. 

Romain

> Le 24 sept. 2019 à 07:48, Gabriel Becker  a écrit :
> 
> Hi Bob,
> 
> Thanks for sending around the link to that. It looks mostly right and looks
> like a useful onramp. There are a few things to watch out for though (I've
> cc'ed Romain so he's aware of these comments). @romain I hope you taake the
> following comments as they are intended, as help rather than attacks.
> 
> The largest issue I see is that the contract for Get_region is that it
> *populates the
> provided buffer with a copy of the data. *That buffer is expected to be
> safe to destructively modify, shuffle, etc though I don't know if we are
> actually doing that anywhere. As such, if I understand his C++ correctly,
> that Get_region method  is not safe and shouldn't be used.
> 
> The other point is that Dataptr_or_null is not actually *guaranteed *not to
> allocate. The default method returns NULL, but we have no way of preventing
> an allocation in a user-defined method, and probably (?) no easy way of
> detecting that it is occurring before it causes a bug. That said, Romain is
> correct that when you are writing Dataptr_or_null methods you should write
> them so that they don't allocate, generally. Basically your methods for
> Dataptr_or_null shouldn't allocate, but you also should not write code that
> relies on hard assumptions that no one's ever will.
> 
> Also, a small nitpick, R's internal mean function doesn't hit Dataptr, it
> hits either INTEGER_ELT (which really should probably be a
> ITERATE_BY_REGION) or ITERATE_BY_REGION.
> 
> Anyway, I hope that helps.
> ~G
> 
> 
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:12 PM Bob Rudis mailto:b...@rud.is>> 
> wrote:
> 
>> Not sure if you're using just C++ or Rcpp for C++ access but
>> https://purrple.cat/blog/2018/10/14/altrep-and-cpp/ has some tips on
>> using C++ w/ALTREP.
>> 
>>> On Sep 23, 2019, at 3:17 PM, Wang Jiefei  wrote:
>>> 
>>> Sorry for post a lot of things, for the first part of code, I copied my
>> C++
>>> iter macro by mistake(and you can see an explicit type casting). Here is
>>> the macro definition from R_exts/Itermacros.h
>>> 
>>> #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
>>> 
>>>strt, nfull, expr) do { \
>>> 
>>> *   const** etype *px = DATAPTR_OR_NULL(sx);   *
>> \
>>> 
>>>  if (px != NULL) {  \
>>> 
>>>  R_xlen_t __ibr_n__ = strt + nfull;\
>>> 
>>>  R_xlen_t nb = __ibr_n__;  \
>>> 
>>>  for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) {   \
>>> 
>>> expr\
>>> 
>>>   } \
>>> 
>>>  }  \
>>> 
>>>  else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype,
>>> \
>>> 
>>> strt, nfull, expr);\
>>> 
>>>   } while (0)
>>> 
>>> 
>>> Best,
>>> 
>>> Jiefei
>>> 
>>> On Mon, Sep 23, 2019 at 3:12 PM Wang Jiefei  wrote:
>>> 
 Hi Gabriel,
 
 I have tried the macro and found a small issue, it seems like the macro
>> is
 written in C and does an implicit type conversion(const void * to const
>> int
 *), see below. While it is allowed in C, C++ seems not happy with it.
>> Is it
 possible to add an explicit type casting so that it can be compatible
>> with
 both language?
 
 
 #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
 
strt, nfull, expr) do { \
 
  *const etype *px = (const** etype *)DATAPTR_OR_NULL(sx);  *
 \
 
  if (px != NULL) {  \
 
  R_xlen_t __ibr_n__ = strt + nfull;\
 
  R_xlen_t nb = __ibr_n__;  \
 
  for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) {   \
 
 expr\
 
   } \
 
  }  \
 
  else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype,
 vtype,   \
 
  strt, nfull, expr);\
 
   } while (0)
 
 
 Also, I notice that the element type(etype) and vector type(vtype) has
 to be specified in the macro. Since the SEXP is the first argument in
>> the
 macro, it seems redundant to define etype and vtype for 

Re: [Rd] Use of C++ in Packages

[Romain Francois]

tl;dr: we need better C++ tools and documentation. 

We collectively know more now with the rise of tools like rchk and improved 
documentation such as Tomas’s post. That’s a start, but it appears that there 
still is a lot of knowledge that would deserve to be promoted to actual 
documentation of best practices. 

I think it is important to not equate C++ as a language, and Rcpp. 

Also, C++ is not just RAII. 

RAII is an important part of how Rcpp was conceived for sure, but it’s not the 
only thing C++ can bring as a language. Templates, lambdas, the stl are 
examples of things that can be used for expressiveness when just accessing data 
without interfering with R, calling R api functions ... 

It would be nice that the usual « you should do that only if you know what 
you’re doing » be transformed to precise documentation, and maybe become part 
of some better tool. If precautions have to be taken before calling such and 
such functions: that’s ok. What are they ? Can we embed that in some tool.

 It is easy enough to enscope code that uses potentially jumpy code into a c++ 
lambda. This could be together with recommendations such as the body of the 
lambda shall only use POC data structures. 

This is similar to precautions you’d take when writing concurrent code. 

Romain

> Le 30 mars 2019 à 00:58, Simon Urbanek  a écrit :
> 
> Kevin,
> 
> 
>> On Mar 29, 2019, at 17:01, Kevin Ushey  wrote:
>> 
>> I think it's also worth saying that some of these issues affect C code
>> as well; e.g. this is not safe:
>> 
>>   FILE* f = fopen(...);
>>   Rf_eval(...);
>>   fclose(f);
> 
> I fully agree, but developers using C are well aware of the necessity of 
> handling lifespan of objects explicitly, so at least there are no surprises.
> 
> 
>> whereas the C++ equivalent would likely handle closing of the file in the 
>> destructor. In other words, I think many users just may not be cognizant of 
>> the fact that most R APIs can longjmp, and what that implies for cleanup of 
>> allocated resources. R_alloc() may help solve the issue specifically for 
>> memory allocations, but for any library interface that has a 'open' and 
>> 'close' step, the same sort of issue will arise.
> 
> Well, I hope that anyone writing native code in package is well aware of that 
> and will use an external pointer with finalizer to clean up native objects in 
> any 3rd party library that are created during the call.
> 
> 
>> What I believe we should do, and what Rcpp has made steps towards, is make 
>> it possible to interact with some subset of the R API safely from C++ 
>> contexts. This has always been possible with e.g. R_ToplevelExec() and 
>> R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). 
>> In theory, as a prototype, an R package could provide a 'safe' C++ interface 
>> to the R API using R_UnwindProtect() and friends as appropriate, and client 
>> packages could import and link to that package to gain access to the 
>> interface. Code generators (as Rcpp Attributes does) can handle some of the 
>> pain in these interfaces, so that users are mostly insulated from the nitty 
>> gritty details.
> 
> I agree that we should strive to provide tools that make it safer, but note 
> that it still requires participation of the users - they have to use such 
> facilities or else they hit the same problem. So we can only fix this for the 
> future, but let's start now.
> 
> 
>> I agree that the content of Tomas's post is very helpful, especially since I 
>> expect many R programmers who dip their toes into the C++ world are not 
>> aware of the caveats of talking to R from C++. However, I don't think it's 
>> helpful to recommend "don't use C++"; rather, I believe the question should 
>> be, "what can we do to make it possible to easily and safely interact with R 
>> from C++?". Because, as I understand it, all of the problems raised are 
>> solvable: either through a well-defined C++ interface, or through better 
>> education.
> 
> I think the recommendation would be different if such tools existed, but they 
> don't. It was based on the current reality which is not so rosy.  Apparently 
> the post had its effect of mobilizing C++ proponents to do something about 
> it, which is great, because if this leads to some solution, the 
> recommendation in the future may change to "use C++ using tools XYZ".
> 
> 
>> I'll add my own opinion: writing correct C code is an incredibly difficult 
>> task. C++, while obviously not perfect, makes things substantially easier 
>> with tools like RAII, the STL, smart pointers, and so on. And I strongly 
>> believe that C++ (with Rcpp) is still a better choice than C for new users 
>> who want to interface with R from compiled code.
> 
> My take is that Rcpp makes the interface *look* easier, but you still have to 
> understand more about the R API that you think. Hence it much easier to write 
> buggy code. Personally, that's why I don't like it (apart from the code 
> 

Re: [Rd] R_ext/Altrep.h should be more C++-friendly

[Romain Francois]

Thank you, 

I updated my example package so that it works with both. 
https://github.com/romainfrancois/altrepisode/blob/96af0548a9ecc08701d119ea427e16940a82882b/src/altrepisode.h
 


We have to do something like this unless we depend on R 3.6.0: 

#if R_VERSION < R_Version(3, 6, 0)
  #define class klass
  extern "C" {
#include 
  }
  #undef class
#else
  #include 
#endif

Romain

> Le 9 oct. 2018 à 05:09, Tierney, Luke  a écrit :
> 
> Thanks for the suggestion. Committed in R_devel.
> 
> Best,
> 
> luke
> 
> On Mon, 8 Oct 2018, Michael Sannella wrote:
> 
>> I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
>> it needs two changes:
>> 
>> 1. add the same __cplusplus check as most of the other header files:
>> #ifdef  __cplusplus
>> extern "C" {
>> #endif
>> ...
>> #ifdef  __cplusplus
>> }
>> #endif
>> 
>> 2. change the line
>> R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
>>  to
>> R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
>>  since C++ doesn't like an argument named 'class'
>> 
>>   ~~ Michael Sannella
>> 
>> 
>> 
> 
> -- 
> Luke Tierney
> 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:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_ext/Altrep.h should be more C++-friendly

[Romain Francois]

I successfully use this workaround in this package: 
https://github.com/romainfrancois/altrepisode

(which is just my way to get familiar with altrep, nothing serious)

> Le 9 oct. 2018 à 17:00, Gabe Becker  a écrit :
> 
> Michael,
> 
> Thanks for reaching out. This was brought up by Romaine Francois offline to 
> me as well. What he does as a workaround is 
> 
> 
> #define class klass
> extern "C" {
>   #include 
> }
> #undef class
> 
> While we consider changing Altrep.h, the above should work for you  in the 
> immediate term.
> 
> Let me know if it doesn't.
> 
> ~G
> 
> 
> 
> 
> 
>> On Mon, Oct 8, 2018 at 4:17 PM, Michael Sannella via R-devel 
>>  wrote:
>> I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
>> it needs two changes:
>> 
>> 1. add the same __cplusplus check as most of the other header files:
>> #ifdef  __cplusplus
>> extern "C" {
>> #endif
>> ...
>> #ifdef  __cplusplus
>> }
>> #endif
>> 
>> 2. change the line
>> R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
>>  to
>> R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
>>  since C++ doesn't like an argument named 'class'
>> 
>>   ~~ Michael Sannella
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> 
> 
> -- 
> Gabriel Becker, Ph.D
> Scientist
> Bioinformatics and Computational Biology
> Genentech Research

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Linking to the BH package introduces CRAN warnings

[Romain Francois]

Envoyé de mon iPhone

 Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel e...@debian.org a écrit :
 
 
 On 5 November 2014 at 00:55, kaveh wrote:
 | Dear all,
 | 
 | 
 | the simple code in below, when send to the
 | win-builder returns the following (and no other)
 | warning:
 | 
 | 
 | * checking compiled code ... WARNING
 | File 'quicky/libs/i386/quicky.dll':
 |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
 |  Object: 'quicky.o'
 |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
 |  Object: 'quicky.o'
 | File 'quicky/libs/x64/quicky.dll':
 |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
 |  Object: 'quicky.o'
 |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
 |  Object: 'quicky.o'
 | 
 | Compiled code should not call entry points which might terminate R nor
 | write to stdout/stderr instead of to the console, nor the C RNG.
 | 
 | See 'Writing portable packages' in the 'Writing R Extensions' manual.
 | 
 | 
 | Here is the source:
 | 
 | #include algorithm
 | #include cstdlib
 | #include ctime
 | #include functional
 | #include fstream
 | #include iostream
 | #include math.h
 | #include time.h
 | #include stdio.h
 | #include stdlib.h
 | #include sstream
 | #include vector
 | #include random
 | 
 | #include boost/math/distributions/normal.hpp
 | #include boost/math/distributions/chi_squared.hpp
 | 
 | #include Eigen/Dense
 | 
 | using namespace std;
 | using namespace Eigen;
 | using Eigen::MatrixXd;
 | using Eigen::VectorXd;
 | using Eigen::VectorXi;
 | using Eigen::RowVectorXd;
 | 
 | 
 | using boost::math::chi_squared;
 | using boost::math::quantile;
 | using boost::math::complement;
 | using boost::math::normal_distribution;
 | using namespace boost::math::policies;
 | 
 | typedef policy
 |promote_doubletrue
 | my_policy_norm;
 | typedef policy
 |promote_doubletrue
 | my_policy_chi2;
 | 
 | typedef boost::math::normal_distributiondouble,my_policy_norm my_norm;
 | typedef boost::math::chi_squared_distributiondouble,my_policy_chi2 
 | my_chi2;
 | 
 | 
 | VectorXd GetQs(const VectorXd x){
 |  const int n=x.size();
 |  double mytol=1e-8;
 |  double the_max=x.maxCoeff();
 |  double the_min=x.minCoeff();
 |  double the_rag=(the_max-the_min);
 |  if(the_ragmytol)return(x);
 |  if(1.0-the_maxmytol)return(x);
 |  if(the_minmytol)return(x);
 |  VectorXd y=x.array();
 |  for(int i=0;in;i++) 
 | y(i)=sqrt(quantile(complement(my_chi2(1.0),x(i;
 |  return(y);
 | }
 | extern C{
 |  void quicky(int* rn,double* xi,double* yi){
 |  const int n=*rn;
 |  VectorXd x=MapVectorXd(xi,n);
 |  MapVectorXd(yi,n)=GetQs(x);
 |  }
 | }
 | 
 | 
 | So I guess, I should fill a bug report with the
 | BH maintainer?
 
 Err, why? BH does nothing wrong. 

Calls to these forbidden fruits come from the BH tree so ...

 You are NOT forced or required to use the Boost distributions header __as R
 comes with the equivalent functionality__ via the Rmath.h header file from R.
 Which has functionality that Rcpp provides to you in scalar and vector form.
 
 And there are probably several dozen examples of using the R distribution
 functions from Rcpp.
 
 So this is _precisely_ what I suggested several mails ago: do your homework,
 identify which header is causing it.  And the obvious next step is then to
 not use the header.

So why these headers are shipped with BH then. 

 Dirk
 
 
 | Best regards,
 | 
 | 
 | On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
 |  Gentlemen,
 | 
 |  On 4 November 2014 at 23:36, kaveh wrote:
 |  | Dear Hadley,
 |  |
 |  | Thank you for this information, maybe the CRAN gods
 |  | will look favourably on this case too,
 | 
 |  You seemed to have missed a point my earlier email tried to stress: 
 Inclusion
 |  of BH does not lead to the warning.
 | 
 |  All this depends on WHICH headers are included, and the OP will need to 
 sort
 |  this out by modifying his code.
 | 
 |  Dirk
 |
 |  | Best regards,
 |  |
 |  | On 2014-11-04 23:32, Hadley Wickham wrote:
 |  |  | However, it seems some of the codes in the BH package
 |  |  | might. At any rate, when I include some boost headers such as
 |  |  | boost/math/distributions/ through BH, I get the following warnings
 |  |  |   when  submitting to the win-builder page:
 |  |  |
 |  |  |
 |  |  |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
 |  |  |
 |  |  |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
 |  |  |
 |  |  |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
 |  |  |
 |  |  |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
 |  |  You’re kind of out of luck. These functions are both:
 |  |- used by the boost headers
 |  |- forbidden by R, well at least forbidden by CRAN
 |  |  Mybe - I had this note in RSQLite, and CRAN seemed ok with my 
 explanation:
 |  | 
 |  |  * checking compiled code ... NOTE
 |  | File 
 

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Romain Francois]

I'll pick up operators. 

Le 7 sept. 2014 à 18:03, Uwe Ligges lig...@statistik.tu-dortmund.de a écrit :

 
 
 On 05.09.2014 20:25, Greg Snow wrote:
 Uwe,
 
 Have all of these packages found new maintainers? if not, which ones
 are still looking to be adopted?
 
 Thanks for asking, the ones still looking to be adaopted are:
 SemiPar cghseg monreg operators
 
 Best,
 Uwe Ligges
 
 
 
 thanks,
 
 On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges uwe.lig...@r-project.org wrote:
 Dear maintainers and R-devel,
 
 Several orphaned CRAN packages are about to be archived due to outstanding
 QC problems, but have CRAN and BioC packages depending on them which would
 be broken by the archival (and hence need archiving alongside).
 Therefore we are looking for new maintainers taking over maintainership for
 one or more of the following packages:
 
 R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr
 
 Package maintainers whose packages depend on one of these may be natural
 candidates to become new maintainers.
 Hence this messages is addressed to all these maintainers via BCC and to
 R-devel.
 
 See
 
   http://CRAN.R-project.org/package=R2HTML
   http://CRAN.R-project.org/package=SemiPar
   http://CRAN.R-project.org/package=cghseg
   http://CRAN.R-project.org/package=hexbin
   http://CRAN.R-project.org/package=lgtdl
   http://CRAN.R-project.org/package=monreg
   http://CRAN.R-project.org/package=muhaz
   http://CRAN.R-project.org/package=operators
   http://CRAN.R-project.org/package=pamr
 
 for information on the QC issues and the reverse dependencies.
 
 Best wishes,
 Uwe Ligges
 (for the CRAN team)
 
 __
 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] using C code to create data frame but always return as list

[Romain Francois]

Hi, 

Can you give us what str on the returned object gives you? 

I think you need : 

SET_OBJECT(and, 1) ; 

at the end. 

Romain

Le 24 juin 2014 à 08:57, Yu Gong armg...@yahoo.com a écrit :

 there is my code,  expect return value  is a data frame but R say it is list:
 
 SEXP Julia_R_MD_NA_DataFrame(jl_value_t* Var)
 {
  SEXP ans,names,rownames;
  char evalcmd[4096];
  int i;
  const char* dfname=DataFrameName0tmp;
  jl_set_global(jl_main_module, jl_symbol(dfname), (jl_value_t*)Var);
  //Get Frame cols 
  sprintf(evalcmd,size(%s,2),dfname);
  jl_value_t* cols=jl_eval_string(evalcmd);
  int collen=jl_unbox_long(cols);
  jl_value_t* eachcolvector;
  //Create VECSXP
 
  //Create SEXP for Each Column and assign
  PROTECT(ans=allocVector(VECSXP,collen));
  for (i=0;icollen;i++)
  {
   sprintf(evalcmd,%s[%d],dfname,i+1);
   eachcolvector=jl_eval_string(evalcmd);
   SET_VECTOR_ELT(ans,i,Julia_R_MD_NA(eachcolvector));
  }
  //set names attribute
  sprintf(evalcmd,names(%s),dfname);
  jl_value_t* ret=jl_eval_string(evalcmd);
  jl_value_t* onesymbol;
  if (jl_is_array(ret))
  {
   PROTECT(names=allocVector(STRSXP,collen));
   for (i=0;ijl_array_len(ret);i++)
   { 
onesymbol=jl_arrayref((jl_array_t*)ret,i);
if (jl_is_symbol(onesymbol))
 SET_STRING_ELT(names,i,mkChar(((jl_sym_t*)onesymbol)-name));
   }
   setAttrib(ans,R_NamesSymbol,names);
   UNPROTECT(1);
  } 
  //set row names
  sprintf(evalcmd,size(%s,1),dfname);
  jl_value_t* rows=jl_eval_string(evalcmd);
  int rowlen=jl_unbox_long(rows);
  PROTECT(rownames=allocVector(INTSXP,rowlen));
  for (i=0;irowlen;i++)
   INTEGER(rownames)[i]=i+1;
  setAttrib(ans,R_RowNamesSymbol,rownames);
  UNPROTECT(1);
  //set class as data frame
  setAttrib(ans,R_ClassSymbol,mkString(data.frame));
  UNPROTECT(1);
  return ans;
 }

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Is it possible to shrink an R object in place?

[Romain Francois]

Hello, 

I’ve been using shrinking in 
https://github.com/hadley/dplyr/blob/master/inst/include/tools/ShrinkableVector.h

This defines a ShrinkableVector of some R type (INTSXP, ...) given the maximum 
number of elements it will hold. Then, I reset with SETLENGTH when needed. The 
constructor protects the SEXP, and the destructor restores the original length 
before removing the protection. With this I only have to allocate the data 
once, and I can make R believe a vector is of a different size. As long as I 
restore the correct size eventually. 

Kevin, when you start using parallelism, you have to change the way you 
approach the sequence of things that go on. Particularly it is less of a 
problem to do a double pass, i.e. one to figure out the appropriate size and 
one to handle part of the data. And guess what, there is lots of that to come 
in next versions of Rcpp11. 

Romain

Le 11 avr. 2014 à 17:08, Simon Urbanek simon.urba...@r-project.org a écrit :

 Kevin,
 Kevin,
 
 On Apr 10, 2014, at 4:57 PM, Kevin Ushey kevinus...@gmail.com wrote:
 
 Suppose I generate an integer vector with e.g.
 
   SEXP iv = PROTECT(allocVector(INTSXP, 100));
 
 and later want to shrink the object, e.g.
 
   shrink(iv, 50);
 
 would simply re-set the length to 50, and allow R to reclaim the
 memory that was previously used.
 
 Is it possible to do this while respecting how R manages memory?
 
 
 The short answer is, no.
 
 There are several problems with this, one of the main ones being that there 
 is simply no way to release the excess memory, so the vector still has the 
 full length in memory. There is the SETLENGTH() function, but it's not part 
 of the API and it has been proposed for elimination because of the inherent 
 issues it causes (discrepancy in allocated and reported length).
 
 
 The motivation: there are many operations where the length of the
 output is not known ahead of time, and in such cases one typically
 uses a data structure that can grow efficiently. Unfortunately, IIUC
 SEXPRECs cannot do this; however, an alternative possibility would
 involve reserving extra memory, and then shrinking to fit after the
 operation is complete.
 
 There have been some discussions previously that defaulted to answers
 of the form you should probably just copy, e.g.
 https://stat.ethz.ch/pipermail/r-devel/2008-March/048593.html, but I
 wanted to ping and see if others had ideas, or if perhaps there was
 code in the R sources that might be relevant.
 
 Another reason why this is interesting is due to C++11 and
 multi-threading: if I can pre-allocate SEXPs that will contain results
 in the main thread, and then fill these SEXPs asynchronously (without
 touching R, and hence not getting in the way of the GC or otherwise),
 I can then fill these SEXPs in place and shrink-to-fit after the
 computations have been completed. With C++11 support coming with R
 3.1.0, functionality like this is very attractive.
 
 
 I don't see how this is related to the question - it was always possible to 
 fill SEXPs from parallel threads and has been routinely used even in R itself 
 (most commonly via OpenMP).
 
 
 The obvious alternatives are to 1) determine the length of the output
 first and hence generate SEXPs of appropriate size right off the bat
 (potentially expensive), and 2) fill thread-safe containers and copy
 to an R object (definitely expensive).
 
 
 In most current OSes, it is impossible to shrink allocated memory in-place, 
 so if you really don't know the size of the object, it will be copied anyway. 
 As mentioned above, the only case where shrinking may work is if you only 
 need to strip a few elements of a large vector so that keeping the same 
 allocation has no significant effect.
 
 Cheers,
 Simon
 
 
 
 
 I am probably missing something subtle (or obvious) as to why this may
 not work, or be recommended, so I appreciate any comments.
 
 Thanks,
 Kevin
 
 __
 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] CXX_STD and configure.ac in packages

[Romain Francois]

Hi, 

My advice would be to use SystemRequirements: C++11

As unordered_map is definitely a part of C++11, assuming this version of the 
standard gives it to you. Your package may not compile on platforms where a 
C++11 compiler is not available, but perhaps if this becomes a pattern, then 
such compilers will start to be available, as in the current version of OSX and 
recent enough versions of various linux distributions. 

The subset of feature that the version of gcc gives you with Rtools might be 
enough. 

Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which 
will expand to either unordered_map or tr1::unordered_map, all the condition 
compiling is done in Rcpp. 

Romain

Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :

 In C++ code for use in a R-3.1.0 package, my specific problem is that I would 
 like to use unordered_map if it is available, or tr1/unordered_map if 
 not, or map if all else fails.
 
 I (think I) can accomplish this with configure.ac as
 
 AC_INIT(DESCRIPTION)
 
 CXX=`${R_HOME}/bin/R CMD config CXX`
 CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
 
 AC_CONFIG_HEADERS([src/config.h])
 AC_LANG(C++)
 AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
 AC_OUTPUT
 
 Use of configure.ac does not seem to be entirely consistent with section 
 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see 
 below) code one should
 
CXX_STD = CXX11
 
 in Makevars(.win). My code does not require a compiler that supports the full 
 C++11 feature set. In addition, I do not understand the logic of setting a 
 variable that influences compiler flags in Makevars -- configure.ac will see 
 a compiler with inaccurate flags.
 
 Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
 
 Some minor typos:
 
 /R-3-1-branch$ svn diff
 Index: doc/manual/R-exts.texi
 ===
 --- doc/manual/R-exts.texi(revision 65339)
 +++ doc/manual/R-exts.texi(working copy)
 @@ -2250,7 +2250,7 @@
 @subsection Using C++11 code
 
 @R{} can be built without a C++ compiler although one is available
 -(but not necessarily installed) or all known @R{} platforms.
 +(but not necessarily installed) on all known @R{} platforms.
 For full portability across platforms, all
 that can be assumed is approximate support for the C++98 standard (the
 widely used @command{g++} deviates considerably from the standard).
 @@ -2272,7 +2272,7 @@
 support a flag @option{-std=c++0x}, but the latter only provides partial
 support for the C++11 standard.
 
 -In order to use C++ code in a package, the package's @file{Makevars}
 +In order to use C++11 code in a package, the package's @file{Makevars}
 file (or @file{Makevars.win} on Windows) should include the line
 
 @example
 @@ -2329,7 +2329,7 @@
 anything other than the GNU version of C++98 and GNU extensions (which
 include TR1).  The default compiler on Windows is GCC 4.6.x and supports
 the @option{-std=c++0x} flag and some C++11 features (see
 -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
 +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
 platforms, it is necessary to select a different compiler for C++11, as
 described above, @emph{via} personal @file{Makevars} files.  For
 example, on OS X 10.7 or later one could select @command{clang++}.
 
 -- 
 Computational Biology / Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109
 
 Location: Arnold Building M1 B861
 Phone: (206) 667-2793
 
 __
 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] [RFC] A case for freezing CRAN

[Romain Francois]

Weighting in. FWIW, I find the proposal conceptually quite interesting. 

For package developers, it does not have to be a frustration to have to wait a 
new version of R to release their code. Anticipated frustration was my initial 
reaction. Thinking about this more, I think this could be changed into 
opportunity. 

Since the pattern here is to use Rcpp as an example of something causing 
compatibility headaches, and I have some responsibility there, maybe I can 
comment on this. I would find it extremely valuable if there was only one 
unique version of Rcpp for a given released version of R. 

Users would have to wait longer to have the new stuff, but one can argue that 
at least they get something that is more tested. 

Would it be helpful for authors of package that have lots of dependency to 
start having stricter depends declarations in their DESCRIPTION files, e.g. : 

Depends: R (== 3.1.0)

?

Romain


For example, personally I’m waiting for 3.1.0 for releasing Rcpp11 because I 
want to leverage some C++11 support that has been included in R. It has been 
frustrating to have to wait, but it does change the way I make changes to the 
codebase. Perhaps it is a good habit to take. And it does not need « more work 
» for others, just more discipline and self control from people implementing 
this pattern. 

also, declaring a strict dependency requirement against a released version of R 
perhaps could resume the drama of « you were asked to test this against a very 
recent version of R-devel, and guess what a few hours ago I’ve just added a new 
test that makes your package non R CMD check worthy ». So less work for CRAN 
maintainers then. 

Le 19 mars 2014 à 23:57, Hervé Pagès hpa...@fhcrc.org a écrit :

 
 
 On 03/19/2014 02:59 PM, Joshua Ulrich wrote:
 On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu 
 wrote:
 On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich josh.m.ulr...@gmail.com
 wrote:
 
 The suggested solution is not described in the referenced article.  It
 was not suggested that it be the operating system's responsibility to
 distribute snapshots, nor was it suggested to create binary
 repositories for specific operating systems, nor was it suggested to
 freeze only a subset of CRAN packages.
 
 
 IMO this is an implementation detail. If we could all agree on a particular
 set of cran packages to be used with a certain release of R, then it doesn't
 matter how the 'snapshotting' gets implemented. It could be a separate
 repository, or a directory on cran with symbolic links, or a page somewhere
 with hyperlinks to the respective source packages. Or you can put all
 packages in a big zip file, or include it in your OS distribution. You can
 even distribute your entire repo on cdroms (debian style!) or do all of the
 above.
 
 The hard problem is not implementation. The hard part is that for
 reproducibility to work, we need community wide conventions on which
 versions of cran packages are used by a particular release of R. Local
 downstream solutions are impractical, because this results in
 scripts/packages that only work within your niche using this particular
 snapshot. I expect that requiring every script be executed in the context of
 dependencies from some particular third party repository will make
 reproducibility even less common. Therefore I am trying to make a case for a
 solution that would naturally improve reliability/reproducibility of R code
 without any effort by the end-user.
 
 So implementation isn't a problem.  The problem is that you need a way
 to force people not to be able to use different package versions than
 what existed at the time of each R release.  I said this in my
 previous email, but you removed and did not address it: However, you
 would need to find a way to actively _prevent_ people from installing
 newer versions of packages with the stable R releases.  Frankly, I
 would stop using CRAN if this policy were adopted.
 
 I suggest you go build this yourself.  You have all the code available
 on CRAN, and the dates at which each package was published.  If others
 who care about reproducible research find what you've built useful,
 you will create the very community you want.  And you won't have to
 force one single person to change their workflow.
 
 Yeah we've already heard this do it yourself kind of answer. Not a
 very productive one honestly.
 
 Well actually that's what we've done for the Bioconductor repositories:
 we freeze the BioC packages for each version of Bioconductor. But since
 this freezing doesn't happen at the CRAN level, and many BioC packages
 depend on CRAN packages, the freezing is only at the surface. Would be
 much better if the freezing was all the way down to the bottom of the
 sea. (Note that it is already if you install binary packages only.)
 
 Yes it's technically possible to work around this by also hosting
 frozen versions of CRAN, one per version of Bioconductor, and have
 biocLite() (the tool BioC 

Re: [Rd] getting environment from top promise

[Romain Francois]

Le 14 févr. 2014 à 16:40, luke-tier...@uiowa.edu a écrit :

 On Tue, 11 Feb 2014, Romain Francois wrote:
 
 Hello,
 
 We have something very similar to your while loop in dplyr.
 https://github.com/hadley/dplyr/blob/02a609310184d003c2ae9e0c013bfa69fa4d257a/inst/include/tools/DataDots.h#L15
 
 because we need to know exactly in which environment a promise is supposed 
 to be evaluated, even though we might combine standard R evaluation with an 
 alternative faster engine. this is the basis of what we called hybrid 
 evaluation.
 
 
 For future work, I also have the while loop in the Promise class in Rcpp11, 
 so that when you create a Promise in Rcpp11, its .environment() method gives 
 you what you expect.
 https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Promise.h#L14
 
 So, this is something I find useful, although I’m not sure we are supposed 
 to mess with promises.
 
 No you are not :-)

Most of what we do with them is consult them. So whenever the better approach 
you mention becomes available in R, we can update the Promise class and change 
how to get access to the expression and the environment in which it will be 
eventually evaluated. 

Not the first time I get « you are not supposed to use that because we might 
change it ». Experience is that that sort of changes are relatively slow to 
happen, so are easy to adapt to. 

Romain

 Promises are an internal mechanism for implementing lazy
 evaluation. They are convenient but also very inefficient, so they may
 very well go away when a better approach becomes available.  What will
 not go away is the functionality they provide -- bindings with
 deferred evaluations, an expression/code for the evaluation, and an
 environment (until the evaluation happens). If you build on those
 concepts you will be more future proof than if you assume there will
 be an internal promise object.
 
 Best,
 
 luke
 
 
 Romain
 
 Le 11 févr. 2014 à 19:02, Michael Lawrence lawrence.mich...@gene.com a 
 écrit :
 
 Hi all,
 
 It seems that there is a use case for obtaining the environment for the
 top promise. By top, I mean following the promise chain up the call
 stack until hitting a non-promise.
 
 S4 data containers often mimic the API of base R data structures. This
 means writing S4 methods for functions that quote their arguments, like
 with() and subset(). The methods package directly forwards any arguments
 not used for dispatch, so substitute(subset) is able to resolve the
 original quoted argument (this is not the case for naively written
 wrappers).  The problem then becomes figuring out the environment in which
 to evaluate the expression.
 
 Consider:
 
 setClass(A, representation(df = data.frame))
 
 setMethod(subset, A, function(x, subset) {
 env - parent.frame(2)
 x@df - x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
 x
 })
 
 dropLowMpg - function(x, cutoff=20) {
 invisible(subset(x, mpg  cutoff))
 }
 
 a - new(A, df=mtcars)
 dropLowMpg(a)
 
 The above works just fine, because we figured out that we need to evaluate
 in the grand-parent frame to avoid the frame of the generic call. But now
 let's assume A has a subclass B, and subset,B delegates to subset,A via
 callNextMethod(). The call stack is different, and our assumption is
 invalid.
 
 setClass(B, representation(nrow=integer), contains=A)
 setMethod(subset, B, function(x, ...) {
 ans - callNextMethod()
 ans@nrow - nrow(ans@df)
 ans
 })
 b - new(B, df=mtcars)
 dropLowMpg(b)
 Error in eval(expr, envir, enclos) (from #3) : object 'cutoff' not found
 
 We can fix this with a simple C function:
 SEXP top_prenv(SEXP nm, SEXP env)
 {
 SEXP promise = findVar(nm, env);
 while(TYPEOF(promise) == PROMSXP) {
   env = PRENV(promise);
   promise = PREXPR(promise);
 }
 return env;
 }
 
 With R wrapper:
 top_prenv - function(x) {
 .Call2(top_prenv, substitute(x), parent.frame())
 }
 
 Then this works (need to set subset,B again to reset cache):
 
 setMethod(subset, A, function(x, subset) {
 env - top_prenv(subset)
 x@df - x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
 x
 })
 setMethod(subset, B, function(x, ...) {
 ans - callNextMethod()
 ans@nrow - nrow(ans@df)
 ans
 })
 
 b - new(B, df=mtcars)
 dropLowMpg(b)
 
 Would this be a useful addition to R? Is there a better way to solve this
 issue? We're using this successfully in the IRanges package now, but we'd
 like to avoid dealing with the internal details of R, and this is something
 that could be of general benefit.
 
 Thanks,
 Michael
 
 [[alternative HTML version deleted]]
 
 __
 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
 
 
 -- 
 Luke Tierney
 Chair, Statistics and Actuarial Science
 Ralph E. Wareham Professor of Mathematical Sciences
 University of Iowa  Phone: 319-335

Re: [Rd] getting environment from top promise

[Romain Francois]

Hello, 

We have something very similar to your while loop in dplyr. 
https://github.com/hadley/dplyr/blob/02a609310184d003c2ae9e0c013bfa69fa4d257a/inst/include/tools/DataDots.h#L15

because we need to know exactly in which environment a promise is supposed to 
be evaluated, even though we might combine standard R evaluation with an 
alternative faster engine. this is the basis of what we called hybrid 
evaluation. 


For future work, I also have the while loop in the Promise class in Rcpp11, so 
that when you create a Promise in Rcpp11, its .environment() method gives you 
what you expect. 
https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Promise.h#L14
 

So, this is something I find useful, although I’m not sure we are supposed to 
mess with promises. 

Romain

Le 11 févr. 2014 à 19:02, Michael Lawrence lawrence.mich...@gene.com a écrit :

 Hi all,
 
 It seems that there is a use case for obtaining the environment for the
 top promise. By top, I mean following the promise chain up the call
 stack until hitting a non-promise.
 
 S4 data containers often mimic the API of base R data structures. This
 means writing S4 methods for functions that quote their arguments, like
 with() and subset(). The methods package directly forwards any arguments
 not used for dispatch, so substitute(subset) is able to resolve the
 original quoted argument (this is not the case for naively written
 wrappers).  The problem then becomes figuring out the environment in which
 to evaluate the expression.
 
 Consider:
 
 setClass(A, representation(df = data.frame))
 
 setMethod(subset, A, function(x, subset) {
  env - parent.frame(2)
  x@df - x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
  x
 })
 
 dropLowMpg - function(x, cutoff=20) {
  invisible(subset(x, mpg  cutoff))
 }
 
 a - new(A, df=mtcars)
 dropLowMpg(a)
 
 The above works just fine, because we figured out that we need to evaluate
 in the grand-parent frame to avoid the frame of the generic call. But now
 let's assume A has a subclass B, and subset,B delegates to subset,A via
 callNextMethod(). The call stack is different, and our assumption is
 invalid.
 
 setClass(B, representation(nrow=integer), contains=A)
 setMethod(subset, B, function(x, ...) {
  ans - callNextMethod()
  ans@nrow - nrow(ans@df)
  ans
 })
 b - new(B, df=mtcars)
 dropLowMpg(b)
 Error in eval(expr, envir, enclos) (from #3) : object 'cutoff' not found
 
 We can fix this with a simple C function:
 SEXP top_prenv(SEXP nm, SEXP env)
 {
  SEXP promise = findVar(nm, env);
  while(TYPEOF(promise) == PROMSXP) {
env = PRENV(promise);
promise = PREXPR(promise);
  }
  return env;
 }
 
 With R wrapper:
 top_prenv - function(x) {
  .Call2(top_prenv, substitute(x), parent.frame())
 }
 
 Then this works (need to set subset,B again to reset cache):
 
 setMethod(subset, A, function(x, subset) {
  env - top_prenv(subset)
  x@df - x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
  x
 })
 setMethod(subset, B, function(x, ...) {
  ans - callNextMethod()
  ans@nrow - nrow(ans@df)
  ans
 })
 
 b - new(B, df=mtcars)
 dropLowMpg(b)
 
 Would this be a useful addition to R? Is there a better way to solve this
 issue? We're using this successfully in the IRanges package now, but we'd
 like to avoid dealing with the internal details of R, and this is something
 that could be of general benefit.
 
 Thanks,
 Michael
 
   [[alternative HTML version deleted]]
 
 __
 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

[Rd] LinkingTo self

[Romain Francois]

Hello, 

Shipping header files for a package in inst/include and let other packages use 
it with LinkingTo is popular. 

Unfortunately for the package itself, we still need to use something like :

PKG_CPPFLAGS+=-I../inst/include/

in the Makevars and Makevars.win files. 

Could this become automatic ? 

So if a package has src/ and inst/include/ can we have it so that a -I flag is 
set accordingly. 

Would anyone be interested in reviewing a patch against R-devel for such 
feature ?

Romain

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Strategies for keeping autogenerated .Rd files out of a Git tree

[Romain Francois]

Pushing back to github is not so difficult. See e.g 
http://blog.r-enthusiasts.com/2013/12/04/automated-blogging.html

You can manage branches easily in travis. You could for example decide to do 
something different if you are on the master branch ...

Romain

Le 13 déc. 2013 à 12:03, Kirill Müller kirill.muel...@ivt.baug.ethz.ch a 
écrit :

 Gabor
 
 I agree with you. There's Travis CI, and r-travis -- an attempt to integrate 
 R package testing with Travis. Pushing back to GitHub is possible, but the 
 setup is somewhat difficult. Also, this can be subject to race conditions 
 because each push triggers a test run and they can happen in parallel even 
 for the same repository. How do you handle branches?
 
 It would be really great to be able to execute custom R code before building. 
 Perhaps in a PreBuild: section in DESCRIPTION?
 
 
 Cheers
 
 Kirill
 
 
 On 12/12/2013 02:21 AM, Gábor Csárdi wrote:
 Hi,
 
 this is maybe mostly a personal preference, but I prefer not to put
 generated files in the vc repository. Changes in the generated files,
 especially if there is many of them, pollute the diffs and make them
 less useful.
 
 If you really want to be able to install the package directly from
 github, one solution is to
 1. create another repository, that contains the complete generated
 package, so that install_github() can install it.
 2. set up a CI service, that can download the package from github,
 build the package or the generated files (check the package, while it
 is at it), and then push the build stuff back to github.
 3. set up a hook on github, that invokes the CI after each commit.
 
 I have used this setup in various projects with jenkins-ci and it
 works well. Diffs are clean, the package is checked and built
 frequently, and people can download it without having to install the
 tools that generate the generated files.
 
 The only downside is that you need to install a CI, so you need a
 server for that. Maybe you can do this with travis-ci, maybe not, I
 am not familiar with it that much.
 
 Best,
 Gabor
 
 On Wed, Dec 11, 2013 at 7:39 PM, Kirill Müller
 kirill.muel...@ivt.baug.ethz.ch wrote:
 Hi
 
 Quite a few R packages are now available on GitHub long before they appear
 on CRAN, installation is simple thanks to devtools::install_github().
 However, it seems to be common practice to keep the .Rd files (and NAMESPACE
 and the Collate section in the DESCRIPTION) in the Git tree, and to manually
 update it, even if they are autogenerated from the R code by roxygen2. This
 requires extra work for each update of the documentation and also binds
 package development to a specific version of roxygen2 (because otherwise
 lots of bogus changes can be added by roxygenizing with a different
 version).
 
 What options are there to generate the .Rd files during build/install? In
 https://github.com/hadley/devtools/issues/43 the issue has been discussed,
 perhaps it can be summarized as follows:
 
 - The devtools package is not the right place to implement
 roxygenize-before-build
 - A continuous integration service would be better for that, but currently
 there's nothing that would be easy to use
 - Roxygenizing via src/Makefile could work but requires further
 investigation and an installation of Rtools/xcode on Windows/OS X
 
 Especially the last point looks interesting to me, but since this is not
 widely used there must be pitfalls I'm not aware of. The general idea would
 be:
 
 - Place code that builds/updates the .Rd and NAMESPACE files into
 src/Makefile
 - Users installing the package from source will require infrastructure
 (Rtools/make)
 - For binary packages, the .Rd files are already generated and added to the
 .tar.gz during R CMD build before they are submitted to CRAN/WinBuilder, and
 they are also generated (in theory) by R CMD build --binary
 
 I'd like to hear your opinion on that. I have also found a thread on package
 development workflow
 (https://stat.ethz.ch/pipermail/r-devel/2011-September/061955.html) but
 there was nothing on un-versioning .Rd files.
 
 
 Cheers
 
 Kirill
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 
 -- 
 _
 ETH Zürich
 Institute for Transport Planning and Systems
 HIL F 32.2
 Wolfgang-Pauli-Str. 15
 8093 Zürich
 
 Phone:   +41 44 633 33 17
 Fax: +41 44 633 10 57
 Secretariat: +41 44 633 31 05
 E-Mail:  kirill.muel...@ivt.baug.ethz.ch
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Linking to native routines in other packages

[Romain Francois]

Le 06/12/2013 22:29, Hadley Wickham a écrit :

But now if I do Depends: Rcpp or Imports: Rcpp for the sole purpose of this
LinkingTo mechanism, I'm getting

* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘Rcpp’
   All declared Imports should be used.
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.


This is just a note, so perhaps it's spurious, and can be ignored as
long as you provide an explanation when submitting to CRAN.

Hadley


The problem is that I'd have to ask every package maintainer to 
negociate that when they release a package that depends on Rcpp.


Perhaps that's alright.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Linking to native routines in other packages

[Romain Francois]

Le 16/11/2013 11:02, Romain Francois a écrit :

Hello,

I'm currently working on making Rcpp use the feature described here more:
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages


To give more context, Rcpp has for a long time built what we called the
Rcpp user library, i.e. a library we could link against user the
linker. We were then producing appropriate linker flag with
Rcpp:::LdFlags(), ...

Now, I'm moving away from this and the intention is that a package using
Rcpp would only have to use

LinkingTo: Rcpp

This sets the -I flag as before to find headers from Rcpp, but this also
now takes advantage of what is described in writing R extensions:
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages


I'm doing this in a way that, when we are not compiling Rcpp, for
example the type2name function is defined in Rcpp's headers as an
inline function that grabs the registered function from Rcpp.

inline const char* type2name(SEXP x){
 typedef const char* (*Fun)(SEXP) ;
 static Fun fun = GET_(Fun) R_GetCCallable( Rcpp, type2name) ;
 return fun(x) ;
 }


This works great.


Now for the question. The documentation says:

It must also specify ‘Imports’ or ‘Depends’ of those packages, for they
have to be loaded prior to this one (so the path to their compiled code
has been registered).

Indeed if I don't have Depends or Imports, the R_init_Rcpp is not
called, and so the function is not registered.

But now if I do Depends: Rcpp or Imports: Rcpp for the sole purpose of
this LinkingTo mechanism, I'm getting

* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘Rcpp’
   All declared Imports should be used.
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.

It would be simple enough to require of our users that they have
Imports: Rcpp and import(Rcpp) or less in their NAMESPACE, but I was
wondering if we could make this more transparent, i.e. having LinkingTo:
Rcpp mean loading Rcpp.

I'm also curious about this sentence from the doc:

In the future R may provide some automated tools to simplify exporting
larger numbers of routines.

Is there a draft of something ?

Romain



For details on how we will be using LinkingTo. Please see:

https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/routines.h

where depending
- when we are compiling Rcpp, we just have a declaration of the
function, which is then defined in any of our .cpp files.
- when we are using Rcpp from another package, we are retrieving the
function

https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp

where the functions are registered with the RCPP_REGISTER macro.

This way of using it moves all the logic to the package exposing its
functions. I find this nicer to use than other tactics I've seen, such
as the sub technique from Matrix ...


Typo alert. Of course here I meant the stub technique.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] serialization for external pointers

[Romain Francois]

Hello,

Are there any recipe to handle serialization / deserialization of 
external pointers.


I'm thinking about something similar in spirit to the way we handle 
finalization of external pointers.


Currently, if we create an external pointer, save the session, quit R, 
then load the session, we get a null pointer.


One way I'm thinking of is to have an environment in the protected 
part of the xp, then have an active binding there, since apparently 
active bindings:

 - are get during serialization
 - lose their active ness when reloaded:

$ R
[...]
 f - local( {
+ x - 1
+ function(v) {
+if (missing(v))
+cat(get\n)
+else {
+cat(set\n)
+x - v
+}
+x
+ }
+ })
 makeActiveBinding(fred, f, .GlobalEnv)
 bindingIsActive(fred, .GlobalEnv)
[1] TRUE

 q(yes)
get
get


romain@naxos /tmp $ R
[..]
 fred
[1] 1
 bindingIsActive(fred, .GlobalEnv)
[1] FALSE

Is this possible ? Is there any other hook to handle serialization, 
unserialization of external pointers ?


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serialization for external pointers

[Romain Francois]

Le 16/11/2013 14:30, Romain Francois a écrit :

Hello,

Are there any recipe to handle serialization / deserialization of
external pointers.

I'm thinking about something similar in spirit to the way we handle
finalization of external pointers.

Currently, if we create an external pointer, save the session, quit R,
then load the session, we get a null pointer.

One way I'm thinking of is to have an environment in the protected
part of the xp, then have an active binding there, since apparently
active bindings:
  - are get during serialization
  - lose their active ness when reloaded:


This will not work. Apparently the active feature is kept on other 
environments:


$ R
[...]
 f - local( {
+ x - 1
+ function(v) {
+if (missing(v))
+cat(get\n)
+else {
+cat(set\n)
+x - v
+}
+x
+ }
+ })
 makeActiveBinding(fred, f, .GlobalEnv)
 bindingIsActive(fred, .GlobalEnv)
[1] TRUE

 e - new.env()
 makeActiveBinding(fred, f, e)
 bindingIsActive(fred, e)
[1] TRUE

 q()
Save workspace image? [y/n/c]: y
get
get

Then:

$ R
[...]
 e
environment: 0x104c56f78
 bindingIsActive(fred, .GlobalEnv)
[1] FALSE
 bindingIsActive(fred, e)
[1] TRUE

Is this the expected behavior ?

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dynamic list creation (SEXP in C) returns error unimplemented type (29) in 'duplicate'

[Romain Francois]

). The steps I've follow are:

FIRST: Create the mother list of size n=length(L0) (doesn't
change) and protect it as
   PROTECT(L1=allocVector(VECEXP, length(L0)))
and filling it with vectors of length two:
   for(i=0;in;i++) SET_VECTOR_ELT(L1,i, allocVector(VECSXP, 2));

then, for each element of the mother list:

   for(i=0;in;i++) {

SECOND: By reading this post in Stackoverflow


http://stackoverflow.com/questions/7458364/growing-an-r-matrix-inside-a-c-loop/7458516#7458516
I understood that it was necesary to (1) create the child lists and
protecting them with PROTECT_WITH_INDEX, and (2) changing its size
using SETLENGTH (Rf_lengthgets) and REPROTECT ing the lists in order
to tell the GC that the vectors had change.

THIRD: Once my two vectors are done (id and lambda), assign them
to the i-th element of the mother list L1 using
   SET_VECTOR_ELT(VECTOR_ELT(L1,i), 0, duplicate(id));
   SET_VECTOR_ELT(VECTOR_ELT(L1,i), 1, duplicate(lambda));

and unprotecting the elements protected with index: UNPROTECT(2);

}

FOURTH: Unprotecting the mother list (L1) and return it to R

With small datasets this works fine, but after trying with bigger ones
R (my code) keeps failing and returning a strange error that I haven't
been able to identify (or find in the web)

   unimplemented type (29) in 'duplicate'

This happens right after I try to use the returned list from my
routine (trying to print it or building a data-frame).

Does anyone have an idea of what am I doing wrong?

Best regards,

PS: I didn't wanted to copy the entire function... but if you need it
I can do it.

George Vega Yon
+56 9 7 647 2552
http://ggvega.cl

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis





--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dynamic list creation (SEXP in C) returns error unimplemented type (29) in 'duplicate'

[Romain Francois]

Le 07/11/2013 14:30, George Vega Yon a écrit :

Romain,

Thanks for your quick response. I've already received that suggestion,
but, besides of haven't ever used C++, I wanted to understand first
what am I doing wrong.


For that type of code, it is actually quite simpler to learn c++ than it 
is to learn the macros and loose typing of the R interface.



Still, would you give me a small example, in R
C++, of:

   - Creating a generic vector L1 of size N
   - Creating a data.frame D and increasing its the number of rows of it
   - Storing the data.frame D in the first element of L1

I would be very gratefull if you can do that.


#include Rcpp.h
using namespace Rcpp ;

// [[Rcpp::export]]
List example(int N){
List out(N) ;

// let's first accumulate data in these two std::vector
std::vectordouble x ;
std::vectorint y ;
for( int i=0; i30; i++){
x.push_back( sqrt( i ) ) ;
y.push_back( i ) ;
}

// Now let's create a data frame
DataFrame df = DataFrame::create(
_[x] = x,
_[y] = y
) ;

// storing df as the first element of out
out[0] = df ;

return out ;
}

You can also do it like this acknowleding what a data frame really is 
(just a list of vectors):


List df = List::create(
_[x] = x,
_[y] = y
) ;
df.attr( class ) = data.frame ;
df.attr( row.names) = IntegerVector::create(
IntegerVector::get_na(), -30 ) ;


The key thing here is that we accumulate data into std::vectordouble 
and std::vectorint which know how to grow efficiently. Looping around 
with SET_LENGTH will allocate and copy data at each iteration of the 
loop which will lead to disastrous performance.


Romain


Thanks again!

George Vega Yon
+56 9 7 647 2552
http://ggvega.cl


2013/11/7 Romain Francois rom...@r-enthusiasts.com:

Hello,

Any particular reason you're not using Rcpp? You would have access to nice
abstraction instead of these MACROS all over the place.

The cost of these abstractions is close to 0.

Looping around and SET_LENGTH is going to be quite expensive. I would urge
you to accumulate data in data structures that know how to grow efficiently,
i.e. a std::vector and then convert that to an R vector when you're done
with them.

Romain

Le 07/11/2013 14:03, George Vega Yon a écrit :


Hi!

I didn't wanted to do this but I think that this is the easiest way
for you to understand my problem (thanks again for all the comments
that you have made). Here is a copy of the function that I'm working
on. This may be tedious to analyze, so I understand if you don't feel
keen to give it a time. Having dedicated many hours to this (as a new
user of both C and R C API), I would be very pleased to know what am I
doing wrong here.

G0 is a Nx2 matrix. The first column is a group id (can be shared with
several observations) and the second tells how many individuals are in
that group. This matrix can look something like this:

id_group  nreps
1  3
1  3
1  3
2  1
3  1
4  2
5  1
6  1
4  2
...

L0 is list of two column data.frames with different sizes. The first
column (id) are row indexes (with values 1 to N) and the second column
are real numbers. L0 can look something like this
[[1]]
id  lambda
3  0.5
15  0.3
25  0.2
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
80  1

TE0 is a int scalar in {0,1,2}

T0 is a dichotomous vector of length N that can look something like this
[1] 0 1 0 1 1 1 0 ...
[N] 1

L1 (the expected output) is a modified version of L0, that, for
instance can look something like this (note the rows marked with *)

[[1]]
id  lambda
3  0.5
*15  0.15 (15 was in the same group of 50, so I added this new row and
divided the value of lambda by two)
25  0.2
*50  0.15
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
*80  0.333 (80 shared group id with 30 and 100, so lambda is divided by 3)
*30  0.333
*100 0.333

That said, the function is as follows

SEXP distribute_lambdas(
SEXP G0,  // Groups ids (matrix of Nx2). First column = Group Id,
second column: Elements in the group
SEXP L0,  // List of N two-column dataframes with different number of
rows
SEXP TE0, // Treatment effect (int scalar): ATE(0) ATT(1) ATC(2)
SEXP T0   // Treat var (bool vector, 0/1, of size N)
)
{

int i, j, l, m;
const int *G = INTEGER_POINTER(PROTECT(G0 = AS_INTEGER(G0 )));
const int *T = INTEGER_POINTER(PROTECT(T0 = AS_INTEGER(T0 )));
const int *TE= INTEGER_POINTER(PROTECT(TE0= AS_INTEGER(TE0)));
double *L, val;
int *I, nlambdas, nreps;

const int n = length(T0);

PROTECT_INDEX pin0, pin1;
SEXP L1;
PROTECT(L1 = allocVector(VECSXP,n));
SEXP id, lambda;

// Fixing size
for(i=0;in;i++)
{
  SET_VECTOR_ELT(L1, i, allocVector(VECSXP, 2));
//  SET_VECTOR_ELT(VECTOR_ELT(L1,i), 0, NEW_INTEGER(100));
//  SET_VECTOR_ELT(VECTOR_ELT(L1,i), 1, NEW_NUMERIC(100));
}

// For over the list, i.e observations
for(i=0;in;i

Re: [Rd] Dynamic list creation (SEXP in C) returns error unimplemented type (29) in 'duplicate'

[Romain Francois]

Le 07/11/2013 14:43, Romain Francois a écrit :

Le 07/11/2013 14:30, George Vega Yon a écrit :

Romain,

Thanks for your quick response. I've already received that suggestion,
but, besides of haven't ever used C++, I wanted to understand first
what am I doing wrong.


For that type of code, it is actually quite simpler to learn c++ than it
is to learn the macros and loose typing of the R interface.


Still, would you give me a small example, in R
C++, of:

   - Creating a generic vector L1 of size N
   - Creating a data.frame D and increasing its the number of rows
of it
   - Storing the data.frame D in the first element of L1

I would be very gratefull if you can do that.


#include Rcpp.h
using namespace Rcpp ;

// [[Rcpp::export]]
List example(int N){
 List out(N) ;

 // let's first accumulate data in these two std::vector
 std::vectordouble x ;
 std::vectorint y ;
 for( int i=0; i30; i++){
 x.push_back( sqrt( i ) ) ;
 y.push_back( i ) ;
 }

 // Now let's create a data frame
 DataFrame df = DataFrame::create(
 _[x] = x,
 _[y] = y
 ) ;

 // storing df as the first element of out
 out[0] = df ;

 return out ;
}


Forgot to mention. You would just put the code above in a .cpp file and 
call sourceCpp on it.


sourceCpp( file.cpp )
example( 3 )


You can also do it like this acknowleding what a data frame really is
(just a list of vectors):

 List df = List::create(
 _[x] = x,
 _[y] = y
 ) ;
 df.attr( class ) = data.frame ;
 df.attr( row.names) = IntegerVector::create(
 IntegerVector::get_na(), -30 ) ;


The key thing here is that we accumulate data into std::vectordouble
and std::vectorint which know how to grow efficiently. Looping around
with SET_LENGTH will allocate and copy data at each iteration of the
loop which will lead to disastrous performance.

Romain


Thanks again!

George Vega Yon
+56 9 7 647 2552
http://ggvega.cl


2013/11/7 Romain Francois rom...@r-enthusiasts.com:

Hello,

Any particular reason you're not using Rcpp? You would have access to
nice
abstraction instead of these MACROS all over the place.

The cost of these abstractions is close to 0.

Looping around and SET_LENGTH is going to be quite expensive. I would
urge
you to accumulate data in data structures that know how to grow
efficiently,
i.e. a std::vector and then convert that to an R vector when you're done
with them.

Romain

Le 07/11/2013 14:03, George Vega Yon a écrit :


Hi!

I didn't wanted to do this but I think that this is the easiest way
for you to understand my problem (thanks again for all the comments
that you have made). Here is a copy of the function that I'm working
on. This may be tedious to analyze, so I understand if you don't feel
keen to give it a time. Having dedicated many hours to this (as a new
user of both C and R C API), I would be very pleased to know what am I
doing wrong here.

G0 is a Nx2 matrix. The first column is a group id (can be shared with
several observations) and the second tells how many individuals are in
that group. This matrix can look something like this:

id_group  nreps
1  3
1  3
1  3
2  1
3  1
4  2
5  1
6  1
4  2
...

L0 is list of two column data.frames with different sizes. The first
column (id) are row indexes (with values 1 to N) and the second column
are real numbers. L0 can look something like this
[[1]]
id  lambda
3  0.5
15  0.3
25  0.2
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
80  1

TE0 is a int scalar in {0,1,2}

T0 is a dichotomous vector of length N that can look something like
this
[1] 0 1 0 1 1 1 0 ...
[N] 1

L1 (the expected output) is a modified version of L0, that, for
instance can look something like this (note the rows marked with *)

[[1]]
id  lambda
3  0.5
*15  0.15 (15 was in the same group of 50, so I added this new row and
divided the value of lambda by two)
25  0.2
*50  0.15
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
*80  0.333 (80 shared group id with 30 and 100, so lambda is divided
by 3)
*30  0.333
*100 0.333

That said, the function is as follows

SEXP distribute_lambdas(
SEXP G0,  // Groups ids (matrix of Nx2). First column = Group Id,
second column: Elements in the group
SEXP L0,  // List of N two-column dataframes with different
number of
rows
SEXP TE0, // Treatment effect (int scalar): ATE(0) ATT(1) ATC(2)
SEXP T0   // Treat var (bool vector, 0/1, of size N)
)
{

int i, j, l, m;
const int *G = INTEGER_POINTER(PROTECT(G0 = AS_INTEGER(G0 )));
const int *T = INTEGER_POINTER(PROTECT(T0 = AS_INTEGER(T0 )));
const int *TE= INTEGER_POINTER(PROTECT(TE0= AS_INTEGER(TE0)));
double *L, val;
int *I, nlambdas, nreps;

const int n = length(T0);

PROTECT_INDEX pin0, pin1;
SEXP L1;
PROTECT(L1 = allocVector(VECSXP,n));
SEXP id, lambda;

// Fixing size
for(i=0;in;i++)
{
  SET_VECTOR_ELT(L1, i, allocVector(VECSXP, 2));
//  SET_VECTOR_ELT

Re: [Rd] R 3.1.0 and C++11

[Romain Francois]

Le 03/11/2013 22:45, Michael Kane a écrit :

I'd like to echo Whit's sentiment and hopefully warm up this thread.
C++11's new features and functionality give R users low-level tools (like
threads, mutexes, futures, date-time, and atomic types) that work across
platforms and wouldn't require other external libraries like boost.


+1

portability is really important. One of the points is that by giving 
means to assume a certain standard, we can write more portable code.


There has been lots of discussion about Boost.Thread, etc ... no need 
for that if you have C++11.



Romain, will you be taking pull requests?


Yes. Definitely. I will carefully review them.
Can give you write access too.

I'm getting a good feel of what C++11 brings while developping Rcpp11. 
But I think it makes a lot of sense to write such an article with other 
people as well.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C++ debugging help needed

[Romain Francois]

Le 02/10/13 17:05, Duncan Murdoch a écrit :

A quick addition:

If I add

#define Shape rglShape

near the top of my Shape.hpp header file, the bug goes away.  But I
can't believe that would be necessary.  These are in separate packages,
don't they have separate namespaces in C++?  How can I avoid clashes
with types declared in other packages in the future?

Duncan Murdoch


That is weird indeed and should not happen. But I don't know much 
linkers ...


I'd advise to scope code in some rgl namespace. At the moment (reading 
the code on r-forge) it's all in the global namespace.


This might be more involved than the macro trick you used above but this 
will be safer. It would have been more problematic if other packages 
needed to compile code against rgl headers, but apparently that is not 
what happens (you don't have inst/include and I don't see 
R_RegisterCCallable either) ...


Romain


On 02/10/2013 10:50 AM, Duncan Murdoch wrote:

I've had reports lately about segfaults in the rgl package.  I've only
been able to reproduce these on Linux.   I am not so familiar with C++
details, so I have a couple of questions way down below. But first some
background info.

   One recipe to recreate the crash works with a new version 5.0-1 of the
mixOmics package:

   library(mixOmics)
   example(pca)

This crashes with messages like this:

Program received signal SIGSEGV, Segmentation fault.
0x728aafd9 in __exchange_and_add (__mem=0x7f7f7f77,
  __val=optimized out) at /usr/include/c++/4.7/ext/atomicity.h:48
48{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }

The call stack ends with this:

#0  0x728aafd9 in __exchange_and_add (__mem=0x7f7f7f77,
  __val=optimized out) at /usr/include/c++/4.7/ext/atomicity.h:48
#1  __exchange_and_add_dispatch (__mem=0x7f7f7f77,
  __val=optimized out) at /usr/include/c++/4.7/ext/atomicity.h:81
#2  _M_dispose (__a=..., this=0x7f7f7f7fffe7)
  at /usr/include/c++/4.7/bits/basic_string.h:242
#3  ~basic_string (this=0x15f8770, __in_chrg=optimized out)
  at /usr/include/c++/4.7/bits/basic_string.h:536
#4  Shape::~Shape (this=0x15f8760, __in_chrg=optimized out) at
Shape.cpp:13
#5  0x722df50b in ~Background (this=0x15f8760,
  __in_chrg=optimized out) at Background.hpp:15
#6  Background::~Background (this=0x15f8760, __in_chrg=optimized out)
  at Background.hpp:15

Up to entry #4 this all looks normal.  If I go into that stack frame, I
see this:


(gdb) up
#4  Shape::~Shape (this=0x15f8760, __in_chrg=optimized out) at
Shape.cpp:13
warning: Source file is more recent than executable.
13blended(in_material.isTransparent())
(gdb) p this
$9 = (Shape * const) 0x15f8760
(gdb) p *this
$10 = {_vptr.Shape = 0x72d8e290, mName = 6, mType = {
  static npos = optimized out,
  _M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar =
{No data fields}, No data fields},
_M_p = 0x7f7f7f7f Address 0x7f7f7f7f out of
bounds}},
mShapeColor = {mRed = -1.4044474254567505e+306,
  mGreen = -1.4044477603031902e+306, mBlue = 4.24399170841135e-314,
  mTransparent = 0}, mSpecularReflectivity = 0.0078125,
mSpecularSize = 1065353216, mDiffuseReflectivity =
0.007812501848093234,
mAmbientReflectivity = 0}

The things displayed in *this are all wrong.  Those field names come
from the Shape object in the igraph package, not the Shape object in the
rgl package.   The mixOmics package uses both.

My questions:

- Has my code somehow got mixed up with the igraph code, so I really do
have a call out to igraph's Shape::~Shape instead of rgl's
Shape::~Shape, or is this just bad info being given to me by gdb?

- If I really do have calls to the wrong destructor in there, how do I
avoid this?

Duncan Murdoch


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C++ debugging help needed

[Romain Francois]

Duncan,

extern C just means that the function(s) below it have C calling 
conventions, so that .Call, .External, ... can find them. Without this, 
your function names would be c++ mangled to disambiguate different 
overloads.


What is inside can use namespace without any issue. You'd have something 
like:


extern C SEXP dot_call_function(){
rgl::Whatever object(1, 2 ) ;
object.do_something() ;
return R_NilValue ;
}

IIRC, if you register your functions (see WRE #5.4), you don't need 
those extern C because you directly give the function pointer so you 
don't have to search for it with its name.


Romain

Le 02/10/13 19:45, Duncan Murdoch a écrit :

Thanks Dirk, Martyn and Romain.  I'm planning to do a temporary
workaround release with the Shape class renamed to rglShape, but over
the longer term I'll put everything that's supposed to be local inside
an rgl namespace.  First I need to learn how namespaces interact with
extern C declarations; pointers to any readable tutorials would be
appreciated.

Duncan Murdoch

On 02/10/2013 11:52 AM, Dirk Eddelbuettel wrote:

On 2 October 2013 at 15:45, Martyn Plummer wrote:
| In C++, everything goes in the global namespace unless the programmer
| explicitly creates one. So when you dynamically load two dynamic shared
| libraries with a Shape object they clash.
|
| The solution here is to put
|
| namespace rgl {
| ...
| }
|
| around your class definitions in the rglm package, and
|
| using rgl::Shape

Exactly.
| at the top of any source file that refers to rgl Shape. Likewise, the
| igraph package should declare shape in the igraph namespace.

And as I wrote to Duncan off-list, igraph doesn't, even though it
otherwise
uses an igraph namespace:

/** Shape.h
 */
#ifndef SHAPE_H
#define SHAPE_H
#include string
#include Color.h
#include Ray.h
#include Point.h
class Shape
[]

So the clash is due to two packages simulatenously failing to make use of
namespaces.

And at that point the linker appears to pick in search (link ?) order.

Dirk


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C++ debugging help needed

[Romain Francois]

Le 02/10/13 22:15, Duncan Murdoch a écrit :

On 02/10/2013 4:01 PM, Ross Boylan wrote:

On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:

 Up to entry #4 this all looks normal.  If I go into that stack
frame, I
 see this:


 (gdb) up
 #4  Shape::~Shape (this=0x15f8760, __in_chrg=optimized out) at
 Shape.cpp:13
 warning: Source file is more recent than executable.

That warning looks suspicious.  Are your sure gdb is finding the right
source files, and that the object code has been built from them?


I'm pretty sure that's a warning about the fact that igraph also has a
file called Shape.cpp, and the Shape::~Shape destructor was in that
file, not in my Shape.cpp file.


 13blended(in_material.isTransparent())
 (gdb) p this
 $9 = (Shape * const) 0x15f8760
 (gdb) p *this
 $10 = {_vptr.Shape = 0x72d8e290, mName = 6, mType = {
   static npos = optimized out,
   _M_dataplus = {std::allocatorchar =
 {__gnu_cxx::new_allocatorchar =
 {No data fields}, No data fields},
 _M_p = 0x7f7f7f7f Address 0x7f7f7f7f out of
 bounds}},
 mShapeColor = {mRed = -1.4044474254567505e+306,
   mGreen = -1.4044477603031902e+306, mBlue =
4.24399170841135e-314,
   mTransparent = 0}, mSpecularReflectivity = 0.0078125,
 mSpecularSize = 1065353216, mDiffuseReflectivity =
0.007812501848093234,
 mAmbientReflectivity = 0}

 The things displayed in *this are all wrong.  Those field names come
 from the Shape object in the igraph package, not the Shape object
in the
 rgl package.   The mixOmics package uses both.

 My questions:

 - Has my code somehow got mixed up with the igraph code, so I
really do
 have a call out to igraph's Shape::~Shape instead of rgl's
 Shape::~Shape, or is this just bad info being given to me by gdb?


I don't know, but I think it's possible to give fully qualified type
names to gdb to force it to use the right definition.  That's assuming
that both Shape's are in different namespaces.  If they aren't, that's
likely the problem.


Apparently they aren't, even though they are in separately compiled and
linked packages.  I had been assuming that the fact that rgl knows
nothing about igraph meant I didn't need to worry about it. (igraph does
list rgl in its Suggests list.)  On platforms other than Linux, I
don't appear to need to worry about it, but Linux happily loads one,
then loads the other and links the call to the wrong .so rather than the
local one, without a peep of warning, just an eventual crash.

Supposing I finish my editing of the 100 or so source files and put all
of the rgl stuff in an rgl namespace, that still doesn't protect me
from what some other developer might do next week, creating their own
rgl namespace with a clashing name.   Why doesn't the linking step
resolve the calls, why does it leave it until load time?


That makes it less likely though.

You could also use an unnamed namespace to sort of scope your code in 
your translation unit. See 
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/unnamed_namespaces.htm



- If I really do have calls to the wrong destructor in there, how do I
avoid this?


Are you invoking the destructor explicitly?  An object should know
it's type, which should result in the right call without much effort.


No, this is an implicit destructor call.  I'm deleting an object whose
class descends from Shape.

Duncan Murdoch



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Using long long types in C++

[Romain Francois]

Le 20 sept. 2013 à 02:31, Patrick Welche pr...@cam.ac.uk a écrit :

 On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
 In Rcpp we'd like to do something useful for types such as long long
 and unsigned long long.
 ...
 But apparently this is still not enough and on some versions of gcc
 (e.g. 4.7 something), -pedantic still generates the warnings unless
 we also use -Wno-long-long
 
 Can you also add -std=c++0x or is that considered as bad as adding
 -Wno-long-long?

IIRC, a package on CRAN is not allowed to change -std, there is or at least was 
barriers to forbid this. 

Plus, some of us use the default settings on OSX, this is still (simili) gcc 
4.2.1 which has long long but does not implement c++11

 (and why not use autoconf's AC_TYPE_LONG_LONG_INT and
 AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?)

Because no matter how many precautions we take, if at the end of the day we end 
up having mentions of long long in the code, even behind sufficient test, it 
will still generate warnings which i'm told would prevent the cran distribution 
of the package. 

I'd really like to hear from cran maintainers on this. 

 Cheers,
 
 Patrick

Because
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Using long long types in C++

[Romain Francois]

Karl, 

Brian gave some insights already. 

I'm also reluctant to use int64_t because there does not seem to be a standard 
version of what the type is. Eg on OSX, int64_t is a typedef to long long. IIRC 
there are cases where it is a typedef to long ... 

At least with long an long long they are guaranteed to be different types and i 
dont need to resort to configure voodoo, i can just rely on the compiler and 
its preprocessor. 

Romain

Le 20 sept. 2013 à 04:04, Karl Millar kmil...@google.com a écrit :

 Romain,
 
 Can you use int64_t and uint_t64 instead?  IMHO that would be more useful 
 than long long anyway.
 
 Karl
 
 On Sep 19, 2013 5:33 PM, Patrick Welche pr...@cam.ac.uk wrote:
 On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
  In Rcpp we'd like to do something useful for types such as long long
  and unsigned long long.
 ...
  But apparently this is still not enough and on some versions of gcc
  (e.g. 4.7 something), -pedantic still generates the warnings unless
  we also use -Wno-long-long
 
 Can you also add -std=c++0x or is that considered as bad as adding
 -Wno-long-long?
 
 (and why not use autoconf's AC_TYPE_LONG_LONG_INT and
 AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?)
 
 Cheers,
 
 Patrick
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Calling an array in a struct in C to R

[Romain Francois]

Hello,

I would use external pointers for something like this.

If c++ is an option, you can take advantage of Rcpp classes to deal with 
external pointers. Put the following in a .cpp and sourceCpp() it.


#include Rcpp.h
using namespace Rcpp ;

class Array {
public:
Array( ) : size(10), used(0){
array = new float[10] ;
}

~Array(){
delete[] array ;
}

size_t get_used(){ return used ; }
// other methods doing stuff with the data

private:
float *array;
size_t used;
size_t size;
} ;
typedef XPtrArray ArrayPointer ;

// [[Rcpp::export]]
ArrayPointer create_ptr( ){
return ArrayPointer( new Array ) ;
}

// [[Rcpp::export]]
size_t Array_get_used(ArrayPointer obj){
// here we use ArrayPointer just like an Array*
return obj-get_used() ;
}

Now, this is very raw and at the R level you get opaque external pointers:

 a - create_ptr()

 str(a)
externalptr

 Array_get_used(a)
[1] 0



You can go further than this and use Rcpp modules so that you don't need 
to worry about external pointers, which you can consider as 
implementation details. For example:


#include Rcpp.h
using namespace Rcpp ;

class Array {
public:
Array( ) : size(10), used(0){
array = new float[10] ;
}

~Array(){
delete[] array ;
}

size_t get_used(){ return used ; }
// other methods doing stuff with the data

private:
float *array;
size_t used;
size_t size;
} ;

// the module code, this is where you declare what of
// your class you expose to the R level
RCPP_MODULE(ArrayModule){
class_Array(Array)
.constructor()
.method( get_used, Array::get_used)
;
}

With this, the R code looks like this:

# we should get rid of the need to call populate.
# for now let us just assume it is a way to copy
# the content of the module
# into the global environment
 populate(ArrayModule, globalenv())

 b - new(Array)

 str(b)
Reference class 'Rcpp_Array' [package .GlobalEnv] with 0 fields
 list()
 and 15 methods, of which 3 are possibly relevant:
   finalize, get_used, initialize

 b$get_used()
[1] 0

Romain

Le 19/06/13 16:14, Tee-Jay-Ardie a écrit :

Hi there,

Although I'm a quite experienced R user and know my ways in C, I stumbled
upon a problem I don't know how to solve. Therefore, I hope someone can
provide me with the information or pointers I need in order to understand
the way in which the communication between R and C occurs. I have the
following C code which basicallly reflects what I want:

typedef struct
{
float *array;
size_t used;
size_t size;
} Array;

void main2R()
{
   Array a;
   examplefunction(a);   /*fills and dynamically grows a-array*/
}

Now I would want to return a.array or a-array to R. According to the R
manuals, the compiled C code should not return anything except through its
arguments. The problem here is, I have a dynamically growing array, and I
have no idea what to pass on to C from R in order to let that work.
The word 'should' indicates that the compiled code may return something in
special circumstances, but I have no idea how to get a.array in R.

So my question is simply this: How on earth do I get the information in the
float array 'a.array' in R? Is it even possible or should I rewrite my C
code using Call in R?

Another, not preferred, options is to pre-allocate the array/vector in R on
a fixed (large-enough) size? Or do I miss something here?

Regards.


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:http://blog.r-enthusiasts.com
|- http://bit.ly/13SrjxO : highlight 0.4.2
`- http://bit.ly/10X94UM : Mobile version of the graph gallery

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] invalid operands of types ‘SEXPREC*’ and ‘R_len_t’ to binary ‘operator/’ with Rcpp.

[Romain Francois]

Please use the appropriate mailing list (Rcpp-devel) for Rcpp questions. 

Romain

Le 14 mai 2013 à 06:42, Xiao He praguewaterme...@gmail.com a écrit :

 Dear R-Developers,
 
 I just started learning how to use Rcpp. Earlier while using it, I
 encountered an error as shown below:
 
 file74d8254b96d4.cpp: In function ‘Rcpp::NumericVector
 foo(Rcpp::NumericVector, Rcpp::NumericVector, Rcpp::NumericVector,
 Rcpp::Function, Rcpp::Function)’:
 file74d8254b96d4.cpp:10: error: invalid operands of types ‘SEXPREC*’ and
 ‘R_len_t’ to binary ‘operator/’
 make: *** [file74d8254b96d4.o] Error 1
 
 Below is a mock function that can reproduce this error. I wonder if anyone
 can tell me what is the problem here. Thank you in advance!!
 
 foo-cppFunction('
   NumericVector foo(NumericVector q, NumericVector shape1, NumericVector
 shape2, Function pbeta, Function sequence){
 NumericVector output(q.size());
 output=pbeta(sequence(q.size())/q.size(), shape1, shape2);
return output;
 }
 ')
 
 
 Best,
 Xiao
 
[[alternative HTML version deleted]]
 
 __
 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] Problem using raw vectors with inline cfunction

[Romain Francois]

Hello,

That is a bug in inline indeed. I just commited a fix in r-forge.

The fix is to obviously replace this as.character by an as.raw.

Thanks for teh report.

Romain

Le 01/02/13 10:25, Karl Forner a écrit :

Hello,


From what I understood from the documentation I found, when using the

inline cfunction with convention=.C,
R raw vectors should be given as unsigned char* to the C function.

But consider the following script:

library(inline)

testRaw - cfunction(signature(raw='raw', len='integer')
 , body='
 int l = *len;
 int i = 0;
 Rprintf(sizeof(raw[0])=%i\\n, sizeof(raw[0]));
 for (i = 0; i  l; ++i) Rprintf(%i, , (int)raw[i]);
 for (i = 0; i  l; ++i) raw[i] = i*10;
 '
 , convention=.C, language='C', verbose=TRUE
)

tt - as.raw(1:10)
testRaw(tt, length(tt))


When I execute it:

$ R --vanilla --quiet  work/inline_cfunction_raw_bug.R

sizeof(raw[0])=1
192, 216, 223, 0, 0, 0, 0, 0, 224, 214,
  *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
  1: .Primitive(.C)(pointer: 0x7eff8bd605c0, raw =
as.character(raw), len = as.integer(len))
  2: testRaw(tt, length(tt))
aborting ...
Segmentation fault (core dumped)


I was expecting to get in the C function a pointer on a byte array of
values (1,2,3,4,5,6,7,8,9,10).
Apparently that is not the case. I guess that the raw =
as.character(raw), printed in the traceback is responsible for the
observed behavior.

If it is expected behavior, how can I get a pointer on my array of bytes ?


Thanks.

Karl



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Interfacing a C++ class

[Romain Francois]

Le 04/06/11 16:31, soeren.vo...@uzh.ch a écrit :


Hello

Apologies for cross-posting, the discussion should (if) go to R-devel, but I 
also want to reach the rcpp-devel people.

My C++ class FOO is a module available through Rcpp, and it works fine and is 
-- so far -- bug free. With trying to further develop my R package, I thought 
it was a good idea to interface my C++ workhorse FOO with an S4 class Foo. 
After some long and not always insightful trip through S4 classes and methods, 
I am not sure if I am on the right way of thinking and designing. Since there 
is no local assistance available, could you help to make things clearer?

Just a brief outline:

FOO is the C++ object, and Foo should be the S4 class. If the user creates an object, say bar, from 
class Foo, the creation process automatically makes a new FOO object relating to bar in that a 
unique name of the FOO instance is stored in a slot of bar. All the user then has to do is modify 
bar by simple assignments. The getters and setters ($, [) are set up and 
work. Each modification goes in hand with assigning new values to bar as well as updating the FOO 
object through available setters from FOO.

So far, this way has brought me to about 100 lines, but now I read about 
ReferenceClasses and was wondering, if there is a much easier way of achieving 
my goals. Moreover, I was not sure any longer if my goals make sense or if a 
more advanced programmer would do it totally different (and could share some 
structural thinking on their approach).

The idea behind my way of doing was based upon several considerations. First, a 
classical R object would not confuse users, as I assume users of my package 
to be rather non-skilled (and not willing to change that). Second, I want to create a 
properly programmed package for distribution on CRAN and publication, eventually. Third, 
I want to save objects across sessions. So if a user restores a session, a simple 
command, say, restore(), would do the trick to build all the related C++ objects again. 
However, I admit that I still have not figured out how to automatically clean up the 
workspace correctly before leaving a session, wanted or unwanted, that is, clean up 
memory before leaving home. Fourth, pure arithmetic check is done in C++, however, 
semantic check *should* be left to R, and the validity and class routines seem to be 
perfect for this. Fifth, some work should be done in R, such as the passing of data 
frames or samples from distributions.

I hope to get some structured ideas and hints how to start and/or proceed.

Thank you in advance,
Sören


Hello,

A C++ class that is exposed through an Rcpp module is already a 
reference class, and so you can add methods, etc ...


Consider this example :

require(inline)
require(Rcpp)

fx - cxxfunction( , '', includes = '

class FOO{
public:
FOO( double x_, double y_): x(x_), y(y_){}

double x ;
double y ;

void move( double dx, double dy){
x += dx ;
y += dy ;
}
} ;

RCPP_MODULE(mod){

class_FOO(FOO )

.constructordouble,double()

.field( x, FOO::x )
.field( y, FOO::y )

.method( move, FOO::move )
;
}


', plugin = Rcpp )
mod - Module( mod, getDynLib(fx),mustStart = TRUE )

# grab the exposed C++ class
FOO - mod$FOO

# add R methods
FOO$methods(
bla = function() x+y,
reset = function() {
x - 0.0
y - 0.0
}
)
# create an instance
f - new( FOO, 2.0, 3.0 )

# call an R method
f$reset()

# call a C++ method
f$move( 2.0, 2.0 )

# call an R method
f$bla()


Hope this helps.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] assignInNamespace and new bindings

[Romain Francois]

Le 31/05/11 12:01, Prof Brian Ripley a écrit :

On Tue, 31 May 2011, Prof Brian Ripley wrote:


On Tue, 31 May 2011, Romain Francois wrote:


Hello,

assignInNamespace refuses to assign an object to a name that is not
already used in the namespace.


That's intentional, and as documented:

‘assignInNamespace’ and ‘fixInNamespace’ are invoked for their
side effect of changing the object in the name space.


I very much doubt we want to allow adding objects.


Even clearer, the Note says

They can only be used to change the values of objects in the name
space, not to create new objects.


Sure.

I'll just keep using this small workaround, unexported from the next Rcpp:

# just like assignInNamespace but first checks that the binding exists 


forceAssignInNamespace - function( x, value, env ){
is_ns - isNamespace( env )
if( is_ns  exists( x, env )  bindingIsLocked(x, env ) ){
unlockBinding( x, env )
}

assign( x, value, env )

if( is_ns ){
lockBinding( x, env )
}
}

I find this useful for when a package wants to assign in its own namespace.

Romain


Something like this would make it possible:

--- src/library/utils/R/objects.R (revision 56024)
+++ src/library/utils/R/objects.R (working copy)
@@ -252,8 +252,9 @@
stop(environment specified is not a package)
ns - asNamespace(substring(nm, 9L))
} else ns - asNamespace(ns)
- if(bindingIsLocked(x, ns)) {
- unlockBinding(x, ns)
+ new_binding - !exists(x,ns)
+ if( new_binding || bindingIsLocked(x, ns)) {
+ if(!new_binding) unlockBinding(x, ns)
assign(x, value, envir = ns, inherits = FALSE)
w - options(warn)
on.exit(options(w))

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Brian D. Ripley, rip...@stats.ox.ac.uk
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, UK Fax: +44 1865 272595




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serialization of external pointers

[Romain Francois]

Le 26/05/11 17:04, Simon Urbanek a écrit :



On May 26, 2011, at 10:40 AM, Romain Francois wrote:


Hello,

I'm looking for examples of how to handle serialization of external pointers.

We use external pointers intensively in Rcpp for modules and one popular 
request is to have persistence. And I guess we need to be able to 
serialize/deserialize external pointers for this.

Also, module objects are all instances of reference classes, so maybe that can 
be handled at the R level ?



Reference classes have nothing to do with EXTPTR - they are simply built around 
environments and as such have no issues with serialization.


Sure. I understand that.

It just happens that our classes end up encapsulating an external 
pointer, so I figured instead of dealing with this at the xp level, I 
could deal with it higher up.


Sort of looking for a class specific serialization. But the comments in 
serialize.c sounds like a maybe later answer to my question.



As for EXTPTR, well, you can perform custom serialization (see refhook in 
serialize() and unserialize()), so to answer your question, yes it's easy to 
serialize EXPPTRs - you just have to provide functions that convert them to 
some string representation and back.

So far, so good, but if you were thinking of using save()/save.image()/load() 
to automatically serialize references in a workspace then the bad new is you 
can't since there is no way to provide the hooks (that's why rJava caches 
serialized representation inside the object so that you can restore the 
pointers on load when you see a NULL pointer with a serialized cache - less 
ideal solution, but doable).


Yes. That's what I'm looking for. I'll check what rJava does. Thanks.


Cheers,
Simon



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Recursively parsing srcrefs

[Romain Francois]

Le 12/05/11 21:59, Hadley Wickham a écrit :



Is it possible to recursively parse srcrefs to match the recursive
structure of the underlying code?  I'm interested in this because it's


I don't understand what you mean by that.  It is certainly possible to walk
through nested srcrefs, to zoom in on a particular location; that's what
findLineNum() does.


Does the example below not help?  Given the whole function, I want to
be able to walk down the call tree, finding the matching src refs as I
go.  i.e. given f, how do I get f_inside?

f- function(x = T) {
   # This is a comment
   if (x)  return(4)
   if (emergency_status()) return(T)
}

f_inside- parse(text = 
   # This is a comment
   if (x)  return(4)
   if (emergency_status()) return(T)
)

findLineNum doesn't quite do what I want - it works on the text of the
srcref, not on the parse tree.

Here's another go at explaining what I want:

h- quote(
   1 # one
   + # plus
   2 # two
)

h[[1]] extracts +.  What can I do to extract + # plus (on an object
created in the appropriate manner to keep the srcref)?  Is that even
possible?


Maybe the parser package can help you.

 x - parser( /tmp/test.R )
 attr( x, data )
   line1 col1 byte1 line2 col2 byte2 token id parent top_level 
  token.desc terminal   text
1  10 0 11 1   263  1  3 0 
 SYMBOL TRUE  h
2  11 1 13 3   265  2 32 0 
LEFT_ASSIGN TRUE -
3  10 0 11 177  3 32 0 
   exprFALSE
4  14 4 19 9   296  5  7 0 
SYMBOL_FUNCTION_CALL TRUE  quote
5  19 9 1   101040  6 30 0 
'(' TRUE  (
6  14 4 19 977  7 30 0 
   exprFALSE
7  23 3 24 4   261 10 11 0 
  NUM_CONST TRUE  1
8  23 3 24 477 11 27 0 
   exprFALSE
9  25 5 2   1010   289 13 27 0 
COMMENT TRUE  # one
10 33 3 34 443 16 27 0 
'+' TRUE  +
11 35 5 3   1111   289 18 27 0 
COMMENT TRUE # plus
12 43 3 44 4   261 21 22 0 
  NUM_CONST TRUE  2
13 43 3 44 477 22 27 0 
   exprFALSE
14 45 5 4   1010   289 24 30 0 
COMMENT TRUE  # two
15 50 0 51 141 26 30 0 
')' TRUE  )
16 23 3 44 477 27 30 0 
   exprFALSE
17 14 4 51 177 30 32 0 
   exprFALSE
18 10 0 51 177 32  0 0 
   exprFALSE


Romain


My eventual goal is something like

f- function(x) {
   # This is my function
   T
}

g- fix_logical_abbreviations(f)

which would be equivalent to

g- function(x) {
   # This is my function
   TRUE
}



That last display looks like a bug indeed.  I'll take a look.


The key seems to be a leading newline:

parse(text = \nx)
parse(text = x)

Hadley





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Create and access several instances of a C++ class from R

[Romain Francois]

, double *ss)
void Foo::do_foo(int mm)
{
m=mm;
}
void Foo::do_bar(double *CC)
{
C=CC;
}

RCPP_MODULE(mod_foo)
{
using namespace Rcpp;
class_Foo( Foo )
.constructorint,int,int()
.method(do_foo,Foo::do_foo) // works
.method(do_bar,Foo::do_bar) // does not work!
;
}


### compile warning with the working version:
** checking whether the name space can be loaded with stated dependencies ... 
WARNING
Error: .onLoad failed in loadNamespace() for 'Foo', details:
   call: value[[3L]](cond)
   error: failed to load module mod_foo from package Foo
Execution halted
A namespace must be able to be loaded with just the base namespace
loaded: otherwise if the namespace gets loaded by a saved object, the
session will be unable to start.
Probably some imports need to be declared in the NAMESPACE file.


### 00install.out
* installing *source* package ‘Foo’ ...
** libs
*** arch - i386
g++-4.2 -arch i386 -I/Library/Frameworks/R.framework/Resources/include 
-I/Library/Frameworks/R.framework/Resources/include/i386  -I/usr/local/include 
-I/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include
   -fPIC  -g -O2 -c Foo_mod.cpp -o Foo_mod.o
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/traits/Exporter.h:
 In constructor ‘Rcpp::traits::ExporterT::Exporter(SEXPREC*) [with T = 
double*]’:
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/as.h:51:
   instantiated from ‘T Rcpp::internal::as(SEXPREC*, 
Rcpp::traits::r_type_generic_tag) [with T = double*]’
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/as.h:75:
   instantiated from ‘T Rcpp::as(SEXPREC*) [with T = double*]’
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/module/Module_generated_CppMethod.h:122:
   instantiated from ‘SEXPREC* Rcpp::CppMethod1Class, void, 
U0::operator()(Class*, SEXPREC**) [with Class = Foo, U0 = double*]’
Foo_mod.cpp:59:   instantiated from here
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/traits/Exporter.h:31:
 error: cannot convert ‘SEXPREC*’ to ‘double*’ in initialization
make: *** [Foo_mod.o] Error 1
ERROR: compilation failed for package ‘Foo’

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] as.environment.list provides inconsistent results under torture

[Romain Francois]

Hello,

Using R-devel (rev 53950), I get inconsistent results with 
as.environment( VECSXP ) when gctorture is on.


Consider:

a - list( aa = rnorm, bb = runif )
gctorture(TRUE)
as.environment( a )

The last line sometimes produces the correct environment, but sometimes 
I get errors. Here are the three situations:


# good
 as.environment( a )
environment: 0x100b1c978

# not good
 as.environment( a )
Erreur dans length(x) : 'x' est manquant

# not good either
 as.environment( a )
Erreur dans list(NULL, list(aa = function (n, mean = 0, sd = 1)  :
  correspondance partielle de chaînes de caractères incorrecte


Is it because the call made by lang4 is not protected while evaluated in 
this line :


case VECSXP: {
/* implement as.environment.list() {isObject(.) is false for a list} */
return(eval(lang4(install(list2env), arg,
  /*envir = */R_NilValue, /* parent = */R_EmptyEnv),
rho));
}


(BTW, this was detected in a long Rcpp-devel thread. See 
http://comments.gmane.org/gmane.comp.lang.r.rcpp/1336)


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] embed Sweave driver in .Rnw file

[Romain Francois]

Hello,

Sweave lets you use alternative drivers through the driver argument, and 
several packages take advantage of that and define custom Sweave driver 
for various purposes. Most of them are listed on the Reproducible 
Research CTV: 
(http://cran.r-project.org/web/views/ReproducibleResearch.html)


The next natural step is for package developpers to take advantage of 
this in their vignettes. In Rcpp we work around the way package building 
works and we do:

- let R build a dummy vignette
- then use the inst/doc/Makefile to replace it with a vignette that is 
processed by the driver from the highlight package (giving syntax 
highlighting).


I played with Sweave so that it would be able to create the driver from 
some text included in the text of the .Rnw file:


$ svn diff
Index: src/library/utils/R/Sweave.R
===
--- src/library/utils/R/Sweave.R(revision 53846)
+++ src/library/utils/R/Sweave.R(working copy)
@@ -20,6 +20,16 @@
 # We don't need srclines for code, but we do need it for text, and 
it's easiest

 # to just keep it for everything.

+SweaveGetDriver - function(file){
+txt - readLines(file)
+line - grep( \\SweaveDriver, txt, value = TRUE )
+if( length(line) ){
+txt - sub( ^.*\\SweaveDriver[{](.*)[}], \\1, line[1L] )
+driver - try( eval( parse( text = txt ) ), silent = TRUE )
+if( !inherits( driver, try-error) ) driver
+}
+}
+
 Sweave - function(file, driver=RweaveLatex(),
syntax=getOption(SweaveSyntax), ...)
 {
@@ -28,7 +38,9 @@
 else if(is.function(driver))
 driver - driver()

-
+drv - SweaveGetDriver(file)
+if( !is.null(drv) ) driver - drv
+
 if(is.null(syntax))
 syntax - SweaveGetSyntax(file)
 if(is.character(syntax))



This allows one to write something like this in their file:

%\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }

So that when calling :

 Sweave( somefile.Rnw )

the highlight driver is used instead of the default driver.

Could something like that be added to Sweave ?

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] embed Sweave driver in .Rnw file

[Romain Francois]

Le 14/12/10 13:21, Friedrich Leisch a écrit :

On Tue, 14 Dec 2010 12:40:04 +0100,
Romain Francois (RF) wrote:


 Hello,
 Sweave lets you use alternative drivers through the driver argument, and
 several packages take advantage of that and define custom Sweave driver
 for various purposes. Most of them are listed on the Reproducible
 Research CTV:
 (http://cran.r-project.org/web/views/ReproducibleResearch.html)

 The next natural step is for package developpers to take advantage of
 this in their vignettes. In Rcpp we work around the way package building
 works and we do:
 - let R build a dummy vignette
 - then use the inst/doc/Makefile to replace it with a vignette that is
 processed by the driver from the highlight package (giving syntax
 highlighting).

 I played with Sweave so that it would be able to create the driver from
 some text included in the text of the .Rnw file:

 $ svn diff
 Index: src/library/utils/R/Sweave.R
 ===
 --- src/library/utils/R/Sweave.R   (revision 53846)
 +++ src/library/utils/R/Sweave.R   (working copy)
 @@ -20,6 +20,16 @@
   # We don't need srclines for code, but we do need it for text, and
 it's easiest
   # to just keep it for everything.

 +SweaveGetDriver- function(file){
 +txt- readLines(file)
 +line- grep( \\SweaveDriver, txt, value = TRUE )
 +if( length(line) ){
 +txt- sub( ^.*\\SweaveDriver[{](.*)[}], \\1, line[1L] )
 +driver- try( eval( parse( text = txt ) ), silent = TRUE )
 +if( !inherits( driver, try-error) ) driver
 +}
 +}
 +
   Sweave- function(file, driver=RweaveLatex(),
  syntax=getOption(SweaveSyntax), ...)
   {
 @@ -28,7 +38,9 @@
   else if(is.function(driver))
   driver- driver()

 -
 +drv- SweaveGetDriver(file)
 +if( !is.null(drv) ) driver- drv
 +
   if(is.null(syntax))
   syntax- SweaveGetSyntax(file)
   if(is.character(syntax))



 This allows one to write something like this in their file:

 %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }

 So that when calling :

 Sweave( somefile.Rnw )

 the highlight driver is used instead of the default driver.

 Could something like that be added to Sweave ?

Yes, sure!

Will have a look at the patch later this week and apply it if it
passes the tests.


Great. Let me know if I can expand on it (documentation, etc ...)


The patch is against a current r-devel?


yes. rev 53846.


Best,
Fritz




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Enough (was: Terminology clarification (Re: GPL and R Community Policies (Rcpp))

[Romain Francois]

Dear Dominick,

Thank you so much for the numerous reminders about this request of yours.

You will be pleased to know that as part of our ongoing search for 
quality, the current development version of the Rcpp package no longer 
contains code from what we call the `classic Rcpp' API. We owe this 
classic API to your contribution and for that we are grateful. It will 
be released as another package outside of Rcpp as a courtesy to R users 
and CRAN package maintainers who still want to use this API which we 
consider deprecated.


As of the current svn status of Rcpp (rev 2711 on r-forge), your name 
appears in several places, detailed below. Feel free to take whatever 
actions you find appropriate if this does not suit your needs.


Lastly, please do not take R-devel hostage of this thread anymore. Feel 
free to send your questions and remarks to the place where it belongs: 
the Rcpp-devel mailing list.



Regards,

Romain




$ grep -R Samperi * | grep -v .svn
DESCRIPTION: 'classic Rcpp API' was written during 2005 and 2006 by 
Dominick Samperi.
debian/copyright:R / C++ interface package. Rcpp was written by Dominick 
Samperi,

debian/copyright:   2005 and 2006 by Dominick Samperi
inst/announce/ANNOUNCE-0.6.0.txt:Rcpp was initially written by Dominick 
Samperi as part of his contributions
inst/doc/Rcpp-introduction.Rnw:\pkg{Rcpp} first appeared in 2005 as a 
contribution (by Samperi) to the
inst/doc/Rcpp-introduction.Rnw:in early 2006. Several releases (all by 
Samperi) followed in quick succession

inst/doc/Rcpp.bib:  author = {Dominick Samperi},
inst/doc/Rcpp.bib:@Manual{Samperi:2009:RcppTemplate,
inst/doc/Rcpp.bib:  author = {Dominick Samperi},
inst/README:Rcpp continues and extends earlier work by Dominick Samperi 
which he initially
inst/THANKS:Dominick Samperifor starting what we now call the 
Classic Rcpp
man/Rcpp-package.Rd:  The initial versions of Rcpp were written by 
Dominick Samperi during 2005 and
src/Makevars.win:# (C) Dominick Samperi and Uwe Ligges and gratefully 
acknowledged



* In the DESCRIPTION file [1] in the Description field
* In the debian/copyright file [2]
* in the ANNOUNCE-0.6.0.txt file which records the announcement that was 
made about the relauch of Rcpp. The file is a plain text copy of the 
email that was sent to the R-pkgs mailing list on 2008/12/03 [3].
* In the Rcpp-introduction.Rnw file [4]. In the Historical context 
subsection.

* In the Rcpp.bib file [5] that we use to reference to creations of yours.
* In the README file [6] where we acknowledge that Rcpp initiated from you.
* In the THANKS file [7] where we acknowledge your involvment.
* In the Makevars.win file [8]

[1] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/DESCRIPTION?root=rcpp
[2] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/debian/copyright?root=rcpp

[3] https://stat.ethz.ch/pipermail/r-packages/2008/000980.html
[4] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/doc/Rcpp-introduction.Rnw?root=rcpp
[5] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/doc/Rcpp.bib?root=rcpp
[6] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/README?root=rcpp
[7] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/THANKS?root=rcpp
[8] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/src/Makevars.win?root=rcpp




Le 03/12/10 00:28, Dominick Samperi a écrit :

 On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettele...@debian.org  wrote:


 On 2 December 2010 at 17:23, Dominick Samperi wrote:
 | OK, since you are so accomodating, then please remove all reference to
 | my name from Rcpp as I do not want to be subject to arbitrary 
revisions

 of
 | my status. I may not have the right to say how my prior work will be
 used,
 | but I think I have the right to ask that my name not be used in 
the way

 | it is used in the recent update.

 As I pointed out, you change your mind on this every 12 months, 
limiting my
 patience and willingness for these dances.  It has also been 
suggested by

 other than attribution is clearer if you listed as the maintainer of the
 2005/2006 code that we started from in 2008.


 The change that this thread is a reaction to happened a few days ago, not
 12 months ago. If I wavered in the past it was because I was being
 forced to compete with my own work, not a pleasant place to be.

 Are you telling me that you refuse to stop using my name
 in Rcpp (except in copyright notices)?

 Are you telling me that you will continue to use my name and
 update the associated status as you see fit, whether or not I
 approve or consent to those changes?

 Please answer yes or no.

 Thanks,
 Dominick


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
|- http://bit.ly/hovakS : RcppGSL initial release
`- http://bit.ly/iaxTdO : parser 0.0-12

[Rd] faster base::sequence

[Romain Francois]

Hello,

Based on yesterday's R-help thread (help: program efficiency), and 
following Bill's suggestions, it appeared that sequence:


 sequence
function (nvec)
unlist(lapply(nvec, seq_len))
environment: namespace:base

could benefit from being written in C to avoid unnecessary memory 
allocations.


I made this version using inline:

require( inline )
sequence_c - local( {
fx - cfunction( signature( x = integer), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; in; i++){
x_i = px[i] ;
/* this includes the check for NA */
if( x_i = 0 ) error( needs non negative integer ) ;
s += x_i ;
}

SEXP res = PROTECT( allocVector( INTSXP, s ) ) ;
int * p_res = INTEGER(res) ;
for( int i=0; in; i++){
x_i = px[i] ;
for( int j=0; jx_i; j++, p_res++)
*p_res = j+1 ;
}
UNPROTECT(1) ;
return res ;
' )
function( nvec ){
fx( as.integer(nvec) )
}
})


And here are some timings:

 x - 1:1
 system.time( a - sequence(x ) )
utilisateur système  écoulé
  0.191   0.108   0.298
 system.time( b - sequence_c(x ) )
utilisateur système  écoulé
  0.060   0.063   0.122
 identical( a, b )
[1] TRUE



 system.time( for( i in 1:1) sequence(1:10) )
utilisateur système  écoulé
  0.119   0.000   0.119

 system.time( for( i in 1:1) sequence_c(1:10) )
utilisateur système  écoulé
  0.019   0.000   0.019


I would write a proper patch if someone from R-core is willing to push it.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] faster base::sequence

[Romain Francois]

Le 28/11/10 10:30, Prof Brian Ripley a écrit :

Is sequence used enough to warrant this? As the help page says

Note that ‘sequence - function(nvec) unlist(lapply(nvec,
seq_len))’ and it mainly exists in reverence to the very early
history of R.


I don't know. Would it be used more if it were more efficient ?


I regard it as unsafe to assume that NA_INTEGER will always be negative,
and bear in mind that at some point not so far off R integers (or at
least lengths) will need to be more than 32-bit.


sure. updated and dressed up as a patch.

I've made it a .Call because I'm not really comfortable with .Internal, 
etc ...


Do you mean that I should also use something else instead of int and 
int*. Is there some future proof typedef or macro for the type 
associated with INTSXP ?




On Sun, 28 Nov 2010, Romain Francois wrote:


Hello,

Based on yesterday's R-help thread (help: program efficiency), and
following Bill's suggestions, it appeared that sequence:


sequence

function (nvec)
unlist(lapply(nvec, seq_len))
environment: namespace:base

could benefit from being written in C to avoid unnecessary memory
allocations.

I made this version using inline:

require( inline )
sequence_c - local( {
fx - cfunction( signature( x = integer), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; in; i++){
x_i = px[i] ;
/* this includes the check for NA */
if( x_i = 0 ) error( needs non negative integer ) ;
s += x_i ;
}

SEXP res = PROTECT( allocVector( INTSXP, s ) ) ;
int * p_res = INTEGER(res) ;
for( int i=0; in; i++){
x_i = px[i] ;
for( int j=0; jx_i; j++, p_res++)
*p_res = j+1 ;
}
UNPROTECT(1) ;
return res ;
' )
function( nvec ){
fx( as.integer(nvec) )
}
})


And here are some timings:


x - 1:1
system.time( a - sequence(x ) )

utilisateur système écoulé
0.191 0.108 0.298

system.time( b - sequence_c(x ) )

utilisateur système écoulé
0.060 0.063 0.122

identical( a, b )

[1] TRUE




system.time( for( i in 1:1) sequence(1:10) )

utilisateur système écoulé
0.119 0.000 0.119


system.time( for( i in 1:1) sequence_c(1:10) )

utilisateur système écoulé
0.019 0.000 0.019


I would write a proper patch if someone from R-core is willing to push
it.

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

Index: src/library/base/R/seq.R
===
--- src/library/base/R/seq.R(revision 53680)
+++ src/library/base/R/seq.R(working copy)
@@ -85,4 +85,6 @@
 }
 
 ## In reverence to the very first versions of R which already had sequence():
-sequence - function(nvec) unlist(lapply(nvec, seq_len))
+# sequence - function(nvec) unlist(lapply(nvec, seq_len))
+sequence - function(nvec) .Call( sequence, as.integer(nvec), PACKAGE = 
base )
+
Index: src/main/registration.c
===
--- src/main/registration.c (revision 53680)
+++ src/main/registration.c (working copy)
@@ -245,6 +245,8 @@
 CALLDEF(bitwiseOr, 2),
 CALLDEF(bitwiseXor, 2),
 
+/* sequence */
+CALLDEF(sequence,1),
 {NULL, NULL, 0}
 };
 
Index: src/main/seq.c
===
--- src/main/seq.c  (revision 53680)
+++ src/main/seq.c  (working copy)
@@ -679,3 +679,28 @@
 
 return ans;
 }
+
+SEXP attribute_hidden sequence(SEXP x)
+{
+   R_len_t n = length(x), s = 0 ;
+   int *px = INTEGER(x) ;
+   int x_i ;
+   /* error checking */
+   for( int i=0; in; i++){
+   x_i = px[i] ;
+   if( x_i == NA_INTEGER || x_i = 0 ) 
+   error( _(argument must be coercible to non-negative integer) ) ;
+   s += x_i ;
+   }
+   
+   SEXP res = PROTECT( allocVector( INTSXP, s ) ) ;
+   int *p_res = INTEGER(res) ;
+   for( int i=0; in; i++){
+   x_i = px[i] ;
+   for( int j=0; jx_i; j++, p_res++)
+   *p_res = j+1 ;
+   }
+   UNPROTECT(1) ;
+   return res ;
+}
+
Index: src/main/basedecl.h
===
--- src/main/basedecl.h (revision 53680)
+++ src/main/basedecl.h (working copy)
@@ -114,3 +114,6 @@
 SEXP bitwiseAnd(SEXP, SEXP);
 SEXP bitwiseOr(SEXP, SEXP);
 SEXP bitwiseXor(SEXP, SEXP);
+
+SEXP sequence(SEXP);
+
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] faster base::sequence

[Romain Francois]

Le 28/11/10 11:30, Prof Brian Ripley a écrit :

On Sun, 28 Nov 2010, Romain Francois wrote:


Le 28/11/10 10:30, Prof Brian Ripley a écrit :

Is sequence used enough to warrant this? As the help page says

Note that ‘sequence - function(nvec) unlist(lapply(nvec,
seq_len))’ and it mainly exists in reverence to the very early
history of R.


I don't know. Would it be used more if it were more efficient ?


It is for you to make a compelling case for others to do work (maintain
changed code) for your wish.


No trouble. The patch is there, if anyone finds it interesting or 
compelling, they will speak up I suppose.


Otherwise it is fine for me if it ends up in no man's land. I have the 
code, if I want to use it, I can squeeze it in a package.



I regard it as unsafe to assume that NA_INTEGER will always be negative,
and bear in mind that at some point not so far off R integers (or at
least lengths) will need to be more than 32-bit.


sure. updated and dressed up as a patch.

I've made it a .Call because I'm not really comfortable with
.Internal, etc ...



Do you mean that I should also use something else instead of int and
int*. Is there some future proof typedef or macro for the type
associated with INTSXP ?


Not yet. I was explaining why NA_INTEGER might change.


sure. thanks for the reminder.


On Sun, 28 Nov 2010, Romain Francois wrote:


Hello,

Based on yesterday's R-help thread (help: program efficiency), and
following Bill's suggestions, it appeared that sequence:


sequence

function (nvec)
unlist(lapply(nvec, seq_len))
environment: namespace:base

could benefit from being written in C to avoid unnecessary memory
allocations.

I made this version using inline:

require( inline )
sequence_c - local( {
fx - cfunction( signature( x = integer), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; in; i++){
x_i = px[i] ;
/* this includes the check for NA */
if( x_i = 0 ) error( needs non negative integer ) ;
s += x_i ;
}

SEXP res = PROTECT( allocVector( INTSXP, s ) ) ;
int * p_res = INTEGER(res) ;
for( int i=0; in; i++){
x_i = px[i] ;
for( int j=0; jx_i; j++, p_res++)
*p_res = j+1 ;
}
UNPROTECT(1) ;
return res ;
' )
function( nvec ){
fx( as.integer(nvec) )
}
})


And here are some timings:


x - 1:1
system.time( a - sequence(x ) )

utilisateur système écoulé
0.191 0.108 0.298

system.time( b - sequence_c(x ) )

utilisateur système écoulé
0.060 0.063 0.122

identical( a, b )

[1] TRUE




system.time( for( i in 1:1) sequence(1:10) )

utilisateur système écoulé
0.119 0.000 0.119


system.time( for( i in 1:1) sequence_c(1:10) )

utilisateur système écoulé
0.019 0.000 0.019


I would write a proper patch if someone from R-core is willing to push
it.

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube







--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] How to call R from C

[Romain Francois]

Le 22/11/10 17:24, 이원재 a écrit :


Hi all!
I read R Extensions manual.
But still I am not sure how to call R functions from C.
Would any of you give me a sample C code to show how to call R functions - for 
instance, time series functions - from C in the embedded way of C code?


As Brian said, there are plenty of examples to follow.

The basic idea is to create a call and evaluate it.

txt - '
#include R.h
#include Rdefines.h

SEXP callrnorm(){
SEXP call = PROTECT( lang2( install( rnorm), ScalarInteger(10) ) ) ;
SEXP res = PROTECT( eval( call, R_GlobalEnv ) ) ;
UNPROTECT(2) ;
return res ;
}
'
writeLines( txt, test.c )
system( R CMD SHLIB test.c )
dyn.load( test.so )
.Call( callrnorm )



or using the inline package :

require(inline)
fx - cfunction( , '
SEXP call = PROTECT( lang2( install( rnorm), ScalarInteger(10) ) ) ;
SEXP res = PROTECT( eval( call, R_GlobalEnv ) ) ;
UNPROTECT(2) ;
return res ;
' , verbose = TRUE)
fx()



And now for the Rcpp plug ;-) calling R functions is dramatically easy 
with Rcpp with the Rcpp::Function class.


require(inline)
fx - cxxfunction( , '
// grab the function
Function rnorm(rnorm) ;

// call it
return rnorm(10, _[sd] = 10) ;

' , plugin = Rcpp )
fx()


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R5 reference classes: how to initialize exactly?

[Romain Francois]

Le 17/11/10 11:39, Janko Thyson a écrit :



-Ursprüngliche Nachricht-
Von: Simon Urbanek [mailto:simon.urba...@r-project.org]
Gesendet: Mittwoch, 17. November 2010 11:35
An: Janko Thyson
Cc: 'r-de...@r-project. org'
Betreff: Re: [Rd] R5 reference classes: how to initialize exactly?

Just a clarification for posterity - R5 has nothing to do with the new
reference classes. It's not even an official name, but informally it's a
collection of ideas for an entirely new object system that can replace
both S3 and S4 (not that it will but it should be seen as having the
capability to do so technically). Reference classes are just an addition
to S4.

Cheers,
Simon


Thanks for that clarification. I picked that name up from the Google
TechTalks presentation of Dirk and Romain. So I refer to them as S4
reference classes in future posts?

Regards,
Janko


Sorry about that. It was meant as a sort of private joke. (we do say in 
the talk that this is not an official name).



On Nov 16, 2010, at 12:30 AM, Janko Thyson wrote:


Sorry, I was stupid:



MyRefObj- setRefClass(Blabla, .)



One can always get the generator object of an defined class with
'getRefClass()'. So:



g- getRefClass(Blabla)

x- g$new(.)



Regards,

Janko





Von: Janko Thyson [mailto:janko.thy...@ku-eichstaett.de]
Gesendet: Dienstag, 16. November 2010 00:27
An: 'r-de...@r-project. org'
Betreff: R5 reference classes: how to initialize exactly?



Dear List,



So far, I really like those new R5 classes. But what kind of puzzles

me is

that it's not just enough to define the actual reference class, I also

have

to assign it to an object (e.g. 'MyRefObj') in order to fire
'MyRefObj$new(.)'.



S4:

setClass(Blabla, .)

x- new(Blabla)



R5:

MyRefObj- setRefClass(Blabla, .)

x- MyRefObj$new(.)



But then how do I define a reference class in a package that should be
available after the package is loaded via 'library(my_pkg)' as there

is no

'MyRefObj' at startup yet? Do I have to call the script where the

definition

lives?



Thanks for any comments,

Janko



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Reference classes: accessor functions via 'getRefClass(...)$accessors(...)'

[Romain Francois]

Le 17/11/10 13:07, Janko Thyson a écrit :


Hi there,



I'd like to choose between an static and dynamic access of a reference
class field, say 'a'.



myObj- getRefClass(Blabla)$new()



Static:   myObj$a

Dynamic: myObj$a.get() where the function retrieves the data
from a database (or some other location), stores it to a buffer and
optionally updates the static field value 'a'.



I've set up such a method 'a.get()' where I can actually decide between
static and dynamic runmode (so the method also wraps the call 'myObj$a' for
the static runmode).



Now I saw that setting up such accessor methods (get/set) is already done
for me if I use 'getRefClass(Blabla)$accessors(.)'. I just don't
understand what exactly I have to do there, because this results in an
error: 'getRefClass(Blabla)$accessors(a)'



Can anyone point me to the correct use of 'getRefClass(.)$accessors(.)'?



Thanks a lot,

Janko


Hi,

fields can either be data or active binding functionss. See 
?makeActiveBinding for some example of active binding functions in their 
original context.


Here is an example of a reference class that keeps its data in a file.

require( methods )

Foo - setRefClass( Foo,
fields = list(
file = character,
x = function(value){
if( missing( value ) ){
read.table( file )
} else{
write.table( value, file = file )
}
}
)
)

foo - Foo$new( file=/tmp/iris.txt )
foo$x - iris
foo$x

write.table( subset( iris, Petal.Length  2), file = /tmp/iris.txt )
foo$x


Does that help ?


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] SEXP and slots

[Romain Francois]

Le 15/11/10 21:15, Romain Francois a écrit :


Hello,

Since people have whisperred about Rcpp, I'd like to play too.


On 11/15/2010 07:45 AM, Patrick Leyshock wrote:

Very helpful, thank you.

A couple other questions, please:

1. I've got a function written in C, named my_c_function. In my R
code I call this function, passing to it an INTSXP and a STRSXP,
respectively:

result - .Call(my_c_function, int_vector, str_vector)

The prototype of my_c_function is:

SEXP my_c_function(SEXP int_vec, SEXP str_vec);

Within my_c_function I am able to extract the values within the integer
vector, e.g. I can grab the first value with these lines of code:

int extracted_value;
extracted_value = *INTEGER(int_vec);

What I cannot figure out how to do is extract the value from the
STRSXP. I'm assuming that I can create a pointer to a character array,
then malloc enough memory to hold the value. Is there an analogous
operation on INTEGER for STRSXPs?


STRING_ELT(str_vec, 0)

gets the 0th component of str_vec, which is a CHARSXP, i.e., an SEXP for
a character string. The char* can be retrieved with CHAR, so the usual
paradigm is

const char *x = CHAR(STRING_ELT(str_vec, 0));

note the const-ness of the char* -- it's not mutable, because R is
managing char * memory.

The converse action, of assigning to an element, is

SET_STRING_ELT(str_vec, 0, mkChar(foo));

mkChar() is creating a copy (if necessary) of foo, managing it, and
returning a CHARSXP. Working through protection (which will likely be
your next obstacle ;) in this last example is a good exercise.


In Rcpp, you would wrap up the STRSXP into a CharacterVector and then
pull things in and out using indexing:

Rcpp::CharacterVector aladdin(str_vec) ;
std::string first = aladdin[0] ;
aladdin[0] = foobar ;


As it was pointed out to me offlist, the code above fails to compile. 
This is what you get when you reply to emails while watching a Woody 
Allen movie ...


Anyway, the reason for this is that the line:

std::string first = aladdin[0] ;

uses the __constructor__ of std::string and not the assignment operator. 
The code below does work :


std::string first ;
Rcpp::CharacterVector aladdin(str_vec) ;
first = aladdin[0] ;
aladdin[0] = foobar ;


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] SEXP and slots

[Romain Francois]

)
 @96ed08 09 CHARSXP g1c1 [MARK,gp=0x21] example
   ATTRIB:
 @df70fd0 02 LISTSXP g0c0 []
   TAG: @624f70 01 SYMSXP g1c0 [MARK,NAM(2)] package
   @c0f6d88 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
 @67f5e0 09 CHARSXP g1c2 [MARK,gp=0x21,ATT] .GlobalEnv

that the 'eg' object is an S4SXP with an attribute that is a LISTSXP.
The LISTSXP has elements that are tagged with SYMSXP representing the
slot name, and values that are REALSXP (for 'size') or STRSXP (for
'id'). The LISTSXP attribute itself has an attribute, which contains
information about the package where the class is defined. With these
hints one can see through the S4 interface to the underlying
implementation

 attributes(eg)
$size
[1] 4

$id
[1] id_value

$class
[1] example
attr(,package)
[1] .GlobalEnv

But probably you have a specific goal in mind, and this is too much
information...

Martin


 Thanks, Patrick

   [[alternative HTML version deleted]]

 __
 R-devel at r-project.org mailto:R-devel at r-project.org mailing 
list
 https://stat.ethz.ch/mailman/listinfo/r-devel


--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793




--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Possible bug or annoyance with library.dynam.unload()

[Romain Francois]

Le 22/09/10 17:31, Duncan Murdoch a écrit :


On 22/09/2010 11:22 AM, Karl Forner wrote:

Thanks Duncan for your suggestion.

I could not find any package using dynamic library, namespaces and not
the
useDynLib pragma so
I created a minimalistic package to demonstrate the problem.
Please find attached a very small package foo (8.8k)


Your package depends on Rcpp, so I didn't try it in the alpha version of
2.12.0 (Rcpp isn't available there in a Windows binary at the moment)


(This might be moot given Karl's answer), but:

We are working on having Rcpp to work with R 2.12.0, we have currently a 
few issues to deal with due to the use of a newer compiler for R 2.12.0.


We hope we can make this happen before R 2.12.0 is out next month.

Romain


but I did try it in R-patched. With one minor change to your script (the
lib.loc needs to be local, not local/ on Windows), I can reproduce
the problem, and it looks like a bug to me. Thanks for the report, I'll
put it on the bugs page, and hopefully it will be fixed before the
2.12.0 release.

Duncan Murdoch


Steps to reproduce the problem:

* unarchive it ( tar zxvf foo_0.1.tar.gz )
* cd foo
* install it locally ( mkdir local; R CMD INSTALL -l local . )
* R
 library(foo, lib.loc=local/)
.dynLibs()
# there you should be able to see the foo.so lib, in my case
/x05/people/m160508/workspace/foo/local/foo/libs/foo.so

 unloadNamespace(foo)
.onUnload, libpath= local/fooWarning message:
.onUnload failed in unloadNamespace() for 'foo', details:
call: library.dynam.unload(foo, libpath)
error: shared library 'foo' was not loaded

#The libpath that the .onUnload() gets is local/foo.

#This fails:
library.dynam.unload(foo, local/foo)
Error in library.dynam.unload(foo, local/foo) :
shared library 'foo' was not loaded

# but if you use the absolute path it works:
library.dynam.unload(foo,
/x05/people/m160508/workspace/foo/local/foo)

Karl

On Tue, Sep 21, 2010 at 5:33 PM, Duncan
Murdochmurdoch.dun...@gmail.comwrote:

 On 21/09/2010 10:38 AM, Karl Forner wrote:

 Hello,

 I got no reply on this issue.
 It is not critical and I could think of work-around, but it really
looks
 like a bug to me.
 Should I file a bug-report instead of posting in this list ?


 I'd probably post instructions for a reproducible example first.
Pick some
 CRAN package, tell us what to do with it to trigger the error, and
then we
 can see if it's something special about your package or Roxygen or a
general
 problem.

 Duncan Murdoch

 Thanks,

 Karl

 On Thu, Sep 16, 2010 at 6:11 PM, Karl Fornerkarl.for...@gmail.com
 wrote:

  Hello,
 
  I have a package with a namespace. Because I use Roxygen that
 overwrites
  the NAMESPACE file each time it is run, I use a R/zzz.R file with
  an .onLoad() and .onUnload() functions to take care of loading and
  unloading my shared library.
 
  The problem: if I load my library from a local directory, then the
  unloading of the package fails, e.g:
 
  # loads fine
  library(Foo, lib.loc=.Rcheck)
 
  unloadNamespace(Foo)
  Warning message:
  .onUnload failed in unloadNamespace() for 'Foo', details:
  call: library.dynam.unload(Foo, libpath)
  error: shared library 'Foo' was not loaded
 
  # I traced it a little:
  library.dynam.unload(Foo, .Rcheck/Foo)
  Error in library.dynam.unload(Foo, .Rcheck/Foo) :
  shared library 'Foo' was not loaded
 
  # using an absolute path works
  library.dynam.unload(Foo, /home/toto/.Rcheck/Foo)
 
 
  So from what I understand, the problem is either that the relative
 libpath
  is sent to the .onUnload() function instead of the absolute one,
  or that library.dynam.unload() should be modified to handle the
 relative
  paths.
 
  Am I missing something ? What should I do ?
 
  Thanks,
 
 
  Karl



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cCmbgg : Rcpp 0.8.6
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
`- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] list2env( list() )

[Romain Francois]

Hello,

list2env generates an error on empty lists.

 l - list()
 list2env( l )
Erreur dans list2env(l) : names(x) must be valid character(length(x)).


This is consistent with the requirement that the list must be a 
__named__ list, so this works:


 names(l) - character(0)
 list2env( l )
environment: 0x102b8fbc8


But I was wondering if it would make sense to make a special case of 
zero sized lists, with this:


Index: src/main/envir.c
===
--- src/main/envir.c(revision 52910)
+++ src/main/envir.c(working copy)
@@ -1555,7 +1555,7 @@
 x = CAR(args); args = CDR(args);
 n = LENGTH(x);
 xnms = getAttrib(x, R_NamesSymbol);
-if (TYPEOF(xnms) != STRSXP || LENGTH(xnms) != n)
+if (n  (TYPEOF(xnms) != STRSXP || LENGTH(xnms) != n) )
error(_(names(x) must be valid character(length(x)).));
 envir = CAR(args);  args = CDR(args);
 if (TYPEOF(envir) == NILSXP) {


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cCmbgg : Rcpp 0.8.6
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
`- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C or Java code generation

[Romain Francois]

Le 20/08/10 10:32, Vyacheslav Karamov a écrit :

Dirk Eddelbuettel пишет:

No, what you describe in the next few hundred lines would _build the
examples
if the package is already installed_
Also, building these examples (once you have the package is installed)
does
Work For Me (TM) in the sense that the compiles and linking steps
succeed
(WinXP, Rtools with gcc/g++ 4.2.x, R 2.11.0) yet it, as noted above,
leads to
a seg.fault which Romain and I have found neither time nor motivation
to fix.

You would be very welcome to help out -- our discussions around Rcpp and
RInside take place on the rcpp-devel list off R-Forge.


| 1) First I added R_HOME environment variable.
| 2) Then modified c:\Program |
Files\R\R-2.11.1\library\RInside\examples\standard\Makefile.win by |
surrounding $(R_HOME)/bin/R with the quotation marks.
| 3) And finally
| C:\Program Files\R\R-2.11.1\library\RInside\examples\standardmake
-f | Makefile.win
| g++ -Ic:/PROGRA~1/R/R-211~1.1/include |
-Ic:/PROGRA~1/R/R-211~1.1/library/Rcpp/include |
-Ic:/PROGRA~1/R/R-211~1.1/library/RInside/include -O2 -Wall -Wall -s
| rinside_callbacks0.cpp -Lc:/PROGRA~1/R/R-211~1.1/bin -lR |
-Lc:/PROGRA~1/R/R-211~1.1/bin -lRblas -Lc:/PROGRA~1/R/R-211~1.1/bin |
-lRlapack c:/PROGRA~1/R/R-211~1.1/library/RInside/lib/libRInside.a |
c:/PROGRA~1/R/R-211~1.1/library/Rcpp/lib/libRcpp.a -o rinside_callbacks0
|
c:/PROGRA~1/R/R-211~1.1/library/RInside/lib/libRInside.a(RInside.o):RInside.cpp:(.text+0x10b):
| undefined reference to `__gxx_personality_sj0'

[ Hundreds of similar lines removed. ]


Thanks, Dirk


Hi all!

Could you help me to install Rinside in Ubuntu Jaunty?
I've installed R and Rcpp but I have no idea how to deal with Rinside.
I couldn't find any makefile.

WBR,
Vyacheslav.


Hi,

It installs just like any other R package, there is no need for a Makefile.

$ R CMD RInside_0.2.3.tar.gz

or from R:

 install.packages( RInside )

We usually encourage people to use the Rcpp-devel mailing list for 
questions about RInside :

http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
|- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th
`- http://bit.ly/aAyra4 : highlight 0.2-2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Defining a method that behaves like '$'?

[Romain Francois]

Le 09/07/10 14:18, Renaud Gaujoux a écrit :


Hi,

is there a way to define a method say '$$' that would behave like '$'
and allow calls like 'a$$name'?
Thanks.

Renaud


No. This is not grammatically valid syntax:

 parse( text = 'a$$name' )
Erreur dans parse(text = a$$name) : '$' inattendu(e) dans a$$


But you can define custom methods for $.

setClass( Foo, representation( n = integer ) )
setMethod( $, Foo, function(x, name ){
function( ) rnorm( x...@n )
} )
foo - new( Foo, n = 10L )
foo$bla( )


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/aJHNLV : Rmetrics slides
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
`- http://bit.ly/c6YnCi : graph gallery collage

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] nchar( NA )

[Romain Francois]

Hello,

Is this expected ?

 nchar( c( , NA ) )
[1] 0 2

Should not the second one be NA ?

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] nchar( NA )

[Romain Francois]

Le 18/06/10 22:58, Sarah Goslee a écrit :

Hi Romain,

Did you read the help for nchar?

Value:

  For ‘nchar’, an integer vector giving the sizes of each element,
  currently always ‘2’ for missing values (for ‘NA’).

It may be unexpected behavior, but it's *well-documented* unexpected behavior.


Oops. My scan of the help page was too quick. I did not see it.

Sorry for the noise.


Sarah

On Fri, Jun 18, 2010 at 4:52 PM, Romain Francois
rom...@r-enthusiasts.com  wrote:

Hello,

Is this expected ?


nchar( c( , NA ) )

[1] 0 2

Should not the second one be NA ?

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] using C++ finalizers for external pointers

[Romain Francois]

Hello,

In Rcpp, we use a C++ template to finalizers for external pointers:

template typename T
void delete_finalizer(SEXP p){
if( TYPEOF(p) == EXTPTRSXP ){
T* ptr = (T*) EXTPTR_PTR(p) ;
delete ptr ;
}
}

This works fine. Or at least it has appeared to work fine for some time.


However, when compiled with suncc, this generates warnings [1] because 
the generated function is of C++ linkage and the finalizer type is 
declared to have C linkage in Rinternals.h


extern C {
...
typedef void (*R_CFinalizer_t)(SEXP);
void R_RegisterFinalizer(SEXP s, SEXP fun);
void R_RegisterCFinalizer(SEXP s, R_CFinalizer_t fun);
void R_RegisterFinalizerEx(SEXP s, SEXP fun, Rboolean onexit);
void R_RegisterCFinalizerEx(SEXP s, R_CFinalizer_t fun, Rboolean 
onexit);
...
}

Does anyone know a workaround ?

Would using an R finalizer (with R_RegisterFinalizer) using another 
external pointer to some class be appropriate ?


Romain

[1] : http://article.gmane.org/gmane.comp.lang.r.rcpp/433

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] require( foo (= 2.1) )

[Romain Francois]

Le 31/05/10 10:41, Barry Rowlingson a écrit :


On Sun, May 30, 2010 at 5:50 PM, Romain Francois
rom...@r-enthusiasts.com  wrote:

Hi,

Sure. I could and I would provide a patch. Since this is more of a nice to
have, I wanted to first find out whether others would find it useful, and
also if such a patch would have chances to get accepted by one of R-core
members.

Sometimes patches I or others provide upfront are not accepted. I'm not
complaining about it, it is always an opportunity to learn something ...



  For starters you could write a function called requireVersion that
does what you want. That would help you (since you say you often find
yourself using this paradigm) and also it would help anyone else who
does this. And since it wouldn't be a patch to R it wouldn't need
R-gods to approve it. It would also make you think about how you'd
parameterise the call - I wouldn't want to build something that had to
parse foo (=2.1)


The code already exists, to process DESCRIPTION files with:

Depends: foo (= 2.1)

but I think I also prefer using another argument anyway. Then there is 
also : what do you do if a lower version is found: warning, error, 
something that is parameterized y another argument, ...



for example, but having a minimum.version
argument makes more sense. Shouldn't be that difficult, you've written
most of it already!

  It might then get included in one of the packages of miscellany on
CRAN, and then maybe become core R functionality (if you sacrifice the
required animal to the R-gods, of course).

Barry


The problem with another function on top of require or library is that 
it either has to copy a lot of code from library or first call library 
and then find out if the loaded version is high enough. I think it is 
better that the package is not loaded at all if the version is not good 
enough (it might load the packages it depends on for nothing, etc ...) 
which is why I think a patch to library makes more sense.




But, library or require currently don't have a ... sink so code like :

require( foo, min.version = 2.1 )

would only work in, say R 2.12.0.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] require( foo (= 2.1) )

[Romain Francois]

Hi,

Sure. I could and I would provide a patch. Since this is more of a nice 
to have, I wanted to first find out whether others would find it 
useful, and also if such a patch would have chances to get accepted by 
one of R-core members.


Sometimes patches I or others provide upfront are not accepted. I'm not 
complaining about it, it is always an opportunity to learn something ...


Romain

Le 30/05/10 14:49, Wolfgang Huber a écrit :


Hi Romain,

not that I have any authority here, but wouldn't your suggestion (which
I think could be very useful) be more powerful if it were accompanied by
a patch that could be applied to the R sources?

Best wishes
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber




On 28/05/10 19:25, Romain Francois wrote:

Hello,

I often find myself writing code like :

if( require( foo )  compareVersion( packageDescription(
foo)[[Version]], 2.1 )  0 ){

# code that uses version 2.1 of foo
} else {
stop( could not load version = 2.1 of foo )
}



Would it make sense to include something like this in require, library,
etc ...

require( foo (= 2.1) )
require( foo, minimal.version = 2.1 )

I know we can use Depends: foo (= 2.1) in a package DESCRIPTION file,
but that does not work for loose dependencies, when package bar works
better with foo but can still work fine without, or when not making a
package.

Romain



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

Hello,

I'm trying to make .DollarNames generic and implement a method for it in 
a package. .DollarNames is the function that is now called to get 
completion possibilities.


My R code looks like this:

setGeneric( .DollarNames )

setClass(track,
 representation(x=numeric, y=numeric))
## A class extending the previous, adding one more slot
setClass(trackCurve,
representation(smooth = numeric),
contains = track)

setMethod( .DollarNames, signature( x = track, pattern = character 
), function(x, pattern){

grep( pattern, c(foo, bar), value = TRUE )  
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :

 require( foo )
 x - new( trackCurve, x = 1:10, y = 1:10, smooth = 1:10 )
 .DollarNames( x, f )
[1] foo

but completion does not work :

 x$fTAB
x$


What do I miss ?

I've uploaded foo here : http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9CQ66r : RMetrics 2010
|- http://bit.ly/cork4b : highlight 0.1-8
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

This seems to do the trick, but it does not feel right:

.onLoad - function( libname, pkgname ){ 
utils - asNamespace( utils )
unlockBinding( .DollarNames, utils )
assignInNamespace( .DollarNames, .DollarNames, utils )
lockBinding( .DollarNames, utils )
}

Any better idea ?

Romain

Le 29/05/10 13:21, Romain Francois a écrit :


Hello,

I'm trying to make .DollarNames generic and implement a method for it in
a package. .DollarNames is the function that is now called to get
completion possibilities.

My R code looks like this:

setGeneric( .DollarNames )

setClass(track,
representation(x=numeric, y=numeric))
## A class extending the previous, adding one more slot
setClass(trackCurve,
representation(smooth = numeric),
contains = track)

setMethod( .DollarNames, signature( x = track, pattern = character
), function(x, pattern){
grep( pattern, c(foo, bar), value = TRUE )
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :

  require( foo )
  x - new( trackCurve, x = 1:10, y = 1:10, smooth = 1:10 )
  .DollarNames( x, f )
[1] foo

but completion does not work :

  x$fTAB
x$


What do I miss ?

I've uploaded foo here :
http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9CQ66r : RMetrics 2010
|- http://bit.ly/cork4b : highlight 0.1-8
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

Le 29/05/10 20:23, Deepayan Sarkar a écrit :

On Sat, May 29, 2010 at 4:21 AM, Romain Francois
rom...@r-enthusiasts.com  wrote:

Hello,

I'm trying to make .DollarNames generic and implement a method for it in a
package. .DollarNames is the function that is now called to get completion
possibilities.

My R code looks like this:

setGeneric( .DollarNames )

setClass(track,
 representation(x=numeric, y=numeric))
## A class extending the previous, adding one more slot
setClass(trackCurve,
representation(smooth = numeric),
contains = track)

setMethod( .DollarNames, signature( x = track, pattern = character ),
function(x, pattern){
grep( pattern, c(foo, bar), value = TRUE )
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :


require( foo )
x- new( trackCurve, x = 1:10, y = 1:10, smooth = 1:10 )
.DollarNames( x, f )

[1] foo

but completion does not work :


x$fTAB

x$


I guess because


utils:::.DollarNames(x, f)

character(0)


yes. hence the hack I used when replying which is probably not a good 
idea, specially if two packages want it.



so the S4 generic is not being seen within the utils namespace. I
don't know what the right fix is...

-Deepayan


Perhaps something like the attached ?

defining a generic in methods and use this one when methods dispatch is on.



What do I miss ?

I've uploaded foo here : http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1

Index: src/library/utils/R/completion.R
===
--- src/library/utils/R/completion.R(revision 52140)
+++ src/library/utils/R/completion.R(working copy)
@@ -351,7 +351,8 @@
else
{
## ## suffix must match names(object) (or 
ls(object) for environments)
-   .DollarNames(object, pattern = sprintf(^%s, 
makeRegexpSafe(suffix)))
+   dollarNames - if( .isMethodsDispatchOn() ) 
methods:::.DollarNames else .DollarNames
+   dollarNames(object, pattern = sprintf(^%s, 
makeRegexpSafe(suffix)))   
## if (is.environment(object))
## {
## ls(object,
Index: src/library/methods/R/makeBasicFunsList.R
===
--- src/library/methods/R/makeBasicFunsList.R   (revision 52140)
+++ src/library/methods/R/makeBasicFunsList.R   (working copy)
@@ -222,7 +222,14 @@
base::sample(x, size, replace=replace, prob=prob, ...),
   signature = c(x, size), where = where)
 setGenericImplicit(sample, where, FALSE)
-
+
+setGeneric( .DollarNames, 
+   function(x, pattern) standardGeneric(.DollarNames), 
+   useAsDefault = function(x,pattern) utils:::.DollarNames(x,pattern), 
+   signature = x, 
+   where = where )
+setGenericImplicit(.DollarNames, where, FALSE)
+
 ## not implicitGeneric() which is not yet available here
 registerImplicitGenerics(where = where)
 }
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

Thanks. I'll apply the nice workaround for now.

Romain

Le 29/05/10 23:15, John Chambers a écrit :

The idea of modifying .DollarNames to recognize S4 methods is OK, but
the problem could arise again.

It would be better to have a general solution.  The general problem as
it seems is that an S3 generic called from within its package's
namespace (or from some other 3rd package) will not detect S4 methods.
In a sense, this is a natural consequence of namespace semantics and
therefore not a bug.  We don't really want to fix up each case when it
arises.

I can see two general solutions, one a reasonable fix that could likely
be implemented for 2.12.0, the other a slight hack added to make the
solution work now.

Both solutions start with the idea that we continue to treat the S3
generic as an S3 generic (at least when it's called from the owning
package's namespace).  We then define an S3 method for the S4 class.

Right now, that fails to recognize S4 inheritance (that's the fix that
should be doable for 2.12.0; most of the mechanism needed is already in
the UseMethod implementation).

The workaround/hack that *does* work now, I believe, is to insert a
dummy S3 class into the mix and define the S3 .DollarNames method for it.

Example:
  setOldClass(foo3)
  .DollarNames.foo3 - function(x, pattern)bar
 
  setClass(foo, contains = foo3, representation(x = numeric))
[1] foo
 
  ff = new(foo)
 
  setClass(fee, contains = foo)
[1] fee
 
  fe = new(fee)

Both ff$ and fe$ complete with bar, running 2.11.0 from the command line.

John





On 5/29/10 12:37 PM, Romain Francois wrote:

Le 29/05/10 20:23, Deepayan Sarkar a écrit :

On Sat, May 29, 2010 at 4:21 AM, Romain Francois
rom...@r-enthusiasts.com  wrote:

Hello,

I'm trying to make .DollarNames generic and implement a method for
it in a
package. .DollarNames is the function that is now called to get
completion
possibilities.

My R code looks like this:

setGeneric( .DollarNames )

setClass(track,
 representation(x=numeric, y=numeric))
## A class extending the previous, adding one more slot
setClass(trackCurve,
representation(smooth = numeric),
contains = track)

setMethod( .DollarNames, signature( x = track, pattern =
character ),
function(x, pattern){
grep( pattern, c(foo, bar), value = TRUE )
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :


require( foo )
x- new( trackCurve, x = 1:10, y = 1:10, smooth = 1:10 )
.DollarNames( x, f )

[1] foo

but completion does not work :


x$fTAB

x$


I guess because


utils:::.DollarNames(x, f)

character(0)


yes. hence the hack I used when replying which is probably not a good
idea, specially if two packages want it.


so the S4 generic is not being seen within the utils namespace. I
don't know what the right fix is...

-Deepayan


Perhaps something like the attached ?

defining a generic in methods and use this one when methods dispatch
is on.



What do I miss ?

I've uploaded foo here :
http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain



__
R-devel@r-project.org  mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] require( foo (= 2.1) )

[Romain Francois]

Hello,

I often find myself writing code like :

if( require( foo )  compareVersion( packageDescription( 
foo)[[Version]], 2.1 )  0 ){


# code that uses version 2.1 of foo
} else {
stop( could not load version = 2.1 of foo )
}



Would it make sense to include something like this in require, library, 
etc ...


require( foo (= 2.1) )
require( foo, minimal.version = 2.1 )

I know we can use Depends: foo (= 2.1) in a package DESCRIPTION file, 
but that does not work for loose dependencies, when package bar works 
better with foo but can still work fine without, or when not making a 
package.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9CQ66r : RMetrics 2010
|- http://bit.ly/cork4b : highlight 0.1-8
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R 2.10 and help

[Romain Francois]

Le 27/05/10 09:48, Jamie Love a écrit :


Thanks for the info,

I'm happy to use the new httpd server that serves the help files -
that'd definitely help. My difficulty with this approach is that I'm
not sure how to get the URL -

Say for example I've done help.start(),

then I do:

help(plot)

it will redirect my web browser to the plot page -

How can I stop it touching my web browser and instead return to me the URL.

I tried overriding the browseURL() function, but it seem to do nothing.


Perhaps something like this:

 options( browser = function(url, ...) print( url ) )
 ?plot
[1] http://127.0.0.1:9000/library/graphics/html/plot.html;

Romain


Ta




It's much more simple since 2.10 as you can simply use the URL (same URL as the 
help system uses). For examples see JGR or the Mac GUI. Or you can do the same 
thing that the Rhttpd server does  actually generating the html - see 
tools:::httpd






--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cork4b : highlight 0.1-8
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
`- http://bit.ly/936ck2 : Rcpp 0.8.0

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Use of R and Rscript in configure/Makevars in packages

[Romain Francois]

Hello,

Thank you for these clear guidelines.

Given these subtleties, would it make sense to have a configure.R that 
would win over configure and configure.win, and have R invoking it 
correctly, as below ?


Romain

Le 20/05/10 08:51, Prof Brian Ripley a écrit :


We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.

(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use

${R_HOME}/bin/R

to select the right version. And since ${R_HOME} might contain spaces,
you need something like ${R_HOME}/bin/R.

There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.

(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of

${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe
${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe
${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe

On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.

On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).

(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.

(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)

BDR




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Use of R and Rscript in configure/Makevars in packages

[Romain Francois]

Le 20/05/10 09:40, Prof Brian Ripley a écrit :

On Thu, 20 May 2010, Romain Francois wrote:


Hello,

Thank you for these clear guidelines.

Given these subtleties, would it make sense to have a configure.R
that would win over configure and configure.win, and have R invoking
it correctly, as below ?


Only if someone in R-core volunteers to implement it, and this would not
solve the issue until R 2.12.0 and all the packages involved moved to it.


Sure. This leaves plently of time to test it then.

Reading the above literally, I will not work on a patch, but I can offer 
my time to test it if someone in R-core does volunteer.


Romain


Romain

Le 20/05/10 08:51, Prof Brian Ripley a écrit :


We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.

(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use

${R_HOME}/bin/R

to select the right version. And since ${R_HOME} might contain spaces,
you need something like ${R_HOME}/bin/R.

There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.

(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of

${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe
${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe
${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe

On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.

On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).

(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.

(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)

BDR




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents







--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] print.data.frame curiosity

[Romain Francois]

Hello,

I made a mistake and passed stringsAsFactors to the wrong function in :

 df - as.data.frame( list( x = 1:3, y = c(a, b, c ), 
stringsAsFactors = FALSE ) )


But then :

 df
  x y
1 1 a
2 2 b
3 3 c

and :

 df[[y]]
[1] a b c
Levels: a b c
 str( df )
'data.frame':   3 obs. of  3 variables:
 $ x   : int  1 2 3
 $ y   : Factor w/ 3 levels a,b,c: 1 2 3
 $ stringsAsFactors: logi  FALSE FALSE FALSE


Somehow, print.data.frame does not want to print a column named 
stringsAsFactors. (I know this is a bad name for a column, but ...)


Apparently, this line in format.data.frame is responsible for the mismatch:

x - do.call(data.frame, rval)

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RInside child threads

[Romain Francois]

Hi,

Thank you for your interest in RInside.

We usually engage people to use the Rcpp-devel mailing list for 
questions about RInside.


Could you prepare a small example of what you are trying to achieve and 
repost there. 
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


Romain

Le 30/04/10 19:32, Jaiganesh Balasubramanian a écrit :


Hi Folks,

I am creating a multi-threaded C++ application that initializes RInside in
one of the child thread.

I would also like to access support interfaces like Rcpp::Environment in the
remaining child threads, so that I could access any R function associated
with the
environment initialized.

When I run my program, I always get C Stack limit too huge errors.

I looked at the Writing R Extensions manual, and it pointed to
initializing the R_CStackLimit variable to -1, and
that this initialization need to be made after the RInside constructor is
called. I did that, but it still does not work.

Can you please let me know how do we accomplish this task?

Thanks very much,
Jai




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RInside child threads

[Romain Francois]

Hi,

Thank you for your interest in RInside.

We usually engage people to use the Rcpp-devel mailing list for 
questions about RInside.


Could you prepare a small example of what you are trying to achieve and 
repost there. 
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


Romain

Le 30/04/10 19:32, Jaiganesh Balasubramanian a écrit :


Hi Folks,

I am creating a multi-threaded C++ application that initializes RInside in
one of the child thread.

I would also like to access support interfaces like Rcpp::Environment in the
remaining child threads, so that I could access any R function associated
with the
environment initialized.

When I run my program, I always get C Stack limit too huge errors.

I looked at the Writing R Extensions manual, and it pointed to
initializing the R_CStackLimit variable to -1, and
that this initialization need to be made after the RInside constructor is
called. I did that, but it still does not work.

Can you please let me know how do we accomplish this task?

Thanks very much,
Jai




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Memory allocation in C/C++ vs R?

[Romain Francois]

 from C++ 
unless you are very, very careful (don't forget that C++ does a lot of things 
behind your back such as initializing objects, exception contexts etc. which 
you technically have no control over).


As I said in my post, you can write safe C++ code, but you have to be very 
careful. But the point about libraries is that you have no control over what 
they do, so you cannot know whether they will interact in a bad way with R or 
not. STL is an example where only the interface is defined, the implementations 
are not and vary by OS, compiler etc. This makes it pretty much impossible to 
use it reliably since the fact that it will work on one implementation doesn't 
mean that it will work on another since it is the implementation details that 
will bite you. (I know that we had reports of things breaking due to STL but I 
don't remember what implementation/OS it was)

[The above issue are only the ones I was pointing out, there may be others that 
are not covered here].

Cheers,
Simon




 R context vs C++ exception example



dyn.load(stl.so)
.Call(bar)

something went wrong somewhere in C++...
Warning: stack imbalance in '.Call', 2 then 4
NULL

-- what happens is that this really corrupts the R call stack since the C++ 
exception mechanism bypassed R's call stack so R is now is an inconsistent 
state. The same can be invoked vice-versa (and is more common - using error in 
C++ will do it) but that's harder to show because you would have to track C++ 
allocations to see that you're leaking objects all over the place. That is also 
the reason why it's hard to find unless it's too late (and things may *appear* 
to work for some time while they are not).


stl.cc:

#includeRinternals.h
#includevector

using namespace std;

extern C SEXP foo() {
  vectorint  a;
  a.resize(-1);
  return R_NilValue;
}

extern C SEXP bar() {
  try {
// lots of other C++ code here ...
eval(lang2(install(.Call),mkString(foo)), R_GlobalEnv);
  } catch (...) {
REprintf(something went wrong somewhere in C++...\n);
  }
  return R_NilValue;
}


The fact that R has a C main may be problematic because C++ static
initializers may not be called properly, but the fact that packages are
usually loaded dynamically complicates this picture. The dynamic
library itself may take care of calling the static initializers (I'm not
sure about this, and this is probably OS-dependent). One possible
work-around would be to compile the first few lines (a stub) of
R main using the C++ compiler, leaving everything else as is
and compiled using the C compiler (at least until CXXR is widely
available).

Since C++ (and STL) are very popular it would be helpful for developers
to have a better idea of the benefits and risks of using these tools
with R.

Thanks,
Dominick

On Fri, Apr 30, 2010 at 9:00 AM, Simon Urbanek
simon.urba...@r-project.org  wrote:

Brian's answer was pretty exhaustive - just one more note that is indirectly 
related to memory management: C++ exception handling does interfere with R's 
error handling (and vice versa) so in general STL is very dangerous and best 
avoided in R. In addition, remember that regular local object rules are broken 
because you are not guaranteed to leave a function the regular way so there is 
a high danger of leaks and inconsistencies when using C++ memory management 
unless you specifically account for that. That said, I have written C++ code 
that works in R but you have to be very, very careful and think twice about 
using any complex C++ libraries since they are unlikely written in R-safe way.

Cheers,
Simon


On Apr 30, 2010, at 1:03 AM, Dominick Samperi wrote:


The R docs say that there are two methods that the C programmer can
allocate memory, one where R automatically frees the memory on
return from .C/.Call, and the other where the user takes responsibility
for freeing the storage. Both methods involve using R-provided
functions.

What happens when the user uses the standard new allocator?
What about when a C++ application uses STL and that library
allocates memory? In both of these cases the R-provided functions
are not used (to my knowledge), yet I have not seen any problems.

How is the memory that R manages and garbage collects kept
separate from the memory that is allocated on the C++ side
quite independently of what R is doing?

Thanks,
Dominick


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Resolving functions using R's namespace mechanism can double runtime

[Romain Francois]

Le 27/04/10 22:16, Dominick Samperi a écrit :

It appears that the runtime for an R script can more than double if a few
references to a function foo() are replaced by more explict references
of the form pkgname::foo().


It would probably help your question if you provide some benchmarks.

a::b is just a shortcut for `::`( a, b ).


The more explicit references are of course required when two
loaded packages define the same function.


Not really. You can :
- resolve once: my_foo - pkgname::foo
- import the variable into your namespace using the importFrom namespace 
directive.



I can understand why use of this mechanism is not free in an
interpreted environment like R, but the cost seems rather high.

Dominick


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RUnit bug?

[Romain Francois]

Le 22/04/10 02:19, Dominick Samperi a écrit :


There appears to be a bug in RUnit.

Given a testsuite testsuite.math, say, when I run:

runTestSuite(testsuite.math)

this works fine, provided there are no extraneous files in the
unit test subdirectory.

But if there are any Emacs temp files (with names that
end with '~') then runTestSuite gets confused and tries to
run functions from the temp files as well.


How do you define 'testsuite.math'. The default value of the 
testFileRegexp argument in defineTestSuite should rule these files out.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] suggestion how to use memcpy in duplicate.c

[Romain Francois]

Le 21/04/10 17:54, Matthew Dowle a écrit :



From copyVector in duplicate.c :


void copyVector(SEXP s, SEXP t)
{
 int i, ns, nt;
 nt = LENGTH(t);
 ns = LENGTH(s);
 switch (TYPEOF(s)) {
...
 case INTSXP:
 for (i = 0; i  ns; i++)
 INTEGER(s)[i] = INTEGER(t)[i % nt];
 break;
...

could that be replaced with :

 case INTSXP:
 for (i=0; ins/nt; i++)
 memcpy((char *)DATAPTR(s)+i*nt*sizeof(int), (char *)DATAPTR(t),
nt*sizeof(int));
 break;


or at least with something like this:

int* p_s = INTEGER(s) ;
int* p_t = INTEGER(t) ;
for( i=0 ; i  ns ; i++){
p_s[i] = p_t[i % nt];
}

since expanding the INTEGER macro over and over has a price.


and similar for the other types in copyVector.  This won't help regular
vector copies, since those seem to be done by the DUPLICATE_ATOMIC_VECTOR
macro, see next suggestion below, but it should help copyMatrix which calls
copyVector, scan.c which calls copyVector on three lines, dcf.c (once) and
dounzip.c (once).

For the DUPLICATE_ATOMIC_VECTOR macro there is already a comment next to it
:

 FIXME: surely memcpy would be faster here?

which seems to refer to the for loop  :

 else { \
 int __i__; \
 type *__fp__ = fun(from), *__tp__ = fun(to); \
 for (__i__ = 0; __i__  __n__; __i__++) \
   __tp__[__i__] = __fp__[__i__]; \
   } \

Could that loop be replaced by the following ?

else { \
memcpy((char *)DATAPTR(to), (char *)DATAPTR(from), __n__*sizeof(type)); \
}\

In the data.table package, dogroups.c uses this technique, so the principle
is tested and works well so far.

Are there any road blocks preventing this change, or is anyone already
working on it ?  If not then I'll try and test it (on Ubuntu 32bit) and
submit patch with timings, as before.  Comments/pointers much appreciated.

Matthew

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] suggestion how to use memcpy in duplicate.c

[Romain Francois]

Le 21/04/10 21:39, Simon Urbanek a écrit :



On Apr 21, 2010, at 3:32 PM, Romain Francois wrote:


Le 21/04/10 17:54, Matthew Dowle a écrit :



 From copyVector in duplicate.c :


void copyVector(SEXP s, SEXP t)
{
 int i, ns, nt;
 nt = LENGTH(t);
 ns = LENGTH(s);
 switch (TYPEOF(s)) {
...
 case INTSXP:
 for (i = 0; i   ns; i++)
 INTEGER(s)[i] = INTEGER(t)[i % nt];
 break;
...

could that be replaced with :

 case INTSXP:
 for (i=0; ins/nt; i++)
 memcpy((char *)DATAPTR(s)+i*nt*sizeof(int), (char *)DATAPTR(t),
nt*sizeof(int));
 break;


or at least with something like this:

int* p_s = INTEGER(s) ;
int* p_t = INTEGER(t) ;
for( i=0 ; i  ns ; i++){
p_s[i] = p_t[i % nt];
}

since expanding the INTEGER macro over and over has a price.



... in packages, yes, but not in core R.


Hmm. I was not talking about the overhead of the INTEGER function:

int *(INTEGER)(SEXP x) {
if(TYPEOF(x) != INTSXP  TYPEOF(x) != LGLSXP)
error(%s() can only be applied to a '%s', not a '%s',
  INTEGER, integer, type2char(TYPEOF(x)));
return INTEGER(x);
}



but the one related to the macro.

#define INTEGER(x)  ((int *) DATAPTR(x))
#define DATAPTR(x)  (((SEXPREC_ALIGN *) (x)) + 1)

so the loop expands to :

for (i = 0; i   ns; i++)
  ((int *) (((SEXPREC_ALIGN *) (s)) + 1))[i] = ((int *) 
(((SEXPREC_ALIGN *) (t)) + 1))[i % nt];


I still believe grabbing the pointer just once for s and once for t is 
more efficient ...



Cheers,
Simon



and similar for the other types in copyVector.  This won't help regular
vector copies, since those seem to be done by the DUPLICATE_ATOMIC_VECTOR
macro, see next suggestion below, but it should help copyMatrix which calls
copyVector, scan.c which calls copyVector on three lines, dcf.c (once) and
dounzip.c (once).

For the DUPLICATE_ATOMIC_VECTOR macro there is already a comment next to it
:

 FIXME: surely memcpy would be faster here?

which seems to refer to the for loop  :

 else { \
 int __i__; \
 type *__fp__ = fun(from), *__tp__ = fun(to); \
 for (__i__ = 0; __i__   __n__; __i__++) \
   __tp__[__i__] = __fp__[__i__]; \
   } \

Could that loop be replaced by the following ?

else { \
memcpy((char *)DATAPTR(to), (char *)DATAPTR(from), __n__*sizeof(type)); \
}\

In the data.table package, dogroups.c uses this technique, so the principle
is tested and works well so far.

Are there any road blocks preventing this change, or is anyone already
working on it ?  If not then I'll try and test it (on Ubuntu 32bit) and
submit patch with timings, as before.  Comments/pointers much appreciated.

Matthew



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] inject html code into Rd file

[Romain Francois]

Le 03/04/10 02:04, Duncan Murdoch a écrit :


On 02/04/2010 8:06 AM, Duncan Murdoch wrote:

On 02/04/2010 7:13 AM, Romain Francois wrote:

Le 02/04/10 13:07, Duncan Murdoch a écrit :

On 02/04/2010 6:17 AM, Romain Francois wrote:

Hello,

I'm trying to inject html code into an Rd file. For example :

\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
bhello/b
}
}
}

when this file is rendered, instead of having hello in bold, I get
bhello/b, i.e. characters  and  are replaced with html entities
: lt; and gt;

Is there a way to turn this off ?

Yes, if you wrap it in \out{}. The example in the manual is

\if{latex}{\out{\alpha}}\ifelse{html}{\out{alpha;}}{alpha}

Duncan Murdoch

yes, I saw that in WRE, I should have been more specific.


what if instead of a trivial string like bhello/b the text is
to be computed by some function. For example:

print( xtable( iris), type = html )


I think this should do it:

\Sexpr[stage=render,results=rd,echo=FALSE]{
paste(\\out{, bhello/b, }, sep=)}

but this stuff hasn't been tested much, so there might be problems...


One problem is that the backslashes need to be escaped twice, so you'd want

\Sexpr[stage=render,results=rd,echo=FALSE]{
paste(out{, bhello/b, }, sep=)}

and you'd probably want it wrapped in \if or \ifelse so that it doesn't
show up in text or latex output:

\Sexpr[stage=render,results=rd,
echo=FALSE]{if{html}{out{bhello/b}}}

Duncan Murdoch


Thanks.
This gives one way to include images in a Rd file with data uri, here is 
a proof of concept (that depends on openssl to do the base 64 encoding):


img - function(){
tf - tempfile()
tf.out - tempfile()
png( tf, width = 500, height = 500)
plot( 1:100, rnorm(100), pch = 21, bg = red, cex =2 )
dev.off()
system( sprintf( 'openssl base64 -in %s -out %s ', tf, tf.out ) )
sprintf( '\\out{img src=data:image/png;base64,%s /}',
paste( readLines( tf.out), collapse = \n ) )
}

and the Rd file:

\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=rd,echo=FALSE]{
source( test.R )
img()
}
}
}



It might be interesting to have something like results=asis or something.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] inject html code into Rd file

[Romain Francois]

Hello,

I'm trying to inject html code into an Rd file. For example :

\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
bhello/b
}
}
}

when this file is rendered, instead of having hello in bold, I get 
bhello/b, i.e. characters  and  are replaced with html entities : 
lt; and gt;


Is there a way to turn this off ?

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] inject html code into Rd file

[Romain Francois]

Le 02/04/10 13:07, Duncan Murdoch a écrit :

On 02/04/2010 6:17 AM, Romain Francois wrote:

Hello,

I'm trying to inject html code into an Rd file. For example :

\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
bhello/b
}
}
}

when this file is rendered, instead of having hello in bold, I get
bhello/b, i.e. characters  and  are replaced with html entities
: lt; and gt;

Is there a way to turn this off ?


Yes, if you wrap it in \out{}. The example in the manual is

\if{latex}{\out{\alpha}}\ifelse{html}{\out{alpha;}}{alpha}

Duncan Murdoch


yes, I saw that in WRE, I should have been more specific.


what if instead of a trivial string like bhello/b the text is to 
be computed by some function. For example:


print( xtable( iris), type = html )

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Trouble in using rJava

[Romain Francois]

Hello,

Please don't post in multiple mailing lists. (this does not improve your 
chances of getting an answer). I think the best mailing list for this 
question (although see below) is : 
http://mailman.rz.uni-augsburg.de/mailman/listinfo/stats-rosuda-devel


Le 30/03/10 10:19, Nabila Salmi a écrit :


Hello,

I'm using rJava and JRI to call R scripts from my Java code, but my
scripts are sometimes executed, and very often they don't run throwing a
Java exception.
I'm using a 2.7 version of R, with rJava 0.8.4 and Java Sun 1.6.

Somebody can help me please ??

Thank you very much,

Nabila


Even if someone wants to help you, how would they ? Your question is 
very vague.


R version 2.7 does not exist. If we assume you mean 2.7.2, this has been 
released in almost two years ago, in august 2008. In the meantime, these 
versions of R have been released : 2.8.0, 2.8.1, 2.9.0, 2.9.1, 2.9.2, 
2.10.0. Can you try to use the current version of R and see if this fix 
your vague problem.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] for help on building a R package with several R function and a bunch of c, c++

[Romain Francois]

difficult with this main program   makefile

model.


Install Rcpp and try to use the Rcpp.package.skeleton,

this will create

a simple package that uses some C++ classes from Rcpp,

as well as an R

function that calls them.


I read Rcpp , I am not sure ifÂ

RcppResultSet can solve my problem or other function. Once I
make sure it work I need ask UNIX adminstrator to install
it.


We don't know what your problem is. We can answer a

question, but we

cannot guess the question for you.

Rcpp works, please refer to our unit tests, for

example look at this

vignette:
http://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-unitTests.pdf


I think it shouldn't be very complex,  as I

know to build a R function easy with one C function.


Thanks you for yout attention!

Alex

--- On Fri, 3/5/10, Dirk Eddelbuettele...@debian.orgÂ

wrote:



From: Dirk Eddelbuettele...@debian.org
Subject: Re: [Rd] for help on building a R package

with several R function and a bunch of c, c++

To: alex46...@yahoo.com
Cc: r-devel@r-project.org
Date: Friday, March 5, 2010, 8:25 PM



On 5 March 2010 at 13:15, alex46...@yahoo.com

wrote:

| Hope I can get quick help from here, I have a

bunch of c, c++ included main function and makefile. It
works well on both UNIX and windows. I tried to build R
package which include this C++ program and several other R
functions.  These R function here are
independent  of c++ code. I prefer to define one R
function to call this c++ program (main function).

|
| I know how to build R package with just R

function, but I don't know how to handle those c++ c code
after I copied those  code  in ./src, I am
reading manual Writing R Extensions , but I did n't catch
the key point . Do you know any easy way to do it? ,


When you asked _that exact same question_ this

morning on r-help, you got the

following answer:

     From: Whit Armstrongarmstrong.w...@gmail.com
     To: alex46...@yahoo.com
     Cc: r-h...@r-project.org
     Subject: Re: [R] for help on

building a R package with several R function and a bunch of
c, c++

     Date: Fri, 5 Mar 2010 10:33:54

-0500


     Pick up Rcpp, make your life

easier.


     http://dirk.eddelbuettel.com/code/rcpp.html

     -Whit

     On Fri, Mar 5, 2010 at 9:19

AM,alex46...@yahoo.comÂ
wrote:

    Â  Hope I can get quick

help from here, I have a bunch of c, c++ included main
function and makefile. It works well on both UNIX and
windows. I tried to build R package which include this C++
program and several other R functions.  R function
here are independent  c++ code. I prefer to define
one R function to call this c++ program.

    Â
    Â  Do you know any easy

way to do it? I am reading manual Writing R Extensions, I
didn't catch the key point. I know how to build R package
with just R function,  If I put all c++ code and
makefile in /src...what I need do?

    Â
    Â  Thank you in

advance!

    Â
    Â  Alex

Now, can you let us know

      a) what part of the

answer was unclear to you, and


      b) what made you think

you needed to repost _the identical question_ here


| Thank you in advance!

You're welcome.

Dirk



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] for help on building a R package with several R function and a bunch of c, c++

[Romain Francois]

On 03/06/2010 03:27 AM, alex46...@yahoo.com wrote:

I think the first question should be how to build a R function to call a bunch 
of C ,C++ which include one main program, and a makefile. My goal to build a R 
package will be next step.


You should jump straight to making a package. You are making you life 
difficult with this main program  makefile model.


Install Rcpp and try to use the Rcpp.package.skeleton, this will create 
a simple package that uses some C++ classes from Rcpp, as well as an R 
function that calls them.



I read Rcpp , I am not sure if  RcppResultSet can solve my problem or other 
function. Once I make sure it work I need ask UNIX adminstrator to install it.


We don't know what your problem is. We can answer a question, but we 
cannot guess the question for you.


Rcpp works, please refer to our unit tests, for example look at this 
vignette: 
http://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-unitTests.pdf



I think it shouldn't be very complex,  as I know to build a R function easy 
with one C function.

Thanks you for yout attention!

Alex

--- On Fri, 3/5/10, Dirk Eddelbuettele...@debian.org  wrote:


From: Dirk Eddelbuettele...@debian.org
Subject: Re: [Rd] for help on building a R package with several R function and 
a bunch of c, c++
To: alex46...@yahoo.com
Cc: r-devel@r-project.org
Date: Friday, March 5, 2010, 8:25 PM



On 5 March 2010 at 13:15, alex46...@yahoo.com wrote:
| Hope I can get quick help from here, I have a bunch of c, c++ included main 
function and makefile. It works well on both UNIX and windows. I tried to build 
R package which include this C++ program and several other R functions.  These 
R function here are independent  of c++ code. I prefer to define one R function 
to call this c++ program (main function).
|
| I know how to build R package with just R function, but I don't know how to handle 
those c++ c code after I copied those  code  in ./src, I am reading manual Writing 
R Extensions , but I did n't catch the key point . Do you know any easy way to do 
it? ,

When you asked _that exact same question_ this morning on r-help, you got the
following answer:

From: Whit Armstrongarmstrong.w...@gmail.com
To: alex46...@yahoo.com
Cc: r-h...@r-project.org
Subject: Re: [R] for help on building a R package with several R function 
and a bunch of c, c++
Date: Fri, 5 Mar 2010 10:33:54 -0500

Pick up Rcpp, make your life easier.

http://dirk.eddelbuettel.com/code/rcpp.html

-Whit

On Fri, Mar 5, 2010 at 9:19 AM,alex46...@yahoo.com  wrote:
  Hope I can get quick help from here, I have a bunch of c, c++ included 
main function and makefile. It works well on both UNIX and windows. I tried to 
build R package which include this C++ program and several other R functions.  R 
function here are independent  c++ code. I prefer to define one R function to call 
this c++ program.

  Do you know any easy way to do it? I am reading manual Writing R 
Extensions, I didn't catch the key point. I know how to build R package with just R 
function,  If I put all c++ code and makefile in /src...what I need do?

  Thank you in advance!

  Alex

Now, can you let us know

 a) what part of the answer was unclear to you, and

 b) what made you think you needed to repost _the identical question_ here

| Thank you in advance!

You're welcome.

Dirk



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] duplicate STRSXP : shallow copy ?

[Romain Francois]

Hello,

As this little program illustrates, duplicating a STRSXP does not seem 
deep enough.


require( inline )

fx - cfunction( signature( x = character), '
SEXP y = PROTECT( duplicate( x ) );
int n = LENGTH(x);
int nc = 0 ;
char* p = 0 ;
for( int i=0; in; i++){
p = (char*)( CHAR( STRING_ELT( y , i ) ) );
nc = strlen( p ) ;
for( int j=0; jnc; j++){
p[j] = tolower( p[j] ) ;
}
}
SEXP res = PROTECT( allocVector( VECSXP, 2 ) );
SET_VECTOR_ELT( res, 0, x );
SET_VECTOR_ELT( res, 1, y );
UNPROTECT(2) ;
return res ;
', includes = #include ctype.h )

I get :

 fx( c(Tick, Tack, Tock ) )
[[1]]
[1] tick tack tock

[[2]]
[1] tick tack tock

where I would expect the second element of the list to not be modified. 
Is this intended ?


If not, I can track it down to the   DUPLICATE_ATOMIC_VECTOR in 
duplicate.c and submit a patch.


Also, CHARSXP don't seem to be actually duplicated :

case CHARSXP:
return s;

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] duplicate STRSXP : shallow copy ?

[Romain Francois]

Hello,

I understand now that this is very intended after reading: 
http://cran.r-project.org/doc/manuals/R-ints.html#The-CHARSXP-cache


So we are not supposed to modify a CHARSXP character by character.

Sorry for the noise.

Romain

On 03/07/2010 10:48 AM, Romain Francois wrote:


Hello,

As this little program illustrates, duplicating a STRSXP does not seem
deep enough.

require( inline )

fx - cfunction( signature( x = character), '
SEXP y = PROTECT( duplicate( x ) );
int n = LENGTH(x);
int nc = 0 ;
char* p = 0 ;
for( int i=0; in; i++){
p = (char*)( CHAR( STRING_ELT( y , i ) ) );
nc = strlen( p ) ;
for( int j=0; jnc; j++){
p[j] = tolower( p[j] ) ;
}
}
SEXP res = PROTECT( allocVector( VECSXP, 2 ) );
SET_VECTOR_ELT( res, 0, x );
SET_VECTOR_ELT( res, 1, y );
UNPROTECT(2) ;
return res ;
', includes = #include ctype.h )

I get :

  fx( c(Tick, Tack, Tock ) )
[[1]]
[1] tick tack tock

[[2]]
[1] tick tack tock

where I would expect the second element of the list to not be modified.
Is this intended ?

If not, I can track it down to the DUPLICATE_ATOMIC_VECTOR in
duplicate.c and submit a patch.

Also, CHARSXP don't seem to be actually duplicated :

case CHARSXP:
return s;

Romain




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] for help on building a R package with several R function and a bunch of c, c++

[Romain Francois]

 the key point. I know how to build R package with just R 
function,  If I put all c++ code and makefile in /src...what I need do?
    Â
    Â  Thank you in advance!
    Â
    Â  Alex

Now, can you let us know

      a) what part of the answer was unclear to you, and

      b) what made you think you needed to repost _the identical question_ 
here

| Thank you in advance!

You're welcome.

Dirk


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Mentor for GSOC '10: Symbolic Regression in R

[Romain Francois]

Hello,

I can't offer to mentor because I don't know anything about symbolic 
regression.


However, since you have R/C++ as the skills requirements, I would 
strongly recommend that you use Rcpp as an enabling technology, so that 
you can be productive on C++/symbolic regressions as opposed to manage R 
API quirks.


Also, you can count on some implicit support through Rcpp mailing list.
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Good luck finding a mentor, this sounds like a cool project.

Romain

On 03/03/2010 08:17 PM, Chidambaram Annamalai wrote:


Hi all,

I am looking to extend the regression and data analysis capabilities of R
through Symbolic Regression that can potentially find implicit equation
relationships in the input data. You can find my project proposal at:
http://rwiki.sciviews.org/doku.php?id=developers:projects:gsoc2010:syrfr

I am looking for a mentor to guide me through the summer on the project
under the Google Summer Of Code program (GSOC 2010) with relevant experience
in Symbolic Regression or Genetic Programming in general.


Chillu



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to create a SEXP which could be accessed in embedded R

[Romain Francois]

On 02/20/2010 05:58 AM, yeahzx wrote:


Hi all,

I am not familiar with writing R extensions. In a C program, I want to create a 
SEXP and access it in embedded R. How to let the embedded engine know there's a 
new vector? For example, after creating a SEXP, parsing 'ls()' in embedded R 
and then evaluating, STRSXP returned will contain the name of the SEXP. Any 
help would be appreciated.

Regards,
Spiral


Hi ,

I'm not sure I understand what you mean. If you want the variable to be 
in the global environment, you have to assign it there. You can use e.g. 
defineVar :


SEXP x = PROTECT( allocVector( STRSXP, 2 ) );
SET_STRING_ELT( x, 0, Rf_mkChar( foo ) ) ;
SET_STRING_ELT( x, 1, Rf_mkChar( bar ) ) ;
defineVar( Rf_install(x), x, R_GlobalEnv  ) ;
UNPROTECT(1) ; /* x */

Romain


PS: with Rcpp, you can do the same as :

using namespace Rcpp;
Environment global = Environment::global_env() ;
CharacterVector x(2) ; x[0] = foo ; x[1] = bar ;
global[x] = x ;

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Portability of a C function

[Romain Francois]

Hello,

This was discussed this week in the thread LinkingTo and C++.

It is possible, and documented in WRE section 5.4 : 
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines


Romain

On 02/14/2010 12:58 PM, Christophe Genolini wrote:


Hi the list,

In a package P1, I write a function f1 in C, potentially an internal
function (not to be called from R).
In a package P2, I write a function f2 in C. The f2 function needs to
use f1 from P1. Is it possible ?

--- 8  In file P1.c -
double f1(x,y){

}

--- 8  In file P2.c -
void f2(x,y,z){
double result;

result = f1(x,y);

}

Thanks
Christophe


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/O1wO : highlight 0.1-5
|- http://tr.im/O1qJ : Rcpp 0.7.6
`- http://tr.im/NrTG : Rcpp 0.7.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] How S3method() is implemented and called? And when to use it?

[Romain Francois]

Hello `Blue Sky` ,

Will you please start posting under your real name.

As documented in WRE, S3method is meant for use in namespaces:
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods

It is not an R function.

Romain

On 02/14/2010 07:32 PM, blue sky wrote:


R-exts.pdf discribes S3method a little bit. But I want to understand
more on how it is called, implemented and when to use it.

I don't find it in an R session. But I see S3method() in some NAMESPACE files.


S3method

Error: object 'S3method' not found

?S3method

No documentation for 'S3method' in specified packages and libraries:
you could try '??S3method'



I don't understand why S3method is necessary.

My understanding is that we can always use
print.foo(something) {function body} # and appropriate exporting
to replace
S3method(print, foo)
, right?

Or I misunderstand something?



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/O1wO : highlight 0.1-5
|- http://tr.im/O1qJ : Rcpp 0.7.6
`- http://tr.im/NrTG : Rcpp 0.7.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] LinkingTo and C++

[Romain Francois]

Hello,

I've been trying to make LinkingTo work when the package linked to has 
c++ code.


I've put dumb packages to illustrate this emails here ; 
http://addictedtor.free.fr/misc/linkingto


Package A defines this C++ class:

class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;

Package B has this function :

SEXP say_hello(){
A a ;
return a.hello() ;
}

headers of package A are copied into inst/include so that package B can 
have.


LinkingTo: A

in its DESCRIPTION file.

Also, package B has the R function ;

g - function(){
.Call(say_hello, PACKAGE = B)
}

With this I can compile A and B, but then I get :

$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
  /usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch - tryCatchList - tryCatchOne - Anonymous

If I then add a Makevars in B with this :


# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )

PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)


Then it works:

$ Rscript -e B::g()
[1] hello

So it appears that adding the -I flag, which is what LinkingTo does is 
not enough when the package linking from (B) actually has to link to 
the linked to package (A).


I've been looking at 
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines 
but it seems only applicable to c(++) functions and not classes ...


What am I missing ? Should/can linkingto be extended in a way that 
accomodates c++


Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] LinkingTo and C++

[Romain Francois]

On 02/11/2010 10:08 AM, Romain Francois wrote:


Hello,

I've been trying to make LinkingTo work when the package linked to has
c++ code.

I've put dumb packages to illustrate this emails here ;
http://addictedtor.free.fr/misc/linkingto

Package A defines this C++ class:

class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;

Package B has this function :

SEXP say_hello(){
A a ;
return a.hello() ;
}

headers of package A are copied into inst/include so that package B can
have.

LinkingTo: A

in its DESCRIPTION file.

Also, package B has the R function ;

g - function(){
.Call(say_hello, PACKAGE = B)
}

With this I can compile A and B, but then I get :

$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
/usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch - tryCatchList - tryCatchOne - Anonymous

If I then add a Makevars in B with this :


# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )

PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)


Then it works:

$ Rscript -e B::g()
[1] hello

So it appears that adding the -I flag, which is what LinkingTo does is
not enough when the package linking from (B) actually has to link to
the linked to package (A).

I've been looking at
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
but it seems only applicable to c(++) functions and not classes ...

What am I missing ? Should/can linkingto be extended in a way that
accomodates c++

Romain


One other way of course would be to have some lib support, so that for 
example an R library holds not only R packages but shared libraries.


So for example, if as part of package A's Makevars, I copy its A.so into 
R.home( component = lib ) and rename it libA.so :


RLIBDIR=$(shell $(R_HOME)/bin/Rscript -e cat(R.home(component='lib')) )

all: $(SHLIB) install

install:
cp $(SHLIB) $(RLIBDIR)/lib$(SHLIB)
cp -f A.h ../inst/include

Then B can just have this Makevars :

PKG_LIBS=-lA

as well as the LinkingTo: A in the description.

Now I realize that R.home(component='lib') is not the right place where 
to host libA.so, as one might not have rights, etc ... but should there 
be a right place, as a per-R-library lib folder ?


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] LinkingTo and C++

[Romain Francois]

Thanks.

On 02/11/2010 05:55 PM, Simon Urbanek wrote:

Romain,

I think your'e confusing two entirely different concepts here:


Yes. The name LinkingTo probably helped my confusion.


1) LinkingTo: allows a package to provide C-level functions to other packages 
(see R-ext 5.4). Let's say package A provides a function foo by calling 
R_RegisterCCallable for that function. If a package B wants to use that 
function, it uses LinkingTo: and calls R_GetCCallable to obtain the function 
pointer. It does not actually link to package A because that is in general not 
possible - it simply obtains the pointers through R. In addition, LinkingTo: 
makes sure that you have access to the header files of package A which help you 
to cast the functions and define any data structures you may need. Since C++ is 
a superset of C you can use this facility with C++ as long as you don't depend 
on anything outside of the header files.

2) linking directly to another package's shared object is in general not 
possible, because packages are not guaranteed to be dynamic libraries. They are 
usually shared objects which may or may not be compatible with a dynamic 
library on a given platform. Therefore the R-ext describes other way in which 
you may provide some library independently of the package shared object to 
other packages (see R-ext 5.8). The issue is that you have to create a separate 
library (PKG/libs[/arch]/PKG.so won't work in general!) and provide this to 
other packages. As 5.8 says, this is in general not trivial because it is very 
platform dependent and the most portable way is to offer a static library.

To come back to your example, LinkingTo: A and B will work if you remove 
Makevars from B (you don't want to link)and put your hello method into the A.h 
header:


Sure. but in real life I can't realistically put everything in the 
header files.


Thanks again.

Romain


library (B)

Loading required package: A

.Call(say_hello, PACKAGE = B)

[1] hello

However, your'e not really using the LinkingTo: facilities for the functions so 
it's essentially just helping you to find the header file.

Cheers,
Simon



On Feb 11, 2010, at 4:08 AM, Romain Francois wrote:


Hello,

I've been trying to make LinkingTo work when the package linked to has c++ code.

I've put dumb packages to illustrate this emails here ; 
http://addictedtor.free.fr/misc/linkingto

Package A defines this C++ class:

class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;

Package B has this function :

SEXP say_hello(){
A a ;
return a.hello() ;
}

headers of package A are copied into inst/include so that package B can have.

LinkingTo: A

in its DESCRIPTION file.

Also, package B has the R function ;

g- function(){
.Call(say_hello, PACKAGE = B)
}

With this I can compile A and B, but then I get :

$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
  /usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch -  tryCatchList -  tryCatchOne -  Anonymous

If I then add a Makevars in B with this :


# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )

PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)


Then it works:

$ Rscript -e B::g()
[1] hello

So it appears that adding the -I flag, which is what LinkingTo does is not enough when the package 
linking from (B) actually has to link to the linked to package (A).

I've been looking at 
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines 
but it seems only applicable to c(++) functions and not classes ...

What am I missing ? Should/can linkingto be extended in a way that accomodates 
c++

Romain




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] LinkingTo and C++

[Romain Francois]

On 02/11/2010 07:40 PM, Simon Urbanek wrote:



On Feb 11, 2010, at 12:24 PM, Romain Francois wrote:


Thanks.

On 02/11/2010 05:55 PM, Simon Urbanek wrote:

Romain,

I think your'e confusing two entirely different concepts here:


Yes. The name LinkingTo probably helped my confusion.



Admittedly, it's probably not the best name ;).



1) LinkingTo: allows a package to provide C-level functions to other packages 
(see R-ext 5.4). Let's say package A provides a function foo by calling 
R_RegisterCCallable for that function. If a package B wants to use that 
function, it uses LinkingTo: and calls R_GetCCallable to obtain the function 
pointer. It does not actually link to package A because that is in general not 
possible - it simply obtains the pointers through R. In addition, LinkingTo: 
makes sure that you have access to the header files of package A which help you 
to cast the functions and define any data structures you may need. Since C++ is 
a superset of C you can use this facility with C++ as long as you don't depend 
on anything outside of the header files.

2) linking directly to another package's shared object is in general not 
possible, because packages are not guaranteed to be dynamic libraries. They are 
usually shared objects which may or may not be compatible with a dynamic 
library on a given platform. Therefore the R-ext describes other way in which 
you may provide some library independently of the package shared object to 
other packages (see R-ext 5.8). The issue is that you have to create a separate 
library (PKG/libs[/arch]/PKG.so won't work in general!) and provide this to 
other packages. As 5.8 says, this is in general not trivial because it is very 
platform dependent and the most portable way is to offer a static library.

To come back to your example, LinkingTo: A and B will work if you remove 
Makevars from B (you don't want to link)and put your hello method into the A.h 
header:


Sure. but in real life I can't realistically put everything in the header files.



It was just an example based on your example ;) - which was not very realistic, 
either. It practice it is reasonable, because it is sufficient to declare in 
the headers whatever you're providing so the only homework is to cast function 
pointers you have obtained via R_GetCCallable to the declarations from the 
header file.

I suspect what you meant is not as much related to LinkingTo: (since the mess 
C++ creates at the binary level is rather hard to pass through dl pointers - 
but if someone has a working solution it may be worth to create a package), but 
rather to provide a library. That is not covered by R at this point so you're 
in realm of R-ext 5.8. Given how non-trivial task this is (to get it right) it 
may be worthwhile thinking about a portable solution and add it to R, but I 
don't think anyone has done that yet (mainly due to the low benefit/cost ratio 
I suspect). For all cases so far it was sufficient to create C or R level API 
for other package to use.

Cheers,
Simon


Yes. The goal is to provide a library that other packages can just use. 
I thought LinkingTo would help, but now I guess not. or maybe just so 
that B can find headers of A.


The R_RegisterCCallable/R_GetCCallable business seems to be only 
applicable when you are developping both A and B and you deal with plain 
functions, otherwise the name mangling, overloading of methods, etc 
would make the task hard and not fun at all.


So I guess, yes the question is how to reliably and portably provide a 
library for package A so that package B can just use it. This would be 
very valuable.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check error with the GNU Scientific Library

[Romain Francois]

Hi,

You'll need something like :

PKG_LIBS=-lgsl -lgslcblas

in your Makevars.

This is from package gsl (on CRAN). Or maybe you can just depend on the 
gsl package and let it worry about finding where gsl is, etc ...


Romain

On 01/22/2010 10:59 AM, pleyd...@supagro.inra.fr wrote:


I have been working on an R package that calls C code using .C(). I recently
started including some functions from the GNU Scientific Library in my code.
The code runs fine on my machine when not wrapped in the package. But I get the
following error from R CMD check

* checking whether the package can be loaded ... ERROR
Loading required package: splancs
Loading required package: sp

Spatial Point Pattern Analysis Code in S-Plus

  Version 2 - Spatial and Space-Time analysis
Loading required package: ellipse
Loading required package: mvtnorm
Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared library
'/home/david/papers/inProgress/sharka_istanbull/package/sharka.Rcheck/sharka/libs/sharka.so':

/home/david/papers/inProgress/sharka_istanbull/package/sharka.Rcheck/sharka/libs/sharka.so:
undefined symbol: gsl_multimin_fminimizer_nmsimplex
Error in library(sharka) : .First.lib failed for 'sharka'
Execution halted

Clearly there is some difficulty linking up with
gsl_multimin_fminimizer_nmsimplex.

I noticed the QRMlib library also includes gsl functions. In that package they
include a src/gsl directory with the required .h files and in Makevars they
have PKG_CFLAGS = -I./gsl. I have copied this approach, but wonder if using
the standard

R CMD build myPackage
R CMD check myPackage

needs modifying in some way?

All hints or ideas welcome.
Thanks
David



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/KfKn : Rcpp 0.7.2
|- http://tr.im/JOlc : External pointers with Rcpp
`- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] compiler specific flags : -std=c++0x

[Romain Francois]

Hello,

We'd like to use the flag -std=c++0x to take advantage of features of 
the forthcoming C++0x standard that is already partly implemented by the 
GCC = 4.3


R CMD check warns about the flag because it is non portable. Is there a 
way to turn the warning off, considering that we do test that the 
compiler is indeed GCC = 4.3 as part of our configure script and we 
only add the flag in that case.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/KfKn : Rcpp 0.7.2
|- http://tr.im/JOlc : External pointers with Rcpp
`- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] how to call a function from C

[Romain Francois]

Hi,

In Rcpp, we now have a Function class to encapsulate functions (they 
cover all three kinds, but this may change).


To call the function, what we do is generate a call with the function as 
the first node and then evaluate the call.


SEXP stats = PROTECT( R_FindNamespace( mkString( stats) ) );
SEXP rnorm = PROTECT( findVarInFrame( stats, install( rnorm) ) ) ;
SEXP call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10), 
CONS(ScalarReal(0), R_NilValue ) ) ) );

SEXP res = PROTECT( eval( call , R_GlobalEnv ) );
UNPROTECT(4) ;
return res ;

It works, but I was wondering if there was another way. I've seen 
applyClosure, but I'm not sure I should attempt to use it or if using a 
call like above is good enough.


Romain

PS: using Rcpp's C++ classes you would express the code above as :

Environment stats(package:stats) ;
Function rnorm = stats.get( rnorm )
return rnorm( 10, 0.0 ) ;


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/KfKn : Rcpp 0.7.2
|- http://tr.im/JOlc : External pointers with Rcpp
`- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to call a function from C

[Romain Francois]

On 01/14/2010 12:42 PM, Laurent Gautier wrote:

Hi,

In Rcpp, we now have a Function class to encapsulate functions
(they cover all three kinds, but this may change).


Just a note on that: there is probably no hurry to do so.
rpy2 is also having CLOSXP, BUILTINSXP, and SPECIALSXP represented as
one function-like class and seems to be behave reasonably while a lot of
other things seem more urgent to sort out.


To call the function, what we do is generate a call with the function
as the first node and then evaluate the call.

SEXP stats = PROTECT( R_FindNamespace( mkString( stats) ) ); SEXP
rnorm = PROTECT( findVarInFrame( stats, install( rnorm) ) ) ; SEXP
call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10),
CONS(ScalarReal(0), R_NilValue ) ) ) ); SEXP res = PROTECT( eval(
call , R_GlobalEnv ) ); UNPROTECT(4) ; return res ;

It works, but I was wondering if there was another way. I've seen
applyClosure, but I'm not sure I should attempt to use it or if using
a call like above is good enough.


Using R_tryEval() will let you evaluate an expression in a given
environment, as well as capture an eventual error occurring during its
evaluation (and translate it as an exception).


Sure. I did not want to over-complicate the question.

I'm currently reviewing tryEval and its underlying R_TopLevelExec which 
does not give me enough : when the error occurs, it'd be useful that the 
function returns the condition object instead of NULL.



Romain

PS: using Rcpp's C++ classes you would express the code above as :

Environment stats(package:stats) ; Function rnorm = stats.get(
rnorm ) return rnorm( 10, 0.0 ) ;


Feel free to snoop in rpy2's rpy/rinterface/rinterface.c and look for
do_try_eval. The behavior looks very similar, the above snippet in
rpy2 would write like:

from rpy2.robjects.packages import importr
stats = importr('stats')
stats.rnorm(10, 0.0)


nice

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/KfKn : Rcpp 0.7.2
|- http://tr.im/JOlc : External pointers with Rcpp
`- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to call a function from C

[Romain Francois]

On 01/14/2010 03:50 PM, Dominick Samperi wrote:

The Rcpp library in RcppTemplate (the package that Rcpp forked from)
simplifies the process
of calling functions from C++. The design goal was to enable users to
focus on
scientific problem solving rather than interface problems and low-level
R internals (by
hiding these details and documenting everything).


Hello Dominick,

In the Rcpp package, you'd call the rnorm function like this :

/* grab the environment called package:stats */
Environment stats(package:stats) ;
/* or like this if you want the namespace */
/* Environment stats = Environment::namespace_env(stats) ;*/

/* grab function called 'rnorm' from this environment */
Function rnorm = stats.get(rnorm ) ;

/* call the function, about the same way you'd do in R
 *
 *  rnorm( 10L, sd = 100 )
 */
return rnorm( 10, Named( sd, 100.0 ) ) ;

All involved SEXP are encapsulated in suitable C++ objects, such as 
Environment, Function, etc ... the user does not need to know about 
SEXP, does not need to care about the PROTECT/UNPROTECT dance, etc ...


Please let me know which of these three lines of C++ code you consider 
to be low level R internals.


It might be interesting that you post how you would invoke the same 
using RcppTemplate.



The current Rcpp package is a mashup of the packages RcppTemplate (old
version),
inline, and RInside


It is not anything even kind of close to that.

There was code from the inline package at some point, but it is now back 
into inline, which has been improved to support easy inlining of code 
making use of Rcpp.


There is nothing of RInside in Rcpp, it goes the other way, RInside 
depends on Rcpp and uses its features to ease embedding R into an 
existing C++ application


The Rcpp package is under a lot of changes. See :
- http://dirk.eddelbuettel.com/blog/2010/01/12/#rcpp_0.7.2
- http://dirk.eddelbuettel.com/blog/2010/01/02/#rcpp_0.7.1
- 
http://romainfrancois.blog.free.fr/index.php?post/2010/01/13/Rcpp-0.7.2-is-out
- 
http://romainfrancois.blog.free.fr/index.php?post/2010/01/08/External-pointers-with-Rcpp
- 
http://romainfrancois.blog.free.fr/index.php?post/2009/12/29/new-things-in-Rcpp



that involves a fair amount of low-level R hacking,
and this is
probably consistent with the preferences of most readers of this list.


Can you be more specific ?

The whole purpose of the package is to hide the R API. The user does not 
need to know the R API to use the classes of Rcpp. We however indeed use 
and abuse the R API a lot internally.


Romain


If I am mistaken and there are any users of RcppTemplate please let me
know, as I
am thinking about reoganizing that package to minimize confusion with
the fork.

Thanks,
Dominick

On Thu, Jan 14, 2010 at 7:16 AM, Romain Francois
romain.franc...@dbmail.com mailto:romain.franc...@dbmail.com wrote:

On 01/14/2010 12:42 PM, Laurent Gautier wrote:

Hi,

In Rcpp, we now have a Function class to encapsulate functions
(they cover all three kinds, but this may change).


Just a note on that: there is probably no hurry to do so.
rpy2 is also having CLOSXP, BUILTINSXP, and SPECIALSXP
represented as
one function-like class and seems to be behave reasonably while
a lot of
other things seem more urgent to sort out.

To call the function, what we do is generate a call with the
function
as the first node and then evaluate the call.

SEXP stats = PROTECT( R_FindNamespace( mkString( stats) )
); SEXP
rnorm = PROTECT( findVarInFrame( stats, install( rnorm) )
) ; SEXP
call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10),
CONS(ScalarReal(0), R_NilValue ) ) ) ); SEXP res = PROTECT(
eval(
call , R_GlobalEnv ) ); UNPROTECT(4) ; return res ;

It works, but I was wondering if there was another way. I've
seen
applyClosure, but I'm not sure I should attempt to use it or
if using
a call like above is good enough.


Using R_tryEval() will let you evaluate an expression in a given
environment, as well as capture an eventual error occurring
during its
evaluation (and translate it as an exception).


Sure. I did not want to over-complicate the question.

I'm currently reviewing tryEval and its underlying R_TopLevelExec
which does not give me enough : when the error occurs, it'd be
useful that the function returns the condition object instead of NULL.


Romain

PS: using Rcpp's C++ classes you would express the code
above as :

Environment stats(package:stats) ; Function rnorm = stats.get(
rnorm ) return rnorm( 10, 0.0 ) ;


Feel free to snoop in rpy2's rpy/rinterface/rinterface.c and
look for
do_try_eval. The behavior looks very similar, the above

Re: [Rd] how to call a function from C

[Romain Francois]

On 01/14/2010 02:27 PM, Laurent Gautier wrote:


On 1/14/10 1:16 PM, Romain Francois wrote:

On 01/14/2010 12:42 PM, Laurent Gautier wrote:

Hi,

In Rcpp, we now have a Function class to encapsulate functions
(they cover all three kinds, but this may change).


Just a note on that: there is probably no hurry to do so.
rpy2 is also having CLOSXP, BUILTINSXP, and SPECIALSXP represented as
one function-like class and seems to be behave reasonably while a lot of
other things seem more urgent to sort out.


To call the function, what we do is generate a call with the function
as the first node and then evaluate the call.

SEXP stats = PROTECT( R_FindNamespace( mkString( stats) ) ); SEXP
rnorm = PROTECT( findVarInFrame( stats, install( rnorm) ) ) ; SEXP
call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10),
CONS(ScalarReal(0), R_NilValue ) ) ) ); SEXP res = PROTECT( eval(
call , R_GlobalEnv ) ); UNPROTECT(4) ; return res ;

It works, but I was wondering if there was another way. I've seen
applyClosure, but I'm not sure I should attempt to use it or if using
a call like above is good enough.


Using R_tryEval() will let you evaluate an expression in a given
environment, as well as capture an eventual error occurring during its
evaluation (and translate it as an exception).


Sure. I did not want to over-complicate the question.

I'm currently reviewing tryEval and its underlying R_TopLevelExec which
does not give me enough : when the error occurs, it'd be useful that the
function returns the condition object instead of NULL.


I possibly went the same path, and ended with R_tryEval. When looking at
it, I could not figure out any way to get what I wanted outside using
geterrmessage in base.
The error string is in the variable errbuf (in src/main/error.c), with
no obvious route to access it (and if truly no route, this might be
something missing from the R C-API).


It seems to be the regular way around this gap. Martin Morgan gave the 
same advice (using geterrmessage) here last week. it only gives you the 
error message though


I've been staring at R_ToplevelExec, begincontext and addCondHands. Some 
day, I'll understand how to connect the dots. Not today though.


Romain


Romain

PS: using Rcpp's C++ classes you would express the code above as :

Environment stats(package:stats) ; Function rnorm = stats.get(
rnorm ) return rnorm( 10, 0.0 ) ;


Feel free to snoop in rpy2's rpy/rinterface/rinterface.c and look for
do_try_eval. The behavior looks very similar, the above snippet in
rpy2 would write like:p/


I meant do_eval_expr.


thanks.


from rpy2.robjects.packages import importr
stats = importr('stats')
stats.rnorm(10, 0.0)


nice



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/KfKn : Rcpp 0.7.2
|- http://tr.im/JOlc : External pointers with Rcpp
`- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Is nested namespace supported?

[Romain Francois]

On 01/09/2010 09:53 PM, Peng Yu wrote:


Could somebody let me know if there is nested name space supported?
For example, is it possible to define a function in the name space
'nested_namespace' which is nested in the name space 'some_namespace'?

some_namespace:::nested_namespace:::a_function()

I checked Section 1.6 of R-exts.pdf. It seems that nested namespace is
not supported, right?


It is not even grammatically valid:

 parse( text = foo::bar::foobar )
Error in parse(text = foo::bar::foobar) :
  unexpected '::' in foo::bar::

 parse( text = foo:::bar:::foobar )
Error in parse(text = foo:::bar:::foobar) :
  unexpected ':::' in foo:::bar:::

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/JOlc : External pointers with Rcpp
|- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009
`- http://tr.im/IW9B : C++ exceptions at the R level

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R object protection [Was: R-devel Digest, Vol 83, Issue 2]

[Romain Francois]

 the object
 x - new( CPP(setint) )
 # insert data using the insert method
 x$insert( sample( 1:20, size = 50, replace = TRUE ) )
 # ask for the size of the set
 x$size()
[1] 17
 # bring it back as an R classic integer vector
 # see how it comes back sorted and unique (which is set's job)
 as.vector(x)
 [1]  1  3  4  6  7  8  9 10 11 12 13 14 15 17 18 19 20


no magic however since C++ reflection capabilities are very limited, 
well some magic based on the brew package.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IW9B : C++ exceptions at the R level
|- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R_PreserveObject, R_ReleaseObject : reference counting needed ?

[Romain Francois]

Hello,

We are currently making lots of changes to Rcpp (see the open Rcpp 
mailing list if interested [1] in the details).


We are now using [2] R_PreserveObject and R_ReleaseObject to manage 
garbage collection instead of the PROTECT/UNPROTECT dance. This seems to 
work well, but I was wondering if there was documentation about it.


In particular, if we preserve the same SEXP twice (or more), should we 
implement some sort of reference counting ?


Reading the source (below, from memory.c) I think not, but some 
confirmation would help.


void R_PreserveObject(SEXP object)
{
R_PreciousList = CONS(object, R_PreciousList);
}

static SEXP RecursiveRelease(SEXP object, SEXP list)
{
if (!isNull(list)) {
if (object == CAR(list))
return CDR(list);
else
CDR(list) = RecursiveRelease(object, CDR(list));
}
return list;
}

void R_ReleaseObject(SEXP object)
{
R_PreciousList =  RecursiveRelease(object, R_PreciousList);
}


I'd also be interested if there is some ideas on the relative efficiency 
of the preserve/release mechanism compared to PROTECT/UNPROTECT.


Thanks,

Romain

[1] http://lists.r-forge.r-project.org/pipermail/rcpp-devel/
[2] 
http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255root=rcppview=markup


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IW9B : C++ exceptions at the R level
|- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_PreserveObject, R_ReleaseObject : reference counting needed ?

[Romain Francois]

Thanks.

On 01/02/2010 05:36 PM, Laurent Gautier wrote:


[Disclaimer: what is below reflects my understanding from reading the R
source, others will correct where deemed necessary]

On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote:


Hello,

We are currently making lots of changes to Rcpp (see the open Rcpp
mailing list if interested [1] in the details).

We are now using [2] R_PreserveObject and R_ReleaseObject to manage
garbage collection instead of the PROTECT/UNPROTECT dance. This seems to
work well, but I was wondering if there was documentation about it.


The most precise technical documentation is in memory.c
PROTECT is an alias for Rf_protect, itself an alias for
SEXP protect(SEXP s);
and uses a stack (R_PPStack) to store protected objects.


In particular, if we preserve the same SEXP twice (or more), should we
implement some sort of reference counting ?


This depends on the requirements for your system.


We wrap up SEXP into a C++ class that in particular manages itself 
preserving and releasing the object to garbage collection.



For example, in rpy2 I added a reference counting layer(*) because I
wanted to allow several Python objects to share the same underlying R
object, but that's not currently(*) counting how many times an object
should be freed.
(*: imperfect, but currently doing a very decent job - details upon
request).

That kind of feature could be provided by R's C-level API, since this
could be seen of general use as well as give an opportunity to improve
the performances of the R_PreservedObject/R_ReleaseObject duo whenever a
lot of objects are protected and/or external code is
protecting/releasing objects through a FIFO proxy.



Reading the source (below, from memory.c) I think not, but some
confirmation would help.


I understand the code in memory.c like an object preserved twice needs
to be freed twice: R_PreciousList is just a (linked) list, and
R_PreserveObject(object) adds the object to the beginning of the list
while R_ReleaseObject(object) removes the first object found from
the list.


That's what I understand of it too. It fits nicely into C++ assignment 
operator and copy constructor.



void R_PreserveObject(SEXP object)
{
R_PreciousList = CONS(object, R_PreciousList);
}

static SEXP RecursiveRelease(SEXP object, SEXP list)
{
if (!isNull(list)) {
if (object == CAR(list))
return CDR(list);
else
CDR(list) = RecursiveRelease(object, CDR(list));
}
return list;
}

void R_ReleaseObject(SEXP object)
{
R_PreciousList = RecursiveRelease(object, R_PreciousList);
}


I'd also be interested if there is some ideas on the relative efficiency
of the preserve/release mechanism compared to PROTECT/UNPROTECT.


PROTECT/UNPROTECT is trading granularity for speed. It is a stack with
only tow operations possible:
- push 1 object into the stack
- pull (unprotect) N last objects from the stack


HTH,


L.





Thanks,

Romain

[1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/
[2]
http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255root=rcppview=markup


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IW9B : C++ exceptions at the R level
|- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel