from:"romain"

Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :

 I'd like to raise a condition other than error or warning. Is that possible 
 using the Rcpp api? I assume this can be done via R internals, but I'd prefer 
 not to call error() directly (or is that the recommendation?).
 
 THK

Definitely not. Rf_error should really only be called from C code. If you call 
it from C++, there is a great chance you'll lose determinism as destructors for 
your c++ objects are very likely not to be called. Most of the time, it will 
just mean you'll never release some objects to the garbage collector, but it 
could also get you leaks or other nice stuff depending on what your destructors 
were supposed to do and did not get a chance to do.  

I'm not sure Rcpp has a way to raise an R condition apart from calling stop, 
which usually is good enough. Otherwise, you can borrow from Rcpp11 and adapt 
some code from 
https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h

Romain___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Raise a condition

Le 19 juin 2014 à 00:15, Tim Keitt tke...@utexas.edu a écrit :

On Wed, Jun 18, 2014 at 5:07 PM, Romain Francois rom...@r-enthusiasts.com
wrote:
Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :

I'd like to raise a condition other than error or warning. Is that possible
using the Rcpp api? I assume this can be done via R internals, but I'd
prefer not to call error() directly (or is that the recommendation?).

THK

Definitely not. Rf_error should really only be called from C code. If you
call it from C++, there is a great chance you'll lose determinism as
destructors for your c++ objects are very likely not to be called. Most of
the time, it will just mean you'll never release some objects to the garbage
collector, but it could also get you leaks or other nice stuff depending on
what your destructors were supposed to do and did not get a chance to do.

That was my understanding. Just wanted to be sure it was still the case.

I'm not sure Rcpp has a way to raise an R condition apart from calling stop,
which usually is good enough. Otherwise, you can borrow from Rcpp11 and adapt
some code from
https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h

Ah. I see. Eval stop in the global env with the condition as the argument.
Clever.

It is more of a hack due to lack of proper api from R.

If you do this, make sure you don't have any c++ object in scope. Essentially
that means you would evaluate `stop( condition )` in a top level catch block. ___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Raise a condition

Le 19 juin 2014 à 00:30, Tim Keitt tke...@utexas.edu a écrit :

On Wed, Jun 18, 2014 at 5:22 PM, Romain Francois rom...@r-enthusiasts.com
wrote:
Le 19 juin 2014 à 00:15, Tim Keitt tke...@utexas.edu a écrit :

On Wed, Jun 18, 2014 at 5:07 PM, Romain Francois rom...@r-enthusiasts.com
wrote:
Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :

THK

That was my understanding. Just wanted to be sure it was still the case.

I'm not sure Rcpp has a way to raise an R condition apart from calling stop,
which usually is good enough. Otherwise, you can borrow from Rcpp11 and
adapt some code from
https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h

Ah. I see. Eval stop in the global env with the condition as the argument.
Clever.

It is more of a hack due to lack of proper api from R.

If you do this, make sure you don't have any c++ object in scope. Essentially
that means you would evaluate `stop( condition )` in a top level catch block.

Rcpp objects are I assume ok however.

Depends what you mean by ok. If you mean objects like NumericVector, ...
their destructor is responsible for calling R_ReleaseObject, i.e. let go of the
protection that was set by their constructor. If the destructor is not called
because R error handling does a long jump, you will get objects forever
protected.

So things will seemingly work, until you exhaust the memory.

I will try signalCondition and see what happens.

THK

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Raise a condition


Le 19 juin 2014 à 01:02, Tim Keitt tke...@utexas.edu a écrit :

 
 
 
 On Wed, Jun 18, 2014 at 5:37 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 19 juin 2014 à 00:30, Tim Keitt tke...@utexas.edu a écrit :
 
 On Wed, Jun 18, 2014 at 5:22 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 19 juin 2014 à 00:15, Tim Keitt tke...@utexas.edu a écrit :
 
 
 
 On Wed, Jun 18, 2014 at 5:07 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :
 
 
 I'd like to raise a condition other than error or warning. Is that 
 possible using the Rcpp api? I assume this can be done via R internals, 
 but I'd prefer not to call error() directly (or is that the 
 recommendation?).
 
 THK
 
 Definitely not. Rf_error should really only be called from C code. If you 
 call it from C++, there is a great chance you'll lose determinism as 
 destructors for your c++ objects are very likely not to be called. Most of 
 the time, it will just mean you'll never release some objects to the 
 garbage collector, but it could also get you leaks or other nice stuff 
 depending on what your destructors were supposed to do and did not get a 
 chance to do.  
 
 That was my understanding. Just wanted to be sure it was still the case.
  
 
 I'm not sure Rcpp has a way to raise an R condition apart from calling 
 stop, which usually is good enough. Otherwise, you can borrow from Rcpp11 
 and adapt some code from 
 https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h
 
 Ah. I see. Eval stop in the global env with the condition as the 
 argument. Clever.
 
 It is more of a hack due to lack of proper api from R. 
 
 If you do this, make sure you don't have any c++ object in scope. 
 Essentially that means you would evaluate `stop( condition )` in a top level 
 catch block. 
 
 Rcpp objects are I assume ok however.
 
 Depends what you mean by ok. If you mean objects like NumericVector, ... 
 their destructor is responsible for calling R_ReleaseObject, i.e. let go of 
 the protection that was set by their constructor. If the destructor is not 
 called because R error handling does a long jump, you will get objects 
 forever protected. 
 
 So things will seemingly work, until you exhaust the memory. 
 
 I will try signalCondition and see what happens.
 
 THK
 
 
 I can't get signalCondition to do anything.

What exactly did you try ? Did you catch the condition at the R level, with 
withCallingHandlers or something. Just because you don't see something does not 
mean nothing happens. 

 This works although I've not tested it for leaks.

Easy enough to test for forgotten destructors. 

#include Rcpp.h
using namespace Rcpp; 

void raise_condition(const std::string msg,
 const std::string type)
{
  List cond;
  cond[message] = msg;
  cond[call] = R_NilValue;
  cond.attr(class) = CharacterVector::create(type, condition);
  Function stopper(stop);
  stopper(cond);
}

class A {
   public:
   A(){ Rprintf( A::A()\n ) ; }
   ~A(){ Rprintf( A::~A()\n ) ; }
} ;


// [[Rcpp::export]]
void test(){
A a ;
raise_condition( foo, bar) ;  
}

/*** R
test()
*/

which gives me:

 test()
A::A()
Error: foo

So the destructor for A is never called. Not a big deal here, it was not doing 
anything. But might be more problematic elsewhere. 

 void raise_condition(const std::string msg,
  const std::string type)
 {
   List cond;
   cond[message] = msg;
   cond[call] = R_NilValue;
   cond.attr(class) = CharacterVector::create(type, condition);
   Function stopper(stop);
   stopper(cond);
 }
 
 THK
 
 -- 
 http://www.keittlab.org/

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Raise a condition


Le 19 juin 2014 à 03:05, Dirk Eddelbuettel e...@debian.org a écrit :

 
 On 18 June 2014 at 19:40, Tim Keitt wrote:
 | 
 | 
 | 
 | On Wed, Jun 18, 2014 at 6:26 PM, Dirk Eddelbuettel e...@debian.org wrote:
 | 
 | 
 | Tim,
 | 
 | Step back for a second and recognise that everything happens via
 | 
 |SEXP .Call(SEXP a, SEXP b, ...)
 | 
 | where R calls your C++ routine asynchronously.
 | 
 | You can do tricks _within the subroutine that is called_ which is
 | essentially
 | what happens via the automatically-added try/catch block we have in C++.
 |  And
 | Rcpp::stop() is just a shortcut for using those.
 | 
 | 
 | Can I throw a condition (meaning an object inheriting class condition) or 
 am
 | I limited to strings? If I throw a condition, will it be raised as such?
 
 See eg Section 2.7 titled Exception Handling in my Springer book on Rcpp.
 This is standard stuff, and we discussed the basics in the 2011 JSS paper.
 
 You can throw anything that is subclassed from std::exception, and catch it
 appropriately.  The default mechanism is to take the exception text and pass
 it to R -- because, once again, passing a string is all we can do.  _Your_
 code could course provide more complex things and keep them, and tickle (by
 error codes) retrieval via other functions.
 
 But again, the interface we are given by R is fixed.  You can only be
 creative within the confines of that interface.

Would be relatively easy to add an overload to stop
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/exceptions.h#L195

so that it handles other things besides strings. 

The confines of the R interface is not the problem here. 


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Using spatstat in Rcpp

2014-06-11 Thread Romain François

Hello, 

You seem to be confusing R namespaces and C++ namespaces and assuming you can 
call an R function as if it belonged to a C++ namespace. 
R functions and c++ functions are different things. 

You can do something like: 

// get the spatstat environment
Environment spatstat( package:spatstat ) ;

// get the discpartarea function from that env
Function discpartarea = spatstat[discpartarea];

Then you can call discpartarea. 

Romain

Le 11 juin 2014 à 19:01, mohammad ghorbani ghorbani...@yahoo.com a écrit :

 Hi there,
 
 I would like to call discpartarea() and as.owin() functions of spatstat from 
 Rcpp. In a simple example 
 consider the following C++ code in which I'm trying to access the above  
 functions:
 
 #include Rcpp.h
 using namespace Rcpp;
 
 // [[Rcpp::export]]
 NumericVector IndepSelfCortCpp( NumericMatrix obsu) {
   NumericMatrix obsxy = obsu( _ , Range(1,2) ) ;
   NumericVector xyW= NumericVector::create(0,56,0,38);
   double rslt = 0; 
   
 rslt= spatstat::discpartarea(obsxy, 0.1, spatstat::as.owin(xyW));
   
 return (rslt);
 }
 /* ** R
 obsu - matrix(c(0.5, 1.5, 4, 12, 1,2,3,4,2,3,5,7), ncol=3)
 IndepSelfCortCpp(obsu)
 */
 
 When I source the file in Rstudio with  sourceCpp(), I get the error:
  'spatstat' has not been declard 
 
 I was wondering, a direct call  a function of an R package like spatstat is 
 possible from Rcpp.
 If yes, Could anyone help me on debugging the code? 
 
 Best Regards,
 Mohammad Ghorbani
 
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Speed up of the data.frame creation in DataFrame.h

2014-06-07 Thread Romain François


Le 7 juin 2014 à 03:27, Dmitry Nesterov dmitry.neste...@gmail.com a écrit :

 Hello,
 Here I report the slowness in creation of Rcpp DataFrame objects and proposed 
 change to speed it up.
 For system information, here is output from sessionInfo():
 R version 3.1.0 (2014-04-10)
 Platform: x86_64-apple-darwin13.1.0 (64-bit)
 ...
 other attached packages:
 [1] microbenchmark_1.3-0 Rcpp_0.11.1 
 
 I am using Rcpp package to port my old functions written with R's C interface 
 to a more convenient style of Rcpp.
 While writing code that creates data.frame’s, I noticed that the Rcpp-based 
 code was running quite a bit slower (using microbenchmark package) than my 
 old implementation. The difference was approximately 40(!) times slower for 
 data frame 50x2 (row x col)
 
 I have narrowed the speed difference down to the following call:
 
return Rcpp::DataFrame::create(Rcpp::Named(“xdata”)=x,
   Rcpp::Named(“ydata”)=y);
 
 Where x and y are Rcpp::NumericVector objects.
 By debugging through the code and Rcpp, I noticed that during the creation 
 Rcpp uses “as.data.frame” conversion on the vector list that contained x, y 
 vectors and their names “xdata” and “ydata”, while this step was not 
 necessary in my previous code using C interface.

Well, how then do you guarantee that the data frame is not corrupt ?

Consider this code: 

#include Rcpp.h
using namespace Rcpp ;

// [[Rcpp::export]]
DataFrame test(){
  NumericVector x = NumericVector::create( 1, 2, 3, 4 ) ;
  NumericVector y = NumericVector::create( 1, 2 ) ;
  return DataFrame::create(_[x] = x, _[y] = y ) ;
}

The benefit of calling as.data.frame is that it would handle recycling y 
correctly. 

Just setting the class attribute to data.frame by brute force would make a 
corrupt data frame. Perhaps you can get your suggestion approved on the basis 
of being consistent with other ways to get corrupt data frames in Rcpp. 
https://github.com/RcppCore/Rcpp/issues/144 

The basic idea is valid, but this would need more work and understanding of the 
conceptual requirements of a data frame. 

Romain


 In Rcpp/DataFrame.h:87
   static DataFrame_Impl from_list( Parent obj ){
 This in turn calls on line 104:
return DataFrame_Impl(obj) ;
 and which ultimately calls on line 78:
void set__(SEXP x){
if( ::Rf_inherits( x, data.frame )){
Parent::set__( x ) ;
} else{
SEXP y = internal::convert_using_rfunction( x, as.data.frame 
 ) ;
Parent::set__( y ) ;
}
}
 Since the DataFrame::create() function has not set a class attribute to 
 “data.frame” by far, the conversion “as.data.frame” takes place and slows 
 down the creation of the final object.
 I propose to make change on line 103 to set class attribute to “data.frame”, 
 so no further conversion will take place:
if( use_default_strings_as_factors ) {
Rf_setAttrib(obj, R_ClassSymbol, Rf_mkString(data.frame));
return DataFrame_Impl(obj) ;
}
 
 I tested it and it brought the speed of execution of the function to about 
 the same as it was before with plain C API.
 Please let me know if it makes sense or maybe I should use 
 DataFrame::create() function differently.
 
 Best,
 Dmitry
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Speed up of the data.frame creation in DataFrame.h

2014-06-07 Thread Romain François

Hello, 

I was merely pointing out the problem. People who maintain and contribute to 
Rcpp will tell you what they expect. I am no longer one of them. So I don’t 
really care either way, unless it starts adding a bug that will cause issues 
for software I’m involved with that still has to depend on Rcpp for reasons out 
of my control.

On a general note, I’d argue that it makes sense to submit the pull request 
anyway as it creates a special place where you can discuss the proposal, and it 
triggers continuous testing, so that travis will tell you if you break 
something. 

Romain

Le 7 juin 2014 à 14:35, Dmitry Nesterov dmitry.neste...@gmail.com a écrit :

 Hello Romain,
 maybe then another function, like force_create() could be available? Or some 
 checks for equal number of elements in each vector.
 One of the main Rcpp advantages to the user is its flexibility and speed, 
 compared to the plain R code.
 I am not sure at this point what solution would be the best, but having fast 
 methods in Rcpp would be really great.
 Should I wait then before submitting the pull request?
 Dmitry
 
 On Jun 7, 2014, at 7:21 AM, Romain François rom...@r-enthusiasts.com wrote:
 
 
 Le 7 juin 2014 à 03:27, Dmitry Nesterov dmitry.neste...@gmail.com a écrit :
 
 Hello,
 Here I report the slowness in creation of Rcpp DataFrame objects and 
 proposed change to speed it up.
 For system information, here is output from sessionInfo():
 R version 3.1.0 (2014-04-10)
 Platform: x86_64-apple-darwin13.1.0 (64-bit)
 ...
 other attached packages:
 [1] microbenchmark_1.3-0 Rcpp_0.11.1 
 
 I am using Rcpp package to port my old functions written with R's C 
 interface to a more convenient style of Rcpp.
 While writing code that creates data.frame’s, I noticed that the Rcpp-based 
 code was running quite a bit slower (using microbenchmark package) than my 
 old implementation. The difference was approximately 40(!) times slower for 
 data frame 50x2 (row x col)
 
 I have narrowed the speed difference down to the following call:
 
   return Rcpp::DataFrame::create(Rcpp::Named(“xdata”)=x,
  Rcpp::Named(“ydata”)=y);
 
 Where x and y are Rcpp::NumericVector objects.
 By debugging through the code and Rcpp, I noticed that during the creation 
 Rcpp uses “as.data.frame” conversion on the vector list that contained x, y 
 vectors and their names “xdata” and “ydata”, while this step was not 
 necessary in my previous code using C interface.
 
 Well, how then do you guarantee that the data frame is not corrupt ?
 
 Consider this code: 
 
 #include Rcpp.h
 using namespace Rcpp ;
 
 // [[Rcpp::export]]
 DataFrame test(){
  NumericVector x = NumericVector::create( 1, 2, 3, 4 ) ;
  NumericVector y = NumericVector::create( 1, 2 ) ;
  return DataFrame::create(_[x] = x, _[y] = y ) ;
 }
 
 The benefit of calling as.data.frame is that it would handle recycling y 
 correctly. 
 
 Just setting the class attribute to data.frame by brute force would make a 
 corrupt data frame. Perhaps you can get your suggestion approved on the 
 basis of being consistent with other ways to get corrupt data frames in 
 Rcpp. 
 https://github.com/RcppCore/Rcpp/issues/144 
 
 The basic idea is valid, but this would need more work and understanding of 
 the conceptual requirements of a data frame. 
 
 Romain
 
 
 In Rcpp/DataFrame.h:87
  static DataFrame_Impl from_list( Parent obj ){
 This in turn calls on line 104:
   return DataFrame_Impl(obj) ;
 and which ultimately calls on line 78:
   void set__(SEXP x){
   if( ::Rf_inherits( x, data.frame )){
   Parent::set__( x ) ;
   } else{
   SEXP y = internal::convert_using_rfunction( x, 
 as.data.frame ) ;
   Parent::set__( y ) ;
   }
   }
 Since the DataFrame::create() function has not set a class attribute to 
 “data.frame” by far, the conversion “as.data.frame” takes place and slows 
 down the creation of the final object.
 I propose to make change on line 103 to set class attribute to 
 “data.frame”, so no further conversion will take place:
   if( use_default_strings_as_factors ) {
   Rf_setAttrib(obj, R_ClassSymbol, Rf_mkString(data.frame));
   return DataFrame_Impl(obj) ;
   }
 
 I tested it and it brought the speed of execution of the function to about 
 the same as it was before with plain C API.
 Please let me know if it makes sense or maybe I should use 
 DataFrame::create() function differently.
 
 Best,
 Dmitry
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] table, rev and missing names

2014-06-06 Thread Romain François

Hello, 

You pretty much have to do this manually. rev is part of Rcpp sugar. Defined 
here:
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/sugar/functions/rev.h

It does not preserve names. That’s by design. It would have been very difficult 
to do it automatically, i.e. what happens here: rev( x * y ), etc … it is hard 
to decide which names to propagate, harder to try to follow R rules about it, 
and even harder to implement. 

So if you want names, you have to handle them yourself. 

Romain

Le 6 juin 2014 à 12:58, Sven E. Templer sven.temp...@gmail.com a écrit :

 Hi,
 
 consider this code:
 
 
 require(Rcpp)
 require(inline)
 t - cxxfunction(sig=c(xx=character), plugin=Rcpp, body='
 CharacterVector x(xx);
 IntegerVector t = table(x);
 return t;')
 r - cxxfunction(sig=c(xx=character), plugin=Rcpp, body='
 CharacterVector x(xx);
 IntegerVector t = table(x);
 IntegerVector r = rev(t);
 return r;')
 o - cxxfunction(sig=c(xx=character), plugin=Rcpp, body='
 CharacterVector x(xx);
 IntegerVector t = table(x);
 CharacterVector n = t.names();
 IntegerVector r = rev(t);
 r.names() = rev(n);
 return r;')
 t(c('a','a','b',NA))
 r(c('a','a','b',NA))
 o(c('a','a','b',NA))
 
 
 Reversed vectors loose their name ( t() vs r() ) and have to be copied
 and reversed 'manually' ( as in o() ). Is rev() a function declared by
 Rcpp, if so can names be reserved while reverting or is there any
 other easier solution than in o() ?
 
 Thank you!
 Sven
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp release candidate

2014-06-05 Thread Romain François

Watch out for this part: 

Le 5 juin 2014 à 15:05, Gabor Grothendieck ggrothendi...@gmail.com a écrit :

 installing to C:/Users/Gabor/Documents/R/win-library/3.1/Rcpp/libs/x64
 Warning in file.copy(files, dest, overwrite = TRUE) :
  problem copying .\Rcpp.dll to
 C:\Users\Gabor\Documents\R\win-library\3.1\Rcpp\libs\x64\Rcpp.dll:
 Permission denied

I guess you tried to install from github while Rcpp was already loaded in your 
R session, so it has not really been installed. 

Romain

 ** R
 ** inst
 ** tests
 ** preparing package for lazy loading
 ** help
 *** installing help indices
 ** building package indices
 ** installing vignettes
 ** testing if installed package can be loaded
 *** arch - i386
 *** arch - x64
 * DONE (Rcpp)
 code - '
 + // [[Rcpp::plugins(cpp11)]]
 + #include Rcpp.h
 + #include boost/range/irange.hpp
 + using boost::irange;
 + // [[Rcpp::depends(BH)]]
 + // [[Rcpp::export]]
 + int useCpp11() {
 + auto sum(0);
 + for(const auto i : irange(0,4)) { sum += i; }
 + return sum;
 + }
 + '
 library(Rcpp)
 sourceCpp(code = code, rebuild = TRUE)
 useCpp11()
 [1] 6
 R.version.string
 [1] R version 3.1.0 Patched (2014-05-09 r65562)
 
 
 
 On Thu, Jun 5, 2014 at 4:21 AM, JJ Allaire jj.alla...@gmail.com wrote:
 I couldn't reproduce this on Windows 7 with R 3.1 (which should have been
 using USE_CXX1X=yes under the hood resulting in -std=c++0x passed to gcc).
 
 However, I have this change which should make the cpp11 plugin automatically
 pass -std=c++0x when on R = 3.0:
 
 https://github.com/RcppCore/Rcpp/pull/148
 
 Does that work for you? You can install with:
 
 devtools::install_github(RcppCore/Rcpp, ref = feature/windows-c++0x)
 
 
 On Thu, Jun 5, 2014 at 3:36 AM, Gabor Grothendieck ggrothendi...@gmail.com
 wrote:
 
 On Wed, Jun 4, 2014 at 11:21 PM, Dirk Eddelbuettel e...@debian.org wrote:
 
 Rcpp 0.11.2 should be ready.
 
 If anybody wants to jump in and do last minute testing, please do so
 now.
 
 I ran two complete tests against CRAN last weekend, the results are
 summarized as usual in the GitHub repo at
 
   https://github.com/RcppCore/rcpp-logs
 
 Of 215 CRAN packages, all but 18 passed. Of those 18 a number where due
 to
 package sirt not building because ... I use FC='ccache gfortran' which
 is not
 gfortran so its configure failed. Grrr. I would pass next time.
 
 Anyway, 195 packages passed just fine, so we should be good.  But if
 there is
 something anyone of you would like to test, now would be a good time as
 I may
 upload the current version to CRAN in the next few days unless I hear
 objections.
 
 
 There seems to be a problem using Rcpp::plugins(cpp11) on Windows
 8.1.  It gives the error:
 cc1plus.exe: error: unrecognized command line option '-std=c++11'
 
 I am using Rtools 3.1.0.1942 (which is the latest version) and for
 that it needs -std=c++0x or -std=gnu++0x
 
 If I remove the plugins line and instead issue this line first then it
 all works (except as per prior email I built Rcpp without vignettes to
 get around that problem):
 Sys.setenv(PKG_CXXFLAGS=-std=c++0x) # for gcc 4.6.3
 
 code - '
 + // [[Rcpp::plugins(cpp11)]]
 +
 + #include Rcpp.h
 + #include boost/range/irange.hpp
 +
 + using boost::irange;
 +
 + // [[Rcpp::depends(BH)]]
 +
 + // [[Rcpp::export]]
 + int useCpp11() {
 + auto sum(0);
 + for(const auto i : irange(0,4)) { sum += i; }
 + return sum;
 + }
 + '
 library(Rcpp)
 sourceCpp(code = code)
 g++ -m64 -IC:/PROGRA~1/R/R-3.1/include -DNDEBUG
 -IC:/Users/Gabor/Documents/R/win-library/3.1/Rcpp/include
 -IC:/Users/Gabor/Documents/R/win-library/3.1/BH/include
 -Id:/RCompile/CRANpkg/extralibs64/local/include  -std=c++11-O2
 -Wall  -mtune=core2 -c file18a42f7f546e.cpp -o file18a42f7f546e.o
 cc1plus.exe: error: unrecognized command line option '-std=c++11'
 make: *** [file18a42f7f546e.o] Error 1 Warning message: running
 command 'make -f C:/PROGRA~1/R/R-3.1/etc/x64/Makeconf -f
 C:/PROGRA~1/R/R-3.1/share/make/winshlib.mk
 SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)'
 SHLIB=sourceCpp_83768.dll WIN=64 TCLBIN=64
 OBJECTS=file18a42f7f546e.o' had status 2
 Error in sourceCpp(code = code) :
  Error 1 occurred building shared library.
 useCpp11()
 Error: could not find function useCpp11
 sourceCpp(code = code, verbose = TRUE)
 
 Generated extern C functions
 
 
 
 #include Rcpp.h
 
 RcppExport SEXP sourceCpp_37333_useCpp11() {
 BEGIN_RCPP
SEXP __sexp_result;
{
Rcpp::RNGScope __rngScope;
int __result = useCpp11();
PROTECT(__sexp_result = Rcpp::wrap(__result));
}
UNPROTECT(1);
return __sexp_result;
 END_RCPP
 }
 
 Generated R functions
 ---
 
 `.sourceCpp_37333_DLLInfo` -
 
 dyn.load('C:/Users/Gabor/AppData/Local/Temp/RtmpmUpJdX/sourcecpp_18a41e263c3c/sourceCpp_77519.dll')
 
 useCpp11 - Rcpp:::sourceCppFunction(function() {}, FALSE,
 `.sourceCpp_37333_DLLInfo

Re: [Rcpp-devel] Error during wrapup

2014-05-28 Thread Romain Francois

This looks like a protection issue. 

For whomever this makes sense to: From the code that wraps such object, i would 
investigate the call to setAttrib. 

Perhaps we are supposed to get the result of it and protect it. 

So i would tend to use an Armor instead of a Shield. 

Romain

Le 28 mai 2014 à 16:02, John Mous john.mo...@gmail.com a écrit :

 Hmm, unfortunately the GitHub version failed also. The attributes on the 
 failed object are a little different though, here's what they look like:
 
 Browse[1] str(results)
  atomic [1:4] 1 1 2270 0
  - attr(*, )= symbol sim
  - attr(*, value)= promise to  NULL
 
 
 On Tue, May 27, 2014 at 6:10 PM, John Mous john.mo...@gmail.com wrote:
 Hi Kevin,
 
 Thanks. I will give the GitHub version a try -- the error usually manifests 
 only after running for about a day or so, so it may take a while to do that. 
 Unfortunately I am having trouble creating a small reproducible example -- a 
 function with just the assignments as written in my previous e-mail works 
 fine when executed thousands of times in a loop. The full  code is not that 
 long (~165 lines), but is also non-trivial. 
 
 It's odd that something else is causing things to fail with the end result 
 being that only the field *names*, which are hardcoded, and not the values, 
 not coming through properly. Since you said you suspect the problem may be 
 fixed, can you give me a hint of what you think it may be related to? This 
 might help me isolate the piece of offending code.
 
 
 
 On Tue, May 27, 2014 at 5:46 PM, Kevin Ushey kevinus...@gmail.com wrote:
 Hi John,
 
 I think we may have tackled this in some of the latest fixes with the
 version of Rcpp on GitHub. Can you try installing that version and
 trying again? Ie, try
 
 install.packages(devtools); devtools::install_github(RcppCore/Rcpp)
 
 then try running your code again.
 
 Alternatively, please supply a small reproducible example that we can
 try to run ourselves. You may be able to tease this error out
 reproducibly if you run it with gctorture(TRUE) on.
 
 Thanks,
 Kevin
 
 On Tue, May 27, 2014 at 2:42 PM, John Mous john.mo...@gmail.com wrote:
  Hello,
 
  I am passing back a very simple std::mapstd::string, int from Rcpp as
  follows:
 
  std::mapstd::string, int result;
  result[X1] = X1;
  result[X2] = X2;
  result[X3] = X3;
  result[X4] = X4;
  return wrap(result);
 
  The keys are hardcoded as shown, and the values X1-X4 are ints. Almost
  always everything works fine, however, very intermittently, a vector is
  returned on the R side _without_ named fields. For example:
 
  Browse[1] results
  [1]   1   2 863   0
  Error during wrapup: 'getCharCE' must be called on a CHARSXP
  Browse[1] str(results)
   atomic [1:4] 1 2 863 0
   - attr(*, )= symbol X1
   - attr(*, )= language `[[-`(`*tmp*`, sim, value = 1L)
 
  results[[X1]] works, but results[[X1]] does not, and X2-X4 can be
  retrieved only by index. However, again, most runs are successful:
 
  Browse[1] results
   X1  X2  X3  X4
 11 32540
  Browse[1] str(results)
   Named int [1:4] 1 1 3254 0
   - attr(*, names)= chr [1:4] X1 X2 X3 X4
 
 
  I am using R 3.1.0 and Rcpp 0.11.1. Does the message Error during wrapup:
  'getCharCE' must be called on a CHARSXP within this context hint anything
  to anyone familiar with Rcpp's internals? I realize it's almost impossible
  to diagnose with the given information -- is there a way to get Rcpp to
  display more debugging information?
 
  Thank you.
 
  ___
  Rcpp-devel mailing list
  Rcpp-devel@lists.r-forge.r-project.org
  https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Error during wrapup

2014-05-28 Thread Romain Francois

(now with some links):

Le 28 mai 2014 à 16:31, John Mous john.mo...@gmail.com a écrit :

 The object really is just built as part of the return statement. i.e. the 
 lines from my prior e-mail exist as-is in the full code,

Sure. What happens is that Rcpp::export generates something that calls wrap( 
std::mapstd::string,int ). 

 there's just more that actually builds the variables X1-X4 beforehand.

It should not be relevant. 

 So I'm not sure where to debug from the client side. I'm a C/C++ developer, 
 but have no experience with Rcpp internals or the general interface between R 
 and C. I can insert some debug statements on the Rcpp side if you can guide 
 me to where wrap is defined. 

well wrap is defined here: 
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28

It then performs a series of dispatch, that eventually lead to something that 
handles std::mapstd::string,int: 
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255

template typename InputIterator, typename T
inline SEXP range_wrap_dispatch___impl__cast( InputIterator first, 
InputIterator last, ::Rcpp::traits::false_type ){
size_t size = std::distance( first, last ) ;
const int RTYPE = ::Rcpp::traits::r_sexptype_traitstypename 
T::second_type::rtype ;
ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
CTYPE* start = r_vector_startRTYPE(x) ;
size_t i =0;
std::string buf ;
for( ; isize; i++, ++first){
start[i] = (*first).second ;
buf = (*first).first ;
SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ;
}
::Rf_setAttrib( x, R_NamesSymbol, names ) ;
return wrap_extra_stepsT( x ) ;
}

what I suspect to be the problem is this line:

 ::Rf_setAttrib( x, R_NamesSymbol, names ) ;


 What Romain says makes sense to me, despite my lack of expertise in this 
 area.. the really intermittent nature of the problem and the fact that I 
 can't recreate it in a small / fast running example suggests that perhaps 
 this manifests when R happens to garbage collect at an unfortunate time (if I 
 understood correctly). Thanks again.

Something like that. as hadley hinted, please try this under gc torture, or 
preferably through a debugger. 

 On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel e...@debian.org wrote:
 
 On 28 May 2014 at 10:02, John Mous wrote:
 | Hmm, unfortunately the GitHub version failed also.
 
 Darn.
 
 | The attributes on the failed
 | object are a little different though, here's what they look like:
 |
 | Browse[1] str(results)
 |  atomic [1:4] 1 1 2270 0
 |  - attr(*, )= symbol sim
 |  - attr(*, value)= promise to  NULL
 
 I am not sure what we can do without a reproducible example. :-/
 The code just got a review / refreshment over the last few months.
 
 You best bet may the slow and tedious insertion of debug statements to see
 when / if the object changes.
 
 Dirk
 
 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Error during wrapup

2014-05-28 Thread Romain Francois


Le 29 mai 2014 à 00:35, John Mous john.mo...@gmail.com a écrit :

 No luck with gctorture on yet, but I haven't run it for very long. It slowed 
 things down to a complete crawl, but maybe in the long run it can recreate 
 the problem faster than running the original code (about 12 hours, the 
 previous estimate of a day was too high), so this may still be worthwhile. 
 
 On a whim I did try changing the two instances of Shield to Armor this 
 morning (I was able to locate the code in wrap.h by digging around before I 
 saw your e-mail) and ran the original full code without gctorture on, and the 
 problem still persists. 

Would not be enough, you'd also have to do: 

x = ::Rf_setAttrib( x, R_NamesSymbol, names ) ;

so that the result of setAttrib gets protected even if it is a new SEXP, which 
AFAIU can happen with setAttrib. 

But I'm not sure this is the problem. 

Romain

 
 On Wed, May 28, 2014 at 3:44 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 (now with some links):
 
 Le 28 mai 2014 à 16:31, John Mous john.mo...@gmail.com a écrit :
 
 The object really is just built as part of the return statement. i.e. the 
 lines from my prior e-mail exist as-is in the full code,
 
 Sure. What happens is that Rcpp::export generates something that calls wrap( 
 std::mapstd::string,int ). 
 
 there's just more that actually builds the variables X1-X4 beforehand.
 
 It should not be relevant. 
 
 So I'm not sure where to debug from the client side. I'm a C/C++ developer, 
 but have no experience with Rcpp internals or the general interface between 
 R and C. I can insert some debug statements on the Rcpp side if you can 
 guide me to where wrap is defined. 
 
 well wrap is defined here: 
 https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28
 
 It then performs a series of dispatch, that eventually lead to something that 
 handles std::mapstd::string,int: 
 https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255
 
 
 template typename InputIterator, typename T
 
 inline SEXP range_wrap_dispatch___impl__cast( InputIterator first, 
 InputIterator last, ::Rcpp::traits::false_type ){
 
   size_t size = std::distance( first, last ) ;
 
   const int RTYPE = ::Rcpp::traits::r_sexptype_traitstypename 
 T::second_type::rtype ;
 
   ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
 
   ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
 
   typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
 
   CTYPE* start = r_vector_startRTYPE(x) ;
 
   size_t i =0;
 
   std::string buf ;
   for( ; isize; i++, ++first){
 
   start[i] = (*first).second ;
 
   buf = (*first).first ;
 
   SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ;
 
   }
   ::Rf_setAttrib( x, R_NamesSymbol, names ) ;
 
   return wrap_extra_stepsT( x ) ;
 
 }
 
 what I suspect to be the problem is this line:
 
  ::Rf_setAttrib( x, R_NamesSymbol, names ) ;
 
 
 What Romain says makes sense to me, despite my lack of expertise in this 
 area.. the really intermittent nature of the problem and the fact that I 
 can't recreate it in a small / fast running example suggests that perhaps 
 this manifests when R happens to garbage collect at an unfortunate time (if 
 I understood correctly). Thanks again.
 
 Something like that. as hadley hinted, please try this under gc torture, or 
 preferably through a debugger. 
 
 On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel e...@debian.org wrote:
 
 On 28 May 2014 at 10:02, John Mous wrote:
 | Hmm, unfortunately the GitHub version failed also.
 
 Darn.
 
 | The attributes on the failed
 | object are a little different though, here's what they look like:
 |
 | Browse[1] str(results)
 |  atomic [1:4] 1 1 2270 0
 |  - attr(*, )= symbol sim
 |  - attr(*, value)= promise to  NULL
 
 I am not sure what we can do without a reproducible example. :-/
 The code just got a review / refreshment over the last few months.
 
 You best bet may the slow and tedious insertion of debug statements to see
 when / if the object changes.
 
 Dirk
 
 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Converting std::cout to Rcpp::Rcout automatically

2014-05-23 Thread Romain François

Hi, 

I used to redirect std::cout to Rcpp::Rcout back when I still had Rcout in 
Rcpp11. e.g. 
https://github.com/Rcpp11/Rcpp11/blob/22cc410ea87a2668e547acf6510d07ca812dfca8/src/Rcpp11_init.cpp

Which was basically leveraging std::cout.rdbuf. 
A variant of 
http://stackoverflow.com/questions/10150468/how-to-redirect-cin-and-cout-to-files

And then just using std::cout; Of course then you get CRAN complaining. 

Romain

 Hi, dear all,
 
 I am using Rcpp to integrate an available C++ library with R.
 
 Since the std::cout and std::cerr are not permitted when uploading to CRAN, I 
 have to modify files manually. It will be somewhat laborious if the library 
 
 Does anyone have any idea how can I do that automatically?
 
 Thank you!
 
 Best,
 
 KK
 
 -- 
 Qiang Kou
 q...@umail.iu.edu
 School of Informatics and Computing, Indiana University
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Not able to convert from Rcpp::NumericVector to Teuchos::ArrayRCPsize_t

2014-05-22 Thread Romain François

Hello, 

From what I understand of ArrayRCP, having read the documentation for a few 
minutes. 
(http://trilinos.sandia.gov/packages/docs/r9.0/packages/teuchos/doc/html/classTeuchos_1_1ArrayRCP.html)
This looks like a vector and therefore it is likely that the default 
ExporterT will not be useful as it tries to use the constructor taking a SEXP 
: 

template typename T
class Exporter{
public:
Exporter( SEXP x ) : t(x){}
inline T get(){ return t ; }

private:
T t ;
} ;

you can use a RangeExporter instead which looks more compatible to what 
ArrayRCP looks like: 

template typename T class RangeExporter {
public:
typedef typename T::value_type r_export_type ;

RangeExporter( SEXP x ) : object(x){}
~RangeExporter(){}

T get(){
T vec( ::Rf_length(object) );
::Rcpp::internal::export_range( object, vec.begin() ) ;
return vec ;
}

private:
SEXP object ;
} ;


You can probably do this by having something like this early enough (after 
RcppCommon.h but before Rcpp.h). 

namespace Rcpp {
namespace traits {

  template typename T class Exporter  Teuchos::ArrayRCPT  : public 
RangeExporter Teuchos::ArrayRCPT {
  public:
Exporter( SEXP x) : RangeExporter Teuchos::ArrayRCPT (x){}  
  }

}
}


Romain

Le 23 mai 2014 à 00:42, Chaomei Lo chaome...@gmail.com a écrit :

 Sorry to confuse you, Dirk, I had my previous message title wrong.  Here 
 below was the message with the correct title and content.
  
 
 I have created R packages using Makevars and it works pretty good for me. I 
 am able to convert from a Rcpp::NumericVector to std::vector as in below.
  
 NumericVector col_cts = buildMatrix(Xr);
 
 vectorlong unsigned int col_counts = Rcpp::asvectorlong unsigned 
 int(col_cts);
   
 Now I am having a problem with an application involves the Trilinos library. 
 Here below I am trying to convert a Rcpp::NumericVector to 
 Teuchos::ArrayRCPsize_t in the following line, it gave me errors as shown 
 below in red.  Would you please help me with this ?
  
 Teuchos::ArrayRCPsize_t 
 col_counts=Rcpp::asTeuchos::ArrayRCPsize_t(col_cts);
  
 Thanks a lot.
  
 In file included from 
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/as.h:25:0,
  from 
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/RcppCommon.h:169,
  from 
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp.h:27,
  from buildMatrix.cpp:4:
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/internal/Exporter.h: In 
 constructor 'Rcpp::traits::ExporterT::Exporter(SEXP) [with T = 
 Teuchos::Array
 RCPlong unsigned int, SEXP = SEXPREC*]':
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/as.h:79:51:   
 instantiated from 'T Rcpp::internal::as(SEXP, 
 Rcpp::traits::r_type_generic_tag) [with T =
  Teuchos::ArrayRCPlong unsigned int, SEXP = SEXPREC*]'
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/as.h:144:84:   
 instantiated from 'T Rcpp::as(SEXP) [with T = Teuchos::ArrayRCPlong unsigned 
 int, SEXP
  = SEXPREC*]'
 buildMatrix.cpp:84:87:   instantiated from here
 /share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/internal/Exporter.h:31:31:
  error: invalid conversion from 'SEXP' to 'long int' [-fpermissive]
 /people/d3j508/trilinos-11.6.1/trilinos-11.6.1_Install/include/Teuchos_ArrayRCP.hpp:129:1:
  error:   initializing argument 1 of 'Teuchos::ArrayRCPT::ArrayRC
 P(Teuchos::ArrayRCPT::size_type, const T) [with T = long unsigned int, 
 Teuchos::ArrayRCPT::size_type = long int]' [-fpermissive]
 make: *** [buildMatrix.o] Error 1
 ERROR: compilation failed for package 'Tpkg'
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] bigmatrix and segmentation fault due to 'memory not mapped'

2014-05-15 Thread Romain François


Le 15 mai 2014 à 09:03, Stefano Calza steca...@gmail.com a écrit :

 Hi everybody,
 
 I am trying to use big.matrix from Rcpp basically to write some (integer) 
 data to a matrix.
 
 I keep getting segmentation fault due to 'memory not mapped'.
 Debugging with gdb I found out that the critical point is
 
 MatrixAccessorint ma(*pBigMat);
 
 The function is declared as something like (I just followed the Gallery Rcpp 
 example):
 
 RcppExport SEXP myFun(SEXP X, SEXP Y, SEXP Z, SEXP XX, XPtrBigMatrix 
 pBigMat)
 
 Basically it cannot get to the correct pointer.
 
 The really weird thing is that this error happens ONLY using the function 
 built within a package
 
 .Call('myFun',X,Y,Z,XX,bigMat@address,package='myPackage')
 
 BUT if I use the very same code, changing just the declaration
 
 // [Rcpp::export]
 IntegerVector myFun(SEXP X, SEXP Y, SEXP Z, SEXP XX, XPtrBigMatrix pBigMat)
 
 and then
 
 sourceCpp('mycode.cpp')
 
 and
 
 myFun(X,Y,Z,XX,bigMat@address)
 
 it works fine!
 
 So what am I doing wrong here? Is the pointer reset somehow? But why only 
 when using .Call version?
 
 Thanks
 
 Stefano

If you use a raw .Call, all your parameters have to be SEXP. 
If you want to use other parameter types, such as XPtrBigMatrix, you need to 
use attributes (i.e. sourceCpp or compileAttributes) so that it generates .Call 
compatible function for you. 

Romain


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Questions on extending Rcpp wrap and as with templates

2014-05-06 Thread Romain Francois


Le 6 mai 2014 à 08:45, Florian Burkart florian.burk...@gmail.com a écrit :

 Hi everyone (and Dirk),
 
 Second attempt on corrected email list.
 
 I have been trying to extend Rcpp with my own wrap and as templates.
 
 Two issues:
 
 1) I need to explicitly call wrap. Is that expected?
 
 So for example I wrote this specialization:

This is not a specialization, just another overload. You need to write a 
specialization, as in: 

namespace Rcpp{
template SEXP wrapstd::vector TimedOptDouble   
(std::vectorTimedOptDouble const entries) { … }
}

 template SEXP Rcpp::wrap(std::vectorTimedOptDouble const entries) {
   std::vectordouble sec_times;
   std::vectordouble doubles;
   for(auto const entry : entries)
   {
   sec_times.push_back(entry.GetTime().Seconds());
   TimedOptDouble::OptDouble opt_double(entry.GetOptDouble());
   if(opt_double)
   doubles.push_back(*opt_double);
   else
   doubles.push_back(R_NaReal);
   }
   return List::create(
   Named( Time ) = sec_times,
   Named( Value ) = doubles);
 }
 
 First of all, this returns what I believe to be a Rcpp::List object, which 
 seems to be converted implicitly to a SEXP. This is the typical behaviour I 
 know.
 
 Unfortunately, when making use of this template, it doesn't work implicitly, 
 but I need to explicitly call it.
 
 So for example
 
 SEXP GetSunPositions(SEXP a) {
   std::vectorTimedOptDouble sun_positions;
   ...
   return wrap(sun_positions);
 }
 
 works, where as
 
 return sun_positions;
 
 as last line doesn't. Am I doing something wrong here? I did do the 
 declaration before including Rcpp.h.

This should work if you return a std::vector TimedOptDouble  from your 
function, as in: 

std::vector TimedOptDouble  GetSunPositions(SEXP a) { … }

 2) How to make as work for own types in containers
 
 The other way around, one can return a std::vectordouble implicitly, but 
 how do I return std::vectorMyType? I tried to define
 
   template MyType as(SEXP);
 
 But that didn't help, e.g. I had to write my own
 
   template std::vectorMyType as(SEXP);

This is the easiest way. A more general way would need you to express how to 
handle containers of MyType, but that requires defining some traits classes etc 
… not sure it is worth the effort. 

But again, you’d need to actually write a specialization: template 
std::vectorMyType as std::vectorMyType  (SEXP);

Romain


 Thanks for help
 
 Florian
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] How to create list of list without known structure

2014-05-06 Thread Romain Francois


Le 6 mai 2014 à 09:35, Florian Burkart florian.burk...@gmail.com a écrit :

 Hi,
 
 I have been creating lists of lists with 
 
 return Rcpp::List::create(Rcpp::Named(vec) = someVector,
   Rcpp::Named(lst) = someList,
   Rcpp::Named(vec2) = someOtherVector);
 
 or to follow Romain:
 
 using namespace Rcpp ;
 return List::create( 
_[vec]  = someVector, 
_[lst]  = someList, 
_[vec2] = someOtherVector
  ) ;
 
 But how do I convert the following into a list of lists?
 
 std::vectorstd::string m_column_headers;
 std::vectorstd::vectorOptDouble  m_vectors_of_values;

You probably just need to know about .names() =, i.e. something like this 
should do: 

List values = wrap(m_vectors_of_values) ;
values.names()  = m_column_headers ;

FWIW, in Rcpp11, you could use structure, e.g. :

List values = structure( m_vectors_of_values, _[names] = m_column_headers ) ;

Romain
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] g++ flags

2014-04-30 Thread Romain Francois

That looks alright to me. But apparently dirk has another way to do it that 
does not depend on R 3.1.0, whatever works.  

Romain

Le 30 avr. 2014 à 16:15, JJ Allaire jj.alla...@gmail.com a écrit :

 Romain,
 
 I think this PR addresses the issue:
 
 https://github.com/RcppCore/Rcpp/pull/143
 
 I've tested and it seems to work as intended. Is this fix you were conceiving 
 of or is there something more we should be doing?
 
 J.J.
 
 
 On Wed, Apr 30, 2014 at 9:19 AM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 The plugin as implemented now is not portable. The easiest way to make it 
 portable would be to define the USE_CXX1X environment variable, which R 
 knows how to interpret.
 
 This way R would do what makes sense, i.e. use -std=c++0x on windows (for 
 which rtools is limited to gcc 4.6.3 now) and -std=c++11 when it makes sense.
 
 Romain
 
 Le 30 avr. 2014 à 15:10, Darren Cook dar...@dcook.org a écrit :
 
  The problem seems to be that Rcpp uses -std=c++11; however, g++ 4.6.3,
  which is what comes with the latest version of Rtools on Windows, uses
  -std=c++0x or -std=gnu++0x ...
 
  In g++ 4.8.1 those two are deprecated in favour of -std=c++11 and
  -std=gnu++11 respectively; however they are still available.
 
  Darren
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Parallel random numbers using Rcpp and OpenMP

2014-04-28 Thread Romain Francois

Hi, 

If you can assume c++11, you might bot need openmp, as you can just use 
standard support for threads, etc ... 

Although the compiler suite used on windows (if you care about that) does not 
support c++11 threads. This might be available later. 

Romain


Le 28 avr. 2014 à 12:51, Matteo Fasiolo matteo.fasi...@gmail.com a écrit :

 Hi all,
 
  many thanks for your detailed replies, I see that there are many options out 
 there.
 
 As a first step I think I will try out the C++11 option that Matt suggested, 
 as it seems
 relatively simple. In particular I might do something like:
 
 #pragma omp parallel
 {
 std::mt19937_64 engine( static_castuint64_t(seeds[omp_get_thread_num()] 
 ) );
 std::uniform_real_distributiondouble zeroToOne(0.0, 1.0);
 
 #pragma omp for
 for (int i = 0; i  1000; i++) {
 double a = zeroToOne(engine);
 }
 }
 
 were seeds is a NumericVector coming from R. That's probably not ideal, but 
 it might
 give reasonable and reproducible results.
 
 Thanks,
 
 Matteo
 
 
 
 On Mon, Apr 28, 2014 at 9:39 AM, Matt D. mat...@gmail.com wrote:
 On 4/28/2014 01:30, Matteo Fasiolo wrote:
 [...]
 
 
 As I understand, doing things such as:
 
 NumericMatrix out(n, d);
 #pragma omp for schedule(static)
 for(int kk = 0; kk  d; kk++) out( _, kk) = rnorm(n);
 
 is not going to work, because rnorm() is not thread safe
 (in fact this code crashed R). On the other hand R level parallelism
 using clusterApply, mclapply etc appears to be too slow to be of any
 use for this purpose.
 
 Is anybody aware of any package providing a parallel C++ rng which my
 package might link to?
 Your first choice can be to go with the C++ Standard Library -- header 
 random -- (importantly) using one object per thread:
 http://stackoverflow.com/questions/8813592/c11-thread-safety-of-random-number-generators
 
 See:
 http://en.cppreference.com/w/cpp/numeric/random
 http://isocpp.org/blog/2013/03/n3551-random-number-generation
 
 Since you're using OpenMP, you can get the distinct thread ID by using the 
 `omp_get_thread_num` function:
 http://stackoverflow.com/questions/15918758/how-to-make-each-thread-use-its-own-rng-in-c11
 
 Note that if you're doing large scale parallel statistics (say, Monte Carlo) 
 you may also want a PRNG with statistical properties which don't deteriorate 
 (e.g., no spurious correlation, let alone overlapping) for very large 
 samples; preferably, also one that doesn't maintain any kind of global state 
 (so-called stateless) is going to be easier to use, too (nothing to 
 synchronize/lock across threads).
 
 A relatively recent work that's particularly relevant is Random123:
 https://www.deshawresearch.com/resources_random123.html
 http://www.thesalmons.org/john/random123/
 
 MIT-licensed C++ version is available here:
 http://www.sitmo.com/article/parallel-random-number-generator-in-c/
 
 With a simple example:
 http://www.sitmo.com/article/multi-threaded-random-number-generation-in-c11/
 
 // The author is currently working on getting it into Boost.Random; 
 discussion: 
 http://www.wilmott.com/messageview.cfm?catid=44threadid=95882STARTPAGE=2#710955
 
 HTH,
 
 Best,
 
 Matt
 
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp11 3.1.0 is on CRAN

2014-04-17 Thread Romain François

Hello, 

(may contains traces of personal opinions)

My motivation for starting Rcpp11 were:
 - Assuming C++11, which is nicer to use and teach. Rcpp still wants to be 
compatible with older standard, which essentially means that even if I write 
something new using C++11, I still have to figure out how to write the same 
thing in C++98. 
 - modernize the code base. This meant let go of a few features so that we have 
what we keep better. This is incompatible with Rcpp’s maintainership policy. 
Last time I asked to remove a feature from Rcpp, I was told that it would take 
a year of deprecation. In Rcpp11, because I’m in charge I can decide to break 
stuff to make something better. 

Rcpp has been a great project to work on for me. I’ve learned a lot of C++, and 
I think I owe most of my C++ knowledge from involvement I have with Rcpp. But 
as far as I’m concerned, the string requirements take all the fun away. Working 
on Rcpp11 has brought fun back. I can innovate. 

There will always be some conceptual compatibility between Rcpp and Rcpp11. For 
example both have the NumericVector class to handle numeric vectors. However in 
that particular example, the implementation of NumericVector in Rcpp is too 
complicated, you have gazillion of constructors, etc ... hard to maintain, hard 
to document, hard to teach. 

Now that Rcpp11 can be used on current versions of OSX, recent enough linux, 
windows and even solaris (if you use gcc), what I would suggest is that you try 
it and come back with questions (not on this list though, please use the google 
group that is not strictly restricted to Rcpp questions). 

What might help you deciding is that in Rcpp11, we did not retain some features 
such as modules and date/time related classes. If your code uses these, then 
you should probably either stick with Rcpp or start motivating me for adding 
something along the lines in Rcpp11. There is still a need for something like 
modules, but not with this implementation. 

Now, as Dirk says, you can use C++11 with Rcpp. Just as much as you can use 
C++11 with vanilla .Call/.C. 

Personally I think the future of R and C++ is with Rcpp11. This is where I’ll 
focus my time. 

Romain

Le 17 avr. 2014 à 08:24, Søren Højsgaard sor...@math.aau.dk a écrit :

 Dear all,
 My understanding is that Rcpp11 will employ features of c++11 (which is very 
 nice) but other than that it is not clear to me how Rcpp and Rcpp11 relate to 
 each other? Can I start to use Rcpp11 with my existing Rcpp-based packages or 
 is Rcpp and Rcpp11 branching off in different directions?
 Cheers
 Søren
 
 -Original Message-
 From: rcpp-devel-boun...@lists.r-forge.r-project.org 
 [mailto:rcpp-devel-boun...@lists.r-forge.r-project.org] On Behalf Of Romain 
 Francois
 Sent: 11. april 2014 15:26
 To: rcpp-devel@lists.r-forge.r-project.org
 Subject: [Rcpp-devel] Rcpp11 3.1.0 is on CRAN
 
 Hello, 
 
 I'll keep it short here. Rcpp11 3.1.0 was released on CRAN today. An 
 announcement email has been sent to both r-packages and the new R and C++ 
 mailing list. https://groups.google.com/forum/#!forum/r-and-cpp
 
 Best Regards, 
 
 Romain
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp11 3.1.0 is on CRAN

2014-04-17 Thread Romain François


Le 17 avr. 2014 à 09:42, Hao Ye h...@ucsd.edu a écrit :

 Hi Romain,
 
 Thanks for the explanation -- I was curious about the difference between Rcpp 
 and Rcpp11, as well.
  
 What might help you deciding is that in Rcpp11, we did not retain some 
 features such as modules and date/time related classes. If your code uses 
 these, then you should probably either stick with Rcpp or start motivating me 
 for adding something along the lines in Rcpp11. There is still a need for 
 something like modules, but not with this implementation.
 
 Does this mean that there will be some other mechanism for exposing c++ 
 classes to R? Maybe in some way that supports inheritence? ;)

Yes. Problems with Rcpp modules are: 
  -  the way you express things is limited by C++ grammar. It was fun and 
challenging to write it. But experience of teaching modules shows that the 
concepts are somewhat hard to grasp. 
  - it is very demanding in terms of resources

In the future, I’d like to look into code generation (a la attributes) as a 
mean of exposing classes. So we need something expressive enough. My current 
blue sky line of thinking about this is that I’d like to have some sort of 
intermediate language between R and C++. John has done something similar with 
the exposeClass in Rcpp. 
https://github.com/RcppCore/Rcpp/blob/master/R/exposeClass.R

It goes in the right direction, but this time you are limited by R’s grammar. 
This has been on my radar for some time, but I think having a class system that 
is nice to use in R requires some grammatical changes. It is unlikely that I 
will have the leverage to change R’s grammar, but what I can work on is an 
intermediate language that generates R code. 

In any case, Rcpp11 still has the external pointer class template, so we can « 
write modules by hand ». 

Romain

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] Rcpp11 3.1.0 is on CRAN

2014-04-11 Thread Romain Francois

Hello, 

I’ll keep it short here. Rcpp11 3.1.0 was released on CRAN today. An 
announcement email has been sent to both r-packages and the new R and C++ 
mailing list. https://groups.google.com/forum/#!forum/r-and-cpp

Best Regards, 

Romain
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Distribution of Rcpp codebase


Le 8 avr. 2014 à 10:12, Xavier Robin xav...@cbs.dtu.dk a écrit :

 My 2 cents...
 
 On 07/04/14 10:12, Romain François wrote:
 It would also mean many copies of the same code base. To which I’m thinking: 
 so what.
 No, it will mean many copies of /many different and mostly outdated/ code 
 bases.

Still: so what ;)

 You can count on me to forget to git pull next time I update my package.

And as long as your package keeps working, this is not so much of an issue. You 
are then in control of which version of the codebase is used. If you want a new 
version of the codebase, you can get it, and the challenge for me is to make it 
easy enough for you to get and deploy it into your package, if you don’t that’s 
fine. 

Now consider the alternative. You have no idea of which version of the codebase 
is used with your package. You have no idea if the version used at runtime is 
the same as the version that was used when the package was compiled. When a new 
Rcpp package is released, you definitely have to recompile yours, and need to 
ask your users to recompile your package against this version. 

I prefer when I’m in control. 

 What about something like the BH package that contains the boost headers? I'm 
 using it in a project I'm working on, and just use a LinkingTo declaration 
 with something in Makevars.

That works fine because BH is truly header only. Rcpp is not. The change in 
Rcpp 0.11.0 was a big step forward, but it is a job half done. Functions in the 
.h files of Rcpp constantly poke into the Rcpp.so. 

Any binary change in Rcpp creates hard problem to fix. Currently the usual 
advice is to ask to recompile, etc ... It is really easy to make such a binary 
change. 

 Of course ideally it would be in a build-depends type of declaration so it 
 isn't pulled during binary installs.
 
 Xavier

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] Generic R and C++ discussion

Hello, 

I have created a new mailing list (as a google group) for general discussions 
about R and C++. https://groups.google.com/forum/#!forum/r-and-cpp

Shame that it had to come to this, but apparently Rcpp-devel is only for 
discussing the Dirk approved implementation of Rcpp. 

Personally, I will keep watching Rcpp-devel, and I hope I can still contribute 
interesting answers here, but I will use the google group for broad 
discussions. 

Romain
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Distribution of Rcpp codebase

Le 8 avr. 2014 à 10:51, Rainer M Krug rai...@krugs.de a écrit :

 Martyn Plummer plumm...@iarc.fr writes:
 
 And another 2 cents from me.
 
 A package is the basic unit of functionality in R. Whatever
 functionality you are providing, I think a package is the best way to
 deliver it. There is a well developed framework for versioning,
 dependency resolution, testing, and distribution.
 
 If you choose some other mechanism, then I suspect that any developer
 problems you eliminate will just return as system administration
 problems.
 
 I thought I could keep out of this...
 
 rcpp... is so much the core of many packages, that the mechanism of
 packages really shows its shortcomings, namely the versioning. A
 different aspect was discussed on the r-devel list some time ago
 concerning snapshots of CRAN to provide reproducibility.
 
 The part which makes rcpp outstanding from other packages, is that it is
 used mainly during compilation and not that much during running - that
 is if I understand the header only concept correctly.

Well with the current Rcpp, you still need the runtime for any of the functions 
that are registered here: 
https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp#L85

That’s what I meant earlier when I mentioned job half done. The intention of 
the change in 0.11.0 was to move away from runtime, but we did not go far 
enough. 

 In contrast, as far as I know, all other packages provide run-time
 features as well as compile time - and this is what the packages were
 designed for - and I might say they work quite well. 

I agree. 

 I can see Romain's point (oparticularly the more fine grained control of
 the developer), but I also understand that Dirk will keep rcpp as a
 package.

Sure. 

 My question is: would it be possible to combine these two, i.e. have one
 package, which contains different versions, and to use one command to
 switch between these? So one would have one package, which will switch
 between different versions?

I see your point, but I would not want to do that. I can definitely foresee a 
whole new class of issues with this scenario. 

 I don't know if this would be possible or a suitable solution?
 
 The other would obviously be to have different versions of rcpp on CRAN,
 similar to ggplot or oxygen.

I can see this working. 

But there could be Rcpp_0_12_0, Rcpp_0_12_1, etc .. as different packages so 
that developers who want to update their package would need to change the 
version on which they depend. 

Not sure CRAN would be impressed if I start releasing a new package for each 
version. 

 Cheers,
 
 Rainer
 
 
 Martyn
 
 On Tue, 2014-04-08 at 10:12 +0200, Xavier Robin wrote:
 My 2 cents...
 
 On 07/04/14 10:12, Romain François wrote:
 It would also mean many copies of the same code base. To which I’m 
 thinking: so what.
 No, it will mean many copies of /many different and mostly outdated/ 
 code bases.
 You can count on me to forget to git pull next time I update my package.
 
 What about something like the BH package that contains the boost 
 headers? I'm using it in a project I'm working on, and just use a 
 LinkingTo declaration with something in Makevars.
 Of course ideally it would be in a build-depends type of declaration so 
 it isn't pulled during binary installs.
 
 Xavier
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 -- 
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
 UCT), Dipl. Phys. (Germany)
 
 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa
 
 Tel :   +33 - (0)9 53 10 27 44
 Cell:   +33 - (0)6 85 62 59 98
 Fax :   +33 - (0)9 58 10 27 44
 
 Fax (D):+49 - (0)3 21 21 25 22 44
 
 email:  rai...@krugs.de
 
 Skype:  RMkrug
 
 PGP: 0x0F52F982
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Distribution of Rcpp codebase


Le 8 avr. 2014 à 11:47, Rainer M Krug rai...@krugs.de a écrit :

 Romain François rom...@r-enthusiasts.com writes:
 
 Le 8 avr. 2014 à 10:51, Rainer M Krug rai...@krugs.de a écrit :
 
 Martyn Plummer plumm...@iarc.fr writes:
 
 And another 2 cents from me.
 
 A package is the basic unit of functionality in R. Whatever
 functionality you are providing, I think a package is the best way to
 deliver it. There is a well developed framework for versioning,
 dependency resolution, testing, and distribution.
 
 If you choose some other mechanism, then I suspect that any developer
 problems you eliminate will just return as system administration
 problems.
 
 I thought I could keep out of this...
 
 rcpp... is so much the core of many packages, that the mechanism of
 packages really shows its shortcomings, namely the versioning. A
 different aspect was discussed on the r-devel list some time ago
 concerning snapshots of CRAN to provide reproducibility.
 
 The part which makes rcpp outstanding from other packages, is that it is
 used mainly during compilation and not that much during running - that
 is if I understand the header only concept correctly.
 
 Well with the current Rcpp, you still need the runtime for any of the
 functions that are registered here:
 https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp#L85
 
 That’s what I meant earlier when I mentioned job half done. The
 intention of the change in 0.11.0 was to move away from runtime, but
 we did not go far enough.
 
 I must admit, I am not to familiar with rcpp to comment on these
 functions, but would it be possible to split Rcpp into headers-only,
 i.e. only for compiling and developing, and Rcpp-runtime for runtime?
 Because I really think it might make sense to have additional function
 at runtime? 

They are really too tightly coupled for that. I’ve been through making Rcpp11 
truly header only and it was really hard. It was worth every second of it, but 
still hard. 

Doing it for Rcpp is impossible, at least with Dirk’s maintainer requirements. 

 
 In contrast, as far as I know, all other packages provide run-time
 features as well as compile time - and this is what the packages were
 designed for - and I might say they work quite well. 
 
 I agree. 
 
 I can see Romain's point (oparticularly the more fine grained control of
 the developer), but I also understand that Dirk will keep rcpp as a
 package.
 
 Sure. 
 
 My question is: would it be possible to combine these two, i.e. have one
 package, which contains different versions, and to use one command to
 switch between these? So one would have one package, which will switch
 between different versions?
 
 I see your point, but I would not want to do that. I can definitely
 foresee a whole new class of issues with this scenario.
 
 I don't know if this would be possible or a suitable solution?
 
 The other would obviously be to have different versions of rcpp on CRAN,
 similar to ggplot or oxygen.
 
 I can see this working. 
 
 But there could be Rcpp_0_12_0, Rcpp_0_12_1, etc .. as different
 packages so that developers who want to update their package would
 need to change the version on which they depend.
 
 Well - I would stick with the usual system, that would mean Rcpp_0_12,
 Rcpp_0_13, ... and no further fine grained. 

Same difference. I think this would be kind of confusing, but at least it would 
be allowed as « Rcpp » is not the same name as « Rcpp_0_12 ». 

As a side note, I plan to version Rcpp11 according to the version of R, so the 
first release of Rcpp11 will be version 3.1.0, ...

 Not sure CRAN would be impressed if I start releasing a new package for each 
 version. 
 
 Agreed. 
 
 
 Cheers,
 
 Rainer
 
 
 Martyn
 
 On Tue, 2014-04-08 at 10:12 +0200, Xavier Robin wrote:
 My 2 cents...
 
 On 07/04/14 10:12, Romain François wrote:
 It would also mean many copies of the same code base. To which I’m 
 thinking: so what.
 No, it will mean many copies of /many different and mostly outdated/ 
 code bases.
 You can count on me to forget to git pull next time I update my package.
 
 What about something like the BH package that contains the boost 
 headers? I'm using it in a project I'm working on, and just use a 
 LinkingTo declaration with something in Makevars.
 Of course ideally it would be in a build-depends type of declaration so 
 it isn't pulled during binary installs.
 
 Xavier
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 -- 
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
 UCT), Dipl. Phys. (Germany)
 
 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa
 
 Tel :   +33

Re: [Rcpp-devel] Generic R and C++ discussion

2014-04-08 Thread Romain Francois

Le 8 avr. 2014 à 13:28, stat quant mail.statqu...@gmail.com a écrit :
 Hi, 
 Will that be ok to ask Rcpp questions to on this list too? 
 

Definitely. Anything R and C++ related. 

 On 8 Apr 2014 09:56, Romain François rom...@r-enthusiasts.com wrote:
 Hello,
 
 I have created a new mailing list (as a google group) for general discussions 
 about R and C++. https://groups.google.com/forum/#!forum/r-and-cpp
 
 Shame that it had to come to this, but apparently Rcpp-devel is only for 
 discussing the Dirk approved implementation of Rcpp.
 
 Personally, I will keep watching Rcpp-devel, and I hope I can still 
 contribute interesting answers here, but I will use the google group for 
 broad discussions.
 
 Romain
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Error in Module

Hello, 

Just sourceCpp the .cpp file and use the functions verbatim: 

 sourceCpp( /tmp/mod.cpp )
 bar(2L)
[1] 4 

If you really want to use the module as an object, you have to pick it up from 
the right spot: 

 yada - Module(yada, where = tail(getLoadedDLLs(), 1)[[1]] )
 yada$hello()
[1] hello

Romain

Le 8 avr. 2014 à 09:00, Brötje David d.broe...@tu-braunschweig.de a écrit :

 Hello,
 
 
 I want to expose a C++ class to R through Rcpp. For that I want to try out a 
 few examples from the note Exposing C++ functions and classes with Rcpp 
 modules and the book Seamless R and C++ Integration with Rpp. But I can't 
 manage to get them work. It ends up with an error. So this is what I'm doing.
 
 First I create a cpp file with the c++ code from the example. The full 
 content of the cpp file is below.
 
 
 #include Rcpp.h
 using namespace Rcpp;
 
 
 std::string hello() { return hello; }
 
 int bar( int x) { return x*2; }
 
 double foo( int x, double y) { return x*y; }
 
 void bla( ) { Rprintf( hello\\n ); }
 
 void bla1( int x) {
 Rprintf( hello (x = %d)\\n, x );
 }
 void bla2( int x, double y) {
 Rprintf( hello (x = %d, y = %5.2f)\\n, x, y );
 }
 
 
 RCPP_MODULE(yada) {
 using namespace Rcpp;
 function( hello , hello );
 function( bar , bar );
 function( foo , foo );
 function( bla , bla );
 function( bla1 , bla1 );
 function( bla2 , bla2 );
 }
 
 
 
 Then I run this command:
 
 
 PKG_CXXFLAGS=`Rscript -e 'Rcpp:::CxxFlags()'` PKG_LIBS=`Rscript -e 
 'Rcpp:::LdFlags()'`  R CMD SHLIB test.cpp
 
 
 Afterwards I start R and run these commands in R:
 
 
 
 require(Rcpp)
 yada - Module(yada)
 
 
 yada$bar( 2L )
 yada$foo( 2L, 10.0 )
 yada$hello()
 yada$bla()
 yada$bla1( 2L)
 yada$bla2( 2L, 5.0 )
 
 
 
 And it ends up with this error:
 
 
 
 Error in Module(module, mustStart = TRUE) :
  Failed to initialize module pointer: Error in 
 FUN(_rcpp_module_boot_yada[[1L]], ...): no such symbol 
 _rcpp_module_boot_yada in package .GlobalEnv
 
 
 
 This happens all the time with modules. Did I overlook something or what am I 
 doing wrong?
 
 
 David
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Distribution of Rcpp codebase


Le 7 avr. 2014 à 15:13, Gábor Csárdi csardi.ga...@gmail.com a écrit :

 On Mon, Apr 7, 2014 at 4:12 AM, Romain François rom...@r-enthusiasts.com 
 wrote:
 [...]
 However, in terms of wins:
 - package developers would know for sure which version of the codebase is 
 used with their package. Once they have done testing, they don’t have to be 
 hostage of api breakage and things like « please recompile your package, etc 
 … »
 - developers of Rcpp* are less trapped by the compatibility issues, hands are 
 set free to innovate.
 
 The only small downsides I see here is that (1) users potentially have to do 
 more work to include Rcpp* in their packages (although you can just write an 
 R function to include/update their Rcpp* versions); and that (2) source 
 packages will be somewhat bigger.

The difference is that if they don’t want a new version, they can stick with 
the version they have in their package. So when they want newer Rcpp, they can 
have it, but they are not forced to do anything when the Rcpp* team wants to 
update the codebase. 

About 1). We just need to find a good way to propagate newer Rcpp* into a repo. 
Maybe through git subtree, git sub modules or something. We can come up with 
some tools. 

About 2). So What ;)

 Btw. you are essentially simulating versioned package dependencies this 
 way. :)

Yep. 

 The next thing to consider is that Rcpp is not just Rcpp, there are really 
 nice extensions like RcppArmadillo, etc ... perhaps we could setup some tools 
 (e.g. RcppJam) to combine several header only libraries into the end package, 
 instead of what we do now, which is have some headers in Rcpp, some in 
 RcppArmadillo, some in RcppGSL, … with every risk of one being outdated or 
 out of sync with the other.
 
 Exactly. IMHO this could work well and take the pressure of both Rcpp* 
 developers and users.
 
 Gabor

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] No no no -- Distribution of Rcpp codebase

Le 7 avr. 2014 à 15:34, Dirk Eddelbuettel e...@debian.org a écrit :

 Romain, Gabor,
 
 Would you considerr taking this discussion elsewhere?

This is a broad discussion that might be relevant to anyone doing R and C++ 
work. So no. 

 Or at least make it
 very clear that you are talking about the Rcpp11, which as AFAICT has not
 left Github.

Rcpp11 needs R 3.1.0, so of course it is not on CRAN yet. But this discussion 
is not about the Rcpp11 package, it is not about the Rcpp package. It is about 
exchanging ideas about what would be beneficial to the community of people 
using R and C++. 

The way the Rcpp codebase is currently distributed might have been the best 
model for years, but I’m not convinced it is the best solution nowadays, so I 
wanted to discuss, and this list is the best venue, whether you like it or not. 

As for Rcpp11, I am indeed going to release it as an R package, but I will also 
definitely consider alternatives such as snapshotting the distribution as part 
of the client package. I think there are advantages to doing that. 

But don’t worry, I will definitely not do anything to change the Rcpp package. 
You are doing a fine job of keeping it alive. 

 Rcpp was created as a CRAN package.  It remains a CRAN package.  It fits
 squarely into the dependency mechanism of CRAN.  It has proven useful, and
 stable. As a consequence it is as of today used by almost 200 CRAN packages
 and almost 20 BioC package.
 
 Please do not confuse our users by implying that any of this is about to
 change.  You are more than welcome to experiment with new approaches, new
 implementation, new distributions, ... but *please* make sure you continue to
 do so under a new name too.

or what ? 

 This list is about Rcpp.  The CRAN package.  

In mt view, this list is about R and C++, broadly. At least it was the 
intention when I created it many years ago. There are plenty of threads in this 
list that are not stricly related to Rcpp. The world of R and C++ is bigger 
than Rcpp. 

Romain
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Distribution of Rcpp codebase

Le 7 avr. 2014 à 19:20, Gábor Csárdi csardi.ga...@gmail.com a écrit :

 On Mon, Apr 7, 2014 at 9:20 AM, Romain François rom...@r-enthusiasts.com 
 wrote:
 [...]
 The only small downsides I see here is that (1) users potentially have to do 
 more work to include Rcpp* in their packages (although you can just write an 
 R function to include/update their Rcpp* versions); and that (2) source 
 packages will be somewhat bigger.
 
 The difference is that if they don’t want a new version, they can stick with 
 the version they have in their package. So when they want newer Rcpp, they 
 can have it, but they are not forced to do anything when the Rcpp* team wants 
 to update the codebase. 
 
 About 1). We just need to find a good way to propagate newer Rcpp* into a 
 repo. Maybe through git subtree, git sub modules or something. We can come up 
 with some tools. 
 
 Oh, I see, you mean installing Rcpp* dependent packages from git(hub) 
 directly. I imagine some people would want to put the headers into their 
 tree, as ordinary files.

Having the files into the client package is what I meant. This way, the 
developer of the package is in control of what version is used. The challenge 
is how to make it easy.

 Others might want to have it as submodules. For the latter to work, I imagine 
 you would need to set up some special repo structure.

I think git subtree gives something close to what I mean. But obviously someone 
could just copy the files manually, it would just be a matter of copying the 
inst/include directory. 

 Btw. I obviously don't have to tell you, but I want to point it out that this 
 snapshotting is already possible today. I can just take the Rcpp* headers 
 and put them in my package, and then I don't have to worry about future 
 changes. This is assuming the package is header-only. With compiled code it 
 is trickier, because of the name clashes.

Good luck doing that with current Rcpp. Many functions are compiled into the 
shared library shipped with the package. It is not linking as it used to do it, 
which is the big win of 0.11.0, but there is still a library. 

Many of these functions go through the namespace of the Rcpp package, etc … so 
you could snapshot Rcpp, but it would definitely not be easy at all. 

 So I think, the question is whether to support this with some infrastructure, 
 e.g. to update the embedded headers, have them as a git submodule, etc.
 
 About 2). So What ;)
 
 Agreed. CRAN-core might be fussy about it, though, if source packages get 
 much bigger because of this. Or might be not. 

This is a drop of water in the ocean of CRAN packages. I think the benefit 
would outweigh this quite easily. 

In any case, not gonna happen, at least not with Rcpp. 

Romain

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Distribution of Rcpp codebase