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
nsions 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
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
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, s
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-rc
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
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, 201
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 :
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 t
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 p
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 w
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 int
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 i
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:
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
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 whi
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 a
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 Vassi
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
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 t
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
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 nod
he 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
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 t
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) whic
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.
>
erwriting
> 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
>
>> 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 &
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.
&g
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
a
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 wr
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
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
>
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
> 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 h
e 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
&g
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
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
t;>
>> 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
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:
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 he
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 f
ove 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
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++ des
yle
> 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 longe
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
d
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 term
>
> 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
e
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
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 shou
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 sess
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 b
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 packa
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, t
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, Mar
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
g 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:
> >
> >
> 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
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 u
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 int
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 t
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@li
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/pu
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:
> |
> | htt
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
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.
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).
nettes/Rcpp-extending.Rnw'
>
>'vignettes/Rcpp-modules.Rnw'
>
>'vignettes/Rcpp-package.Rnw'
>
> 'vignettes/Rcpp-quickref.Rnw'
>
>'vignettes/Rcpp-sugar.Rnw'
>
> (Is a VignetteBuilder field missing?)
>
>
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 hav
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 jan
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 incl
>
> 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
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 Ma
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 confi
nters/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
> 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 a
> 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/o
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
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 ar
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
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 T
>
> 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 me
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
>
> 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.
__
>
> 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 wa
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-e
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 succe
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 intentio
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 A
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 sourc
>
> 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 li
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.
yClass_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
>
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 b
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 defi
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,
>
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 ' l
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/list
1 - 100 of 142 matches
Mail list logo
