Re: [Rcpp-devel] Rcpp::exception + threads = disaster

[JJ Allaire]

On Sat, Feb 8, 2020 at 3:45 PM Joshua N Pritikin 
wrote:

> On Sat, Feb 08, 2020 at 03:28:22PM -0500, JJ Allaire wrote:
> >Agreed that it would be good to have more clear docs here. Note
> >that as Dirk pointed out both Writing R Extensions and
> >RcppParallel docs are pretty clear about the fact that you
> >shouldn't call any R APIs when in a background thread.
>
> Rcpp::stop superficially looks like a nice way to throw C++ exceptions
> that also does printf style message formatting. I didn't realize that
> it calls R APIs until I looked at the implementation.
>

That's a good point, I had forgotten about the printf stuff which is a good
reason to prefer it to "regular" exceptions.


> Sure, but does it *have* to be that way? It seems to me that
> exceptions.h line 40,
>
>   rcpp_set_stack_trace(Shield(stack_trace()))
>

Not sure about whether this is indeed a mandatory constraint (I didn't work
on the stack trace bit).
___
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::exception + threads = disaster

[JJ Allaire]

I think the point is that the *only* reason Rcpp::stop exists is to do
forwarding to Rf_error. If that isn't your intention it's strictly worse
than a normal C++ exception.

Agreed that it would be good to have more clear docs here. Note that as
Dirk pointed out both Writing R Extensions and RcppParallel docs are pretty
clear about the fact that you shouldn't call any R APIs when in a
background thread.

On Sat, Feb 8, 2020 at 3:23 PM Joshua N Pritikin 
wrote:

> On Sat, Feb 08, 2020 at 02:55:06PM -0500, JJ Allaire wrote:
> >Yes, the only reason to use Rcpp::stop is because you want a C++
> >exception translated safely into an Rf_error at the SEXP call level.
> If
> >you are trying to signal an error from a background thread you would
> >want to use a regular C++ exception rather than Rcpp::stop.
>
> I'm disappointed that there is no interest in making Rcpp::stop work
> in both contexts.
>
> At a minimum, the distinct uses of C++ exceptions and Rcpp::stop
> should be documented better.
>
> --
> Joshua N. Pritikin, Ph.D.
> Virginia Institute for Psychiatric and Behavioral Genetics
> Virginia Commonwealth University
> PO Box 980126
> 800 E Leigh St, Biotech One, Suite 1-133
> Richmond, VA 23219
> http://exuberant-island.surge.sh
>
___
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::exception + threads = disaster

[JJ Allaire]

Yes, the only reason to use Rcpp::stop is because you want a C++ exception
translated safely into an Rf_error at the SEXP call level. If you are
trying to signal an error from a background thread you would want to use a
regular C++ exception rather than Rcpp::stop.

On Sat, Feb 8, 2020 at 1:56 PM Iñaki Ucar  wrote:

> On Fri, 7 Feb 2020 at 14:24, Joshua N Pritikin 
> wrote:
> >
> > On Thu, Feb 06, 2020 at 08:40:02PM -0600, Dirk Eddelbuettel wrote:
> > > On 6 February 2020 at 20:47, Joshua N Pritikin wrote:
> > > | The Rcpp::exception constructor does,
> > > |
> > > |   rcpp_set_stack_trace(Shield(stack_trace()))
> > > |
> > > | This can corrupt R if called within an OpenMP block.
> > >
> > > ... here. In general, we can _never_ call back into R for anything,
> > > exceptions or other things.
> > >
> > > The RcppParallel package documentation is quite good and clear about
> > > this; it even has extra data types RMatrix and RVector to stay away
> > > from R's memory (which Rcpp is close to for performance and zero
> > > copy reasons). The Writing R Extensions manual also as a little, but
> > > maybe less clearly.  In short, there is simply "so much going with
> > > R" that it stands little chance of every being threadsafe.
> > >
> > > Which means that your OpenMP (or pthreads or TBB or ..) code has to
> > > stay away from R.
> >
> > Yeah, so I replaced Rcpp::stop with,
> >
> > template 
> > inline void NORET mxThrow(const char* fmt, Args&&... args) {
> > throw std::runtime_error( tfm::format(fmt,
> std::forward(args)... ).c_str() );
> > }
> >
> > And now things work great. But why does Rcpp::stop need to get the
> > stack_trace? R's stack trace isn't going to change until the control
> > flow returns back to R. So why can't you just set a flag to indicate
> > that "some C++ exception happened" and grab the stack_trace
> > immediately before returning control to R?
>
> Isn't Rcpp::stop's entire purpose to return control to R immediately?
>
> Iñaki
> ___
> 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 functions threadsafe in RcppParallel?

[JJ Allaire]

Here it's recommended that you simply read the source code to figure out if
memory allocations or stack checking are done:
https://rcppcore.github.io/RcppParallel/#api_restrictions

On Sun, Apr 15, 2018 at 11:56 PM, Murray Efford 
wrote:

> Thanks. This is all happening inside a package for CRAN, so I would rather
> avoid more complexity and potential platform-dependence, but I also cannot
> afford for it to break unpredictably (or otherwise).
> Murray
>
> On Mon, Apr 16, 2018 at 3:33 PM, Dirk Eddelbuettel  wrote:
>
>>
>> On 16 April 2018 at 13:41, Murray Efford wrote:
>> | I read in the RcppParallel blurb "The code that you write within
>> parallel
>> | workers should not call the R or Rcpp API in any fashion", which is
>> | admirably clear. However, it leaves me without threadsafe access to
>> | distribution functions (dpois, dbinom etc.). In practice, so far, these
>> R
>> | API calls seem to work for me, but can they be trusted? Is there an
>> | alternative?
>>
>> That's a fair question. They may work, as they are also exposed /
>> available
>> via the standalone R math library (see Writing R Extensions).
>>
>> As such, they may not required memory allocations or other interactions
>> with
>> the R process and hence "not call R ... in any fashion" per the above.
>>
>> But we can't say for sure. If you want to be safe, maybe stick to
>> equivalent functions from a non-R source: C++11, Boost, ...
>>
>> Dirk
>>
>> | (It seems this question must have arisen before, but I haven't found an
>> | answer)
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
>
___
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] Creating an R interface to non-copyable C++ class

[JJ Allaire]

The XPtr is effectively a shared_ptr with special R friendly behavior.
Using XPtr is as simple as just passing a pointer to your dynamically
allocated C++ object to the XPtr constructor, see
https://stackoverflow.com/questions/45947880/pass-a-c-object-as-a-pointer-an-reuse-in-another-function-in-rcpp

One huge benefit of using XPtr is that it has built in protection against
NULL references (as any time your object is serialized/deserialized it will
become invalid). It's also the case that environments like RStudio do
special handling for XPtr (i.e. being sure not to suspend RStudio Server
sessions that have a live XPtr).



On Thu, Apr 12, 2018 at 2:15 PM, Cris Luengo 
wrote:

> Hi Dirk,
>
> I found a more generic solution than a singleton class. I'm extracting
> the pointer out of the `std::unique_ptr` using `release`, and putting it
> into a `std::shared_ptr`. This one can easily be wrapped using the
> standard Rcpp mechanisms.
>
> This is maybe not the best way to do it, I also followed your
> recommendation to look into `Rcpp::XPtr`, and it seems that it
> should be possible to pass it a raw pointer and construct a
> SEXP around it. But that's more code to write, I like the simple
> solutions...
>
> Many thanks for your help!
> Cris.
>
>
>
>
> On 12 April 2018 at 05:42, Dirk Eddelbuettel  wrote:
>
>>
>> On 11 April 2018 at 23:54, Cris Luengo wrote:
>> | > The way R thinks about this is that _it_ owns everything, and Rcpp
>> makes
>> | > getting things back and forth _using the R memory system and its
>> lifetime /
>> | > reference count control_ fairly easy.
>> |
>> | Yes, that makes sense. But somehow it is not easy to transfer ownership
>> | of an object to R. There needs to be a new object created that it can
>> own?
>>
>> Yes, in general that works just fine. Ie when we do
>>
>>Rcpp::NumericVector x(10);
>>
>> we use the R malloc functions, and to R this _is_ the same as a REAL with
>> 10
>> elements.  Because everything has to be a SEXP, our C++ objects are really
>> proxies to underlying SEXPs. And R is happy. And controls everything and
>> it
>> all works as if you used the C API of R.  Which we extend (by a lot, you
>> could say) to make things easier.
>>
>> A unique_ptr with _control on the C++ side_ does not fit that mold at all
>> so
>> we have to do something different here.  The singleton / static instance
>> is
>> one approach _so that it survives across multiple (different) calls_ from
>> R.
>>
>> I am sure there are other approaches, but they still have to match the
>> basic
>> constraint of 'SEXP in, SEXP out'.
>>
>> Hth, Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
>
___
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] function not getting stored properly..

[JJ Allaire]

Rcpp functions compiled with sourceCpp/cppFunction/etc. are not stored
across sessions. If you want this behavior you should write a package.

J.J.

On Fri, Mar 23, 2018 at 7:49 AM, akshay kulkarni 
wrote:

> dear members,
>
>
> I have created a function mygrpc using cppFunction using Rcpp. When I call
> the function after starting the R session, I get the following error:
>
> > mygrpc(xmc1,ygix,ygrpc)
> Error in .Call(, x, ygix, ygrpc) :
>   NULL value passed as symbol address
>
> xmc1 is a matrix of OHLC data of a stock, while ygix and ygrpc are
> functions that act on the daily increment of the stock.
>
> But when I rewrite the function again using cppFunction in Rcpp, and run
> it, it is getting executed. Even the function is getting displayed in the
> output of the ls() function.
>
> I think the function is not getting stored properly, after I finish my
> session in the R console.
>
> Any idea how to store the function properly so that I can use it again in
> my R functions without rewriting ygrpc again and again? If ygrpc is not
> stored properly, why is it getting displayed in the output of the ls()
> function?
>
> Very many thanks for time and effort...
>
> down votefavoritI have created a function mygrpc using cppFunction using
> Rcpp. When I call the function after starting the R session, I get the
> following error:
> 
>
>
> ___
> 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] expose functions dynamically

[JJ Allaire]

Note that you can also include modules within a C++ file and sourceCpp will
automatically add them to the calling environment (as if you had "sourced"
the definition of an R reference class).


On Mon, Dec 4, 2017 at 12:36 PM, Tim Keitt  wrote:

>
>
> http://www.keittlab.org/
>
> On Mon, Dec 4, 2017 at 10:47 AM, David Bellot 
> wrote:
>
>> | - What is the correct way to do that ?
>>>
>>> In a package, yes. Modules require a package. Outside of a package,
>>> consider
>>> using a package instead :)
>>>
>>
>> ​Huh ?
>> OK I'm lost now :-D
>>
>> So in the end, how would it work ? What am I missing in my code to make
>> it work ?
>>
>
> Unless I misunderstood, are you not looking for "Rcpp::sourceCpp"? Don't
> use modules. Just use the // [[Rcpp::export]] attribute.
>
> THK
>
>
>> ​
>>
>>> ​​
>>> I think a few other people / projects have invented other dynamic
>>> schemes but
>>> I do not have a list or overview. Would be handy to have -- maybe someone
>>> wants to blog about a comparison?
>>>
>>
>> ​I'm curious too indeed.​
>>
>> ___
>> 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] Resolving NativeSymbolInfos from Rcpp (revisited)

[JJ Allaire]

The best you can do is to get the pointer to the function (not sure if that
does what you are hoping for):

func <- Rcpp::cppFunction("int foo() { return 1; }")

> body(func)
.Primitive(".Call")()


On Fri, Jul 28, 2017 at 8:00 PM, Iñaki Úcar  wrote:

> 2017-07-29 0:29 GMT+02:00 Dirk Eddelbuettel :
> >
> > On 28 July 2017 at 19:14, Iñaki Úcar wrote:
> > | Hi all,
> > |
> > | I found this interesting thread by Davor Cubranic in which Romain came
> > | up with a solution for calling a C routine from the 'stats' package:
> > | http://lists.r-forge.r-project.org/pipermail/rcpp-
> devel/2010-June/000753.html
> > |
> > | In a nutshell, I would like to do the same, but with a user-provided
> > | function compiled with Rcpp::cppfunction. Namely,
> > |
> > | 1) get the externalptr
> > | 2) get the DL_FUNC with R_ExternalPtrAddrFn
> > | 3) use it
> > |
> > | Thanks to Romain, 2) and 3) are straightforward. The problem is the
> > | first step. I saw that, if I compile a function like this
> > |
> > | > Rcpp::cppFunction("int foo() { return 1; }")
> > |
> > | then I can obtain the externalptr with
> > |
> > | > getNativeSymbolInfo("sourceCpp_ID_foo")
> > |
> > | but the problem is that you have to figure out this ID. Is there a
> > | general way to obtain the name of the native symbol that Rcpp
> > | produces? (Also I suppose that the initial "sourceCpp_" part could
> > | change in the future).
> >
> > I recall that clever trick.
> >
> > The problem is that R Core really does not want us to access such
> unexported
> > access points.
>
> R Core may or may not want us to do 2) and 3), AKA the tricky part.
> But all I'm asking is how to get the externalptr from a cppFunction,
> which is just another (*kinda*) valid R data type. ;) R core provides
> getNativeSymbolInfo and Rcpp sets up the symbol name: it should be
> easy for Rcpp to expose the externalptr (if it's not already the
> case).
>
> Iñaki
> ___
> 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] Starting R Interpreter from C++

[JJ Allaire]

There is also a way to write C++ unit test with the catch framework and
have them added to the R test suite:
https://rdrr.io/cran/testthat/man/use_catch.html

Note this was originally built with integration with testthat in mind but
you can call it from any R test suite (docs on doing this are on the linked
to page).

On Mon, Jun 12, 2017 at 3:47 PM, Wolf Vollprecht 
wrote:

> RInside seems to have done the trick! Awesome.
>
> I have no strong opinions on how to implement the tests. The only reason
> why I wanted the embedded R solution is because we use it that way with
> Python and Julia, and it gives us "raw C++" tests. In the future, we might
> also have a xtensor-test package, that we can easily use to write tests for
> all three languages (in C++) at the same time (through metaprogramming).
>
> But we will definitly also add tests in R (as we have done with Python and
> Julia, too).
> It would be awesome if you have a chance to add some to your variant.
> I am going to fix up the C++ tests that I've added to the "big" PR and
> make sure that at least those we have right now work fine to establish a
> baseline to work from.
>
> Cheers!
>
> Wolf
>
>
> 2017-06-12 4:11 GMT-07:00 Dirk Eddelbuettel :
>
>>
>> On 12 June 2017 at 11:22, Romain Francois wrote:
>> | You might be looking for RInside.
>>
>> Exactly correct in the narrow sense of 'how to get R going from C++'.
>>
>> On 12 June 2017 at 01:11, Wolf Vollprecht wrote:
>> | I am trying to run C++ tests from C++ directly.
>> | It looks like I need to start the R interpreter for memory management
>> etc.
>>
>> The wider, normal sense of the question is, I suspect, how to add unit
>> tests
>> to an R package such as your xtensor-r.  Give me a day or two and I may
>> get a
>> chance to add this to my variant of your project.
>>
>> You generally do NOT want force an embedded R interpreter __as any Rcpp
>> project is already called from R__.  Use CRAN as a repository of (as of
>> today) 1045 example packages.  I don't think a single one embeds R for
>> testing.  The RUnit (older, used by Rcpp itself) and testthat frameworks
>> are
>> popular.
>>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
>
___
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] testthat + sourceCpp

[JJ Allaire]

Not 100% sure about this but I think the workaround for using sourceCpp
within tests is to define R_TESTS="" (that's what we do in Rcpp and
RcppParallel). Here's the code I'm thinking of:
https://github.com/RcppCore/Rcpp/blob/master/tests/doRUnit.R#L42-L43

Note that we use RUnit in both of those packages so there could indeed be
some issue with testthat that we're not aware of.


On Wed, Jan 25, 2017 at 2:33 PM, Tim Keitt  wrote:

> I have a package that compiles C++ at runtime using sourceCpp and I would
> like to use testthat with the package. Its clear that testthat sets up a
> non-standard environment and so it is difficult to combine it with
> sourceCpp. The first hurdle was include paths not working.
>
> This bit of code in the test_ file seemed to fix that:
>
> ccflags = Sys.getenv("CCFLAGS")
> ipath = file.path(getwd(), "inst", "include")
> ccflags = if (nzchar(ccflags)) paste(ccflags, paste0("-I", ipath)) else
> paste0("-I", ipath)
> Sys.setenv(CCFLAGS = ccflags)
>
> However, once compiled, the object does not load correctly as I cannot
> call the compiled function. Does anyone have a workaround? (I have searched
> and not found anything terribly useful.)
>
> 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
>
___
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] CMakeList.txt for c++ and Rcpp

[JJ Allaire]

I would just have CMake call R CMD [SHLIB/build/INSTALL/etc.) as an
external tool. R does a tremendous amount behind the scenes to configure
the build environment and you don't really want to try to replicate that. A
basic package need only place the cpp files within the "src/" directory and
they will be built automatically. More advanced scenarios can be covered
with a custom Makevars[.win] in the "src/" directory.


On Mon, Oct 17, 2016 at 11:49 AM, Janez Bindas 
wrote:

> I am new at R and i would like to automate my building process with cmake.
> I searched the internet for an example of CMakeList.txt in which connect
> C++ and R through Rcpp. I was unable to find that example.
>
> Could you please help me.
>
> Janez Bindas (janex)
>
> ___
> 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] C++ class methods exported via Interfaces Attribute?

[JJ Allaire]

Rcpp attributes only work for global/free functions rather than class
members. If you want to share clashes between packages the only good way to
do it is header-only classes that you put in inst/include.

On Mon, Aug 15, 2016 at 6:17 AM Charles Determan 
wrote:

> Greetings,
>
> I am trying to integrate some packages of mine so they can share some of
> the same C++ functions (not exposed to the R front-end user).  Here is my
> basic structure of the package I wish to export functions.
>
> Class defined in header (foo.h) complete with all public and private
> members.
>
> Members defined in cpp file (foo.cpp).
> This is also where I thought I could use the Rcpp::interfaces(cpp)
> function generate the header file automatically (as I am not aware of a
> nice linking operation between multiple package .so files).  So each method
> is prefixed with //[[Rcpp::export]] for the package building.
>
> I liked this approach because I wouldn't have to rewrite all my methods to
> the header file manually.  However, this doesn't appear to be working.  I
> am getting errors on the first method (I have tried only exporting one
> method and I get the same error).
>
>
> In file included from ../inst/include/gpuR.h:7:0,
>  from RcppExports.cpp:4:
> ../inst/include/gpuR_RcppExports.h:28:20: error: expected unqualified-id
> before ‘<’ token
>  inline template dynEigenMat::dynEigenMat(SEXP A_) {
> ^
> RcppExports.cpp:3313:1: error: expected ‘;’ at end of input
>  }
>  ^
> RcppExports.cpp:3313:1: error: expected ‘}’ at end of input
>
>
> Any insight would be appreciated.  Not sure if it is a problem with using
> the template methods or if this means I simply have a typo somewhere (I
> don't think so given that the code works without using the Rcpp interfaces
> attribute.
>
> Regards,
> Charles
> ___
> 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] type mismatch between NumericMatrix and IntegerMatrix

[JJ Allaire]

In the latter case the integer matrix is "converted" to a numeric matrix
via a copy which is why your modification doesn't work.

That said, modifying an object in place violates R's language semantics and
could lead to incorrect computations (i.e. users expect that objects are
immutable and this is part of what ensures the integrity of computations)
so this is strongly discouraged.

On Sun, Aug 7, 2016 at 7:00 AM, Kaspar Märtens 
wrote:

> Hi,
>
> When experimenting with the following toy function,
>
> // [[Rcpp::export]]
> void modify_matrix(NumericMatrix A){
>   A(0, 0) = 5;
> }
>
> and applying this on matrices defined in R, I occasionally noticed
> unexpected behaviour (as it turns out, on integer matrices).
>
> ### Example 1 (works as expected)
>
> A = matrix(0, 2, 2)
> modify_matrix(A)
> A
>
> ##  [,1] [,2]
> ## [1,]50
> ## [2,]00
>
> ### Example 2 (does not modify the matrix)
>
> A = matrix(1:4, 2, 2)
> modify_matrix(A)
> A
>
> ##  [,1] [,2]
> ## [1,]13
> ## [2,]24
>
> I realised that in the latter case, A consists of integers, so I guess I
> should be using an IntegerMatrix version of my function instead. However,
> shouldn't Rcpp detect the type mismatch between NumericMatrix and
> IntegerMatrix?
>
> Best,
> Kaspar
>
>
> ___
> 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] Setting armadillo preprocessor macros in R package

[JJ Allaire]

If you create a file called pkgname_types.hpp and put it in your src
directory it will be added to RcppExports.cpp ahead of RcppArmadillo.h.
e.g. if your package is named foo then create:

src/foo_types.hpp

And put your #define macros there.



On Thu, Jun 2, 2016 at 3:32 AM, Scott Ritchie  wrote:

> Hi all,
>
> I would like to set my own Armadillo #define macros (i.e. some of those
> listed http://arma.sourceforge.net/docs.html#config_hpp) in an R package
> I have developed.
>
> The instructions there are to put their definitions before the include
> statement to armadillo.h (or in this case RcppArmadillo.h).
>
> However, the first file to compile is RcppExports.cpp, which has `#include
> ` at the top of the file, so my preprocessor macros in my
> source files are ignored when compiling.
>
> Kind regards,
>
> Scott Ritchie
>
> ___
> 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] Shared code in C++ files

[JJ Allaire]

I don't know enough about the mechanics of your scenario to comment
intelligently, but I would in general agree with Dirk that if there is a
way to put something like this in a package that's the way it ought to be
done. You could certainly dispatch to different C++ functions within a
package using a variety of mechanisms including C++ templates, C-style
function pointers, etc. (the mechanics of doing so for your situation I'm
unsure of, but it should be possible).

On Thu, Apr 14, 2016 at 12:25 AM, Martin Lysy  wrote:

> Hello Dirk,
>
> For my specific purpose I have some reservations about package creation.
> Here is a description of the project I have in mind.
>
> I would like to use Rcpp to create a set of generic MCMC algorithms, into
> which a useR could easily hook their own target distributions written in
> C++ with minimal effort.  For example, I would provide the following files:
>
> --
> GibbsSampler.cpp
>
> //[[Rcpp::export]]
> NumericMatrix GibbsSampler(int nIter, NumericVector xInit, List
> tuningParams) {
>   // run some flavor of the Gibbs sampler
> }
> ---
> GibbsSampler.h
>
> double logDensity(NumericVector x);
> ---
>
> Then the useR would write MyDensityA.cpp, which contains the definition of
> logDensity, compile the three files, and have a Gibbs sampler for their
> specific density function written in C++ and ready to go in R.  However, a
> useR might wish to use the GibbsSampler for a different density tomorrow.
> They would have a different definition of logDensity in MyDensityB.cpp.
> Ideally, the useR would have access to Gibbs samplers for both densities in
> the same R session.
>
> I can think of two ways of doing this with Rcpp:
>
> 1.  Compile with sourceCpp (this is what I'm currently doing).  There's
> the minor issue of giving separate R names to each Gibbs sampler, but there
> are many ways around that.  The major issue is that sourceCpp only accepts
> a single .cpp file (or at least as far as my attempts were unsuccessful in
> the original post).  So I'm stuck text-processing a bunch of .cpp and .h
> files together (the actual project I'm working on has about a dozen of
> each).
>
> 2.  Compile an entire R package for each of MyDensityA and MyDensityB.
> However, it seems somewhat cumbersome to have a package loaded for every
> density function in the workspace.  Moreover, naming conflicts are a bit
> more tricky.  Right now (with sourceCpp), I'm using an interface of the form
>
> smpA <- gibbs.sampler(density = MyDensityA, niter = 1e4)
> smpB <- gibbs.sampler(density = MyDensityB, niter = 1e4)
>
> This is to align with things like lm(formula = MyModel).  However, I can't
> quite see how to do this with separate packages loaded.  Rather it seems
> I'd need something like
>
> smpA <- gibbs.sampler.MyDensityA(niter = 1e4)
> smpB <- gibbs.sampler.MyDensityB(niter = 1e4)
>
> However, to do this with packages I feel like I would still have to do
> some text replacement, which I'm already doing with the sourceCpp approach.
>
> In summary, I am not opposed to package creation, but I hope you can see
> my reservations at taking this route.  Perhaps you could please suggest a
> way to achieve what I'm after with separate Rcpp packages for each density
> function.  I take it from your reluctance to answer my original post that
> Rcpp only supports compilation of multiple files through the package
> creation protocol.  I can think of many applications in which the useR
> could supply a minimal amount of C++ code (e.g., a log-likelihood function)
> to hook in with a large amount of code provided by the developer in order
> to speed things up considerably.  So in my opinion it would be worthwhile
> to devise a mechanism to do this correctly.
>
> Best regards,
>
>
> Martin Lysy
> Assistant Professor of Statistics
> Department of Statistics and Actuarial Science
> University of Waterloo
>
> On Wed, Apr 13, 2016 at 5:34 PM, Dirk Eddelbuettel  wrote:
>
>>
>> Martin,
>>
>> Please please please look into creating a package.
>>
>> If you use RStudio:  File -> New Project -> (New or Existing) Directory ->
>> Package and then select Rcpp.
>>
>> If not, consider install the (very tiny) pkgKitten package and call
>> Rcpp.package.skeleton() from Rcpp itself (but enhanced by pkgKitten if
>> present) for a saner package.
>>
>> Cheers, Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
>
___
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] Shared code in C++ files

[JJ Allaire]

Happily it was an easy fix!

https://github.com/RcppCore/Rcpp/commit/3c096d7ae8523222ac8e83d0e15d92af07df1abe

J.J.

On Thu, Apr 14, 2016 at 5:17 AM, JJ Allaire  wrote:

> Martin,
>
> The code = variation won't work on either platform (as there is no
> baseline file path from which to compute the location of included files).
> The file = variation that works on Linux should indeed work on Windows,
> I'll take a look and see what's going on there.
>
> J.J.
>
> On Wed, Apr 13, 2016 at 5:15 PM, Martin Lysy  wrote:
>
>> In the document "Rcpp Attributes: Rcpp version 0.12.3 as of January 10,
>> 2016", Section 2.10.2 explains how to share code between C++ files.  I am
>> obtaining errors when attempting to compile using the outlined steps on
>> both Windows and Linux.
>>
>> Windows:
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Version: Windows 8.1
>> R version 3.2.4 Revised (2016-03-16 r70336) -- "Very Secure Dishes"
>> Rcpp version 0.12.4
>>
>> Linux:
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Version: CentOS release 6.7 (Final)
>> R version: 3.2.2 (2015-08-14) -- "Fire Safety"
>> (I do not have admin privileges to update R on this machine)
>> Rcpp version: 0.12.4
>>
>> Sample code is:
>>
>>
>> #---
>>
>> require(Rcpp)
>>
>> # header file
>> header <- "
>> #ifndef __UTILITIES__
>> #define __UTILITIES__
>> double timesTwo(double x);
>> #endif // __UTILITIES__
>> "
>> cat(header, file = "utilities.hpp")
>>
>> # implementation file
>> impl <- "
>> #include \"utilities.hpp\"
>> double timesTwo(double x) {
>>   return x * 2;
>> }
>> "
>> cat(impl, file = "utilities.cpp")
>>
>> # main file
>> main <- "
>> #include 
>> using namespace Rcpp;
>> #include \"utilities.hpp\"
>> //[[Rcpp::export]]
>> double TimesTwo(double x) {
>>   return timesTwo(x);
>> }
>> "
>> cat(main, file = "main.cpp")
>>
>> # works on linux
>> sourceCpp(file = "main.cpp")
>>
>> # does not work on linux
>> sourceCpp(code = main)
>>
>>
>> #---
>>
>> Neither of the last two commands works for me on Windows.  Attached below
>> is the output of the failed commands for Windows and Linux (first command
>> for former, second command for latter).  Can you please indicate what is
>> wrong with the steps above?
>>
>> Best regards,
>>
>> Martin Lysy
>> Assistant Professor of Statistics
>> Department of Statistics and Actuarial Science
>> University of Waterloo
>>
>> 
>>
>> WINDOWS OUTPUT
>>
>> > sourceCpp(file = "main.cpp", verbose = TRUE)
>>
>> Generated extern "C" functions
>> 
>>
>>
>> #include 
>> // TimesTwo
>> double TimesTwo(double x);
>> RcppExport SEXP sourceCpp_0_TimesTwo(SEXP xSEXP) {
>> BEGIN_RCPP
>> Rcpp::RObject __result;
>> Rcpp::RNGScope __rngScope;
>> Rcpp::traits::input_parameter< double >::type x(xSEXP);
>> __result = Rcpp::wrap(TimesTwo(x));
>> return __result;
>> END_RCPP
>> }
>>
>> Generated R functions
>> ---
>>
>> `.sourceCpp_0_DLLInfo` <-
>> dyn.load('C:/Users/mlysy/AppData/Local/Temp/RtmpclqYkL/sourcecpp_c5c157c5536/sourceCpp_1.dll')
>>
>> TimesTwo <- Rcpp:::sourceCppFunction(function(x) {}, FALSE,
>> `.sourceCpp_0_DLLInfo`, 'sourceCpp_0_TimesTwo')
>>
>> rm(`.sourceCpp_0_DLLInfo`)
>>
>> Building shared library
>> 
>>
>> DIR: C:/Users/mlysy/AppData/Local/Temp/RtmpclqYkL/sourcecpp_c5c157c5536
>>
>> c:/PROGRA~1/R/R-32~1.4RE/bin/x64/R CMD SHLIB -o "sourceCpp_1.dll"
>> "c:\Users\Jerome\Documents\R\test\utilities.cpp" "main.cpp"
>> make: *** No rule to make target
>> `c:\Users\Jerome\Documents\R\test\utilities.o', needed by
>> `sourceCpp_1.dll'.  Stop.
>> Warning message:
>> running command 'make -f "c:/PROGRA~1/R/R-32~1.4R

Re: [Rcpp-devel] Shared code in C++ files

[JJ Allaire]

Martin,

The code = variation won't work on either platform (as there is no baseline
file path from which to compute the location of included files). The file =
variation that works on Linux should indeed work on Windows, I'll take a
look and see what's going on there.

J.J.

On Wed, Apr 13, 2016 at 5:15 PM, Martin Lysy  wrote:

> In the document "Rcpp Attributes: Rcpp version 0.12.3 as of January 10,
> 2016", Section 2.10.2 explains how to share code between C++ files.  I am
> obtaining errors when attempting to compile using the outlined steps on
> both Windows and Linux.
>
> Windows:
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Version: Windows 8.1
> R version 3.2.4 Revised (2016-03-16 r70336) -- "Very Secure Dishes"
> Rcpp version 0.12.4
>
> Linux:
> Platform: x86_64-pc-linux-gnu (64-bit)
> Version: CentOS release 6.7 (Final)
> R version: 3.2.2 (2015-08-14) -- "Fire Safety"
> (I do not have admin privileges to update R on this machine)
> Rcpp version: 0.12.4
>
> Sample code is:
>
>
> #---
>
> require(Rcpp)
>
> # header file
> header <- "
> #ifndef __UTILITIES__
> #define __UTILITIES__
> double timesTwo(double x);
> #endif // __UTILITIES__
> "
> cat(header, file = "utilities.hpp")
>
> # implementation file
> impl <- "
> #include \"utilities.hpp\"
> double timesTwo(double x) {
>   return x * 2;
> }
> "
> cat(impl, file = "utilities.cpp")
>
> # main file
> main <- "
> #include 
> using namespace Rcpp;
> #include \"utilities.hpp\"
> //[[Rcpp::export]]
> double TimesTwo(double x) {
>   return timesTwo(x);
> }
> "
> cat(main, file = "main.cpp")
>
> # works on linux
> sourceCpp(file = "main.cpp")
>
> # does not work on linux
> sourceCpp(code = main)
>
>
> #---
>
> Neither of the last two commands works for me on Windows.  Attached below
> is the output of the failed commands for Windows and Linux (first command
> for former, second command for latter).  Can you please indicate what is
> wrong with the steps above?
>
> Best regards,
>
> Martin Lysy
> Assistant Professor of Statistics
> Department of Statistics and Actuarial Science
> University of Waterloo
>
> 
>
> WINDOWS OUTPUT
>
> > sourceCpp(file = "main.cpp", verbose = TRUE)
>
> Generated extern "C" functions
> 
>
>
> #include 
> // TimesTwo
> double TimesTwo(double x);
> RcppExport SEXP sourceCpp_0_TimesTwo(SEXP xSEXP) {
> BEGIN_RCPP
> Rcpp::RObject __result;
> Rcpp::RNGScope __rngScope;
> Rcpp::traits::input_parameter< double >::type x(xSEXP);
> __result = Rcpp::wrap(TimesTwo(x));
> return __result;
> END_RCPP
> }
>
> Generated R functions
> ---
>
> `.sourceCpp_0_DLLInfo` <-
> dyn.load('C:/Users/mlysy/AppData/Local/Temp/RtmpclqYkL/sourcecpp_c5c157c5536/sourceCpp_1.dll')
>
> TimesTwo <- Rcpp:::sourceCppFunction(function(x) {}, FALSE,
> `.sourceCpp_0_DLLInfo`, 'sourceCpp_0_TimesTwo')
>
> rm(`.sourceCpp_0_DLLInfo`)
>
> Building shared library
> 
>
> DIR: C:/Users/mlysy/AppData/Local/Temp/RtmpclqYkL/sourcecpp_c5c157c5536
>
> c:/PROGRA~1/R/R-32~1.4RE/bin/x64/R CMD SHLIB -o "sourceCpp_1.dll"
> "c:\Users\Jerome\Documents\R\test\utilities.cpp" "main.cpp"
> make: *** No rule to make target
> `c:\Users\Jerome\Documents\R\test\utilities.o', needed by
> `sourceCpp_1.dll'.  Stop.
> Warning message:
> running command 'make -f "c:/PROGRA~1/R/R-32~1.4RE/etc/x64/Makeconf" -f
> "c:/PROGRA~1/R/R-32~1.4RE/share/make/winshlib.mk" -f
> "C:\Users\mlysy\AppData\Roaming/.R/Makevars"
> SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)'
> SHLIB="sourceCpp_1.dll" WIN=64 TCLBIN=64
> OBJECTS="c:\Users\Jerome\Documents\R\test\utilities.o main.o"' had status 2
> Error in sourceCpp(file = "main.cpp", verbose = TRUE) :
>   Error 1 occurred building shared library.
>
> ==
>
> LINUX OUTPUT
>
> > sourceCpp(code = main, verbose = TRUE)
>
> Generated extern "C" functions
> 
>
>
> #include 
> // TimesTwo
> double TimesTwo(double x);
> RcppExport SEXP sourceCpp_0_TimesTwo(SEXP xSEXP) {
> BEGIN_RCPP
> Rcpp::RObject __result;
> Rcpp::RNGScope __rngScope;
> Rcpp::traits::input_parameter< double >::type x(xSEXP);
> __result = Rcpp::wrap(TimesTwo(x));
> return __result;
> END_RCPP
> }
>
> Generated R functions
> ---
>
> `.sourceCpp_0_DLLInfo` <-
> dyn.load('/tmp/RtmpEhyQ33/sourcecpp_7c167caa37d5/sourceCpp_1.so')
>
> TimesTwo <- Rcpp:::sourceCppFunction(function(x) {}, FALSE,
> `.sourceCpp_0_DLLInfo`, 'sourceCpp_0_TimesTwo')
>
> rm(`.sourceCpp_0_DLLInfo`)
>
> Building shared library
> --

Re: [Rcpp-devel] Rcpp 0.12.3 does not compile properly under Solaris 11.2/sparc Error: Could not find a match for std::wstring::basic_string(const char*, const char*) needed in

[JJ Allaire]

Yes, all the checks pass on CRAN because they use the gcc toolchain for
Rcpp and all packages that depend on it:

https://cran.r-project.org/web/checks/check_results_Rcpp.html


On Tue, Feb 9, 2016 at 7:28 AM, Dirk Eddelbuettel  wrote:

>
> Hi Dimitar,
>
> On 9 February 2016 at 12:08, Dimitar Vassilev wrote:
> | Hello,
> | I’m building on top of Oracle R Community edition 3.2, Sun Studio 12.4
> and
> | Solaris 11.2 some packages for internal use.
>
> The problem is likely the Sun Studio compiler. 'Nobody here' uses that
> anymore, and even CRAN / Oxford which tests on Solaris (x86,sparc) uses gcc
> per the tests page:
>
>https://cloud.r-project.org/web/checks/check_results_Rcpp.html
>
> | The error I get when trying to install Rcpp is:
> | >  install.packages("dplyr");
> | also installing the dependency 'Rcpp'
> |
> | trying URL 'http://cran.uni-muenster.de/src/contrib/Rcpp_0.12.3.tar.gz'
> | Content type 'application/x-gzip' length 2374320 bytes (2.3 MB)
> | ==
> | downloaded 2.3 MB
> |
> | trying URL 'http://cran.uni-muenster.de/src/contrib/dplyr_0.4.3.tar.gz'
> | Content type 'application/x-gzip' length 655997 bytes (640 KB)
> | ==
> | downloaded 640 KB
> |
> | * installing *source* package 'Rcpp' ...
> | ** package 'Rcpp' successfully unpacked and MD5 sums checked
> | ** libs
> | /opt/SunProd/studio12u3/solarisstudio12.3/bin/CC -m64
> -I/usr/local/R/include
> | -DNDEBUG -I../inst/include/ -KPIC  -g  -c Date.cpp -o Date.o
> | "../inst/include/Rcpp/Interrupt.h", line 60: Warning (Anachronism):
> Using void
> | (*)(void*) to initialize extern "C" void(*)(void*).
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 43: Error:
> iterator_traits is
> | not a member of std.
>
> We are doing things in C++ which are standard now, but for which Sun Studio
> does not seem to have caught up.
>
> Maybe you need to look into installing the gcc toolchain.
>
> Maybe another list reader has a better idea but I fear that is all we can
> say
> here.
>
> Greetings,  Dirk
>
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 43: Error: A declaration
> does
> | not specify a tag or an identifier.
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 43: Error: Use ";" to
> terminate
> | declarations.
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 43: Error: "}" expected
> instead
> | of "<".
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 188: Error:
> iterator_traits is
> | not a member of std.
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 188: Error: A
> declaration does
> | not specify a tag or an identifier.
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 188: Error: Use ";" to
> | terminate declarations.
> | "../inst/include/Rcpp/vector/MatrixRow.h", line 188: Error: "}" expected
> | instead of "<".
> | "../inst/include/Rcpp/String.h", line 67: Warning: enc hides
> Rcpp::String::enc.
> | "../inst/include/Rcpp/String.h", line 81: Warning: enc hides
> Rcpp::String::enc.
> | "../inst/include/Rcpp/String.h", line 95: Warning: enc hides
> Rcpp::String::enc.
> | "../inst/include/Rcpp/String.h", line 107: Warning: enc hides
> | Rcpp::String::enc.
> | "../inst/include/Rcpp/String.h", line 378: Error: Could not find a match
> for
> | std::wstring::basic_string(const char*, const char*) needed in
> | Rcpp::String::operator std::wstring () const.
> | 9 Error(s) and 5 Warning(s) detected.
> | *** Error code 2
> | make: Fatal error: Command failed for target `Date.o'
> | ERROR: compilation failed for package 'Rcpp'
> | * removing '/usr/local/R/library/Rcpp'
> | ERROR: dependency 'Rcpp' is not available for package 'dplyr'
> | * removing '/usr/local/R/library/dplyr'
> |
> | The downloaded source packages are in
> | '/tmp/RtmpPbHqdD/downloaded_packages'
> | Updating HTML index of packages in '.Library'
> | Making 'packages.html' ... done
> | Warning messages:
> | 1: In install.packages("dplyr") :
> |   installation of package 'Rcpp' had non-zero exit status
> | 2: In install.packages("dplyr") :
> |   installation of package 'dplyr' had non-zero exit status
> | > q();
> |
> | Can you point me what should I do further?
> | My .Renviron is as follows
> | TZ=CET
> | TERM=vt220
> | TAR=/usr/bin/tar
> | R_UNZIPCMD=/usr/bin/unzip
> | R_ZIPCMD=/usr/bin/zip
> | MAKE=/usr/bin/make
> | LD_LIBRARY_PATH=/usr/lib:/usr/local/R/lib:/lib:/usr/local/lib
> | PAGER=/usr/bin/less
> | R_BZIPCMD=/usr/bin/bzip2
> | R_GZIPCMD=/usr/bin/gzip
> | I made a symlink so that the compilation works. Unfortunately the R
> modules
> | have hard-coded the path to the compiler.
> | -bash-4.1# ls -la /opt/SunProd/studio12u3/solarisstudio12.3/bin
> | lrwxrwxrwx   1 root root  26 Feb  4 15:22
> /opt/SunProd/studio12u3/
> | solarisstudio12.3/bin -> /opt/solarisstudio12.4/bin
> |
> | Can someone point me which compiler options/configure arguments are
> needed so
> | that the conversion and compilation is successful?
> | Thanks!
> |
> | __

[Rcpp-devel] [ANN] RcppParallel 4.3.15

[JJ Allaire]

RcppParallel v4.3.15 was recently released to CRAN. RcppParallel has
been on CRAN for a while but more recently added full support for
using Intel TBB (Thread Building Blocks) on both Windows and Solaris
x86. The package website is here:

http://rcppcore.github.io/RcppParallel/

A presentation Dirk and I prepared for the Workshop for Distributed
Computing in R is here (note that the provisos to TBB not working on
Windows or Solaris no longer apply!):

http://dirk.eddelbuettel.com/papers/rcpp_parallel_talk_jan2015.pdf

Note that there is some overlap between OpenMP and Intel TBB.
Advantages of Intel TBB over OpenMP are more flexibility/tunability
(at the cost of moderate additional complexity) as well as broader
platform support (works on Windows, OS X, Linux, and Solaris).

I think most Rcpp packages that implement custom algorithms could
benefit from the use of RcppParallel. Some important qualifiers
though:

1. If your Rcpp code makes substantial use of R math or other R
internal functions you might not see much benefit (as those functions
with rare exception need to be called from the main thread).

2. If you are already taking advantage of parallelism another way (e.g
RcppArmadillo may already be using multiple threads for many
operations via it's interface to the system BLAS/LAPACK) then you
might actually lose performance by layering more thread scheduling on
top of what you've already got.

RcppParallel currently only deals with thread parallelism, however
we're currently exploring adding Boost.SIMD to the package
(https://meetingcpp.com/tl_files/mcpp/slides/12/simd.pdf).

Finally, we have a number of articles on the RcppGallery which provide
example uses of RcppParallel, but they are (save for one) pretty
straightforward toy examples. If folks do find success with the
package we'd love to see a few more articles written about more
sophisticated use cases.

J.J.
___
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 give default value with Rcpp and roxygen2 involving seq_len

[JJ Allaire]

The parsing of default values for attributes has some significant
limitations (it's mostly just use for literals and empty vectors).
This is what is currently supported:

• String literals delimited by quotes (e.g. "foo")
• Decimal numeric values (e.g. 10 or 4.5)
• Pre-defined constants including true, false, R_NilValue, NA_STRING,
NA_INTEGER, NA_REAL, and NA_LOGICAL.
• Selected vector types (CharacterVector, IntegerVector, and
NumericVector) instantiated using the empty form of the ::create
static member function.
• Matrix types instantiated using the rows, cols constructor.


On Wed, Jan 13, 2016 at 10:41 AM, Lafaye de Micheaux Pierre
 wrote:
> Hello everybody,
>
> Let's consider the simple function:
>
> f <- function(x = 1:10) {return(x)}
>
> where the argument 'x' could take non integer values.
>
> I would like to create such a function using Rcpp and roxygen2. If I try
> something like:
>
> //' @param x Vector of real values
> NumericVector f(NumericVector x) {return(x);}
>
> then after creation using devtools, I will obtain a function like this
> one:
> f <- function(x) {return(x)}
>
> How can I write things in my C++ code so that I will obtain
> the x = 1:10 default values?
>
> I tried something like:
>  //' @param x Vector of real values
> NumericVector f(NumericVector x = NumericVector::create(seq_len(10))
> {return(x);}
>
> but it failed completely ...
>
> I am quite new to Rcpp, so I apologize if my question is too naive. If
> this is the case, feel free to send me a web link to some documentation
> that I could learn to try to solve this problem by myself.
>
> Best regards,
>
> Pierre
>
> ___
> 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] Adding a foreign include file to the RcppExports.cpp file

[JJ Allaire]

See "Section 3.4 Types in Generated Code" of the Rcpp Attributes vignette (
https://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-attributes.pdf)


On Wed, Sep 16, 2015 at 1:44 PM, John Merrill 
wrote:

> I'm trying to build an R package which exposes functions which depend on
> Google's re2 library.  In order to do that, I need to depend on
> /usr/local/include/re2.h.
>
> That's really easy in the main cpp files, since #include works  The
> problem arises when I use compileAttributes() to generate an
> RcppExports.cpp file: the generated file doesn't contain the relevant
> #include line.
>
> I've search all the mailing lists I could find as well as groveling
> through all the documentation I could think of.  Evidently, I've missed
> something obvious.  How does one do this?
>
> ___
> 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] clusterExport fails on Rcpp functions

[JJ Allaire]

The problem is that Rcpp functions created via sourceCpp can't be
serialized (their backing shared library is gone when they are
re-serialized). The solution to this is to either:

a) Rebuild them on the cluster nodes (i.e. just include a string with their
source and then call sourceCpp on each node); or

b) Move your C++ functions into an R package that's available on all the
nodes.


On Fri, Sep 11, 2015 at 7:55 AM, Rguy  wrote:

> I find that when I attempt to export Rcpp functions to a cluster using the
> R clusterExport function I get the following error (or some variant
> thereof):
>
> Error in checkForRemoteErrors(val) :
>   5 nodes produced errors; first error: NULL value passed as symbol address
>
> I am running Windows 7, and the cluster is on a quadcore machine.
> Exporting ordinary R functions is completely error-free in my setup.
>
> Has anyone else experienced this problem? Any suggestions on a fix? Thanks.
>
> ___
> 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] When calling same Rcpp function several times different results are returned

[JJ Allaire]

It's because several instances of your object will be created (via the
splitting constructor) and then joined together using the join method.
If all instances share an output variable then they will overwrite
each others' output, giving them their own allows the split/join logic
to work correctly.


On Wed, Jul 15, 2015 at 8:37 AM, Vaidas Zemlys  wrote:
> Hi,
>
> I’ve finally managed to produce code that works. I hope. The key was to
> leave output variable out of constructor:
>
> #include 
> using namespace Rcpp;
> // [[Rcpp::depends(RcppParallel)]]
> #include 
>
> using namespace RcppParallel;
> struct SumsInGroups5: public Worker
> {
> const RVector v;
> const RVector g;
>
> std::vector s;
>
> SumsInGroups5(const NumericVector v, const IntegerVector g): v(v), g(g),
> s(*std::max_element(g.begin(), g.end()) + 1, 0.0){ }
>
> SumsInGroups5(const SumsInGroups5& p, Split): v(p.v), g(p.g),
> s(*std::max_element(g.begin(), g.end()) + 1, 0.0) {}
>
> void operator()(std::size_t begin, std::size_t end) {
> for (std::size_t i = begin; i < end; ++i) {
> s[g[i]]+=v[i];
> }
>
> }
>
> void join(const SumsInGroups5& rhs) {
> for(std::size_t i = 0; i < s.size(); i++) {
> s[i] += rhs.s[i];
> }
> }
> };
>
> // [[Rcpp::export]]
> NumericVector sg5(NumericVector v, IntegerVector g) {
> SumsInGroups5 p(v, g);
> parallelReduce(0, v.length(), p);
> return wrap(p.s);
> }
>
> /*** R
> a <- 1:10
> g <- c(rep(0,5),rep(1,5))
>
>
> bb <- lapply(1:1,function(x)sg5(a,g))
> cc<-do.call("rbind",bb)
> table(cc[,1])
> table(cc[,2])
> */
>
> Looking at the example
> http://gallery.rcpp.org/articles/parallel-distance-matrix/, the ouput is
> initialized in constructor and everything works. So if anybody can explain
> why in this case leaving out the output from the constructor made the code
> work I would be all ears.
>
> Vaidotas Zemlys
>
>
> Le mar. 14 juil. 2015 à 15:22, Danas Zuokas  a écrit
> :
>>
>> I have tried this with no luck.
>>
>> 2015-07-14 14:34 GMT+03:00 Romain Francois :
>>>
>>> Or just use a std::vector for sg. That should do it.
>>>
>>> Romain
>>>
>>> Envoyé de mon iPhone
>>>
>>> > Le 14 juil. 2015 à 13:21, JJ Allaire  a écrit :
>>> >
>>> > The examples in the RcppParallel documentation assume that access to
>>> > vectors and matrixes are *aligned* (i.e. fall into neat buckets
>>> > whereby reading and writing doesn't overlap between worker instances).
>>> > Your example appears to access arbitrary elements of sg (depending on
>>> > what's passed in gi) which probably creates overlapping reads/writes.
>>> > You should also study the documentation for join carefully.
>>> >
>>> > There's nothing incorrect about RcppParallel's behavior here, rather
>>> > you need to think more carefully about the access patterns of your
>>> > data and how they might conflict. You may need to introduce locking to
>>> > overcome the conflicts, which in turn could kill the performance
>>> > benefit you gain from parallelism. No easy answers here :-\
>>> >
>>> >> On Tue, Jul 14, 2015 at 7:15 AM, Danas Zuokas 
>>> >> wrote:
>>> >> Yes it is the same question on SO and I did consider RHertel's
>>> >> comments.
>>> >> But this problem (sums by group id) is not parallelFor it is
>>> >> parallelReduce:
>>> >> I split vector, calculate sums and then aggregate those sums.
>>> >> Please correct me if I am wrong.
>>> >>
>>> >> 2015-07-14 13:54 GMT+03:00 Dirk Eddelbuettel :
>>> >>>
>>> >>>
>>> >>> On 14 July 2015 at 09:25, Danas Zuokas wrote:
>>> >>> | I have written parallel implementation of sums in groups using
>>> >>> RcppParallel.
>>> >>>
>>> >>> Isn't this the same question as
>>> >>>
>>> >>>
>>> >>> http://stackoverflow.com/questions/31318419/when-calling-same-rcpp-function-several-times-different-results-are-returned
>>> >>>
>>> >>> You got some excellent comments there by SO user 'RHertel'. Did you
>>> >>> consider those?
>>> >>>
>>> >>> Dirk
>>> >>>
>>> >

Re: [Rcpp-devel] When calling same Rcpp function several times different results are returned

[JJ Allaire]

Would that still solve the problem if there are overlapping indexes in
gi ? (i.e. if the same index appeared more than one time and was
utilized from more than one thread at a time)

On Tue, Jul 14, 2015 at 7:21 AM, JJ Allaire  wrote:
> The examples in the RcppParallel documentation assume that access to
> vectors and matrixes are *aligned* (i.e. fall into neat buckets
> whereby reading and writing doesn't overlap between worker instances).
> Your example appears to access arbitrary elements of sg (depending on
> what's passed in gi) which probably creates overlapping reads/writes.
> You should also study the documentation for join carefully.
>
> There's nothing incorrect about RcppParallel's behavior here, rather
> you need to think more carefully about the access patterns of your
> data and how they might conflict. You may need to introduce locking to
> overcome the conflicts, which in turn could kill the performance
> benefit you gain from parallelism. No easy answers here :-\
>
> On Tue, Jul 14, 2015 at 7:15 AM, Danas Zuokas  wrote:
>> Yes it is the same question on SO and I did consider RHertel's comments.
>> But this problem (sums by group id) is not parallelFor it is parallelReduce:
>> I split vector, calculate sums and then aggregate those sums.
>> Please correct me if I am wrong.
>>
>> 2015-07-14 13:54 GMT+03:00 Dirk Eddelbuettel :
>>>
>>>
>>> On 14 July 2015 at 09:25, Danas Zuokas wrote:
>>> | I have written parallel implementation of sums in groups using
>>> RcppParallel.
>>>
>>> Isn't this the same question as
>>>
>>> http://stackoverflow.com/questions/31318419/when-calling-same-rcpp-function-several-times-different-results-are-returned
>>>
>>> You got some excellent comments there by SO user 'RHertel'. Did you
>>> consider those?
>>>
>>> Dirk
>>>
>>> | // [[Rcpp::depends(RcppParallel)]]
>>> | #include 
>>> | #include 
>>> | using namespace Rcpp;
>>> | using namespace RcppParallel;
>>> |
>>> | struct SumsG: public Worker
>>> | {
>>> |   const RVector v;
>>> |   const RVector gi;
>>> |
>>> |   RVector sg;
>>> |
>>> |   SumsG(const NumericVector v, const IntegerVector gi, NumericVector
>>> sg): v(v), gi(gi), sg(sg) {}
>>> |   SumsG(const SumsG& p, Split): v(p.v), gi(p.gi), sg(p.sg) {}
>>> |
>>> |   void operator()(std::size_t begin, std::size_t end) {
>>> | for (std::size_t i = begin; i < end; i++) {
>>> |   sg[gi[i]] += v[i];
>>> | }
>>> |   }
>>> |
>>> |   void join(const SumsG& p) {
>>> | for(std::size_t i = 0; i < sg.length(); i++) {
>>> |   sg[i] += p.sg[i];
>>> | }
>>> |   }
>>> | };
>>> |
>>> | // [[Rcpp::export]]
>>> | List sumsingroups(NumericVector v, IntegerVector gi, int ni) {
>>> |   NumericVector sg(ni);
>>> |   SumsG p(v, gi, sg);
>>> |   parallelReduce(0, v.length(), p);
>>> |
>>> |   return List::create(_["sg"] = p.sg);
>>> | }
>>> |
>>> | It compiles using Rcpp::sourceCpp. Now when I call it from R
>>> sumsingroups(1:10,
>>> | rep(0:1, each = 5), 2) several times I get the right answer (15 40) and
>>> then
>>> | something different (usually some multiplicative of the right answer).
>>> Running
>>> |
>>> |
>>> | res <- sumsingroups(1:10, rep(0:1, each = 5), 2)
>>> | for(i in 1:1000) {
>>> | tmp <- sumsingroups(1:10, rep(0:1, each = 5), 2)
>>> | if(res[[1]][1] != tmp[[1]][1]) break
>>> | Sys.sleep(0.1)
>>> | }
>>> |
>>> | breaks at random iteration returning
>>> |
>>> | $sg
>>> | [1]  60 160
>>> |
>>> | or
>>> |
>>> | $sg
>>> | [1] 30 80
>>> |
>>> | I am new to Rcpp and RcppParallel and do not know what could cause such
>>> | behavior.
>>> |
>>> | Things that did not help:
>>> |
>>> |  1. Added for (std::size_t i = 0; i < sg.length(); i++) sg[i] = 0; to
>>> both of
>>> | constructors.
>>> |  2. Changed names so that they are different in Worker definition and in
>>> | function implementation.
>>> |
>>> | ___
>>> | 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
>>>
>>> --
>>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
___
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] When calling same Rcpp function several times different results are returned

[JJ Allaire]

The examples in the RcppParallel documentation assume that access to
vectors and matrixes are *aligned* (i.e. fall into neat buckets
whereby reading and writing doesn't overlap between worker instances).
Your example appears to access arbitrary elements of sg (depending on
what's passed in gi) which probably creates overlapping reads/writes.
You should also study the documentation for join carefully.

There's nothing incorrect about RcppParallel's behavior here, rather
you need to think more carefully about the access patterns of your
data and how they might conflict. You may need to introduce locking to
overcome the conflicts, which in turn could kill the performance
benefit you gain from parallelism. No easy answers here :-\

On Tue, Jul 14, 2015 at 7:15 AM, Danas Zuokas  wrote:
> Yes it is the same question on SO and I did consider RHertel's comments.
> But this problem (sums by group id) is not parallelFor it is parallelReduce:
> I split vector, calculate sums and then aggregate those sums.
> Please correct me if I am wrong.
>
> 2015-07-14 13:54 GMT+03:00 Dirk Eddelbuettel :
>>
>>
>> On 14 July 2015 at 09:25, Danas Zuokas wrote:
>> | I have written parallel implementation of sums in groups using
>> RcppParallel.
>>
>> Isn't this the same question as
>>
>> http://stackoverflow.com/questions/31318419/when-calling-same-rcpp-function-several-times-different-results-are-returned
>>
>> You got some excellent comments there by SO user 'RHertel'. Did you
>> consider those?
>>
>> Dirk
>>
>> | // [[Rcpp::depends(RcppParallel)]]
>> | #include 
>> | #include 
>> | using namespace Rcpp;
>> | using namespace RcppParallel;
>> |
>> | struct SumsG: public Worker
>> | {
>> |   const RVector v;
>> |   const RVector gi;
>> |
>> |   RVector sg;
>> |
>> |   SumsG(const NumericVector v, const IntegerVector gi, NumericVector
>> sg): v(v), gi(gi), sg(sg) {}
>> |   SumsG(const SumsG& p, Split): v(p.v), gi(p.gi), sg(p.sg) {}
>> |
>> |   void operator()(std::size_t begin, std::size_t end) {
>> | for (std::size_t i = begin; i < end; i++) {
>> |   sg[gi[i]] += v[i];
>> | }
>> |   }
>> |
>> |   void join(const SumsG& p) {
>> | for(std::size_t i = 0; i < sg.length(); i++) {
>> |   sg[i] += p.sg[i];
>> | }
>> |   }
>> | };
>> |
>> | // [[Rcpp::export]]
>> | List sumsingroups(NumericVector v, IntegerVector gi, int ni) {
>> |   NumericVector sg(ni);
>> |   SumsG p(v, gi, sg);
>> |   parallelReduce(0, v.length(), p);
>> |
>> |   return List::create(_["sg"] = p.sg);
>> | }
>> |
>> | It compiles using Rcpp::sourceCpp. Now when I call it from R
>> sumsingroups(1:10,
>> | rep(0:1, each = 5), 2) several times I get the right answer (15 40) and
>> then
>> | something different (usually some multiplicative of the right answer).
>> Running
>> |
>> |
>> | res <- sumsingroups(1:10, rep(0:1, each = 5), 2)
>> | for(i in 1:1000) {
>> | tmp <- sumsingroups(1:10, rep(0:1, each = 5), 2)
>> | if(res[[1]][1] != tmp[[1]][1]) break
>> | Sys.sleep(0.1)
>> | }
>> |
>> | breaks at random iteration returning
>> |
>> | $sg
>> | [1]  60 160
>> |
>> | or
>> |
>> | $sg
>> | [1] 30 80
>> |
>> | I am new to Rcpp and RcppParallel and do not know what could cause such
>> | behavior.
>> |
>> | Things that did not help:
>> |
>> |  1. Added for (std::size_t i = 0; i < sg.length(); i++) sg[i] = 0; to
>> both of
>> | constructors.
>> |  2. Changed names so that they are different in Worker definition and in
>> | function implementation.
>> |
>> | ___
>> | 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
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
___
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] Package code industry request

[JJ Allaire]

On Thu, Apr 30, 2015 at 6:09 AM, Sean O'Riordain  wrote:
> I am curious about the phrase "distribute internally" - surely under GPL,
> that is still distribution and all modifications should thus be made public?
> The GPL does not distinguish between "internal" distribution and any other
> kind.
>

Indeed it does:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLRequireSourcePostedPublic
___
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] Integrating RcppParallel and RcppEigen

[JJ Allaire]

Yes, we'd LOVE to see this turned into an Rcpp Gallery article once
you've got everything ironed out!

Details on creating Gallery articles here:
https://github.com/jjallaire/rcpp-gallery/wiki/Contributing-to-the-Rcpp-Gallery

On Tue, Apr 14, 2015 at 5:36 PM, Joshua Wiley  wrote:
> Hi JJ,
>
> Thank you, that worked wonderfully.
>
> Thanks to your help, I've been able to add a simple way of bootstrapping
> with some success, that seems about 25x faster than direct lm() calls using
> 4 threads.
>
> I've put it online in case anyone else runs across this and is interested:
>
> https://gist.github.com/JWiley/d9cba55603471f75d438
> https://gist.github.com/JWiley/8fe93ae105b1fb244f93
>
> There are some residual issues (the results are not an identical match to
> lm(), and occasionally it can make R crash, so I am probably overwriting
> something in memory), but once I figure things out, I will fix the gist
> files too.
>
> Thanks again for your help and the great package!
>
> Cheers,
>
> Josh
>
>
>
>
>
>
>
> On Tue, Apr 14, 2015 at 7:54 PM, JJ Allaire  wrote:
>>
>> The initialization of your const fields needs to happen within the
>> initializer list (rather than inline where the fields are declared).
>> If you substitute this code for the code in your example everything
>> will compile:
>>
>>   // QR Decomposition
>>   const CPivQR PQR;
>>   const Permutation Pmat;
>>   const int r;
>>
>>   // output
>>   RMatrix betamat;
>>   Eigen::VectorXd betahat;
>>
>>   // initialize with input and output
>>   CVLM(const Eigen::VectorXd y, const Eigen::MatrixXd X,
>> Rcpp::NumericMatrix betamat)
>> : y(y), X(X), PQR(X), Pmat(PQR.colsPermutation()), r(PQR.rank()),
>> betamat(betamat) {}
>>
>>
>>
>> On Tue, Apr 14, 2015 at 4:41 AM, Joshua Wiley 
>> wrote:
>> > Hi,
>> >
>> > I'm interested in combining faster linear model estimation via QR
>> > decompositions from RcppEigen with JJs new(er) RcppParallel package to
>> > do
>> > cross validation and bootstrapping on linear models.
>> >
>> > As a first step, I've been trying to merge the JSS paper on RcppEigen (
>> > http://www.jstatsoft.org/v52/i05/paper ) with about the documentation
>> > for
>> > RcppParallel ( http://rcppcore.github.io/RcppParallel/#examples )
>> >
>> > ignoring bootstrapping and cross validation for the time being and just
>> > getting a linear model to run in the parallel framework.  I've toyed
>> > with
>> > each separately successfuly, and think I am somewhat close to getting
>> > them
>> > together, but I am running into an error:
>> >
>> > partest.cpp:28:20: error: 'X' is not a type
>> > partest.cpp:29:26: error: 'PQR' is not a type
>> > partest.cpp:29:29: error: expected ',' or '...' before '.' token
>> > partest.cpp:30:15: error: 'PQR' is not a type
>> > partest.cpp:30:18: error: expected ',' or '...' before '.' token
>> > partest.cpp: In member function 'virtual void
>> > CVLM::operator()(std::size_t,
>> > std::size_t)':
>> > partest.cpp:44:28: warning: comparison between signed and unsigned
>> > integer
>> > expressions [-Wsign-compare]
>> > make: *** [partest.o] Error 1
>> >
>> > My code is below (run via sourceCpp() ), and I can see exactly where the
>> > first error occurs, but I don't understand why this is OK when run
>> > outside
>> > of RcppParallel, but so very wrong in conjunction with RcppParallel.
>> >
>> > Any pointers on either what's wrong or where I should be reading would
>> > be
>> > deeply appreciated.
>> >
>> > Josh (code below)
>> >
>> >
>> > // [[Rcpp::depends(RcppParallel)]]
>> > // [[Rcpp::depends(RcppEigen)]]
>> > #include 
>> > #include 
>> > #include 
>> >
>> > using namespace std;
>> > using namespace Rcpp;
>> > using namespace RcppParallel;
>> >
>> > using Eigen::Lower;
>> > using Eigen::Map;
>> > using Eigen::MatrixXd;
>> > using Eigen::Upper;
>> > using Eigen::VectorXd;
>> > typedef Map MapMatd;
>> > typedef Map MapVecd;
>> > typedef Eigen::ColPivHouseholderQR CPivQR;
>> > typedef CPivQR::PermutationType Permutation;
>> >
>> > struct CVLM : p

Re: [Rcpp-devel] Integrating RcppParallel and RcppEigen

[JJ Allaire]

The initialization of your const fields needs to happen within the
initializer list (rather than inline where the fields are declared).
If you substitute this code for the code in your example everything
will compile:

  // QR Decomposition
  const CPivQR PQR;
  const Permutation Pmat;
  const int r;

  // output
  RMatrix betamat;
  Eigen::VectorXd betahat;

  // initialize with input and output
  CVLM(const Eigen::VectorXd y, const Eigen::MatrixXd X,
Rcpp::NumericMatrix betamat)
: y(y), X(X), PQR(X), Pmat(PQR.colsPermutation()), r(PQR.rank()),
betamat(betamat) {}



On Tue, Apr 14, 2015 at 4:41 AM, Joshua Wiley  wrote:
> Hi,
>
> I'm interested in combining faster linear model estimation via QR
> decompositions from RcppEigen with JJs new(er) RcppParallel package to do
> cross validation and bootstrapping on linear models.
>
> As a first step, I've been trying to merge the JSS paper on RcppEigen (
> http://www.jstatsoft.org/v52/i05/paper ) with about the documentation for
> RcppParallel ( http://rcppcore.github.io/RcppParallel/#examples )
>
> ignoring bootstrapping and cross validation for the time being and just
> getting a linear model to run in the parallel framework.  I've toyed with
> each separately successfuly, and think I am somewhat close to getting them
> together, but I am running into an error:
>
> partest.cpp:28:20: error: 'X' is not a type
> partest.cpp:29:26: error: 'PQR' is not a type
> partest.cpp:29:29: error: expected ',' or '...' before '.' token
> partest.cpp:30:15: error: 'PQR' is not a type
> partest.cpp:30:18: error: expected ',' or '...' before '.' token
> partest.cpp: In member function 'virtual void CVLM::operator()(std::size_t,
> std::size_t)':
> partest.cpp:44:28: warning: comparison between signed and unsigned integer
> expressions [-Wsign-compare]
> make: *** [partest.o] Error 1
>
> My code is below (run via sourceCpp() ), and I can see exactly where the
> first error occurs, but I don't understand why this is OK when run outside
> of RcppParallel, but so very wrong in conjunction with RcppParallel.
>
> Any pointers on either what's wrong or where I should be reading would be
> deeply appreciated.
>
> Josh (code below)
>
>
> // [[Rcpp::depends(RcppParallel)]]
> // [[Rcpp::depends(RcppEigen)]]
> #include 
> #include 
> #include 
>
> using namespace std;
> using namespace Rcpp;
> using namespace RcppParallel;
>
> using Eigen::Lower;
> using Eigen::Map;
> using Eigen::MatrixXd;
> using Eigen::Upper;
> using Eigen::VectorXd;
> typedef Map MapMatd;
> typedef Map MapVecd;
> typedef Eigen::ColPivHouseholderQR CPivQR;
> typedef CPivQR::PermutationType Permutation;
>
> struct CVLM : public Worker
> {
>   // design matrix and outcome
>   const Eigen::VectorXd y;
>   const Eigen::MatrixXd X;
>
>   // QR Decomposition
>   const CPivQR PQR(X); // ERROR HAPPENS HERE
>   const Permutation Pmat(PQR.colsPermutation());
>   const int r(PQR.rank());
>
>
>   // output
>   RMatrix betamat;
>   Eigen::VectorXd betahat;
>
>   // initialize with input and output
>   CVLM(const Eigen::VectorXd y, const Eigen::MatrixXd X, Rcpp::NumericMatrix
> betamat)
> : y(y), X(X), betamat(betamat) {}
>
>   void operator()(std::size_t begin, std::size_t end) {
>
> //betahat = PQR.solve(y);
> for(int j = begin; j < end; j++) {
>   betamat(j, j) = X(j, j) + y[j];
> }
>   }
> };
>
> // [[Rcpp::export]]
> NumericMatrix parallelFit(Eigen::VectorXd dv, Eigen::MatrixXd x) {
>
>   // allocate the output matrix
>   NumericMatrix betamat(x.rows(), x.cols());
>
>   // pass input and output
>   CVLM cvLM(dv, x, betamat);
>
>   // parallelFor to do it
>   parallelFor(0, x.rows(), cvLM);
>
>   return betamat;
> }
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Joshua F. Wiley
> http://joshuawiley.com/
> ---
> Postdoctoral Research Fellow
> Mary MacKillop Institute for Health Research
> Australian Catholic University
> ---
> Senior Analyst, Elkhart Group Ltd.
> http://elkhartgroup.com
> Office: 260.673.5518
>
> ___
> 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] RcppParallel on Solaris

[JJ Allaire]

We only see the "long long" warnings with clang on Debian testing with
-pedantic enabled. Note that not all CRAN maintainers test under this
configuration so sometimes it depends on who is reviewing the
submission. My first preference would be to ensure that these warnings
don't occur so we always pass muster. However as you point out it can
be fragile and risky to modify upstream code so perhaps asking for an
exception is the right course.





On Mon, Apr 13, 2015 at 9:42 AM, Gábor Csárdi  wrote:
> On Mon, Apr 13, 2015 at 8:32 AM, Dirk Eddelbuettel  wrote:
>>
>>
>> On 13 April 2015 at 08:03, JJ Allaire wrote:
>> | I'll have to take a closer look at the warnings. One other issue that
>> | needs to be resolved prior to the next submission to CRAN revolves
>> | around pedantic warnings on Debian testing that prohibit "long long"
>> | (used by both TinyThread and TBB). The easy workaround is
>> | SystemRequirements: C++11 however this will mean that package won't
>> | compile on pre-Mavericks Macs (~30% of all Macs) nor RedHat/CentOS
>> | systems. Perhaps I can modify TinyThread and TBB to no longer use
>> | "long long" but I'll need to do this very carefully.
>>
>> I never found another way to get 'long long' besides requiring C++11.
>
>
> It might be fine, actually. I have a package with long long on CRAN, and
> yes, they asked me to "fix it", but like for you, it is in upstream code, so
> I am not really comfortable removing it, and CRAN seems to be OK with it
> now.
>
> Other packages seem to have it, too:
> https://github.com/search?q=user%3Acran+%22long+long%22&type=Code&utf8=%E2%9C%93
> I doubt that these all require C++11.
>
> Also, all compilers they use have long long, so what is the point, really?
>
> 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] RcppParallel on Solaris

[JJ Allaire]

One other issue to run down is detecting the current architecture on
Solaris builds. Right now we force 32-bit in Makevars as follows:

ifeq ($(USE_TBB), SunOS)
   MAKE_ARGS += arch=ia32
endif

Does anyone know if there is a variable we could inspect from within
Makevars that would tell us the architecture for R itself? (as opposed
to the underlying system).


On Mon, Apr 13, 2015 at 8:03 AM, JJ Allaire  wrote:
> That's excellent I just updated the branch to reflect this change
> and also successfully ran the tests on the Solaris config that you
> provided me access to.
>
> I'll have to take a closer look at the warnings. One other issue that
> needs to be resolved prior to the next submission to CRAN revolves
> around pedantic warnings on Debian testing that prohibit "long long"
> (used by both TinyThread and TBB). The easy workaround is
> SystemRequirements: C++11 however this will mean that package won't
> compile on pre-Mavericks Macs (~30% of all Macs) nor RedHat/CentOS
> systems. Perhaps I can modify TinyThread and TBB to no longer use
> "long long" but I'll need to do this very carefully.
>
>
>
>
> On Sun, Apr 12, 2015 at 10:30 PM, Gábor Csárdi  wrote:
>> Hi JJ & all,
>>
>> I had some time, had an idea, and made it to work. The problem was that TBB
>> was not compiled with the same flags as R and the rest of the R package, so
>> just had to find what is the difference that is incompatible.
>>
>> It is simple, you need to compile TBB with -library=stlport4
>> So if you change line 34 in SunOS.suncc.inc  to
>>
>> CPLUS = CC -library=stlport4
>>
>> then it compiles and installs fine. What's even better, the tests run fine,
>> too. They spit out a lot of compiler warnings, but they all pass.
>>
>> Best,
>> Gabor
>>
>> On Wed, Apr 8, 2015 at 11:38 AM, Gábor Csárdi 
>> wrote:
>>>
>>> Ok, the server seems to work. JJ, I'll send you a private email. If anyone
>>> wants access, please email me in private.
>>>
>>> Remember that this is just a mac mini, so it might not be super fast. It
>>> seems fast enough for a single user, though.
>>>
>>> Gabor
>>>
>>> On Tue, Apr 7, 2015 at 7:17 PM, Gábor Csárdi 
>>> wrote:
>>>>
>>>> On Tue, Apr 7, 2015 at 6:50 PM, Jeroen Ooms  wrote:
>>>> [...]
>>>>>
>>>>> So that's why I thought they probably use GCC for packages that don't
>>>>> work with Solaris Studio.
>>>>
>>>>
>>>> I see. That would indeed make sense. G.
>>>>
>>>
>>
___
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] RcppParallel on Solaris

[JJ Allaire]

That's excellent I just updated the branch to reflect this change
and also successfully ran the tests on the Solaris config that you
provided me access to.

I'll have to take a closer look at the warnings. One other issue that
needs to be resolved prior to the next submission to CRAN revolves
around pedantic warnings on Debian testing that prohibit "long long"
(used by both TinyThread and TBB). The easy workaround is
SystemRequirements: C++11 however this will mean that package won't
compile on pre-Mavericks Macs (~30% of all Macs) nor RedHat/CentOS
systems. Perhaps I can modify TinyThread and TBB to no longer use
"long long" but I'll need to do this very carefully.




On Sun, Apr 12, 2015 at 10:30 PM, Gábor Csárdi  wrote:
> Hi JJ & all,
>
> I had some time, had an idea, and made it to work. The problem was that TBB
> was not compiled with the same flags as R and the rest of the R package, so
> just had to find what is the difference that is incompatible.
>
> It is simple, you need to compile TBB with -library=stlport4
> So if you change line 34 in SunOS.suncc.inc  to
>
> CPLUS = CC -library=stlport4
>
> then it compiles and installs fine. What's even better, the tests run fine,
> too. They spit out a lot of compiler warnings, but they all pass.
>
> Best,
> Gabor
>
> On Wed, Apr 8, 2015 at 11:38 AM, Gábor Csárdi 
> wrote:
>>
>> Ok, the server seems to work. JJ, I'll send you a private email. If anyone
>> wants access, please email me in private.
>>
>> Remember that this is just a mac mini, so it might not be super fast. It
>> seems fast enough for a single user, though.
>>
>> Gabor
>>
>> On Tue, Apr 7, 2015 at 7:17 PM, Gábor Csárdi 
>> wrote:
>>>
>>> On Tue, Apr 7, 2015 at 6:50 PM, Jeroen Ooms  wrote:
>>> [...]

 So that's why I thought they probably use GCC for packages that don't
 work with Solaris Studio.
>>>
>>>
>>> I see. That would indeed make sense. G.
>>>
>>
>
___
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] RcppParallel on Solaris

[JJ Allaire]

Thanks Jeroen!

Does the ORD version of R use GNU make? (I think we need that for the
RcppParallel makefile). If it doesn't, Gábor do you know if there is a
straightforward way to force it to use GNU make? (or as Jeroen
hypothesizes does CRAN use gcc when testing packages that have GNU
make as a SystemDependency?)

On Tue, Apr 7, 2015 at 4:04 PM, Jeroen Ooms  wrote:
> I've put a copy of my vm image here in case anyone is interested:
> https://gist.github.com/jeroenooms/4c61c821172ad640545d
>
> It is still unclear to me what the exact CRAN setup is. For example
> for the openssl package I had to use the $OPENSSL_INCLUDES variable
> which points to /opt/csw/includes. However on the Solaris 11 vm, the
> openssl headers are simply in /usr/local and can be found without any
> specific flags.
>
>
> On Tue, Apr 7, 2015 at 2:47 AM, JJ Allaire  wrote:
>>
>> I think this is just a matter of passing the right runtime library
>> flag to the TBB configure script (but perhaps this masks a bigger
>> issue, we'll see).
>>
>> Gábor is going to make his VM available to me for further testing and
>> iteration later this week. Hope to be able to report some progress
>> after that.
>>
>>
>>
>> On Mon, Apr 6, 2015 at 9:41 PM, Gábor Csárdi  wrote:
>> > Yeah, you need GNU make.
>> >
>> > We had some progress off-list. This is where we are now:
>> >
>> >> Btw. if you remove -m64, then the 32 bit version is built and there is
>> >> another linking problem:
>> >> Error : .onLoad failed in loadNamespace() for 'RcppParallel', details:
>> >>   call: dyn.load(tbb, local = FALSE, now = TRUE)
>> >>   error: unable to load shared object
>> >> '/export/home/csardi/R/R-3.1.3/lib/R/library/RcppParallel/lib/libtbb.so':
>> >>   ld.so.1: R: fatal: relocation error: file
>> >> /export/home/csardi/R/R-3.1.3/lib/R/library/RcppParallel/lib/libtbb.so:
>> >> symbol __1cDstdNruntime_error2T6M_v_: referenced symbol not found
>> >>
>> >>
>> >>
>> >> https://github.com/gaborcsardi/RcppParallel/commits/feature/tbb-solaris
>> >
>> >
>> > G.
>> >
>> > On Mon, Apr 6, 2015 at 9:36 PM, Jeroen Ooms  wrote:
>> >>
>> >> On Fri, Apr 3, 2015 at 4:44 AM, JJ Allaire  wrote:
>> >>>
>> >>>
>> >>> git clone -b feature/tbb-solaris 
>> >>> g...@github.com:RcppCore/RcppParallel.git
>> >>> R CMD build RcppParallel && R CMD check --as-cran
>> >>> RcppParallel_4.3.7.tar.gz
>> >>
>> >>
>> >> It complains about a problem with make:
>> >>
>> >> root@solaris11:~/Desktop# /opt/csw/bin/R CMD INSTALL
>> >> RcppParallel_4.3.7.tar.gz
>> >> * installing to library '/opt/csw/lib/R/library'
>> >> * installing *source* package 'RcppParallel' ...
>> >> ** libs
>> >> make: Fatal error in reader: Makevars, line 5: Unexpected end of line seen
>> >> ERROR: compilation failed for package 'RcppParallel'
>> >> * removing '/opt/csw/lib/R/library/RcppParallel'
>> >>
>> >
___
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] On Developing Header Packages

[JJ Allaire]

I think that header-only packages (where possible) are definitely
preferable within the R package ecosystem because it allows you to
sidestep a lot of build configuration and runtime linking complexity.

The rub is that some libraries simply can't be made header-only,
especially if they make use of static data. I was able to convert the
TinyThread library to header-only by simply prefacing all
function/method definitions with the inline keyword. However that was
a pretty small library so I'm not sure you'd have the same easy time
of it with a larger library like clBLAS.


On Tue, Apr 7, 2015 at 2:37 PM, Charles Determan  wrote:
> This is probably the best place I can think of to ask this question if
> perhaps not completely on topic.  Some quick context:
>
> I am exploring GPGPU computing and with my 'open-source' mindset I quickly
> gravitated to using OpenCL.  Thankfully, many wonderful programmers have
> already begun creating libraries to make this language better and faster.
> One such library is the clBLAS library which essentially implements BLAS
> routines for OpenCL enabled devices. Naturally, I would like to use this
> library but I don't like the idea of telling users to install a dependency
> outside of R and would rather have them install another package.  Therefore,
> I have it in my head to create a header package for the clBLAS library to be
> used by anyone exploring OpenCL programming within R.
>
> This leads me to my two general questions that I hope others can comment.
>
> 1.  What are developers thoughts regarding the 'packaging' of various C++
> header libraries?  I know this has be very successfully done with the 'BH'
> package but is this considered an exception or an example?
>
> 2. If it is encouraged to create such header packages are there any
> guidelines or standards that should be followed?  Is there an expected
> structure?  I can look at the 'BH' package and go from there but it would be
> nice if the R(cpp) community had some collective opinion about this.
>
> Regards,
> Charles
>
> ___
> 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] RcppParallel on Solaris

[JJ Allaire]

I think this is just a matter of passing the right runtime library
flag to the TBB configure script (but perhaps this masks a bigger
issue, we'll see).

Gábor is going to make his VM available to me for further testing and
iteration later this week. Hope to be able to report some progress
after that.



On Mon, Apr 6, 2015 at 9:41 PM, Gábor Csárdi  wrote:
> Yeah, you need GNU make.
>
> We had some progress off-list. This is where we are now:
>
>> Btw. if you remove -m64, then the 32 bit version is built and there is
>> another linking problem:
>> Error : .onLoad failed in loadNamespace() for 'RcppParallel', details:
>>   call: dyn.load(tbb, local = FALSE, now = TRUE)
>>   error: unable to load shared object
>> '/export/home/csardi/R/R-3.1.3/lib/R/library/RcppParallel/lib/libtbb.so':
>>   ld.so.1: R: fatal: relocation error: file
>> /export/home/csardi/R/R-3.1.3/lib/R/library/RcppParallel/lib/libtbb.so:
>> symbol __1cDstdNruntime_error2T6M_v_: referenced symbol not found
>>
>>
>>
>> https://github.com/gaborcsardi/RcppParallel/commits/feature/tbb-solaris
>
>
> G.
>
> On Mon, Apr 6, 2015 at 9:36 PM, Jeroen Ooms  wrote:
>>
>> On Fri, Apr 3, 2015 at 4:44 AM, JJ Allaire  wrote:
>>>
>>>
>>> git clone -b feature/tbb-solaris g...@github.com:RcppCore/RcppParallel.git
>>> R CMD build RcppParallel && R CMD check --as-cran
>>> RcppParallel_4.3.7.tar.gz
>>
>>
>> It complains about a problem with make:
>>
>> root@solaris11:~/Desktop# /opt/csw/bin/R CMD INSTALL
>> RcppParallel_4.3.7.tar.gz
>> * installing to library '/opt/csw/lib/R/library'
>> * installing *source* package 'RcppParallel' ...
>> ** libs
>> make: Fatal error in reader: Makevars, line 5: Unexpected end of line seen
>> ERROR: compilation failed for package 'RcppParallel'
>> * removing '/opt/csw/lib/R/library/RcppParallel'
>>
>
___
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] RcppParallel on Solaris

[JJ Allaire]

On Thu, Apr 2, 2015 at 3:42 PM, Gábor Csárdi  wrote:
> I have Solaris x86_64 on Virtualbox, and it runs fine. The problem is, it is
> x86, and not Sparc, so for example byte order issues do not come up.

Would you be willing to try the following as a minimal test that our
changes are enough to make RcppParallel work on Solaris x86_64:

git clone -b feature/tbb-solaris g...@github.com:RcppCore/RcppParallel.git
R CMD build RcppParallel && R CMD check --as-cran RcppParallel_4.3.7.tar.gz
___
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] RcppParallel on Solaris

[JJ Allaire]

> I am happy to share my experience with Solaris. I have been meaning to
> write a step-by-step guide to setting up a Solaris testing platform for
> R on a VirtualBox VM, so this gives me some impetus to write it.

That would be excellent! I got as far as getting R running on a
VirtualBox but got hung up on compiler configuration such that was
unable to build packages that included native code.
___
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] RcppParallel on Solaris

[JJ Allaire]

If it's possible to run Solaris on AWS without an extra per-hour
charge then it would only be a matter of creating the AMI then any one
of us could use it within our own AWS accounts at no extra
(incremental) cost.




On Thu, Apr 2, 2015 at 10:31 AM, Romain Francois
 wrote:
> Would be useful to have a solaris machine on aws or whatever with R all these 
> toils installed.
>
> I once had a virtual machine set up thanks to martyn but the user experience 
> of virtualbox + keyboard conflicts with my french mac book keyboard was not 
> that good.
>
> Does someone have the skills to set up a machine on aws once and (almost for 
> all) ?
> Would someone be willing to pay for the machine ?
>
> Romain
>
>> Le 2 avr. 2015 à 15:58, JJ Allaire  a écrit :
>>
>> We've recently done some work on RcppParallel to make it work on
>> Windows (previously it worked on Linux and OS X only). It would be
>> wonderful to also get it working on Solaris, and in theory this
>> shouldn't be difficult as the library at the core of RcppParallel,
>> Intel Threading Building Blocks (TBB), has full support for both Sun
>> and GCC compilers on Solaris
>>
>> This branch does what I think is necessary:
>>
>> https://github.com/RcppCore/RcppParallel/tree/feature/tbb-solaris
>>
>> Unfortunately none of my attempts to setup a working Solaris
>> development environment have succeeded so I have no way of testing
>> this. I'm writing to see if anyone on the list would be willing to
>> help with testing/tweaking on Solaris.
>>
>> More background on RcppParallel is here: 
>> http://rcppcore.github.io/RcppParallel/
>>
>> Thanks,
>>
>> J.J.
>> ___
>> 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] RcppParallel on Solaris

[JJ Allaire]

We've recently done some work on RcppParallel to make it work on
Windows (previously it worked on Linux and OS X only). It would be
wonderful to also get it working on Solaris, and in theory this
shouldn't be difficult as the library at the core of RcppParallel,
Intel Threading Building Blocks (TBB), has full support for both Sun
and GCC compilers on Solaris

This branch does what I think is necessary:

https://github.com/RcppCore/RcppParallel/tree/feature/tbb-solaris

Unfortunately none of my attempts to setup a working Solaris
development environment have succeeded so I have no way of testing
this. I'm writing to see if anyone on the list would be willing to
help with testing/tweaking on Solaris.

More background on RcppParallel is here: http://rcppcore.github.io/RcppParallel/

Thanks,

J.J.
___
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] stop and Rf_error cause the same problem

[JJ Allaire]

Yup, we're aware of the stop issue as well (it has the same root cause).

J.J.

On Fri, Mar 13, 2015 at 12:49 PM, Jack Wasey  wrote:
> I've seen it said that calling Rf_error is the cause of the new hang with
> Rtools33, quoting my example in (closed) github issue
> https://github.com/RcppCore/Rcpp/issues/276
>
> Just to be clear, the calling Rcpp::stop hung in exactly the same way, but I
> did at that time also demonstrate the bug using Rf_error.
>
> Hope that clarifies things a little,
> Jack
> ___
> 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] V8 crashes on 32bit windows when built with new Rtools

[JJ Allaire]

It's not posix per-se, it's "posix threads" (of which there is a win32
port available in mingw). This is done sometimes to ease porting of
software from posix to windows.

An update: Kevin submitted a patch to use win32 threads for Rtools
(restoring the previous behavior) and Duncan is rebuilding Rtools now
with this change. Once we have this update in hand we can test again.



On Thu, Mar 12, 2015 at 7:13 PM, Avraham Adler  wrote:
> Why would posix be enabled for a Windows target?
>
> Avi
>
> On Thu, Mar 12, 2015 at 6:49 PM, Duncan Murdoch 
> wrote:
>>
>> On 12/03/2015 5:51 PM, Jeroen Ooms wrote:
>> > On Thu, Mar 12, 2015 at 2:40 PM, JJ Allaire > > <mailto:jj.alla...@gmail.com>> wrote:
>> >
>> > I had an issue like this in RcppParallel that was solved by
>> > rebuilding
>> > Rcpp from source using the very latest R-devel and Rtools 3.3. Have
>> > you tried that?
>> >
>> >
>> > Yes, that doesn't seem to help.
>> >
>> > I have a suspicion now. I have seen this behavior before when linking
>> > libraries on windows that were built with different threading models.
>> > Based on gcc -v, the old rtools (and hence my v8 static libs) use win32
>> > threading, whereas the new rtools has been built with
>> > --enable-threads=posix.
>>
>> The scripts are on CRAN, if you want to try modifying them.  However, if
>> the scripts aren't satisfactory very soon, I'll just go back to the
>> previous Rtools.
>>
>> Duncan
>>
>> ___
>> 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] New Windows toolchain

[JJ Allaire]

We think the second issue may be caused by Rtools linking against
posix threads rather than win32 threads (which it did in previous
versions). We will attempt to create a patched version of Rtools today
that can be used to verify this.

J.J.

On Fri, Mar 13, 2015 at 6:22 AM, Henrik Singmann
 wrote:
> Hi Kevin,
>
> Sorry to step in here but I would like to draw your attention to my mail
> from yesterday pointing to the fact that there seem to be two issues right
> now.
>
> 1. The issue you mentioned which can be easily reproduced by running the
> following to lines in R-devel 64bit on Windows with the following lines:
> Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }")
> doError()
>
> 2. The issue I mentioned in my previous mail regarding RcppEigen which can
> be reproduced by installing RcppEigen from source on 32bit R-devel and
> running the following line from the unit tests to crash R:
>
> # code #
> install.packages("RcppEigen", type = "source")
> require(RcppEigen)
> data(trees, package="datasets")
> .Call("fastLm",cbind(1, log(trees$Girth)),log(trees$Volume),
> 2L,PACKAGE="RcppEigen")
> # end code #
>
> It seems to even be enough to install RcppEigen from source on 64-bit
> R-devel and then load/attach the package in  32bit R-devel to crash R.
>
>
> To say it more clearly, the difference between the two issues is that while
> the first does not appear on 32bit R-devel, the second does, and the other
> way round for 64-bit R-devel.
>
> I am sorry I cannot provide a more detailed analysis what the bug in issue 2
> actually triggers, but it is perhaps interesting to see that the following
> line does not trigger it (in which only the last argument to fastLM was
> changed):
> .Call("fastLm",cbind(1, log(trees$Girth)),log(trees$Volume),
> 1L,PACKAGE="RcppEigen")
>
>
> I hope this issue can also be considered as I will refrain from submitting a
> (much needed) update of my package to CRAN as long as the check fails like
> this on 32bit Windows R-devel. Unless of course someone knows that the wrath
> of CRAN will not be triggered by this error (which I doubt).
>
> Cheers,
> Henrik
>
> ---
> Dr. Henrik Singmann
> PostDoc
> University of Zürich, Switzerland
> http://singmann.org
>
> -Ursprüngliche Nachricht-
> Von: rcpp-devel-boun...@lists.r-forge.r-project.org
> [mailto:rcpp-devel-boun...@lists.r-forge.r-project.org] Im Auftrag von Kevin
> Ushey
> Gesendet: Freitag, 13. März 2015 03:43
> An: Duncan Murdoch
> Cc: rcpp-devel
> Betreff: Re: [Rcpp-devel] New Windows toolchain
>
> Hi Duncan,
>
> First off -- a _huge_ thanks for all the time and effort you've put into
> updating the toolchain on Windows. We understand that, effectively, your
> (and R-core)'s stake in updating the toolchain on Windows is quite a bit
> smaller than ours, since C++ support is not a governing priority in the
> maintenance and development of R. Those of us on the C++ / Rcpp side are
> very excited at the prospect of being able to develop R packages which
> leverage C++11 features and also work across the board on all the platforms
> used by R, and so the prospect of the toolchain being updated on Windows is
> very exciting.
>
> At the moment, our hope is that a combination of patches to Rcpp, and
> potentially a few small patches to the Rtools scripts (which we are happy to
> provide and test ourselves), will show that the updated toolchain is stable
> enough for use with R 3.2.0.
>
> A summary of the issue for anyone else on the list who hasn't followed the
> other threads follows:
>
> ---
>
> Many Rcpp client packages / C++-containing packages erroneously make calls
> directly to `Rf_error()`. Calling `Rf_error()` directly from C++ can result
> in undefined behaviour -- this is because calling `Rf_error()` will result
> in a `longjmp`, which bypasses the destructors of any objects on the stack
> (thereby potentially leaking memory, but in general, causing undefined
> behaviour). The simplest reproducible example (without Rcpp) demonstrating
> this problem, from JJ, is this:
>
> #include 
> #include 
>
> #include 
>
> extern "C" SEXP ouch() {
> std::string str;
> Rf_error("ouch");
> return R_NilValue;
> }
>
> When calling `ouch()`, the object `str` is effectively leaked, and its
> destructor is never called, due to the longjmp invoked from `Rf_error()`.
>
> With the older Rtools toolchain, packages generally 'got away' with doing
> this -- perhaps certain objects were leaked, or destructors weren't run, but
> often this wasn't a show-stopper. This is no longer the case with the new
> toolchain -- here, our 'luck runs out' and we instead get stuck with an
> infinite loop / a crash, with (at least as I
> see) msvcrt attempting to repeatedly throw and unwind an exception following
> the `longjmp`.
>
> One proposal fix would for us on the Rcpp side is to simply provide our own
> `#define` that masks `Rf_error()` and instead calls R's `Rf_error()` in a
> safe

Re: [Rcpp-devel] V8 crashes on 32bit windows when built with new Rtools

[JJ Allaire]

I had an issue like this in RcppParallel that was solved by rebuilding
Rcpp from source using the very latest R-devel and Rtools 3.3. Have
you tried that?

J.J.

On Thu, Mar 12, 2015 at 5:25 PM, Jeroen Ooms  wrote:
> This is probably not exclusively Rcpp problem, but I could use some
> debugging help from Rcpp experts.
>
> When building V8 on windows with the new tool chain, the build succeeds and
> the package can be loaded, but when trying to use it on i386, it crashes (it
> works fine on x64). Other packages that link to external c++ libraries (e.g.
> RQuantlib) might suffer from this as well.
>
> To reproduce, install latest rtools and r-devel on windows and run:
>
>   install.packages("V8", type = "source")
>   library(V8)
>   ct <- new_context()
>
> The R.exe process crashes without any error message or crashdump, which
> makes this very difficult to debug. I suspect that the problem is that the
> new Rtools has been built with some different settings resulting in
> incompatible binaries, but I can't find the problem.
>
> Any suggestions on where to start debugging this?
>
>
> ___
> 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 bug (was: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib))

[JJ Allaire]

This also does not crash (because the destructor has already run
before the longjmp):

#include 
#include 

#include 

extern "C" SEXP foo(SEXP bar) {

  {
std::string str;
  }

  Rf_error("foobar");
  return bar;
}

Kevin and I are investigating further now.



On Thu, Mar 12, 2015 at 4:51 PM, JJ Allaire  wrote:
> This is a minimum case to reproduce the crash (no Rcpp involved
> *however* a C++ destructor being executed seems to be what triggers
> the crash):
>
> #include 
> #include 
>
> #include 
>
> extern "C" SEXP foo(SEXP bar) {
>
>   std::string str;
>
>   Rf_error("foobar");
>   return bar;
> }
>
> If I remove the "std::string str" line then it doesn't crash.
>
> So it's something related to the interaction between longjmp and C++
> destructors...
>
> On Thu, Mar 12, 2015 at 4:39 PM, JJ Allaire  wrote:
>> Just noticed that Rcpp::stop also causes a hang on 64-bit R so the
>> longjmp in the wrapper macro is having the same effect (good to be
>> clear that the destructors being bypassed wasn't the source of the
>> hang/crash)
>>
>>
>> On Thu, Mar 12, 2015 at 4:25 PM, Avraham Adler  
>> wrote:
>>> I believe the new toolchain uses SJLJ and not SEH specifically for backwards
>>> compatibility.
>>>
>>> Avi
>>>
>>> On Thu, Mar 12, 2015 at 4:24 PM, JJ Allaire  wrote:
>>>>
>>>> Just a note that Rf_error is actually not technically allowed in Rcpp
>>>> (it's a longjmp which bypasses all C++ destructors on the stack). We
>>>> do it as follows:
>>>>
>>>> Rcpp::stop("error message")
>>>>
>>>> Which throws an exception which is ultimately caught by our wrapper
>>>> macro (which then calls Rf_error in a context where there are no more
>>>> destructors).
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2015 at 4:16 PM, Dirk Eddelbuettel  wrote:
>>>> >
>>>> > Duncan,
>>>> >
>>>> > The preferred and widely-documented address for Rcpp issues is
>>>> > rcpp-devel
>>>> > where I am forwarding this, I would appreciate keeping follow-up there.
>>>> >
>>>> > On 12 March 2015 at 15:11, Duncan Murdoch wrote:
>>>> > | Jack (and Dirk):
>>>> > |
>>>> > | I see this as well when I recompile Rcpp.
>>>> > |
>>>> > | Dirk:  We're seeing the Rgui console on Windows lock up in 64 bit
>>>> > | Windows with a program calling Rf_error from Rcpp, but not from a
>>>> > simple
>>>> > | C program (attached) that looks equivalent.   This is using the new
>>>> > | toolchain, both to compile Rcpp and Jack's cppFunction() call below.
>>>> > |
>>>> > | I'd be happy to help with debugging this, but not for a few days: I'll
>>>> > | be out of the office until Wednesday next week, and I don't have 64
>>>> > bit
>>>> > | Windows when I'm on the road.
>>>> >
>>>> > Sure.  We can pick this up when you are back.  The change vector appears
>>>> > to
>>>> > be on your side of the fence so we need access from your end. Few of us
>>>> > (on
>>>> > the Rcpp core group) use Windows all that much.
>>>> >
>>>> > I think I saw a blog post mentioned where someone said that with g++
>>>> > 4.9.2
>>>> > (though possibly a different build/configuration/...) some
>>>> > exception-related
>>>> > behaviour was improved.  I am sure that something is different now, and
>>>> > we
>>>> > will try to accomodate it.
>>>> >
>>>> > Safe travels.
>>>> >
>>>> > Dirk
>>>> >
>>>> > |
>>>> > | Duncan Murdoch
>>>> > |
>>>> > | On 12/03/2015 2:54 PM, Duncan Murdoch wrote:
>>>> > | > On 12/03/2015 1:31 PM, Jack Wasey wrote:
>>>> > | > > Dear Duncan,
>>>> > | > >
>>>> > | > > I hope you don't mind me emailing you directly, rather than
>>>> > through
>>>> > | > > r-devel, since it seemed a very specific problem. I had just sent
>>>> > an
>>>> > | > > email to the list when it crossed with yours saying you had
>>>> > rel

Re: [Rcpp-devel] Rcpp bug (was: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib))

[JJ Allaire]

This is a minimum case to reproduce the crash (no Rcpp involved
*however* a C++ destructor being executed seems to be what triggers
the crash):

#include 
#include 

#include 

extern "C" SEXP foo(SEXP bar) {

  std::string str;

  Rf_error("foobar");
  return bar;
}

If I remove the "std::string str" line then it doesn't crash.

So it's something related to the interaction between longjmp and C++
destructors...

On Thu, Mar 12, 2015 at 4:39 PM, JJ Allaire  wrote:
> Just noticed that Rcpp::stop also causes a hang on 64-bit R so the
> longjmp in the wrapper macro is having the same effect (good to be
> clear that the destructors being bypassed wasn't the source of the
> hang/crash)
>
>
> On Thu, Mar 12, 2015 at 4:25 PM, Avraham Adler  
> wrote:
>> I believe the new toolchain uses SJLJ and not SEH specifically for backwards
>> compatibility.
>>
>> Avi
>>
>> On Thu, Mar 12, 2015 at 4:24 PM, JJ Allaire  wrote:
>>>
>>> Just a note that Rf_error is actually not technically allowed in Rcpp
>>> (it's a longjmp which bypasses all C++ destructors on the stack). We
>>> do it as follows:
>>>
>>> Rcpp::stop("error message")
>>>
>>> Which throws an exception which is ultimately caught by our wrapper
>>> macro (which then calls Rf_error in a context where there are no more
>>> destructors).
>>>
>>>
>>>
>>> On Thu, Mar 12, 2015 at 4:16 PM, Dirk Eddelbuettel  wrote:
>>> >
>>> > Duncan,
>>> >
>>> > The preferred and widely-documented address for Rcpp issues is
>>> > rcpp-devel
>>> > where I am forwarding this, I would appreciate keeping follow-up there.
>>> >
>>> > On 12 March 2015 at 15:11, Duncan Murdoch wrote:
>>> > | Jack (and Dirk):
>>> > |
>>> > | I see this as well when I recompile Rcpp.
>>> > |
>>> > | Dirk:  We're seeing the Rgui console on Windows lock up in 64 bit
>>> > | Windows with a program calling Rf_error from Rcpp, but not from a
>>> > simple
>>> > | C program (attached) that looks equivalent.   This is using the new
>>> > | toolchain, both to compile Rcpp and Jack's cppFunction() call below.
>>> > |
>>> > | I'd be happy to help with debugging this, but not for a few days: I'll
>>> > | be out of the office until Wednesday next week, and I don't have 64
>>> > bit
>>> > | Windows when I'm on the road.
>>> >
>>> > Sure.  We can pick this up when you are back.  The change vector appears
>>> > to
>>> > be on your side of the fence so we need access from your end. Few of us
>>> > (on
>>> > the Rcpp core group) use Windows all that much.
>>> >
>>> > I think I saw a blog post mentioned where someone said that with g++
>>> > 4.9.2
>>> > (though possibly a different build/configuration/...) some
>>> > exception-related
>>> > behaviour was improved.  I am sure that something is different now, and
>>> > we
>>> > will try to accomodate it.
>>> >
>>> > Safe travels.
>>> >
>>> > Dirk
>>> >
>>> > |
>>> > | Duncan Murdoch
>>> > |
>>> > | On 12/03/2015 2:54 PM, Duncan Murdoch wrote:
>>> > | > On 12/03/2015 1:31 PM, Jack Wasey wrote:
>>> > | > > Dear Duncan,
>>> > | > >
>>> > | > > I hope you don't mind me emailing you directly, rather than
>>> > through
>>> > | > > r-devel, since it seemed a very specific problem. I had just sent
>>> > an
>>> > | > > email to the list when it crossed with yours saying you had
>>> > released a
>>> > | > > new Rtools, so I pulled my r-devel email. I have a probable R,
>>> > | > > possible Rcpp bug causing a hang with Rf_error("stop") after
>>> > showing
>>> > | > > the error message, but only with 64 bit Rtools 3.3 (downloaded a
>>> > few
>>> > | > > hours ago).
>>> > | > >
>>> > | > > I'm afraid my reproducible example uses Rcpp, but only for
>>> > | > > compilation. I'm not adept enough to eliminate the Rcpp step
>>> > quickly,
>>> > | > > but I hope it will be of use anyway.
>>> > | > >
>>> > | > > Rcpp::cppFu

Re: [Rcpp-devel] Rcpp bug (was: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib))

[JJ Allaire]

Just noticed that Rcpp::stop also causes a hang on 64-bit R so the
longjmp in the wrapper macro is having the same effect (good to be
clear that the destructors being bypassed wasn't the source of the
hang/crash)


On Thu, Mar 12, 2015 at 4:25 PM, Avraham Adler  wrote:
> I believe the new toolchain uses SJLJ and not SEH specifically for backwards
> compatibility.
>
> Avi
>
> On Thu, Mar 12, 2015 at 4:24 PM, JJ Allaire  wrote:
>>
>> Just a note that Rf_error is actually not technically allowed in Rcpp
>> (it's a longjmp which bypasses all C++ destructors on the stack). We
>> do it as follows:
>>
>> Rcpp::stop("error message")
>>
>> Which throws an exception which is ultimately caught by our wrapper
>> macro (which then calls Rf_error in a context where there are no more
>> destructors).
>>
>>
>>
>> On Thu, Mar 12, 2015 at 4:16 PM, Dirk Eddelbuettel  wrote:
>> >
>> > Duncan,
>> >
>> > The preferred and widely-documented address for Rcpp issues is
>> > rcpp-devel
>> > where I am forwarding this, I would appreciate keeping follow-up there.
>> >
>> > On 12 March 2015 at 15:11, Duncan Murdoch wrote:
>> > | Jack (and Dirk):
>> > |
>> > | I see this as well when I recompile Rcpp.
>> > |
>> > | Dirk:  We're seeing the Rgui console on Windows lock up in 64 bit
>> > | Windows with a program calling Rf_error from Rcpp, but not from a
>> > simple
>> > | C program (attached) that looks equivalent.   This is using the new
>> > | toolchain, both to compile Rcpp and Jack's cppFunction() call below.
>> > |
>> > | I'd be happy to help with debugging this, but not for a few days: I'll
>> > | be out of the office until Wednesday next week, and I don't have 64
>> > bit
>> > | Windows when I'm on the road.
>> >
>> > Sure.  We can pick this up when you are back.  The change vector appears
>> > to
>> > be on your side of the fence so we need access from your end. Few of us
>> > (on
>> > the Rcpp core group) use Windows all that much.
>> >
>> > I think I saw a blog post mentioned where someone said that with g++
>> > 4.9.2
>> > (though possibly a different build/configuration/...) some
>> > exception-related
>> > behaviour was improved.  I am sure that something is different now, and
>> > we
>> > will try to accomodate it.
>> >
>> > Safe travels.
>> >
>> > Dirk
>> >
>> > |
>> > | Duncan Murdoch
>> > |
>> > | On 12/03/2015 2:54 PM, Duncan Murdoch wrote:
>> > | > On 12/03/2015 1:31 PM, Jack Wasey wrote:
>> > | > > Dear Duncan,
>> > | > >
>> > | > > I hope you don't mind me emailing you directly, rather than
>> > through
>> > | > > r-devel, since it seemed a very specific problem. I had just sent
>> > an
>> > | > > email to the list when it crossed with yours saying you had
>> > released a
>> > | > > new Rtools, so I pulled my r-devel email. I have a probable R,
>> > | > > possible Rcpp bug causing a hang with Rf_error("stop") after
>> > showing
>> > | > > the error message, but only with 64 bit Rtools 3.3 (downloaded a
>> > few
>> > | > > hours ago).
>> > | > >
>> > | > > I'm afraid my reproducible example uses Rcpp, but only for
>> > | > > compilation. I'm not adept enough to eliminate the Rcpp step
>> > quickly,
>> > | > > but I hope it will be of use anyway.
>> > | > >
>> > | > > Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }")
>> > | > > doError()
>> > | > >
>> > | > > This causes a hang after showing the error message. Winbuilder
>> > checked
>> > | > > my package "icd9" without problems in 32 bit R-devel, and both 32
>> > and
>> > | > > 64 bit R current.
>> > | > >
>> > | > > Not being sure whether this is an Rcpp or R bug (see also
>> > | > > https://github.com/RcppCore/Rcpp/issues/276), I hesitated to
>> > report
>> > | > > this as a bug against R itself, but perhaps people more skilled
>> > than
>> > | > > me can do this if indeed it is so.
>> > | >
>> > | > I see the same problem.  I've just tried the eq

Re: [Rcpp-devel] Rcpp bug (was: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib))

[JJ Allaire]

Just a note that Rf_error is actually not technically allowed in Rcpp
(it's a longjmp which bypasses all C++ destructors on the stack). We
do it as follows:

Rcpp::stop("error message")

Which throws an exception which is ultimately caught by our wrapper
macro (which then calls Rf_error in a context where there are no more
destructors).



On Thu, Mar 12, 2015 at 4:16 PM, Dirk Eddelbuettel  wrote:
>
> Duncan,
>
> The preferred and widely-documented address for Rcpp issues is rcpp-devel
> where I am forwarding this, I would appreciate keeping follow-up there.
>
> On 12 March 2015 at 15:11, Duncan Murdoch wrote:
> | Jack (and Dirk):
> |
> | I see this as well when I recompile Rcpp.
> |
> | Dirk:  We're seeing the Rgui console on Windows lock up in 64 bit
> | Windows with a program calling Rf_error from Rcpp, but not from a simple
> | C program (attached) that looks equivalent.   This is using the new
> | toolchain, both to compile Rcpp and Jack's cppFunction() call below.
> |
> | I'd be happy to help with debugging this, but not for a few days: I'll
> | be out of the office until Wednesday next week, and I don't have 64 bit
> | Windows when I'm on the road.
>
> Sure.  We can pick this up when you are back.  The change vector appears to
> be on your side of the fence so we need access from your end. Few of us (on
> the Rcpp core group) use Windows all that much.
>
> I think I saw a blog post mentioned where someone said that with g++ 4.9.2
> (though possibly a different build/configuration/...) some exception-related
> behaviour was improved.  I am sure that something is different now, and we
> will try to accomodate it.
>
> Safe travels.
>
> Dirk
>
> |
> | Duncan Murdoch
> |
> | On 12/03/2015 2:54 PM, Duncan Murdoch wrote:
> | > On 12/03/2015 1:31 PM, Jack Wasey wrote:
> | > > Dear Duncan,
> | > >
> | > > I hope you don't mind me emailing you directly, rather than through
> | > > r-devel, since it seemed a very specific problem. I had just sent an
> | > > email to the list when it crossed with yours saying you had released a
> | > > new Rtools, so I pulled my r-devel email. I have a probable R,
> | > > possible Rcpp bug causing a hang with Rf_error("stop") after showing
> | > > the error message, but only with 64 bit Rtools 3.3 (downloaded a few
> | > > hours ago).
> | > >
> | > > I'm afraid my reproducible example uses Rcpp, but only for
> | > > compilation. I'm not adept enough to eliminate the Rcpp step quickly,
> | > > but I hope it will be of use anyway.
> | > >
> | > > Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }")
> | > > doError()
> | > >
> | > > This causes a hang after showing the error message. Winbuilder checked
> | > > my package "icd9" without problems in 32 bit R-devel, and both 32 and
> | > > 64 bit R current.
> | > >
> | > > Not being sure whether this is an Rcpp or R bug (see also
> | > > https://github.com/RcppCore/Rcpp/issues/276), I hesitated to report
> | > > this as a bug against R itself, but perhaps people more skilled than
> | > > me can do this if indeed it is so.
> | >
> | > I see the same problem.  I've just tried the equivalent as a simple C
> | > program, and it was fine.  I will try compiling Rcpp and see if that
> | > fixes it; I wouldn't be surprised if the binary on CRAN was built with
> | > the old compiler.
> | >
> | > Duncan Murdoch
> | > >
> | > > Best wishes,
> | > > Jack
> | > >
> | > > On Thu, Mar 12, 2015 at 1:17 PM, Duncan Murdoch
> | > >  wrote:
> | > > > I've just uploaded a minor update (3.3.0.1957) to Rtools33, adding the
> | > > > cygpath.exe utility.  That utility converts between Windows style 
> paths like
> | > > > D:/Rtools and Cygwin style paths like /cygdrive/d/Rtools.   It may be 
> useful
> | > > > in configuration files if your external library expects to find gcc 
> on the
> | > > > path, since Rtools no longer puts it there.  Assuming you want to use 
> the
> | > > > Rtools toolchain, you can construct the path to the gcc directory in 
> your
> | > > > Makevars.win file as
> | > > >
> | > > > $(cygpath $(RTOOLS))gcc492_$(WIN)/bin
> | > > >
> | > > > (where RTOOLS and WIN are macros from RHOME/etc/*/Makeconf that should
> | > > > already have been read.)
> | > > >
> | > > > Thanks to JJ Allaire for the prompting on this.
> | > > >
> | > > > Duncan Murdoch
> | > > >
> | > > > __
> | > > > r-de...@r-project.org mailing list
> | > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> | >
> |
> | [DELETED ATTACHMENT test.c, plain text]
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
___
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] Linking code in src/ subfolders

[JJ Allaire]

Right now compileAttributes doesn't scan code in subdirectories. This
is mostly because for it to be really seamless compileAttributes
should run before every build. We therefore want to keep the total
execution time <= 50ms.

Since some R packages have *a lot* of code in subdirectories of src we
didn't want to get into scanning recursively before every build.




On Tue, Mar 10, 2015 at 6:23 PM, Balamuta, James Joseph
 wrote:
> Greetings and Salutations All,
>
> I’m trying to add structure to the src folder since the amount of files I
> have residing in the src directory could be better organized. Note: These
> files are made using RcppArmadillo.
>
>
>
> E.g.
>
>
>
> I’m looking to go from:
>
> src/
> |-> main.cpp
>
> |-> testA.cpp
>
> |-> testA.h
>
> |-> testB.cpp
>
> |-> testB.h
>
>
>
> To a structure like:
>
>
> src/
>|-> main.cpp
>|-> A
>
>|-> testA.cpp
>
>|-> testA.h
>
>|-> B
>
>|-> testB.cpp
>
>|-> testB.h
>
>
>
> Each file has a function:
>
> main.cpp => testfunction(x)
>
> testA.cpp => testfunctionA(x)
>
> testB.cpp => testfunctionB(x)
>
>
>
> To illustrate the issue, I have two repositories
>
>
>
> SrcDir: https://github.com/coatless/header_cpp_subdir_code
>
> SubdirSrc: https://github.com/coatless/header_cpp_code
>
>
>
> If I compile without trying to change the folder structure, the package is
> made and is able to use without issue.
>
>
>
> However, when I attempt to change the folder structure, I was getting a
> compiler error that identifies with a linking issue:
>
>
>
> main.o:main.cpp:(.text+0x650a): undefined reference to
> `testfunctionA(arma::Col const&)'
>
> I looked at CRANs documentation for a suggested fix and ended up trying to
> ensure a link by using the makevars file (see:
> http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars)
>
>
> I made the following changes:
>
>
>
> The Makevars file update seemed to work as the package then compiled.
>
> (Exact changes to Makevars.win:
> https://github.com/coatless/header_cpp_subdir_code/blob/master/src/Makevars.win
> )
>
>
>
> Herein lies the issues:
>
>
>
> 1.Any files I’ve written in the subdirectories are no longer
> exported to RcppExport.cpp even though they have a // [[Rcpp::export]] tag
> preceding the function declaration.
>
> 2.   When I try to call the function in main.cpp (testfunction(x)), I
> receive:
>
> testfunction(2^(1:5))
>
> Error in .Call("SubdirSrc_testfunction", PACKAGE = "SubdirSrc", x) :
>
>   "SubdirSrc_testfunction" not available for .Call() for package "SubdirSrc"
>
>
>
>
>
> Any suggestions would be appreciated.
>
> Sincerely,
>
>
> JJB
>
>
> ___
> 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] Linking to c++ files in a package without Rcpp overhead for faster computation

[JJ Allaire]

The overhead comes from the fact that the parameters are converted
to/from SEXP and pushed through a C interface. There's also overhead
that's associated with error checking, etc. This is a fixed overhead
so as more work gets done inside your C++ function the % overhead will
approach zero.

In terms of re-using code across packages, everything in your
inst/include directory is automatically added to the include search
path of any package that has a LinkingTo relationship to yours (and to
any sourceCpp module that does an Rcpp::depends on it). No absolute
paths are therefore necessary (R resolves the path to your package at
build time).

If you want to re-use Rcpp code across packages the most
straightforward way to do it is inside a header file (this has no
linking or associated C interface overhead, and has no versioning
problems). You can just define your function with the 'inline' keyword
and it can be re-used in an arbitrary number of other C++ files with
no linker conflicts.

J.J.

On Fri, Mar 6, 2015 at 5:03 PM, John Tipton  wrote:
> Hey Rcpp developers,
>
> I am brand spanking new to the Rcpp community and I want to introduce myself
> with what is likely a very simple question that I haven't found an answer
> for yet. My question is on package development and linking c++ files from
> one package directly to another package without having to create a CCallable
> function . As a relatively experienced R programmer but novice c++
> programmer, I am still learning as I go so I created a minimal example below
> that I believe better illustrates my question.
>
> I am building a package with RStudio and I want to make available to another
> package the .h header files - (more explicitly the c++ subroutines in those
> headers) without the loss of computation speed shown below.
>
> My question can best be summarized with two parts
>
> 1) Why when I directly source testPack.h is the function call so much slower
> than when I define the function in the same .cpp file (i.e. why is fun1.cpp
> so much slower (~40%) than fun2.cpp in test.R)
>
> 2) How do I build a library in an automated fashion (maybe there is a
> CPPFLAGS variable?) so I can use the functionality of something like
> #include “path/to/file/hello_world2.h” in fun2.cpp without using an absolute
> path? I am building a large MCMC sampler so every bit of marginal speed gain
> is important. In other words, how can I replicate the behavior of fun2.cpp
> in a function that sources my library testPack
>
>
> I have the following files (outside my package) that provide testing. Thanks
> for any help.
>
> test.R
> fun1.cpp <- includes  header, runs slow
> fun2.cpp <- includes “hello_world2.h” header, runs faster
>
> I built a package skeleton in RStudio using Rcpp. Within the src directory I
> have the files
> hello_world2.h
> cpp_hello_world.cpp
>
>
> The files are as follows
> ##
> ##
> ##
>  begin test.R script 
>
> library(rbenchmark)
> n <- 1
> Rcpp::sourceCpp('~/test/fun1.cpp’)
> Rcpp::sourceCpp('~/test/fun2.cpp’)
>
> benchmark(fun1(n), fun2(n), replications = 500)
>
>  end test.R script 
> ##
> ##
> ##
>  begin fun1.cpp 
>
> #include 
> #include 
> // [[Rcpp::depends(testPack)]]
> // [[Rcpp::depends(RcppArmadillo)]]
>
> //using namespace Rcpp;
>
> //[[Rcpp::export]]
> void fun1(const int& n) {
>for(int i = 0; i < n; i++){
> testPack::rcpp_hello_world();
>}
> }
>
>  end fun1.cpp 
> ##
> ##
> ##
>  begin fun2.cpp 
>
> #include 
> #include 
>
> // [[Rcpp::depends(RcppArmadillo)]]
>
> //[[Rcpp::export]]
> void fun2(const int& n) {
>for(int i = 0; i < n; i++){
> rcpp_hello_world2();
>}
> }
>
>  end fun2.cpp 
> ##
> ##
> ##
>  begin hello_world2.h 
>
> Rcpp::List rcpp_hello_world2() {
>
> Rcpp::CharacterVector x = Rcpp::CharacterVector::create("foo", "bar");
> Rcpp::NumericVector y   = Rcpp::NumericVector::create(0.0, 1.0);
> Rcpp::List z= Rcpp::List::create(x, y);
>
> return z ;
> }
>
>  end hello_world2.h 
> ##
> ##
> ##
>  begin rcpp_hello_world.cpp 
>
> #include 
>
> // [[Rcpp::depends(RcppArmadillo)]]
> // [[Rcpp::interfaces(cpp)]]
>
> using namespace Rcpp;
>
> //[[Rcpp::export]]
> List rcpp_hello_world() {
>
> CharacterVector x = CharacterVector::create( "foo", "bar" )  ;
> NumericVector y   = NumericVector::create( 0.0, 1.0 ) ;
> List z= List::create( x, y ) ;
>
> return z ;
> }
>
>  end rcpp_hello_world.cpp 
>
> ___
> 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] assert() for Rcpp?

[JJ Allaire]

>
> This would still bypass the dror for the RNGscope object automatically added 
> by Rcpp::export right ?
>

Indeed it would. I think Dirk's example is really just an illustration
of how we handle exceptions internally via the BEGIN/END macros and
not something that user code should ever emulate (unless it's outside
of Rcpp::export and doesn't use the BEGIN/END macros.
___
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] assert() for Rcpp?

[JJ Allaire]

We *can* call Rf_error from C++ code, but when we do it bypasses all
C++ destructors on the stack, so we don't do it so as not leak memory
and otherwise have deterministic behavior around
construction/destruction.

You'll notice in Dirk's example that there are no C++ objects on the
stack when he calls Rf_error. The core idea in Rcpp is to use
exceptions to get high enough in the stack that there are no more
destructors.

On Wed, Feb 18, 2015 at 9:08 AM, Sparapani, Rodney  wrote:
> On Tue, 2015-02-17 at 17:53 -0700, JJ Allaire wrote:
>> One piece of immediate feedback on your initial implementation: you
>> can't call Rf_error from C++ code (as it will bypass C++ destructors
>> on the stack). Rather, you should throw Rcpp::exception.
>
> Hi JJ:
>
> Ok, this puzzles me.  We can't call Rf_error from C++ code, but we can
> call it from within the exception handler, right?  It would seem so
> since Dirk has written a nice gallery post that does it that way...
> http://gallery.rcpp.org/articles/intro-to-exceptions
>
> Just my $0.02, but I would stick to exceptions and avoid assert in C++.
>
> Rodney
>
>
>
> ___
> 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] assert() for Rcpp?

[JJ Allaire]

I agree that having an assert which complies with CRAN standards would
be valuable.

One piece of immediate feedback on your initial implementation: you
can't call Rf_error from C++ code (as it will bypass C++ destructors
on the stack). Rather, you should throw Rcpp::exception.

Whether assert should throw is another issue entirely. The traditional
semantics of assert don't give it control flow behavior (either do
nothing in release mode or blow the process up in debug mode) so I'm
not sure whether we'd want to introduce a variation of it that does
have control flow. A couple of options:

(1) Create another function e.g. "verify" with the semantics you
suggest (with the different name not fooling people into thinking it
has traditional assert semantics)

(2) Call it assert but have it call Rcpp::warning rather than yielding an error.


On Tue, Feb 17, 2015 at 5:41 PM, Miratrix, Luke
 wrote:
>
> Dirk Eddelbuettel and I were discussing how people do not seem to be
> putting assert() statements in their C code in Rcpp packages.  I expect
> the reason is because assert() prints to cerr, which is a violation of the
> CRAN policies of proper packages.  However, the assert() command is a
> simple macro, and we could tweak it so it is compliant with CRAN
> standards.  Below, I have an example of what might be included.  Dirk
> suggested that this idea be posted to this list to gather peoples insights
> and thoughts (and to catch any memory management issues, for example, that
> might exist with the code below).
>
> The traditional assert() is a macro that calls a function __assert() which
> in turn seems fairly simple, but the C program for Rcpp should not just
> abort but instead throw an error, I think.  (The macro allows for
> detection of line numbers in the code, and also allows for a NDEBUG flag
> to omit all asserts for efficient code.)
>
> The proposed code:
>
> #include 
>
> #ifdef NDEBUG
> # define assert(EX)
> #else
> # define assert(EX) (void)((EX) || (__assert (#EX, __FILE__, __LINE__),0))
> #endif
>
> void __assert (const char *msg, const char *file, int line) {
> char buffer [100];
> snprintf( buffer, 100, "Assert Failure: %s at %s line #%d", msg, file,
> line );
> ::Rf_error( buffer );
> }
>
>
>
> Anyway, I would love to hear people¹s thoughts on this.  I found assert()
> useful in wrapping an existing spaghetti code base with an R package; it
> seems like a nice tool to provide enhanced ability to track down bugs.  I
> am currently using the above in my package Œtextreg¹ and it appears to
> work great.
>
>
>
> Sincerely,
>
> Luke Miratrix
> Assistant Professor of Statistics
>
> Note: Due to my RSI (wrist trouble), e-mail often abrupt.
>
>
> --
>
> Department of Statistics
> Science Center
>
> Harvard University
> 1 Oxford Street
> Cambridge MA 02138-2901
>
>
> lmirat...@stat.harvard.edu
> 510-735-7635
>
>
>
>
> ___
> 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 and ExternalPtr

[JJ Allaire]

I think the XPtr class is what you are looking for:

http://www.r-bloggers.com/external-pointers-with-rcpp/


On Fri, Dec 5, 2014 at 2:45 AM, Jeroen Ooms  wrote:
> Does Rcpp provide some elegant way to let the R user manage persistent
> c++ objects that have no R type (e.g. internal handles or sessions of
> some sort)?
>
> In C, I would use R_MakeExternalPtr to create a ptr SEXP that the user
> can pass from one R function to another. This also makes it easy to
> add a finalizer with R_RegisterCFinalizerEx so that the garbage
> collector will automatically clean up the session/handle whenever user
> deletes the R object.
>
> Most Rcpp examples I have seen use function arguments with standard
> data types that are automatically mapped to R types. Does Rcpp have
> any special mechanics for managing external objects (pointers) from R
> which do not map to a SEXP type? Or do I have to fall back on
> Rinternals for this?
> ___
> 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] rex2arma: from R expression to RcppArmadillo code

[JJ Allaire]

I suggest creating an R package hosted on GitHub. Once this is
available I'd post a link to it back to this list.

After you've received feedback and some real world usage/testing then
promote it to CRAN (or at that point we could consider whether it
merits inclusion in RcppArmadillo itself or is better thought of as an
extension).





On Mon, Nov 3, 2014 at 11:44 AM, Serguei Sokol  wrote:
> Dirk,
>
> Le 03/11/2014 17:33, Dirk Eddelbuettel a écrit :
>>
>>
>> Serguei,
>>
>> Thanks for your enthusiasm about Rcpp and RcppArmadillo. It is mostly
>> shared :)
>>
>> You give a long "sales job" on rex2arma, which is fine.  Open Source
>> mostly
>> works differently.  If you really wanted this to be part of RcppArmadillo,
>> could you provide a pull request?  Code rules, and we need to see the
>> code.
>
> That was precisely the sens of my question : where can I put the code ?
> Have you a github account ?
>
> Best,
> Serguei.
>
>>
>> But without having seen the code, why not ... just make rex2arma a package
>> which you would author and ship to CRAN?  Just a thought.
>>
>> Cheers, Dirk
>>
>
> ___
> 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] Template instantiation of commonly-used types

[JJ Allaire]

Yeah, we definitely want to keep things header-only for ABI stability.
This is pretty non-negotiable IMHO.

On Wed, Oct 15, 2014 at 2:14 PM, Kevin Ushey  wrote:
> If we were to have these vectors as part of the shared object rather
> than header-only, wouldn't this imply breakage for existing packages
> if newer versions of Rcpp changed the Vector template class
> implementation (perhaps it inherits new policies, or gains new
> methods, or methods change, or becomes templated in a different way)?
> This is unlikely but it could happen down the line.
>
> Also, doesn't it imply fewer opportunities for the compiler to inline
> code when possible? Part of the reason Rcpp is header only is that it
> gives the compiler opportunities to inline all parts when sensible; by
> having the Vector class external the compiler can lose the ability to
> inline these calls.
>
> Overall I feel fairly uncomfortable moving away from header-only-ness
> in Rcpp (although we could be persuaded otherwise) -- reducing compile
> time / binary size doesn't seem a convincing enough reason to steer
> away from being header only as possible.
>
> On Wed, Oct 15, 2014 at 11:01 AM, Dirk Eddelbuettel  wrote:
>>
>> On 15 October 2014 at 10:28, Kevin Thornton wrote:
>> | I should clarify: those git gist are the "git clone" links.  Here are the 
>> direct links for viewing:
>> |
>> | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353
>> |
>> | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a
>>
>> Could you give it a spin and actually try how R CMD check behaves if you do
>> that?  And/or check how any of the Rcpp dependents behaves?  Maybe give
>> numbers for the gain in compilation you try to achieve?
>>
>> If it does work we can surely condition via configure on the appropriate
>> compiler and version.
>>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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
> ___
> 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] Grid Search in RcppParallel

[JJ Allaire]

For executing R code in parallel you you may want to take a look at
multicore (part of the parallel package built in to R).

On Sun, Oct 5, 2014 at 1:51 AM, Jeffrey Wong  wrote:
> I am trying to use RcppParallel to do a fast grid search.  The idea is to
> construct a matrix using R's expand.grid, then for each row of that matrix,
> x, call f(x).  For simplicity the function f will always return a double.
> Since Rcpp can call an R function I was hoping RcppParallel would allow me
> to use a parallelFor to process the rows of the grid quickly.  However, it
> keeps crashing R, and I am wondering if this is because an R function cannot
> be passed to RcppParallel?
>
> require(Rcpp)
> require(RcppParallel)
>
> grid = as.matrix(expand.grid(a = 1:5, b = 1:5))
>
> foo = function(pars) {pars[1]^2 + pars[2]^2}
>
> RcppParallelGridSearch(grid, foo)
>
> in .cpp file
>
> #include 
> using namespace Rcpp;
>
> // [[Rcpp::depends(RcppParallel)]]
> #include 
> using namespace RcppParallel;
>
> struct GridSearch : public Worker
> {
>// source matrix
>const RMatrix grid;
>const Function f;
>
>// destination vector
>RVector output;
>
>// initialize with source and destination
>GridSearch(const NumericMatrix grid, const Function f, NumericVector
> output)
>   : grid(grid), f(f), output(output) {}
>
>// take the square root of the range of elements requested
>void operator()(std::size_t begin, std::size_t end) {
>
>   for (std::size_t i = begin; i < end; i++) {
> RMatrix::Row parameters = grid.row(i);
> output[i] = as(f(parameters));
>   }
>}
> };
>
> // [[Rcpp::export]]
> NumericVector RcppParallelGridSearch(NumericMatrix grid, Function f) {
>
>   // allocate the output matrix
>   NumericVector output(grid.nrow());
>
>   // SquareRoot functor (pass input and output matrixes)
>   GridSearch gridSearch(grid, f, output);
>
>   // call parallelFor to do the work
>   parallelFor(0, grid.nrow(), gridSearch);
>
>   // return the output matrix
>   return output;
> }
>
> --
> Jeffrey Wong
> My portfolio: http://jeffreycwong.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] Package Rcpp: Question conerning source code of cpp files and related question

[JJ Allaire]

Note that you can call Rcpp::sourceCpp directly from within any IDE.
You can't just do a an R CMD SHLIB on the file though as there is
_lots_ of work done by sourceCpp to ensure that the build environment
is configured correctly.

On Tue, Sep 30, 2014 at 10:55 AM, Jonathan Olmsted  wrote:
> Hi, Martin.
>
>>
>> 1) Is there a way to see the source file of the "final" cpp-file? (I mean
>> is it possible to see how the //-lines are replaced and what soureCpp does?)
>
>
> The code generation that happens behind the scenes can be made explicit with
>
> sourceCpp(file = "crossp.cpp", verbose = TRUE)
>
> HTH,
> Jonathan
>
>
>
>
>
>>
>>
>>
>> --
>> 
>> Dr. Martin Spindler
>> Senior Researcher
>> Max Planck Society
>> Munich Center for the Economics of Aging
>> Amalienstr. 33
>> 80799 Munich
>> Germany
>>
>>
>> ___
>> 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
>
>
>
>
> --
>
> J.P. Olmsted
> j.p.olms...@gmail.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] compileAttributes() does not export function

[JJ Allaire]

You need two colons after Rcpp in the attribute, e.g. Rcpp::export

On Sat, Sep 27, 2014 at 6:30 AM, Kevin Kunzmann  wrote:
> Hi,
>
> I am experiencing a problem with the 'export' attribute. The file
> 'cmest.cpp' is compiled all right, but Rcpp misses the function 'cv' both in
> RcppExports.cpp as well as RcppExports.R - the compileAttributes() function
> ignores the export statement. Other functions are exported correctly form
> the same project / source folder! Any Idea?
>
> Best,
>
> Kevin
>
> #include 
>
> // [[Rcpp::depends(RcppArmadillo)]]
>
> // [[Rcpp:export]]
> Rcpp::List cv(arma::mat data, int n)
> {
> // n must be small enough!
>
> // find stage one indices
> arma::Col inds = arma::Col(data.n_rows);
> int nStageOne = 0;
> for(int i = 0; i < data.n_rows; i++)
> {
> inds(nStageOne) =  i;
> nStageOne   += 1;
> }
> inds.set_size(nStageOne);
>
> // randomize indices
> inds = arma::shuffle(inds);
>
> // select first n items from each subgroup (marker x treatment)
> arma::mat  res= arma::zeros(data.n_rows - 4*n,
> data.n_cols);
> intnRes   = 0;
> arma::mat  oob= arma::zeros(n*4, data.n_cols);
> arma::Col nCount = arma::zeros >(4);
> for(int i = 0; i < nStageOne; i++)
> {
> if(data(inds(i), 1) == 0 && data(inds(i), 3) == 0 && nCount(0) < n)
> {
> // 00
> for(int j = 0; j < data.n_cols; j++)
> {
> oob(sum(nCount), j) = data(inds(i), j);
> }
> nCount(0) += 1;
> continue;
> }
> if(data(inds(i), 1) == 0 && data(inds(i), 3) == 1 && nCount(1) < n)
> {
> // 01
> for(int j = 0; j < data.n_cols; j++)
> {
> oob(sum(nCount), j) = data(inds(i), j);
> }
> nCount(1) += 1;
> continue;
> }
> if(data(inds(i), 1) == 1 && data(inds(i), 3) == 0 && nCount(2) < n)
> {
> // 00
> for(int j = 0; j < data.n_cols; j++)
> {
> oob(sum(nCount), j) = data(inds(i), j);
> }
> nCount(2) += 1;
> continue;
> }
> if(data(inds(i), 1) == 1 && data(inds(i), 3) == 1 && nCount(3) < n)
> {
> // 00
> for(int j = 0; j < data.n_cols; j++)
> {
> oob(sum(nCount), j) = data(inds(i), j);
> }
> nCount(3) += 1;
> continue;
> }
> // else
> for(int j = 0; j < data.n_cols; j++)
> {
> res(nRes, j) = data(inds(i), j);
> }
> nRes += 1;
> }
> return Rcpp::List::create(Rcpp::Named("data") = res,
>   Rcpp::Named("oob")  = oob);
> }
> ___
> 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-devel Digest, Vol 57, Issue 18

[JJ Allaire]

It very well may be thread-safe, but my thinking is that it could be
dangerous to use a class where some methods are thread-safe and some are
not (and there isn't necessarily documentation or a formal contract on
what's safe and what's not). Your current use is likely fine, I'm just
being cautious.

J.J.


On Thu, Jul 17, 2014 at 4:40 PM, Alessandro Mammana 
wrote:

> Sorry,  I read this post just by chance,
> did I understand correctly, the class Rcpp::Matrix are not thread safe?
> Is there any problem in writing code such as:
>
> mat(i,j) = something
>
> in a multithreaded environment (such as inside a "#pragma omp parallel
> for" loop)?
> My scripts are full of such loops. I have assumed that it was the same as
> doing:
>
> double* M = mat.begin();
> M[i + ncol*j] = something;
>
> This at least should be thread safe, right?
>
> Thx a lot!
> Ale
>
>
>
> On Tue, Jul 15, 2014 at 12:00 PM,
>  wrote:
> > Send Rcpp-devel mailing list submissions to
> > rcpp-devel@lists.r-forge.r-project.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> >
> > or, via email, send a message with subject or body 'help' to
> > rcpp-devel-requ...@lists.r-forge.r-project.org
> >
> > You can reach the person managing the list at
> > rcpp-devel-ow...@lists.r-forge.r-project.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Rcpp-devel digest..."
> >
> >
> > Today's Topics:
> >
> >1. Re: parallel distance matrix calculation (JJ Allaire)
> >2. Re: parallel distance matrix calculation (JJ Allaire)
> >
> >
> > --
> >
> > Message: 1
> > Date: Mon, 14 Jul 2014 10:45:06 -0400
> > From: JJ Allaire 
> > To: Dirk Eddelbuettel 
> > Cc: "rcpp-devel@lists.r-forge.r-project.org"
> > 
> > Subject: Re: [Rcpp-devel] parallel distance matrix calculation
> > Message-ID:
> >  qgkzn22hco...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Here's a parallel version:
> >
> >
> https://github.com/jjallaire/RcppParallel/blob/master/inst/examples/parallel-distance-matrix.cpp
> >
> > To make the code reasonable I introduced a new RMatrix class in
> > RcppParallel that makes offsetting into rows and columns safe and
> > straightforward. This class has no connection on the R or Rcpp APIs so is
> > guaranteed to be thread-safe.
> >
> > On a 4 core machine (8 with hyperthreading) I'm observing a 10x speedup.
> > The parallel related speedup is 4x. There is an additional 2.5x speedup
> > which appears to be related to the lower level access to the Matrix
> memory
> > done by RMatrix (and perhaps some elimination of copying).
> >
> >
> >
> >
> > On Sun, Jul 13, 2014 at 7:27 AM, Dirk Eddelbuettel 
> wrote:
> >
> >>
> >> On 12 July 2014 at 12:37, JJ Allaire wrote:
> >> | If you could send the full source code to your example (including
> >> js_distance
> >> | and whatever R code you are using to test/exercise the functions) I'll
> >> see if I
> >> | can come up with the code you'd use to parallelize the outer loop.
> >> Depending on
> >> | how it turns out perhaps we can even convert this into another gallery
> >> article!
> >>
> >> That's the spirit!  [ I had another quick look at the inner-product
> example
> >> which is short and nice, but there is just too little of a pickup
> there...
> >> ]
> >>
> >> Dirk
> >>
> >> --
> >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >>
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <
> http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140714/a4fcf62a/attachment-0001.html
> >
> >
> > --
> >
> > Message: 2
> > Date: Mon, 14 Jul 2014 12:48:25 -0400
> > From: JJ Allaire 
> > To: Dirk Eddelbuettel 
> > Cc: "rcpp-devel@lists.r-forge.r-project.org"
> > 
> > Subject: Re: [Rcpp-devel] parallel distance matrix calculation
> > Message-ID:
> >  ocycdv98htuhruf+xlbkkfump3l64hjx4ku6uodjjar...@mail.gmail.com>
> > Content-

Re: [Rcpp-devel] parallel distance matrix calculation

[JJ Allaire]

> On a 4 core machine (8 with hyperthreading) I'm observing a 10x speedup.
> The parallel related speedup is 4x. There is an additional 2.5x speedup
> which appears to be related to the lower level access to the Matrix memory
> done by RMatrix (and perhaps some elimination of copying).
>

It turns out that the additional slowdown in the serial version was due to
repeatedly calling Vector::length as a loop termination condition. I
re-wrote the serial version using iterators and now the speedup from
parallel is about 5x (more in line with expectations).
___
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 distance matrix calculation

[JJ Allaire]

Here's a parallel version:

https://github.com/jjallaire/RcppParallel/blob/master/inst/examples/parallel-distance-matrix.cpp

To make the code reasonable I introduced a new RMatrix class in
RcppParallel that makes offsetting into rows and columns safe and
straightforward. This class has no connection on the R or Rcpp APIs so is
guaranteed to be thread-safe.

On a 4 core machine (8 with hyperthreading) I'm observing a 10x speedup.
The parallel related speedup is 4x. There is an additional 2.5x speedup
which appears to be related to the lower level access to the Matrix memory
done by RMatrix (and perhaps some elimination of copying).




On Sun, Jul 13, 2014 at 7:27 AM, Dirk Eddelbuettel  wrote:

>
> On 12 July 2014 at 12:37, JJ Allaire wrote:
> | If you could send the full source code to your example (including
> js_distance
> | and whatever R code you are using to test/exercise the functions) I'll
> see if I
> | can come up with the code you'd use to parallelize the outer loop.
> Depending on
> | how it turns out perhaps we can even convert this into another gallery
> article!
>
> That's the spirit!  [ I had another quick look at the inner-product example
> which is short and nice, but there is just too little of a pickup there...
> ]
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.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] parallel distance matrix calculation

[JJ Allaire]

James,

If you could send the full source code to your example (including
js_distance and whatever R code you are using to test/exercise the
functions) I'll see if I can come up with the code you'd use to parallelize
the outer loop. Depending on how it turns out perhaps we can even convert
this into another gallery article!

J.J.




On Fri, Jul 11, 2014 at 7:20 PM, James Bullard 
wrote:

> Hi All,
>
> I'm attempting to paralellize some Rcpp code I have now, but I'm having a
> hard time understanding the best route for this. I'm looking for some
> guidance about how things need to be restructured to take advantage of the
> parallelFor (if that would be the speediest option).
>
> I have the following two functions:
>
> double kl_divergence(NumericVector vec1, NumericVector vec2)
> NumericMatrix js_distance(NumericMatrix mat)
>
> Right now, the code for js_distance is:
>
> NumericMatrix rmat(mat.nrow(), mat.nrow());
>   for (int i = 0; i < rmat.nrow(); i++) {
> for (int j = 0; j < i; j++) {
>   NumericVector avg = (mat(i,_) + mat(j,_))/2;
>   double d1 = kl_divergence(mat(i,_), avg);
>   double d2 = kl_divergence(mat(j,_), avg);
>   rmat(i,j) = sqrt(.5 * (d1 + d2));
> }
>   }
>
> Which, by the way, is amazingly short and nice. I wanted to parallelize
> the outer loop, but I'm not finding a mechanism to use iterators to go over
> the rows of mat. I've looked at the examples on RcppParallel, but
>
>
>
>
>
>
> ___
> 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 distance matrix calculation

[JJ Allaire]

Two things to consider:

(1) The parallelFor and parallelReduce functions don't require iterators --
they just take indexes which you can use for iterating over any range. In
the gallery examples they are used to offset NumericVector.begin() to get
the address of the slide of the vector or matrix to read but you could us
the index for anything (i.e. the rows to process).

(2) The premise of RcppParallel is that you are reading and writing
directly into C arrays in background threads (it's not safe to call into R
and therefore not really safe to call into Rcpp). So to interact with a
Matrix/Vector you need to calculate the appropriate offsets from
matrix.begin() to get the slices (rows/columns) of the matrix you want.

#2 is based on my conservative assumption about what's thread-safe in Rcpp.
Romain may tell us that it's perfectly safe to call vector iterators and
matrix::operator(,) from a background thread but I don't want to assume
that's okay without confirmation. If those things _aren't_ okay (or might
not be okay in the future) then we either need to provide good examples for
offsetting into vectors and matrixes or perhaps provide some lightweight
helper classes or functions for doing the same.

Romain, what do you think?

In terms of parallelizing the outer vs. inner computations, I think you'd
have to just benchmark. Fewer thread creations and fewer context switches
is better though so my gut would be that the outer loop is the one to
parallelize.

J.J.



On Fri, Jul 11, 2014 at 7:20 PM, James Bullard 
wrote:

> Hi All,
>
> I'm attempting to paralellize some Rcpp code I have now, but I'm having a
> hard time understanding the best route for this. I'm looking for some
> guidance about how things need to be restructured to take advantage of the
> parallelFor (if that would be the speediest option).
>
> I have the following two functions:
>
> double kl_divergence(NumericVector vec1, NumericVector vec2)
> NumericMatrix js_distance(NumericMatrix mat)
>
> Right now, the code for js_distance is:
>
> NumericMatrix rmat(mat.nrow(), mat.nrow());
>   for (int i = 0; i < rmat.nrow(); i++) {
> for (int j = 0; j < i; j++) {
>   NumericVector avg = (mat(i,_) + mat(j,_))/2;
>   double d1 = kl_divergence(mat(i,_), avg);
>   double d2 = kl_divergence(mat(j,_), avg);
>   rmat(i,j) = sqrt(.5 * (d1 + d2));
> }
>   }
>
> Which, by the way, is amazingly short and nice. I wanted to parallelize
> the outer loop, but I'm not finding a mechanism to use iterators to go over
> the rows of mat. I've looked at the examples on RcppParallel, but
>
>
>
>
>
>
> ___
> 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

[JJ Allaire]

On Thu, Jun 5, 2014 at 6:05 AM, Gabor Grothendieck 
wrote:

> I am using  "R version 3.1.0 Patched (2014-05-09 r65562)" but its
> working now so perhaps you changed more than described.
>

Okay, very glad to hear!
___
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

[JJ Allaire]

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 
wrote:

> On Wed, Jun 4, 2014 at 11:21 PM, Dirk Eddelbuettel  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 
> + #include 
> +
> + 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 -I"C:/PROGRA~1/R/R-3.1/include" -DNDEBUG
> -I"C:/Users/Gabor/Documents/R/win-library/3.1/Rcpp/include"
> -I"C:/Users/Gabor/Documents/R/win-library/3.1/BH/include"
> -I"d:/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 
>
> 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`, 'sourceCpp_37333_useCpp11')
>
> rm(`.sourceCpp_37333_DLLInfo`)
>
> Building shared library
> 
>
> DIR: C:/Users/Gabor/AppData/Local/Temp/RtmpmUpJdX/sourcecpp_18a41e263c3c
>
> C:/PROGRA~1/R/R-3.1/bin/x64/R CMD SHLIB -o "sourceCpp_77519.dll"
> "file18a42f7f546e.cpp"
> g++ -m64 -I"C:/PROGRA~1/R/R-3.1/include" -DNDEBUG
> -I"C:/Users/Gabor/Documents/R/win-library/3.1/Rcpp/include"
> -I"C:/Users/Gabor/Documents/R/win-library/3.1/BH/include"
> -I"d:/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_77519.dll" WIN=64 TCLBIN=64
> OBJECTS="file18a42f7f546e.o"' had status 2
> Error in sourceCpp(code = code, verbose = TRUE) :
>   Error 1 occurred building shared library.
>
>
>
>
> --
> Statistics & Software Consult

Re: [Rcpp-devel] g++ flags

[JJ Allaire]

I think that might be overkill (or something that we can do later if users
ask for it).

Should I merge the PR?



On Wed, Apr 30, 2014 at 10:40 AM, Dirk Eddelbuettel  wrote:

>
> On 30 April 2014 at 10:15, JJ Allaire wrote:
> | I think this PR addresses the issue:
> |
> | https://github.com/RcppCore/Rcpp/pull/143
>
> Very nice. We get the better behaviour of R 3.1.0 when it is available but
> do
> not enforce it.
>
> I may still add a new simple plugin to provide 'c++0x' for users on Windoze
> who do not have the newer R.  Or do you think that's overkill?
>
> 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

Re: [Rcpp-devel] g++ flags

[JJ Allaire]

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
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  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] Rcpp attributes, default values for enums

[JJ Allaire]

Gabor,

The issue is that we don't know how to translate C++ enums into R (since R
has no enum construct). Since R typically uses a character vector for
enumerated values, another way to approach this would be use a std::string
and then just convert it to enum within the C++ implementation.

J.J.


On Fri, Feb 28, 2014 at 11:32 PM, Gábor Csárdi wrote:

> Hi All,
>
> it seems that this is currently not supported.
>
> For this:
>
> // [[Rcpp::export("L_tree")]]
> NumericMatrix rogdf_tree_layout(GraphAttributes graph,
>  double siblingDistance=20, double subtreeDistance=20,
>  double levelDistance=50, double treeDistance=50,
>  bool orthogonalLayout=false,
>  Orientation orientation=topToBottom,
>  TreeLayout::RootSelectionType selectRoot=TreeLayout::rootIsSource) {
> ...
>
> where the last two arguments are enums, I get:
>
> Warning messages:
> 1: Unable to parse C++ default value 'topToBottom' for argument
> orientation of function rogdf_tree_layout
> 2: Unable to parse C++ default value 'TreeLayout::rootIsSource' for
> argument selectRoot of function rogdf_tree_layout
>
> and there are no default values in the generated R code.
>
> Is there a workaround? Any chance of adding support for it? How hard do
> you think it is to support it?
>
> Thanks, Best,
> 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
>
___
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] Bug when using #' @title Hello world

[JJ Allaire]

Dieter,

Try locating the roxygen right above the function you want to document
(rcpp_hello_world). If you do that then it will be placed next to that
function in the .R file (when you have "standalone" roxygen within a C++
file then it's automatically associated with a NULL object in the .R file).

J.J.


On Wed, Feb 26, 2014 at 10:53 AM, Dieter Menne  wrote:

> Hi,
>
> I feel guilty that I am a Windows user, and that I am using RStudio, both
> of which is not welcome here. At least the latter is probably not guilty
> here. Before looking at the details, I had reported it on the RStudio list,
> because I thought it was a problem with roxygen.
>
>
> To reproduce:
>
> -- Generate the default rcpp_hello_world
> -- Test; all works well in my installation, since I am using Rcpp a lot
> anyway.
> -- Add the following title line to rcpp_hello_world.cpp
>
> //' @title Hello world
> #include 
> using namespace Rcpp;
>
> // [[Rcpp::export]]
> List rcpp_hello_world() {
>
> ---
> With compileAttributes, this generates:
>
> # This file was generated by Rcpp::compileAttributes
> # Generator token: 10BE3573-1514-4C36-9D1C-5A225CD40393
>
> #' @title Hello world
> NULL
>
> rcpp_hello_world <- function() {
> .Call('test_rcpp_hello_world', PACKAGE = 'test')
> }
> -
>
> That's fine, but note the NULL, which kills the rest of my manual building
> chain.
>
>
> R version 3.0.2 (2013-09-25)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
> [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
> [5] LC_TIME=German_Germany.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] Rcpp_0.11.0.2  roxygen2_4.0.0 test_1.0
>
> loaded via a namespace (and not attached):
> [1] brew_1.0-6 digest_0.6.4   fortunes_1.5-2 stringr_0.6.2  tools_3.0.2
>
>
>
>
>
>
>
> ___
> 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] using [[Rcpp::interfaces(r, cpp)]] causes a package to fail

[JJ Allaire]

You need to specify the owner of the repo -- in this case "RcppCore", so
you would do:

install_github("Rcpp", "RcppCore")

I'm not sure when this will go to CRAN -- it's a pretty egregious bug so
hopefully soon. Dirk, are there other bugs related to the 0.11 transition
that we're expecting a patch release for or is this the only known major
regression?

J.J.



On Sun, Feb 16, 2014 at 3:39 PM, Søren Højsgaard  wrote:

>  Thanks for the info. Learning to work with github is - alas - still on
> my todo-list. I tried
>
>
>
> > install_github("Rcpp")
>
> Installing github repo Rcpp/master from hadley
>
> Downloading Rcpp.zip from
> https://github.com/hadley/Rcpp/archive/master.zip
>
> Installing package from c:\temp\RtmpwLANoa/Rcpp.zip
>
> Installing Rcpp
>
> "C:/programs/R/current/bin/x64/R" --vanilla CMD build  \
>
>   "c:\temp\RtmpwLANoa\devtoolse9c47705010\Rcpp-master" --no-manual
> --no-resave-data
>
>
>
> * checking for file
> 'c:\temp\RtmpwLANoa\devtoolse9c47705010\Rcpp-master/DESCRIPTION' ... OK
>
> * preparing 'Rcpp':
>
> * checking DESCRIPTION meta-information ... OK
>
> * cleaning src
>
> * installing the package to process help pages
>
> * creating vignettes ...Warning: running command
> '"C:/programs/R/current/bin/x64/Rscript" --vanilla --default-packages= -e
> "tools::buildVignettes(dir = '.', tangle = TRUE)"' had status 1
>
> ERROR
>
> Error in loadVignetteBuilder(vigns$pkgdir) :
>
>   vignette builder 'highlight' not found
>
> Calls:  -> loadVignetteBuilder
>
> In addition: Warning message:
>
> In tools::buildVignettes(dir = ".", tangle = TRUE) :
>
>   Files named as vignettes but with no recognized vignette engine:
>
>'vignettes/Rcpp-FAQ.Rnw'
>
>'vignettes/Rcpp-attributes.Rnw'
>
>'vignettes/Rcpp-extending.Rnw'
>
>'vignettes/Rcpp-modules.Rnw'
>
>'vignettes/Rcpp-package.Rnw'
>
>    'vignettes/Rcpp-quickref.Rnw'
>
>'vignettes/Rcpp-sugar.Rnw'
>
> (Is a VignetteBuilder field missing?)
>
> Execution halted
>
> Error: Command failed (1)
>
>
>
> Any insights on what I should do?
>
>
>
> When will this "bugfix" propagate to CRAN (I need to update a package!).
>
>
>
> All the best
>
> Søren
>
>
>
>
>
>
>
>
>
> *From:* j...@rstudio.com [mailto:j...@rstudio.com] *On Behalf Of *JJ Allaire
> *Sent:* 16. februar 2014 21:54
> *To:* Søren Højsgaard
> *Cc:* rcpp-devel@lists.r-forge.r-project.org (
> rcpp-de...@r-forge.wu-wien.ac.at)
> *Subject:* Re: [Rcpp-devel] using [[Rcpp::interfaces(r, cpp)]] causes a
> package to fail
>
>
>
> That's a bug! (introduced when we were adding support for checking user
> interrupts from Rcpp code). Now fixed on master:
> https://github.com/RcppCore/Rcpp/commit/c356c701d79773ba35113872bb6e32d66804f362
>
>
>
>
>
> On Sat, Feb 15, 2014 at 1:16 AM, Søren Højsgaard 
> wrote:
>
> Dear all
>
> If in a package I have
> // [[Rcpp::interfaces(r, cpp)]]
> in all .cpp files then things work.
>
> However, if in a .cpp file I have
> // [[Rcpp::interfaces(r, cpp)]]
> then compilation fails with the message:
>
> * checking whether package 'mypack' can be installed ...Warning: running
> command '"C:/programs/R/current/bin/x64/Rcmd.exe" INSTALL -l
> "c:/Documents/stat/Rdevel/gmwR-DEVEL/gRbaseDEVEL/c-code/c-code-gRbase/array-ops-2014/mypack.Rcheck"
> --no-html
> "c:\DOCUME~2\stat\Rdevel\GMWR-D~1\GRBASE~1\c-code\C-CODE~1\ARRAY-~1\MYPACK~1.RCH\00_PKG~1\mypack"'
> had status 1  ERROR Installation failed.
> See
> 'c:/Documents/stat/Rdevel/gmwR-DEVEL/gRbaseDEVEL/c-code/c-code-gRbase/array-ops-2014/mypack.Rcheck/00install.out
>
>
> The 00install.out says
> * installing *source* package 'mypack' ...
>
> ** libs
>
> *** arch - i386
>
> g++ -m32 -I"C:/programs/R/current/include" -DNDEBUG -I../inst/include/
> -I"C:/programs/R/current/library/Rcpp/include"
> -I"C:/programs/R/current/library/RcppEigen/include"
> -I"C:/programs/R/current/library/RcppArmadillo/include"
> -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall
>  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
> RcppExports.cpp: In function 'SEXPREC* mypack_cell2entry_cpp(SEXP, SEXP)':
>
> RcppExports.cpp:37:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppEx

Re: [Rcpp-devel] using [[Rcpp::interfaces(r, cpp)]] causes a package to fail

[JJ Allaire]

That's a bug! (introduced when we were adding support for checking user
interrupts from Rcpp code). Now fixed on master:
https://github.com/RcppCore/Rcpp/commit/c356c701d79773ba35113872bb6e32d66804f362



On Sat, Feb 15, 2014 at 1:16 AM, Søren Højsgaard  wrote:

> Dear all
>
> If in a package I have
> // [[Rcpp::interfaces(r, cpp)]]
> in all .cpp files then things work.
>
> However, if in a .cpp file I have
> // [[Rcpp::interfaces(r, cpp)]]
> then compilation fails with the message:
>
> * checking whether package 'mypack' can be installed ...Warning: running
> command '"C:/programs/R/current/bin/x64/Rcmd.exe" INSTALL -l
> "c:/Documents/stat/Rdevel/gmwR-DEVEL/gRbaseDEVEL/c-code/c-code-gRbase/array-ops-2014/mypack.Rcheck"
> --no-html
> "c:\DOCUME~2\stat\Rdevel\GMWR-D~1\GRBASE~1\c-code\C-CODE~1\ARRAY-~1\MYPACK~1.RCH\00_PKG~1\mypack"'
> had status 1  ERROR Installation failed.
> See
> 'c:/Documents/stat/Rdevel/gmwR-DEVEL/gRbaseDEVEL/c-code/c-code-gRbase/array-ops-2014/mypack.Rcheck/00install.out
>
>
> The 00install.out says
> * installing *source* package 'mypack' ...
>
> ** libs
>
> *** arch - i386
>
> g++ -m32 -I"C:/programs/R/current/include" -DNDEBUG -I../inst/include/
> -I"C:/programs/R/current/library/Rcpp/include"
> -I"C:/programs/R/current/library/RcppEigen/include"
> -I"C:/programs/R/current/library/RcppArmadillo/include"
> -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall
>  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
> RcppExports.cpp: In function 'SEXPREC* mypack_cell2entry_cpp(SEXP, SEXP)':
>
> RcppExports.cpp:37:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_cell2entry2_cpp(SEXP, SEXP)':
> RcppExports.cpp:72:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_nextCell_cpp(SEXP, SEXP)':
> RcppExports.cpp:107:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_nextCellSlicePrim_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:143:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_nextCellSlice_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:179:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_slice2entry_cpp(SEXP, SEXP,
> SEXP)':
> RcppExports.cpp:215:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_getCellNumberPrim_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:251:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_getCellNumber_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:287:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_permuteCellEntries_cpp(SEXP,
> SEXP)':
> RcppExports.cpp:322:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
>
> make: *** [RcppExports.o] Error 1
> Warning: running command 'make -f "Makevars.win" -f
> "C:/programs/R/current/etc/i386/Makeconf" -f
> "C:/programs/R/current/share/make/winshlib.mk"
> SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)'
> SHLIB="mypack.dll" OBJECTS="RcppExports.o array-ops14-prim.o
> rcppeigen_hello_world.o spdinv-arma.o utils-all-subsets.o"' had status 2
>
> g++ -m32 -I"C:/programs/R/current/include" -DNDEBUG -I../inst/include/
> -I"C:/programs/R/current/library/Rcpp/include"
> -I"C:/programs/R/current/library/RcppEigen/include"
> -I"C:/programs/R/current/library/RcppArmadillo/include"
> -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall
>  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
> RcppExports.cpp: In function 'SEXPREC* mypack_cell2entry_cpp(SEXP, SEXP)':
>
> RcppExports.cpp:37:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_cell2entry2_cpp(SEXP, SEXP)':
> RcppExports.cpp:72:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_nextCell_cpp(SEXP, SEXP)':
> RcppExports.cpp:107:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_nextCellSlicePrim_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:143:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_nextCellSlice_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:179:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_slice2entry_cpp(SEXP, SEXP,
> SEXP)':
> RcppExports.cpp:215:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_getCellNumberPrim_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:251:9: error: 'jumpToTop' is not a member of
> 'Rcpp::internal'
> RcppExports.cpp: In function 'SEXPREC* mypack_getCellNumber_cpp(SEXP,
> SEXP, SEXP)':
> RcppExports.cpp:287:9: error: 'jump

Re: [Rcpp-devel] Bug: compileAttributes incorrectly handles Rcpp::export-ed functions with multiple arguments

[JJ Allaire]

Thanks for the report and sorry it took so long to get the the bottom
of it (I had also tried reproing to no avail). This is now fixed with
https://github.com/RcppCore/Rcpp/commit/d366984e6aabc426bae7f827b9fabc69df8d707b.

J.J.

On Sat, Jan 18, 2014 at 6:41 AM, Romain Francois
 wrote:
>
> Le 18 janv. 2014 à 06:10, Davor Cubranic  a écrit :
>
> Running compileAttributes with “verbose = TRUE” was very informative:
>
> $ Rscript -e 'Rcpp::compileAttributes(".", TRUE)'
> Exports from /Users/davor/projects/Davor/myPackage/src/rcpp_hello_world.cpp:
>List rcpp_hello_world(NumericVector foo)
>
> Exports from
> /Users/davor/projects/Davor/myPackage/src/rcpp_hello_world.cpp~:
>List rcpp_hello_world()
>
>
> Answer: compileAttributes interprets Emacs backup files with extension
> “.cpp~” as source files. (My fault for not zipping up the actual source
> directory but the product of "R CMD build".)
>
> Probable source of the error is in compileAttributes (Attributes.R:355):
>
> cppFiles <- list.files(srcDir, pattern = glob2rx("*.c*”))
>
>
> Hi,
>
> This has bitten me too in various training I gave about Rcp. I guess
> [.]c(c|pp)$ would make a better pattern.
> WRE says (if you read between the lines) that c++ files are .cpp or .cc
>
> So this is a bug.
>
> Romain
>
> You need a better way to identify C++ sources. R-exts manual says R’s make
> rules use .cc and .cpp for C++. (This is supposed to be recorded in
> R_HOME/etcR_ARCH/Makeconf, so it could potentially be processed dynamically,
> although I doubt that’s really necessary.)
>
> Davor
>
>
> On Jan 17, 2014, at 4:18 PM, Dirk Eddelbuettel  wrote:
>
>
> On 17 January 2014 at 15:32, Davor Cubranic wrote:
> | On 2014-01-17, at 2:55 PM, Dirk Eddelbuettel wrote:
> |
> | > You had two mistakes here:
> | >
> | >  i)   after you alter an interface to be used by Rcpp Attributes, you
> must
> | >   re-run the compileAttributes() function to update the files.  See
> the
> | >   vignette for details.
> |
> | What do you mean by this? Like I said, I changed the .cpp file and re-run
> |  compileAttributes. What I uploaded is the result afterwards.
>
> The equivalent of
>
>$ cd myPackage; R -e 'Rcpp::compileAttributes(".")'
>
> For once, I launched R and typed it by hand.
>
> | >   (And if you use RStudio, this is done automagically)
> |
> | So it is by devtools, on one of the functions I regularly use in my
> workflow, perhaps "test". If it wasn't, it would be such a pain.
> |
> | >  ii)  Your C++ function did not work as the 'List z = ...' parameter
> | >   shadowed an already declared parameter from the function
> interface.
> | >   Renaming to zz or z2 works, of course.
> |
> | I fixed it and rerun compileAttributes. Still the same problem. New
> version of the package is attached.
>
> See here, based on your previous file.
>
> edd@max:/tmp/davor/myPackage$ cat src/rcpp_hello_world.cpp
>
> #include 
> using namespace Rcpp;
>
> // [[Rcpp::export]]
> List rcpp_hello_world(NumericVector z) {
>
>CharacterVector x = CharacterVector::create( "foo", "bar" )  ;
>NumericVector y   = NumericVector::create( 0.0, 1.0 ) ;
>List z2   = List::create( x, y ) ;
>
>return z2 ;
> }
> edd@max:/tmp/davor/myPackage$ R CMD check .
> * using log directory ‘/tmp/davor/myPackage/..Rcheck’
> * using R version 3.0.2 (2013-09-25)
> * using platform: x86_64-pc-linux-gnu (64-bit)
> * using session charset: UTF-8
> * checking for file ‘./DESCRIPTION’ ... OK
> * checking extension type ... Package
> * this is package ‘myPackage’ version ‘1.0’
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for executable files ... OK
> * checking for hidden files and directories ... NOTE
> Found the following hidden files and directories:
>  ..Rcheck
> These were most likely included in error. See section ‘Package structure’ in
> the ‘Writing R Extensions’ manual.
> * checking for portable file names ... OK
> * checking for sufficient/correct file permissions ... OK
> * checking whether package ‘myPackage’ can be installed ... WARNING
> Found the following significant warnings:
>  Warning: /tmp/davor/myPackage/man/myPackage-package.Rd:31: All text must be
> in a section
>  Warning: /tmp/davor/myPackage/man/myPackage-package.Rd:32: All text must be
> in a section
> See ‘/tmp/davor/myPackage/..Rcheck/00install.out’ for details.
> * checking installed package size ... OK
> * checking package directory ... OK
> * checking DESCRIPTION meta-information ... WARNING
> Non-standard license specification:
>  What Licence is it under ?
> Standardizable: FALSE
> * checking top-level files ... OK
> * checking for left-over files ... OK
> * checking index information ... OK
> * checking package subdirectories ... WARNING
> Found the following directory with the name of a check directory:
>  ./..Rcheck
> Most likely, these were included

Re: [Rcpp-devel] Thoughts on "wrapping" attributes

[JJ Allaire]

There is one way currently to get type definitions into RcppExports.cpp --
simply add a header file with the same name as your package to
inst/include. For example, if your package is named "foobar" then you place
the type definitions in:

inst/include/foobar.h

This file will be automatically included in RcppExports.cpp. It will also
be automatically included when another user does an Rcpp::depends on your
package (for sourceCpp or compileAttributes) so they get the benefit of the
type definitions as well).

J.J.


On Thu, Jan 2, 2014 at 1:11 PM, Tim Keitt  wrote:

> I am wondering if anyone has considered the following:
>
> // [[Rcpp::include(header.h, extC-bool, namesp-optional)]]
>
> to include header.h in RcppExports.cpp (optionally wrapping it with extern
> "C" and putting it in a namespace)
>
> and
>
> // [[Rcpp::wrap(myType myFunc(const myType& x))]]
>
> which would do exactly what Rcpp::export does (generates a .Call-able
> symbol + R function, but omits the prototype for myFunc in
> RcppExports.cpp). That would allow the function and type definitions to
> appear in header.h.
>
> 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
>
___
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] exporting void test(void) function

[JJ Allaire]

>
> Am I correct in noting that
>
> // [[Rcpp::export]]
> void test(void)
> {
> // do something
> }
>
> does not generate any code in RcppExports.R?
>

The problem occurs because the attributes parser doesn't know what to do
with the void argument specification. If you declare the function with no
argument specification at all then the function will be handled correctly
in RcppExports.R, e.g.

// [[Rcpp::export]]
void foo() {

}
___
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] Attribute does not compile with 'compileAttributes' but with 'sourceCpp'

[JJ Allaire]

Simon,

The other use was also using gcc-4.8.1 so it's got something to do with
that (I don't have a local install of gcc-4.8.1 so can't repo offhand). If
you are running compileAttributes inside RStudio it will run in a separate
process. If not then I don't know of any significant difference between
calling sourceCpp and compileAttributes.

J.J.


On Fri, Nov 1, 2013 at 11:19 AM, Simon Zehnder  wrote:

> Point landing J.J.!
>
> I already compiled a new R when Mavericks came out with a newly installed
> a gcc-4.8.2, that I can load via environment modules. I also installed the
> Xcode Command Line Tools for Mavericks.
>
> I now reinstalled Rcpp with the gcc-4.8.2 and threw away all object and
> shared-object files in my /src/ folder of my package. The problem remains.
> Is there something special I can look for in my Makeconf file? What is so
> different about ‘compileAttributes’ in contrast to ‘sourceCpp’ or a usual
> package compilation via R CMD INSTALL? Does compileAttributes uses some
> additional flags and/or libraries?
>
> Best
> Simon
>
>
>
> On 01 Nov 2013, at 15:56, JJ Allaire  wrote:
>
> > Are you by any chance on OS X Mavericks? I had one other user report
> this specific error on Mavericks and it seemed to be related to the use of
> different compilers (and thus different heaps) within the same compilation
> (there is exposure to this with the changes made by Apple to the toolchain
> in Mavericks).
> >
> > J.J.
> >
> >
> > On Fri, Nov 1, 2013 at 10:01 AM, Simon Zehnder 
> wrote:
> > Dear Rcpp::Users and Rcpp::Devels,
> >
> > I get a weird exception when I try to compile an attribute in one of my
> packages:
> >
> > compileAttributes("/Users/simonzehnder/git/mmstruct/mmstruct/")
> > R(6256,0x7fff79ad9310) malloc: *** error for object 0x7fff7ac48330:
> pointer being freed was not allocated
> > *** set a breakpoint in malloc_error_break to debug
> > Abort trap: 6
> >
> > If I instead use the sourceCpp function all works fine:
> >
> > sourceCpp("/Users/simonzehnder/git/mmstruct/mmstruct/src/testing.cpp”)
> > testfunction_cc(c(0,0,0), list(trades = rnorm(10), T = 360))
> > [1] 0.00e+00 3.509927e-05 1.169976e-05
> >
> > The function in my file is actually pretty simple (and its the only one):
> >
> > #include
> >
> > // [[Rcpp::export]]
> >
> > Rcpp::NumericVector testfunction_cc(Rcpp::NumericVector par,
> > Rcpp::List list)
> > {
> > const unsigned int K= par.size();
> > Rcpp::NumericVector trades  = list["trades"];
> > const unsigned int T= list["T"];
> > double tmp = mean(trades)/T;
> > std::vector startp(K);
> > startp[0] = 0.0;
> > startp[1] = tmp * 0.75/2;
> > startp[2] = tmp * 0.25/2;
> >
> > return Rcpp::wrap(startp);
> > }
> >
> > At this moment I am a little perplexed. Where should I search for a
> possible error? What are things to try out?
> >
> > Best
> >
> > Simon
> >
> > ___
> > 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] Attribute does not compile with 'compileAttributes' but with 'sourceCpp'

[JJ Allaire]

Are you by any chance on OS X Mavericks? I had one other user report this
specific error on Mavericks and it seemed to be related to the use of
different compilers (and thus different heaps) within the same compilation
(there is exposure to this with the changes made by Apple to the toolchain
in Mavericks).

J.J.


On Fri, Nov 1, 2013 at 10:01 AM, Simon Zehnder  wrote:

> Dear Rcpp::Users and Rcpp::Devels,
>
> I get a weird exception when I try to compile an attribute in one of my
> packages:
>
> compileAttributes("/Users/simonzehnder/git/mmstruct/mmstruct/")
> R(6256,0x7fff79ad9310) malloc: *** error for object 0x7fff7ac48330:
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> Abort trap: 6
>
> If I instead use the sourceCpp function all works fine:
>
> sourceCpp("/Users/simonzehnder/git/mmstruct/mmstruct/src/testing.cpp”)
> testfunction_cc(c(0,0,0), list(trades = rnorm(10), T = 360))
> [1] 0.00e+00 3.509927e-05 1.169976e-05
>
> The function in my file is actually pretty simple (and its the only one):
>
> #include
>
> // [[Rcpp::export]]
>
> Rcpp::NumericVector testfunction_cc(Rcpp::NumericVector par,
> Rcpp::List list)
> {
> const unsigned int K= par.size();
> Rcpp::NumericVector trades  = list["trades"];
> const unsigned int T= list["T"];
> double tmp = mean(trades)/T;
> std::vector startp(K);
> startp[0] = 0.0;
> startp[1] = tmp * 0.75/2;
> startp[2] = tmp * 0.25/2;
>
> return Rcpp::wrap(startp);
> }
>
> At this moment I am a little perplexed. Where should I search for a
> possible error? What are things to try out?
>
> Best
>
> Simon
>
> ___
> 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] Problems getting RInside to work on OS X

[JJ Allaire]

I believe that the problem is that gcc has been removed from command line
tools on OS X Mavericks:

http://stackoverflow.com/questions/19533220/cannot-install-r-package-from-source-in-mac-osx-maverick




On Sun, Oct 27, 2013 at 2:46 AM,  wrote:

> Hi,
>
> What does this give you:
>
> $ R CMD config CXX
> $ R CMD config CXXFLAGS
>
> What happens in an R console when you type:
>
>  require(devtools)
>> has_devel()
>>
>
> Romain
>
> Le 2013-10-27 06:02, Claymore M a écrit :
>
>> I am trying to get RInside to run on my mac (Mavericks). (I was able
>> to get RInline running no problem using Ubuntu at work; "it just
>> worked" with none of the hassle outlined below).
>>
>> I downloaded the package and tried to run:
>>
>> "make rinside_sample0" from within the standard folder of RInline.
>>
>> This produced Error1.
>>
>> _Among the first few lines of the many errors, I got:_
>>
>>
>> _/Library/Frameworks/R.**framework/Versions/3.0/**
>> Resources/library/RInside/**include/RInsideCommon.h:34:18:
>> error: string: No such file or directory_
>>
>>
>> _/Library/Frameworks/R.**framework/Versions/3.0/**
>> Resources/library/RInside/**include/RInsideCommon.h:35:18:
>> error: vector: No such file or directory_
>>
>>
>> _/Library/Frameworks/R.**framework/Versions/3.0/**
>> Resources/library/RInside/**include/RInsideCommon.h:36:20:
>> error: iostream: No such file or directory_
>>
>>
>> Why does the make file not find the "base" headers for iostream,
>> string, vector from C++? I am guessing I need to tell the compiler
>> where to find these files? How would I do this, presumably from
>> editing the make file? Are there any guides for how to do this etc?
>> Unfortunately, with no background in working with compilers when
>> errors pop up, I wouldn't know where to start at this point.
>>
>> I found this post suggesting I need to compile RInside from source on
>> the mac.
>>
>> http://stackoverflow.com/**questions/12684408/rinside-**
>> linking-on-mac-osx
>> [1]
>>
>>
>> I then tried compiling RInside from source, but got these errors:
>>
>> _* installing to library
>> ‘/Library/Frameworks/R.**framework/Versions/3.0/**Resources/library’_
>>
>> _* installing *source* package ‘RInside’ ..._
>>
>> _** package ‘RInside’ successfully unpacked and MD5 sums checked_
>>
>> _** libs_
>>
>> _/Library/Frameworks/R.**framework/Resources/bin/**Rscript
>> tools/RInsideAutoloads.r > RInsideAutoloads.h_
>>
>> _/Library/Frameworks/R.**framework/Resources/bin/**Rscript
>> tools/RInsideEnvVars.r > RInsideEnvVars.h_
>>
>> _llvm-g++-4.2 -arch x86_64
>>
>> -I/Library/Frameworks/R.**framework/Resources/include -DNDEBUG -I.
>> -I../inst/include/ -I/usr/local/include
>>
>> -I"/Library/Frameworks/R.**framework/Versions/3.0/**
>> Resources/library/Rcpp/**include"
>> -fPIC -mtune=core2 -g -O2 -c MemBuf.cpp -o MemBuf.o_
>>
>> _MemBuf.cpp:23:20: error: iostream: No such file or directory_
>>
>> _MemBuf.cpp:24:19: error: cstdlib: No such file or directory_
>>
>> _MemBuf.cpp:25:18: error: string: No such file or directory_
>>
>> _In file included from MemBuf.cpp:27:_
>>
>> _../inst/include/MemBuf.h:25: error: ‘string’ in namespace
>> ‘std’ does not name a type_
>>
>> _../inst/include/MemBuf.h:32: error: expected unqualified-id before
>> ‘&’ token_
>>
>> _../inst/include/MemBuf.h:32: error: expected ‘,’ or ‘...’
>> before ‘&’ token_
>>
>> _../inst/include/MemBuf.h: In member function ‘const char*
>> MemBuf::getBufPtr()’:_
>>
>> _../inst/include/MemBuf.h:33: error: ‘buffer’ was not declared in
>> this scope_
>>
>> _MemBuf.cpp: In constructor ‘MemBuf::MemBuf(int)’:_
>>
>> _MemBuf.cpp:34: error: class ‘MemBuf’ does not have any field
>> named ‘buffer’_
>>
>> _MemBuf.cpp:35: error: ‘buffer’ was not declared in this scope_
>>
>> _MemBuf.cpp: In member function ‘void MemBuf::resize()’:_
>>
>> _MemBuf.cpp:39: error: ‘buffer’ was not declared in this scope_
>>
>> _MemBuf.cpp: In member function ‘void MemBuf::rewind()’:_
>>
>> _MemBuf.cpp:43: error: ‘buffer’ was not declared in this scope_
>>
>> _MemBuf.cpp: At global scope:_
>>
>> _MemBuf.cpp:46: error: expected unqualified-id before ‘&’ token_
>>
>> _MemBuf.cpp:46: error: expected ‘,’ or ‘...’ before ‘&’
>> token_
>>
>> _MemBuf.cpp: In member function ‘void MemBuf::add()’:_
>>
>> _MemBuf.cpp:47: error: ‘buf’ was not declared in this scope_
>>
>> _MemBuf.cpp:48: error: ‘buffer’ was not declared in this scope_
>>
>> _MemBuf.cpp:51: error: ‘buffer’ was not declared in this scope_
>>
>> _make: *** [MemBuf.o] Error 1_
>>
>> _ERROR: compilation failed for package ‘RInside’_
>>
>>
>> Again, something about iostream missing etc.
>>
>> Any advice on the steps for what I need to do to fix this problem
>> would be much appreciated.
>>
>> Thanks in advance
>> Clay
>>
>> Links:
>> --
>> [1] http://stackoverflow.com/**questions/12684408/rinside-**
>> linking-on-mac-osx
>>
> ___

Re: [Rcpp-devel] Local .h files and Rcpp attributes

[JJ Allaire]

For it to actually work though we'd need to modify Makevars as well (as
Romain pointed out) so that the RcppExports.cpp could see the include file.
This might get trickly. My thought was that we should either generate a
fully working solution or failing that generation enough
pointers/documentation to get most users over the hump.

J


On Sat, Oct 19, 2013 at 3:56 PM, Dirk Eddelbuettel  wrote:

>
> On 19 October 2013 at 15:40, JJ Allaire wrote:
> |
> | Maybe you could follow the example of Rcpp.package.skeleton() and
> just drop
> | an empty yet amply commented file there?  By "being there" users
> have a
> | better chance of stumbling over it :)
> |
> |
> | Since this would involve creating a new directory (inst/include) perhaps
> I
> | could instead emit comments at the top of RcppExports.cpp explaining the
> | mechanism?
>
> True, but maybe I'd still go for it.  inst/include/ is after all the place
> via which a any package foo can provide its headers to another package bar
> which simply adds 'LinkingTo: foo'.
>
> Currently, the 'cost' of attributes is one extra RcppExports.R, one
> RcppExports.cpp and we'd add a new (small, few lines with comments) header
> file in a new directory.  Seems fair to me -- but entirely your call.
>
> Restraint in not cluttering user systems is also a good thing. We'd be back
> to the need for more/better documentation though.
>
> 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

Re: [Rcpp-devel] Local .h files and Rcpp attributes

[JJ Allaire]

> Maybe you could follow the example of Rcpp.package.skeleton() and just drop
> an empty yet amply commented file there?  By "being there" users have a
> better chance of stumbling over it :)
>

Since this would involve creating a new directory (inst/include) perhaps I
could instead emit comments at the top of RcppExports.cpp explaining the
mechanism?
___
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] Local .h files and Rcpp attributes

[JJ Allaire]

> RcppExports.cpp will automatically include a .h that has the same name as
> the package and is located in inst/include, iirc.


This is indeed the current solution to the problem of typedefs, however I
admin that it's a bit difficult to take advantage of without wading through
documentation and/or the mailing list. One alternative we've considered in
transposing typedefs (and perhaps using namespace statements) into
RcppExports.cpp however this could be considered overly aggressive (e.g.
it's theoretically possible this could introduce side effects).

J.J.
___
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] sourceCpp failing on windows whereas devtools::has_devel and devtools:::R works

[JJ Allaire]

I think the reason Dirk's configuration worked is that he added Rtools to
the path during installation. If Romain didn't do this, then sourceCpp goes
looking for Rtools 2.15 or 2.16 (the initial development version for R 3.0)
and doesn't find it. I just committed a change that includes R 3.0 and R
3.1 in the whitelist of Rtools versions we know work correctly.

J.J.


On Thu, Oct 17, 2013 at 3:04 AM,  wrote:

> Hello,
>
> On a windows machine where Rtools is installed and works, i.e. I get:
>
>  require(devtools)
>> has_devel()
>>
> "C:/R/R-3.0.2/bin/i386/R" --vanilla CMD SHLIB foo.c
>
> gcc -m32 -I"C:/R/R-30~1.2/include" -DNDEBUG
>  -I"C:/R/R-3.0.2/library/Rcpp/**include" 
> -I"d:/RCompile/CRANpkg/**extralibs64/local/include"
> -O3 -Wall  -std=gnu99 -mtune=core2 -c foo.c -o foo.o
> gcc -m32 -shared -s -static-libgcc -o foo.dll tmp.def foo.o
> C:/R/R-3.0.2/library/Rcpp/lib/**i386/libRcpp.a 
> -Ld:/RCompile/CRANpkg/**extralibs64/local/lib/i386
> -Ld:/RCompile/CRANpkg/**extralibs64/local/lib -LC:/R/R-30~1.2/bin/i386 -lR
> [1] TRUE
>
>
> sourceCpp does not manage to find the tools correctly:
>
>  evalCpp( "1+1")
>>
>
> Error in sourceCpp(code = code, env = env, rebuild = rebuild, showOutput =
> showOutput,  :
>   Error 1 occurred building shared library.
>
> WARNING: The tools required to build C++ code for R were not found.
>
> Please download and install the appropriate version of Rtools:
>
> http://cran.r-project.org/bin/**windows/Rtools/
>
>
> Using devtools:::R however, I manage to compile the file correctly:
>
>  code <- '#include 
>>
> + using namespace Rcpp;
> +
> + // [[Rcpp::export]]
> + double foo(){
> +return 2;
> + }
> + '
>
>> Sys.setenv( "PKG_CXXFLAGS" = Rcpp:::RcppCxxFlags() )
>> Sys.setenv( "PKG_LIBS" = Rcpp:::RcppLdFlags() )
>>
>> writeLines( code, "test.cpp" )
>> devtools:::R( "CMD SHLIB test.cpp", getwd() )
>>
> "C:/R/R-3.0.2/bin/i386/R" --vanilla CMD SHLIB test.cpp
>
> g++ -m32 -I"C:/R/R-30~1.2/include" -DNDEBUG 
> -I"d:/RCompile/CRANpkg/**extralibs64/local/include"
>  -IC:/R/R-3.0.2/library/Rcpp/**include   -O2 -Wall  -mtune=core2 -c
> test.cpp -o test.o
> g++ -m32 -shared -s -static-libgcc -o test.dll tmp.def test.o
> C:/R/R-3.0.2/library/Rcpp/lib/**i386/libRcpp.a 
> -Ld:/RCompile/CRANpkg/**extralibs64/local/lib/i386
> -Ld:/RCompile/CRANpkg/**extralibs64/local/lib -LC:/R/R-30~1.2/bin/i386 -lR
>
>
> So perhaps we can borrow some wisdom out of devtools to make sourceCpp
> work. As one can expect, the code from sourceCpp that fails is these lines:
>
> cmd <- paste(R.home(component = "bin"), .Platform$file.sep,
> "R ", "CMD SHLIB ", "-o ", shQuote(context$**dynlibFilename),
> " ", ifelse(rebuild, "--preclean ", ""), shQuote(context$**
> cppSourceFilename),
> sep = "")
>
> Romain
>
>  version
>>
>_
> platform   i386-w64-mingw32
> arch   i386
> os mingw32
> system i386, mingw32
> status
> major  3
> minor  0.2
> year   2013
> month  09
> day25
> svn rev63987
> language   R
> version.string R version 3.0.2 (2013-09-25)
> nickname   Frisbee Sailing
>
>> packageDescription("Rcpp")$**Version
>>
> [1] "0.10.5"
>
>
>
>
>
> __**_
> 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] plugin in a package - how is it registered?

[JJ Allaire]

Simon,

To make a plugin available for use with both inline and Rcpp attributes you
need only define a function named "inlineCxxPlugin" within your package
(which can in turn call Rcpp.plugin.maker). This allow you to use it with
inline as well as Rcpp::depends.

I think this is the scenario you are targeting (since you are writing a
package). The registerPlugin function is used when you want to make
available a plugin that isn't part of a package (e.g. for some type of
ad-hoc complier/linker recipe you need to cook up).

J.J.


On Fri, Oct 11, 2013 at 5:54 PM, Dirk Eddelbuettel  wrote:

>
> Simon,
>
> On 11 October 2013 at 23:43, Simon Zehnder wrote:
> | I have a very short question in regard to plugins in packages. I have
> written my own plugin using Rcpp.plugin.maker (very well documented in FAQ
> btw).
> |
> | I know, that on the command line calling registerPlugin() registers the
> plugin. From RcppArmadillo I can see, that the registerPlugin function is
> never called inside the package - but I see also, that the file is called
> inline.R. How does the inline package register/identify a plugin? Is a
> plugin registered automatically when called inside cxxfunction? Does it
> have to be put into a file called 'inline.R'?
>
> What is your actual intent?  To support inline? To support Rcpp Attributes?
>
> I have not looked at this in a while, but I think we may not actually
> required registration (ie there is no run-time state vector accumulating
> plugin callbacks...) but when a plugin is invoked, it points to a package
> and
> hence the package namespace is searched and a corresponding function is
> called.
>
> This is from memory. Actual details may differ. Void where prohibited :)
>
> 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] Formulas in Markdown of Rcpp-Gallery

[JJ Allaire]

Okay, let's do it that way for now (I spent about 30 minutes seeing if
there was a workaround and haven't found one yet).

J.J.


On Tue, Sep 24, 2013 at 8:20 AM, Simon Zehnder  wrote:

> Hi Dirk,
>
> good to now. I worked with knitr a lot but never with Ruby/Jekyll, so I
> deduced prematurely that formulas are possible. As I wrote to J.J. I can as
> well use just O(N^3) or write it out. I just didn't want to submit an
> article that does not exhibit the expected text form.
>
> Best
>
> Simon
>
> On Sep 24, 2013, at 2:07 PM, Dirk Eddelbuettel  wrote:
>
> >
> > On 24 September 2013 at 13:10, Simon Zehnder wrote:
> > | I need a little help with the markdown in .cpp files for the
> Rcpp-Gallery:
> > | How do I type in inline formulas? For example O(N^3)? I tried $O(N^3)$
> and
> > | also $$latex O(N^3)$$ but nothing seems to work (I forked the
> repository
> > | and make/make preview works perfect - only the formulas do not work -
> I see
> > | there only what I type).
> >
> > PBKAC: Nowhere do we say that you can.  Plots are not (currently)
> supported
> > either.  And consequently, none of the 70+ posts use either.
> >
> > 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] Formulas in Markdown of Rcpp-Gallery

[JJ Allaire]

Simon,

This works differently than standard R Markdown because there is a
different markdown processor (Maruku) being used by jekyll. So out of the
box this doesn't work but a workaround might be possible -- I'll
investigate later today and let you know if I find something that works.

J.J.


On Tue, Sep 24, 2013 at 7:10 AM, Simon Zehnder  wrote:

> Dear Rcpp::Users and Rcpp::Devels,
>
> I need a little help with the markdown in .cpp files for the Rcpp-Gallery:
> How do I type in inline formulas? For example O(N^3)? I tried $O(N^3)$ and
> also $$latex O(N^3)$$ but nothing seems to work (I forked the repository
> and make/make preview works perfect - only the formulas do not work - I see
> there only what I type).
>
>
> Best
>
> Simon
> ___
> 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] Forcing a shallow versus deep copy

[JJ Allaire]

>
> Is it a big deal that we would cheat on chat reference passing means ?
>

If you want to implement these sort of semantics I think at a _minimum_ the
type should be const & (otherwise it looks like you are going to actually
modify the matrix in place which would appear to bypass the implicit memory
barrier of SEXP). Realize that you won't actually bypass the memory barrier
but it sure looks like you intend to for a reader of the code.



> Rcpp::RNGScope __rngScope;
> arma::mat& m = Rcpp::as(mSEXP);
> test_ref(m);
>

It looks like this behavior changed as of rev 4400 when the full_name()
method was introduced. I may not understand the mechanism you established
100% but to me this generated code looks potentially problematic if you are
taking a reference to a stack variable establish within the as<> method. My
guess is that you have something more sophisticated going on here and there
is no memory problem, however I'd love to understand things a bit better to
be 100% sure there isn't something to drill into further.
___
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] Default value for Rcpp List

[JJ Allaire]

Hi Matteo,

The issue here is that the Rcpp attributes code that parses function
declarations isn't able to parse all syntactic forms of C++ but rather a
subset. The default argument parsing is able to handle scalars, strings,
and simple vector initializations but not more complex expressions like the
one in your example. The warning you get is saying that the default
argument couldn't be parsed as a result of these limitations. The lack of a
default argument definition is then what caused the subsequent error.

Best,

J.J.

On Wed, Aug 14, 2013 at 3:42 AM, Matteo Fasiolo wrote:

> Dear Rcpp users,
>
>  a very simple question: I have a function that has a Rcpp::List
> among its arguments, and I would like to set a default values for
> that List.
> Unfortunately this code:
>
> cppFunction(
>   '
>   List myList(List x = List::create(_["a"] = 1, _["b"] = 2))
>  {
>   return x;
>  }
>  '
> )
>
> raises the warning:
>
> Warning message:Unable to parse C++ default value 'List::create(_["a"] = 1, 
> _["b"] = 2)' for argument x of function myList >
> > myList()Error in .Primitive(".Call")(, x) : 'x' is 
> > missing
>
>
> Similar code with NumericVector works fine:
>
> cppFunction(
>   '
>   NumericVector myVett(NumericVector x = NumericVector::create(3))
>  {
>   return x;
>  }
>  '
>  )
>
> myVett()
> # [1] 0 0 0
>
> Am I doing something wrong? Thanks!
>
> ___
> 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] is( SEXP )

[JJ Allaire]

>
> But maybe it is not worth the trouble. Maybe this is simply a
> documentation issue on hiw to dispatch.
>

Yes, I think creating an automatic dispatch system that's general enough to
matter might not be worth the effort. Documentation + some supporting
utilities is probably the optimal path.
___
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] is( SEXP )

[JJ Allaire]

>
> dispatching could also happen in attributes. Why not having something like
> this:
>
> // [[Rcpp::export]]
> void foo( NumericVector x) {
> // do some stuff
> }
>
> // [[Rcpp::export]]
> void foo( IntegerVector x) {
> // do some other stuff
> }
>
> This would involve some work in the way attributes work. But I can
> defintely see the value of this. Comments. JJ ?
>

Yes, agreed, this would be really cool! I don't think it's in principle
difficult to do.
___
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] sourceCpp issue: code vs. file

[JJ Allaire]

On Wed, May 22, 2013 at 6:41 PM, Dirk Eddelbuettel  wrote:

> R governs the behaviour of R CMD  based on the extension.
>
> The .cxx form was /never/ supported by R as far as I know.
>

Indeed. According to "Package subdirectories" in Writing R Extensions (
http://cran.r-project.org/doc/manuals/R-exts.html#Package-subdirectories)
the only supported extensions are .c, .cc, .cpp, .f, .f90, .f95, .m, and
.mm.
___
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] sourceCpp issue: code vs. file

[JJ Allaire]

I also can build successfully on Ubuntu and OSX with the .cpp extension
however the .cxx extension fails. I think the file extension is the likely
culprit.

J.J.


On Wed, May 22, 2013 at 5:13 PM, Kevin Ushey  wrote:

> Hi Rodney,
>
> I have the same problem as you on Mac OSX.
>
> I'm able to successfully compile the file through sourceCpp if I use a
> file extension of .cpp rather than .cxx. Could this somehow be the reason
> why? Let me know if that works for you.
>
> -Kevin
>
>
>
> On Wed, May 22, 2013 at 4:27 PM, Sparapani, Rodney wrote:
>
>> And here is the failure on OS X ML...
>>
>> > sourceCpp(verbose=TRUE, rebuild=TRUE, file="~/arma-sp.cxx")
>>
>> Generated extern "C" functions
>> 
>>
>>
>> #include 
>>
>> RcppExport SEXP sourceCpp_41979_convertSparse(SEXP matSEXP) {
>> BEGIN_RCPP
>> Rcpp::RNGScope __rngScope;
>> S4 mat = Rcpp::as(matSEXP);
>> convertSparse(mat);
>> return R_NilValue;
>> END_RCPP
>> }
>>
>> Generated R functions
>> ---
>>
>> `.sourceCpp_41979_DLLInfo` <-
>> dyn.load('/var/folders/nb/62qyw7056rj7lwfqbqgmh6lwgn/T//RtmpZ7Msbu/sourcecpp_1ade06077c/sourceCpp_88708.so')
>>
>> convertSparse <- Rcpp:::sourceCppFunction(function(mat) {},
>> `.sourceCpp_41979_DLLInfo`, 'sourceCpp_41979_convertSparse')
>>
>> rm(`.sourceCpp_41979_DLLInfo`)
>>
>> Building shared library
>> 
>>
>> DIR:
>> /var/folders/nb/62qyw7056rj7lwfqbqgmh6lwgn/T//RtmpZ7Msbu/sourcecpp_1ade06077c
>>
>> /Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB -o
>> 'sourceCpp_88708.so' --preclean 'arma-sp.cxx'
>> Error in
>> dyn.load("/var/folders/nb/62qyw7056rj7lwfqbqgmh6lwgn/T//RtmpZ7Msbu/sourcecpp_1ade06077c/sourceCpp_88708.so")
>> (from arma-sp.cxx.R#1) :
>>   unable to load shared object
>> '/var/folders/nb/62qyw7056rj7lwfqbqgmh6lwgn/T//RtmpZ7Msbu/sourcecpp_1ade06077c/sourceCpp_88708.so':
>>
>> dlopen(/var/folders/nb/62qyw7056rj7lwfqbqgmh6lwgn/T//RtmpZ7Msbu/sourcecpp_1ade06077c/sourceCpp_88708.so,
>> 6): image not found
>> > sessionInfo()
>> R version 2.15.2 (2012-10-26)
>> Platform: i386-apple-darwin9.8.0/i386 (32-bit)
>>
>> locale:
>> [1] C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> other attached packages:
>> [1] RcppArmadillo_0.3.6.1 Rcpp_0.10.2   Matrix_1.0-10
>> lattice_0.20-13
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_2.15.2 grid_2.15.2 tools_2.15.2
>>
>> Thanks for any hints.
>>
>> Rodney
>> ___
>> 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
>>
>
>
>
> --
> -Kevin
>
> ___
> 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] Pass a function name as an argument.

[JJ Allaire]

Hi Xiao,

The problem is that sourceCpp can only accept arguments of types that can
be converted to R using Rcpp::as (this is detailed in the help topic for
sourceCpp and in the Rcpp vignettes). Plain C function pointers
aren't convertible in this fashion so the compilation fails.

If your intention is to pass an R function to C++ you can however use the
Rcpp::Function type in your signature. This is explained in more detail in
this Rcpp Gallery article:

http://gallery.rcpp.org/articles/r-function-from-c++/

J.J.

On Sat, May 18, 2013 at 1:31 PM, Xiao He  wrote:

> Hi everyone, I have two questions regarding passing a function name as an
> argument.
>
> (1). Suppose that I have a function foo() shown below. The function takes
> a NumericVector and a function pointer that points to a function that takes
> a NumericVector and returns a double. Note that the function pointer will
> only point to functions not exposed to R.
>
> double foo(NumericVector x, double (*f)(NumericVector x) ){
> double output;
>  output=(*f)(x);
> return output;
> }
>
> When I try to compile it as is using sourceCpp(), it's fine, but when I
> add "// [[Rcpp::export]]" above the function definition, I get an error
> message:
>
> Error in sourceCpp("foo.cpp") :
>   Error 1 occurred building shared library.
> foo.cpp:229: error: expected initializer before ‘SEXP’
>
> So I wonder how I can fix this mistake.
>
>
> (2). Imagine a more complex scenario: suppose there are two functions
> available to be passed to foo(). But the two functions differ in the number
> of arguments each has (see fun1() and fun2() below). I wonder if there is
> any way to deal with this.
>
> double fun1(NumericVector x){
> double total=0;
>  for(int i=0;i total+=x(i);
>  return total/10;
> }
>
>
> double fun2(NumericVector x, int n){
> double total=0;
>  for(int i=0;i total+=x(i)+add;
>  return total/n;
> }
>  Thank you in advance!
>
>
> Best,
> -Xiao
>
>
> ___
> 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] Segfault error during simulation in Rcpp: explanation/fix

[JJ Allaire]

Ben,

Thanks SO much for the work you did to discover this problem. I've
committed a fix in rev 4319 (also bumped the version to 0.10.3.3 so a new
tarball will also be available from R-forge soon).

Best,

J.J.

On Fri, May 17, 2013 at 8:12 AM, QRD  wrote:

> Hi,
>
> On Thu, May 16, 2013 at 11:02 AM, Dirk Eddelbuettel 
> wrote:
> > Here is the self-contained example I asked for.
> >
> > And yes, it crashes for me too.  So let's not create 1e6 temp matrices.
> > Until someone has time to debug memory management internals.  Which is
> > really hard, so this may not get fixed for a while.  Sorry.
> >
> > #!/usr/bin/Rscript
> >
> > library(Rcpp)
> > myFun <- cppFunction('NumericMatrix myFun(NumericMatrix input, int n){
> >   NumericMatrix A(n, n);
> >   for(int Row = 0; Row < n; Row++) {
> > for(int Col = 0; Col < n; Col++) {
> >   A(Row, Col) = input(Row, Col);
> > }
> >   }
> >   return A;
> > }')
> >
> > n <- 10
> > x <- 1:n^2
> > N <- 1e6
> > b <- 0
> > for (j in 1:N) {
> > means <- matrix(x, n, n)
> > res <- myFun(means, n)
> > a <- res[1, 1]
> > b <- b + a
> > }
> >
> > cat(sprintf("Done, b is %d\n", b))
>
> I had a look at this, and I think I see what's going on.
>
> The error is reproducible much more quickly under gctorture(), and then
> working directly with the generated code in its own C++ file, I was able
> to cut it down to:
>
> - - - - 8< - - - - crash-fn.r
>
> require(methods)
> require(Rcpp)
>
> dll.info <- dyn.load("crash-fn")
> mod <- Module("Crash", dll.info, mustStart = TRUE)
> myFun <- mod$myFun
>
> N <- 25
> b <- 0
>
> for (j in 1:N) {
> gctorture(TRUE)
> res <- myFun()
> gctorture(FALSE)
> b <- b + res[1]
> }
>
> - - - - 8< - - - - crash-fn.cpp
>
> #include 
>
> static SEXP myFun()
> {
> Rcpp::RNGScope __rngScope;
> Rcpp::NumericMatrix __result(5, 5);
>
> return Rcpp::wrap(__result);
> }
>
> RCPP_MODULE(Crash)
> {
> Rcpp::function("myFun", &myFun);
> }
>
> - - - - 8< - - - -
>
> Then:
>
> R CMD SHLIB crash-fn.cpp && Rscript crash-fn.r
>
> reliably and quickly crashes.
>
> I think what happens is that the
>
> return Rcpp::wrap(__result);
>
> line at the end of the function pulls the m_sexp out of the
> NumericMatrix (because a NumericMatrix is an RObject) via
>
> inline operator SEXP() const { return m_sexp ; }
>
> and gets ready to return it.  But before the 'return' actually happens,
> the destructors for the NumericMatrix and the RNGScope get called, in
> that order.  The NumericMatrix destructor releases its underlying SEXP,
> via the base class destructor
>
> RObject::~RObject() {
> RCPP_DEBUG_1("~RObject(<%p>)", m_sexp)
> Rcpp_ReleaseObject(m_sexp) ;
> }
>
> and now our return-value SEXP is unprotected.  The destructor of
> RNGScope then runs, calling PutRNGstate(), where (reliably under
> gctorture(); very occasionally without this) our result SEXP gets
> re-allocated, or otherwise stomped on.
>
> If you swap the order of the declarations of __rngScope and __result,
> the code runs correctly, supporting this explanation.
>
> As for a fix, one way would be to wrap an extra scope round the main
> body of the generated code and PROTECT the wrapped result.  This works
> in my cut-down example:
>
> static SEXP myFun()
> {
> SEXP __sexp_result;
> {
> Rcpp::RNGScope __rngScope;
> Rcpp::NumericMatrix __result(5, 5);
>
> PROTECT(__sexp_result = Rcpp::wrap(__result));
> }
> UNPROTECT(1);
> return __sexp_result;
> }
>
> and the generated code could instead be
>
> RcppExport SEXP sourceCpp_78413_myFun(SEXP inputSEXP, SEXP nSEXP) {
> BEGIN_RCPP
> SEXP __sexp_result;
> {
> Rcpp::RNGScope __rngScope;
> NumericMatrix input = Rcpp::as(inputSEXP);
> int n = Rcpp::as(nSEXP);
> NumericMatrix __result = myFun(input, n);
> PROTECT(__sexp_result = Rcpp::wrap(__result));
> }
> UNPROTECT(1);
> return __sexp_result;
> END_RCPP
> }
>
> I'm not fully familiar with how the C++ code gets generated, but perhaps
> somebody who is could implement this or similar fix?
>
> Thanks,
>
> Ben.
> ___
> 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] compileAttributes() and subfolders

[JJ Allaire]

No, there currently isn't a way to cause it look inside subfolders.

J.J.

On Mon, May 13, 2013 at 5:48 AM, Finlay Scott wrote:

> Hi,
> I am putting a package together using Rcpp attributes. It's all working
> well so far (thanks to help I previously I got from this list).
>
> To organise my source files a little better I wanted to have a subfolder
> in the /src folder (not essential but makes things a little neater). The
> *.cpp files in the /src/subfolder have functions that are exported with the
> //[[Rcpp::export]] tag. However, when I call compileAttributes() (or use
> load_all() from the devtools package) the RcppExports.cpp file that is
> created does not include the functions from the /src/subfolder.
>
> Is there a way to get compileAttributes() to look inside subfolders? It's
> not essential, I'm just curious.
>
> Yours
>
> Finlay
>
>
>
> ___
> 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] sourceCpp error

[JJ Allaire]

>
> other attached packages:
> [1] Rcpp_0.10.2
>
>
In your first message you said you were running Rcpp 0.10.3 whereas this
output says you are running Rcpp 0.10.2. That seems a likely culprit.

Sometimes there are DLL permission problems associated with updating Rcpp
(or any package with shared libraries). In the most recent versions of
RStudio v0.97 we do a lot to prevent these problems -- if you aren't
running the very latest RStudio maybe update an try re-installing Rcpp
again?

J.J.
___
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] Question about custom as and wrap functions

[JJ Allaire]

Okay, very glad to hear you've got things working!

J.J.

On Fri, Apr 26, 2013 at 3:35 AM, Finlay Scott wrote:

> Fixed it.
> It was me making a stupid mistake. I had:
>
> PKG_CXXFLAGS=-I../inst/include
>
> in the Makevars when I should have had
>
> PKG_CPPFLAGS=-I../inst/include
>
> After using J.J.'s suggestion of renaming the header files, the package
> now compiles and my minimal test now works.
>
> Thanks to everyone for responding quickly.
>
> Finlay
>
>
>
> On Thu, Apr 25, 2013 at 12:28 PM, Dirk Eddelbuettel wrote:
>
>>
>> On 25 April 2013 at 10:47, Finlay Scott wrote:
>> | Thanks for the reply. I followed your suggestion and changed the name
>> of the
>> | header file in /inst/include to 'asWrapExample.h' (the name of the
>> package). I
>> | then changed the #include in the 'DummyClass_example.cpp' file to
>> reflect that
>> | change. I also added:
>> |
>> | PKG_CXXFLAGS=-I../inst/include
>> |
>> | To the top of the Makevars file. However, I still get the same error. I
>> have
>> | the feeling I'm missing something obvious. Thanks for the help so far.
>>
>> Seems you are "just" having issues with package mechanics.
>>
>> You could try to look at an existing package as eg out RcppGSL which has
>> had
>> this working for several years.  Try comparing all the relevant files
>> mentioned in the corresponding vignette Rcpp-extending.
>>
>> Dirk
>>
>> | Yours
>> |
>> | Finlay
>> |
>> |
>> |
>> | On Wed, Apr 24, 2013 at 5:41 PM, JJ Allaire 
>> wrote:
>> |
>> | Hi Finlay,
>> |
>> | If you name your include file the same name as your package then it
>> will be
>> | included automatically in RcppExports.cpp. The convention at work
>> here is
>> | that any custom as/wrap handlers should be accumulated (or
>> referenced from)
>> | that single file. This mirrors the existing convention used by Rcpp,
>> | RcppArmadillo, RcppEigen, etc. to have a single global header file
>> for
>> | their C++ API.
>> |
>> | J.J.
>> |
>> |
>> | On Wed, Apr 24, 2013 at 8:22 AM, Finlay Scott <
>> drfinlaysc...@gmail.com>
>> | wrote:
>> |
>> | Hi
>> | First of all I want to say how impressed I am with Rcpp. I
>> think it is
>> | going to be very useful for some of the packages I am
>> developing. Thank
>> | you very much for developing it.
>> |
>> | I have a question regarding writing custom as and wrap
>> functions for my
>> | own classes. Following the example in:
>> |
>> | http://gallery.rcpp.org/articles/custom-as-and-wrap-example/
>> |
>> | I can get my own minimal example to work with a very simple
>> class, and
>> | using the sourceCpp() function.
>> |
>> | The cpp code saved as a *.cpp file:
>> |
>> | #include 
>> |
>> | class DummyClass {
>> | public:
>> | double value;
>> | };
>> |
>> | namespace Rcpp {
>> | // non-intrusive extension via template specialisation
>> | template <> DummyClass as(SEXP dt);
>> | // non-intrusive extension via template specialisation
>> | template <> SEXP wrap(const DummyClass &d);
>> | }
>> |
>> | #include 
>> |
>> | // define template specialisations for as and wrap
>> | namespace Rcpp {
>> | template <> DummyClass as(SEXP dtsexp) {
>> | S4 dc_s4 = Rcpp::as(dtsexp);
>> | DummyClass dc;
>> | dc.value = dc_s4.slot("value");
>> | return dc;
>> | }
>> |
>> | template <> SEXP wrap(const DummyClass &d) {
>> | Rcpp::S4 dc_s4("DummyClass");
>> | dc_s4.slot("value") = d.value;
>> | return Rcpp::wrap(dc_s4);
>> | }
>> | }
>> |
>> | // [[Rcpp::export]]
>> | DummyClass test_as_wrap(DummyClass dc, double multiplier){
>> | DummyClass dc_out;
>> | dc_out.value = dc.value * multiplier;
>> | return dc_out;
>> |   

Re: [Rcpp-devel] Question about custom as and wrap functions

[JJ Allaire]

Finlay,

Are you running Rcpp 0.10.3 (that version is required for the behavior I
mentioned to work).

If you could provide a fully self-contained reproducible example then it
will be pretty easy for us to track down the source of the troubles
(perhaps create a simple test package then upload it to a gist?)

J.J.

On Thu, Apr 25, 2013 at 4:47 AM, Finlay Scott wrote:

> Thanks for the reply. I followed your suggestion and changed the name of
> the header file in /inst/include to 'asWrapExample.h' (the name of the
> package). I then changed the #include in the 'DummyClass_example.cpp' file
> to reflect that change. I also added:
>
> PKG_CXXFLAGS=-I../inst/include
>
> To the top of the Makevars file. However, I still get the same error. I
> have the feeling I'm missing something obvious. Thanks for the help so far.
>
> Yours
>
> Finlay
>
>
>
> On Wed, Apr 24, 2013 at 5:41 PM, JJ Allaire  wrote:
>
>> Hi Finlay,
>>
>> If you name your include file the same name as your package then it will
>> be included automatically in RcppExports.cpp. The convention at work here
>> is that any custom as/wrap handlers should be accumulated (or referenced
>> from) that single file. This mirrors the existing convention used by Rcpp,
>> RcppArmadillo, RcppEigen, etc. to have a single global header file for
>> their C++ API.
>>
>> J.J.
>>
>>
>>  On Wed, Apr 24, 2013 at 8:22 AM, Finlay Scott 
>> wrote:
>>
>>>  Hi
>>> First of all I want to say how impressed I am with Rcpp. I think it is
>>> going to be very useful for some of the packages I am developing. Thank you
>>> very much for developing it.
>>>
>>> I have a question regarding writing custom as and wrap functions for my
>>> own classes. Following the example in:
>>>
>>> http://gallery.rcpp.org/articles/custom-as-and-wrap-example/
>>>
>>> I can get my own minimal example to work with a very simple class, and
>>> using the sourceCpp() function.
>>>
>>> The cpp code saved as a *.cpp file:
>>>
>>> #include 
>>>
>>> class DummyClass {
>>> public:
>>> double value;
>>> };
>>>
>>> namespace Rcpp {
>>> // non-intrusive extension via template specialisation
>>> template <> DummyClass as(SEXP dt);
>>> // non-intrusive extension via template specialisation
>>> template <> SEXP wrap(const DummyClass &d);
>>> }
>>>
>>> #include 
>>>
>>> // define template specialisations for as and wrap
>>> namespace Rcpp {
>>> template <> DummyClass as(SEXP dtsexp) {
>>> S4 dc_s4 = Rcpp::as(dtsexp);
>>> DummyClass dc;
>>> dc.value = dc_s4.slot("value");
>>> return dc;
>>> }
>>>
>>> template <> SEXP wrap(const DummyClass &d) {
>>> Rcpp::S4 dc_s4("DummyClass");
>>> dc_s4.slot("value") = d.value;
>>> return Rcpp::wrap(dc_s4);
>>> }
>>> }
>>>
>>> // [[Rcpp::export]]
>>> DummyClass test_as_wrap(DummyClass dc, double multiplier){
>>> DummyClass dc_out;
>>> dc_out.value = dc.value * multiplier;
>>> return dc_out;
>>> }
>>>
>>>
>>> And the following R code compiles and calls the function:
>>>
>>> library(Rcpp)
>>> sourceCpp("DummyClass_example.cpp")
>>> setClass("DummyClass", representation(value = "numeric"))
>>> dc <- new("DummyClass")
>>> dc@value <- 23
>>> test_as_wrap(dc, 4)
>>>
>>> This works just fine (like magic!) and the test_as_wrap() function is
>>> happily called from R and returns an object of type DummyClass. I want to
>>> use a similar approach in a package, so I made a minimal package using:
>>>
>>> Rcpp.package.skeleton("asWrapExample",attributes=TRUE)
>>>
>>> I then split my original cpp file above into header and source code
>>> files. In the /inst/include directory I placed a file
>>> 'DummyClass_example.h' which has:
>>>
>>> #include 
>>>
>>> class DummyClass {
>>> public:
>>> double value;
>>> };
>>>
&

Re: [Rcpp-devel] Question about custom as and wrap functions

[JJ Allaire]

Hi Finlay,

If you name your include file the same name as your package then it will be
included automatically in RcppExports.cpp. The convention at work here is
that any custom as/wrap handlers should be accumulated (or referenced from)
that single file. This mirrors the existing convention used by Rcpp,
RcppArmadillo, RcppEigen, etc. to have a single global header file for
their C++ API.

J.J.


On Wed, Apr 24, 2013 at 8:22 AM, Finlay Scott wrote:

> Hi
> First of all I want to say how impressed I am with Rcpp. I think it is
> going to be very useful for some of the packages I am developing. Thank you
> very much for developing it.
>
> I have a question regarding writing custom as and wrap functions for my
> own classes. Following the example in:
>
> http://gallery.rcpp.org/articles/custom-as-and-wrap-example/
>
> I can get my own minimal example to work with a very simple class, and
> using the sourceCpp() function.
>
> The cpp code saved as a *.cpp file:
>
> #include 
>
> class DummyClass {
> public:
> double value;
> };
>
> namespace Rcpp {
> // non-intrusive extension via template specialisation
> template <> DummyClass as(SEXP dt);
> // non-intrusive extension via template specialisation
> template <> SEXP wrap(const DummyClass &d);
> }
>
> #include 
>
> // define template specialisations for as and wrap
> namespace Rcpp {
> template <> DummyClass as(SEXP dtsexp) {
> S4 dc_s4 = Rcpp::as(dtsexp);
> DummyClass dc;
> dc.value = dc_s4.slot("value");
> return dc;
> }
>
> template <> SEXP wrap(const DummyClass &d) {
> Rcpp::S4 dc_s4("DummyClass");
> dc_s4.slot("value") = d.value;
> return Rcpp::wrap(dc_s4);
> }
> }
>
> // [[Rcpp::export]]
> DummyClass test_as_wrap(DummyClass dc, double multiplier){
> DummyClass dc_out;
> dc_out.value = dc.value * multiplier;
> return dc_out;
> }
>
>
> And the following R code compiles and calls the function:
>
> library(Rcpp)
> sourceCpp("DummyClass_example.cpp")
> setClass("DummyClass", representation(value = "numeric"))
> dc <- new("DummyClass")
> dc@value <- 23
> test_as_wrap(dc, 4)
>
> This works just fine (like magic!) and the test_as_wrap() function is
> happily called from R and returns an object of type DummyClass. I want to
> use a similar approach in a package, so I made a minimal package using:
>
> Rcpp.package.skeleton("asWrapExample",attributes=TRUE)
>
> I then split my original cpp file above into header and source code files.
> In the /inst/include directory I placed a file 'DummyClass_example.h' which
> has:
>
> #include 
>
> class DummyClass {
> public:
> double value;
> };
>
> namespace Rcpp {
> // non-intrusive extension via template specialisation
> template <> DummyClass as(SEXP dt);
> // non-intrusive extension via template specialisation
> template <> SEXP wrap(const DummyClass &d);
> }
>
> In the /src directory I placed a file 'DummyClass_example.cpp' which has:
>
> #include "../inst/include/DummyClass_example.h"
> #include 
>
> // define template specialisations for as and wrap
> namespace Rcpp {
> template <> DummyClass as(SEXP dtsexp) {
> S4 dc_s4 = Rcpp::as(dtsexp);
> DummyClass dc;
> dc.value = dc_s4.slot("value");
> return dc;
> }
>
> template <> SEXP wrap(const DummyClass &d) {
> Rcpp::S4 dc_s4("DummyClass");
> dc_s4.slot("value") = d.value;
> return Rcpp::wrap(dc_s4);
> }
> }
>
> // [[Rcpp::export]]
> DummyClass test_as_wrap(DummyClass dc, double multiplier){
> DummyClass dc_out;
> dc_out.value = dc.value * multiplier;
> return dc_out;
> }
>
> When I try to compile the package I get this error message:
>
> RcppExports.cpp:9:1: error: 'DummyClass' does not name a type
>
> This is probably caused by the RcppExports.cpp not having an #include for
> my DummyClass_example.h.
> I understand the RcppExports.cpp file is automatically generated by the
> magic of Rcpp so there is no point in adding it there by hand.
> I've looked at the documentation but it is not clear to me how I can tell
> RcppExports to also include my header file (if this is the source of the
> problem).
> Have I missed something in the documentation, or is there an example I can
> follow?
> Any help is appreciated.
>
> Yours
>
> Finlay
>
>
>
>
>
> ___
> 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, bigmemory, package creation

[JJ Allaire]

Alex,

Glad that you sorted all of this out! Wanted to also point out that there
is a mechanism for bigmemory to have it's headers automatically included in
RcppExports.cpp and perhaps this is something Michael can pursue so
everything works automatically in the future.

In short, if bigmemory defines an Rcpp inline plugin (by calling
Rcpp.plugin.maker) that lists the includes required for correct compilation
then these includes will be inserted at the top of RcppExports.cpp.
Michael, ping me off list if you have any questions or want to discuss
further.

J.J.




On Thu, Apr 11, 2013 at 5:44 PM, Alex Ustian wrote:

> All right!  I think I have it figured out, at least for the toy
> functions/package.
>
> What wasn't compiling wasn't my functions, it was RcppExports.cpp.
> sourceCpp (and hence also the knit example) have been working for me all
> along.  The only issue (apparently) was that RcppExports.cpp was not
> including the bigmemory headers.  It complained about not knowing the type
> "BigMatrix" for example.  However since RcppExports.cpp is automatically
> generated, I didn't know how to force it to include more headers.
>
> It dawned on me that somewhere in the Rcpp-attributes vignette creating
> custom headers came up, sure enough using // [[Rcpp::interfaces(r, cpp)]]
> and following along in that section 3.5 discussion and then rebuilding did
> the trick.  In the end I just I added the required bigmemory header
> "MatrixAccessor.hpp" to the generated "package.h" file, which is then
> automatically included into the RcppExports.cpp file.
>
> Thanks again, and thanks everybody for developing and providing support
> for this incredible software.
> Alex
>
>
> On Thu, Apr 11, 2013 at 4:33 PM, Dirk Eddelbuettel  wrote:
>
>>
>>
>> On 11 April 2013 at 16:14, Alex Ustian wrote:
>> | Sorry to be dense, but you mean to copy and paste the source into an
>> Rmd file
>> | and knit it?  If yes, then I did just that and it did work.
>>
>> Good.
>>
>> Now try to find the differences to your code, which as I understand your
>> post, does not compile.  As you just demonstrated that your compiler, R,
>> Rcpp,
>> bigmemory, ... setup is fine.
>>
>> 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

Re: [Rcpp-devel] Rcpp, bigmemory, package creation

[JJ Allaire]

Alex,

Did you add an entry for bigmemory in the Depends field of the package
DESCRIPTION file? That would certainly explain the errors you are seeing.

J.J.


On Wed, Apr 10, 2013 at 12:50 PM, Alex Ustian wrote:

> Sorry for this double post, I am now correctly subscribed to the list!
>
> Hello,
>
> I'm having an issue building a package (named bigExplore) in RStudio which
> uses both Rcpp and the MatrixAccessor from bigmemory.  All of my functions
> seem to work fine when I was interactively developing them via sourceCpp.
>
> The head of a sample .cpp file is:
>
> // [[Rcpp::depends(bigmemory)]]
> #include 
> #include 
>
> // [[Rcpp::export]]
> void cbindWriter(Rcpp::XPtr pA, Rcpp::XPtr pB,
> Rcpp::XPtr pC)
> ...
>
> My DESCRIPTION file contains:
> Depends: bigmemory(>= 4.2.11), Rcpp(>= 0.10.3), RcppArmadillo(>= 0.3.800.1)
> LinkingTo: bigmemory, Rcpp, RcppArmadillo
>
> NAMESPACE:
> useDynLib(bigExplore)
> exportPattern("^[[:alpha:]]+")
>
> and I made the two Makevars(.win) files for the src directory with:
>
> PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
> PKG_LIBS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e 
> "Rcpp:::LdFlags()")
>
>
> When I hit Build&Reload in RStudio I get the following message which seems to 
> be complaining about not being able to find the bigmemory header infos
>
> ==> Rcpp::compileAttributes()
>
> bigmemory >= 4.0 is a major revision since 3.1.2; please see package
> biganalytics and http://www.bigmemory.org for more information.
> ==> Rcmd.exe INSTALL --no-multiarch bigExplore
> * installing to library 'C:/Users/Alex/Documents/R/win-library/2.15'* 
> installing *source* package 'bigExplore' ...** libsg++ -m64 
> -I"C:/PROGRA~1/R/R-215~1.3/include" -DNDEBUG
> -I"C:/Users/Alex/Documents/R/win-library/2.15/bigmemory/include" 
> -I"C:/Users/Alex/Documents/R/win-library/2.15/Rcpp/include" 
> -I"C:/Users/Alex/Documents/R/win-library/2.15/RcppArmadillo/include" 
> -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall  -mtune=core2 
> -c RcppExports.cpp -o RcppExports.oRcppExports.cpp:10:29: error: 'BigMatrix' 
> was not declared in this scopeRcppExports.cpp:10:38: error: template argument 
> 1 is invalidRcppExports.cpp:10:38: error: template argument 2 is 
> invalidRcppExports.cpp:10:55: error: 'BigMatrix' was not declared in this 
> scope
>
>
> and so on...
>
>
> The RcppExports.cpp that is generated starts out like:
>
> // This file was generated by Rcpp::compileAttributes
> // Generator token: 10BE3573-1514-4C36-9D1C-5A225CD40393
>
> #include 
>
>
> #include 
>
> using namespace Rcpp;
>
> // cbindWriter
> void cbindWriter(Rcpp::XPtr pA, Rcpp::XPtr pB, 
> Rcpp::XPtr pC);
> ...
>
> which doesn't include any of the bigmemory header information.
>
>
> I did see a recent similar question that was archived on Google
> http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg05232.html
>
> but it appears that a solution was found by adding bigmemory into the depends 
> part of the DESCRIPTION file.  (which I have already done)
>
> Thanks in advance for your patience and taking the time to look over my 
> problem.
>
>
> Alex Ustian
>
>
> ___
> 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+bigmemory

[JJ Allaire]

Hi Aileen,

You should also add bigmemory to the the Depends line of the DESCRIPTION
file. See:
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages

J.J.


On Tue, Apr 2, 2013 at 2:49 AM, Aileen Lin wrote:

> Problem solved. Need to add bigmemory after ' linking:' in description
> file. Thanks.
>
> Aileen Lin
>
> View my profile: au.linkedin.com/in/aileen2
>
> ___
> 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] Regular Expressions

[JJ Allaire]

Note that the Sys.setenv technique described by Dirk will work for
Rcpp from SVN but not (yet) for the version of Rcpp on CRAN.

JJ
___
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