[Rcpp-devel] release 0.7.1 ?

Romain François francoisromain at free.fr
Fri Jan 1 18:41:27 CET 2010

On 01/01/2010 06:13 PM, Dirk Eddelbuettel wrote:
> On 1 January 2010 at 09:35, Romain François wrote:
> | Hello,
> |
> | I've commited the two last items I wanted to commit into the new API:
> |
> | - protect has been reworded to preserve to avoid confusion with
> | PROTECT/UNPROTECT. I might add protect/unprotect methods later to allow
> | PROTECT/UNPROTECT protection
> Cool.
> | - I've removed many constructors RObject::RObject and replaced them with
> | the set of functions Rcpp::wrap, taking the same arguments and returning
> | instances of RObject. The idea is that these constructors do not pollute
> | classes that inherit from RObject, and also later when we have a more
> | complete API, we can have for example
> |
> | Rcpp::Double Rcpp::wrap( const double&  d )
> |
> | Double being an extension of RObject dealing specifically with double
> | vectors, in which we'll have for example operator[] and iterators so
> | that we can apply STL algorithms to R vectors.
> |
> | but before that we need to release.
> |
> | Are you happy with Rcpp::wrap or should it be something else. I do not
> | mind, but we need to decide before we release. To reduce typing it does
> | not even need to be in the Rcpp namespace.
> I haven't had a time to look at it in detail. It is sleek in the example I
> just adapted to illustrate namespaces.  But what I dislike is that just
> yesterday I managed to get back to the example from the Dec 20 blog post:
>          int seed = RcppSexp(s).asInt();
> That worked with the typedef.  I think that we owe "our users" more constant
> behaviour in released interface.  Right now wrap() replaces this (and is
> arguably nicer) -- but should we not keep the old stuff?

Eventually RObject should have only the SEXP constructor, but we can 
slowly deprecate it.

Do you think the constructors should be back on RObject and keep the 
typedef or code bloat RcppSexp so that its interface looks like the one 
in 0.7.0, but leaving RObject as it is now. Slightly more work, but I 
prefer this.

> | Also, maybe the typedef RcppSexp is not good enough anymore, should I
> | recreate a class RcppSexp with all constructors to keep backwards
> | compatibility.
> Ahhh yes. Had I read your email to the end before starting to reply ... :)
> I think we should, even though it is code bloat.  But we introduced RcppSexp,
> so now we are 'stuck' with it.  Can you whip the old interface back in?
> | I'm starting to work on what will go in 0.7.2 but I won't commit until
> | release.
> Ok. There is no chance you will ever stop will you?
> Dirk

I don't know. Same thing happened when Simon invited me to commit to 
rJava. I had a good month where I was coding like the wind in rJava, and 
then less now.

Today I've added some constructors to Environment

      * Gets the environment associated with the given name
      * @param name name of the environment, e.g "package:Rcpp"
     Environment( const std::string& name ) throw(no_such_env) ;

      * Gets the environment in the given position of the search path
      * @param pos (1-based) position of the environment, e.g pos=1 
gives the
      *        global environment
     Environment( int pos ) throw(no_such_env) ;

I have a Symbol class that wraps up SYMSXP, xo that we can do : 
Symbol("rnorm") instead of the cryptic Rf_install("rnorm")

and I am working on a Language class to wrap calls.

also thinking about sort sort of template like this (not clear yet)

template <typename T> T as( SEXP x)

so that we could o things like:

int x = as<int>( y ) ;

where y is a SEXP that can be converted to int, this combined with the 
operator SEXP() also means that x can be any RObject.

OTOH, I'm back at actual work on monday, so things will slow down.


Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
|- 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

More information about the Rcpp-devel mailing list