Rcpp checks for R version >= 4.4.2, so older versions of R-devel
(which report R 4.5.0) might encounter this error. Updating to the
latest R-devel should resolve the issue, and any existing releases of
R shouldn't be affected. See:
https://github.com/RcppCore/Rcpp/blob/c0d16d4601c08b4031f4f7fcff19
I'm also not able to reproduce, but I see a different linker invocation:
g++ -shared -static-libgcc -o sourceCpp_3.dll tmp.def file43185fe94049.o
-LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64
-LC:/rtools43/x86_64-w64-mingw32.static.posix/lib -LC:/R/R-43~1.0/bin/x64
-lR
In particular, your
Kevin
On Thu, Feb 23, 2023 at 11:34 AM Kevin Ushey wrote:
>
> Hi Roberto,
>
> (RcppParallel maintainer here.) We had some correspondence with
> Professor Ripley regarding this; package authors affected by this
> could request the C++14 standard in their package as described h
Hi Roberto,
(RcppParallel maintainer here.) We had some correspondence with
Professor Ripley regarding this; package authors affected by this
could request the C++14 standard in their package as described here:
https://cran.r-project.org/doc/manuals/R-exts.html#Using-C_002b_002b-code
I believe i
For posterity, what machine are you compiling the package on? If you're
using a modern Linux system, it's possible the default compilation flags
are including stack protection code during compilation that might call
abort on error. See e.g.
https://developers.redhat.com/articles/2022/06/02/use-com
nd you
want to be able to catch and handle R errors at the C++ level,
UnwindProtect() isn't the right tool -- you'll want a proper tryCatch()
handler.
It does also imply (as had been shown) that switching to unwind-protect
would be a behavior change in Rcpp, which may not be ideal.
Tha
And I'm seeing you pointed that out at the end of the README... so yes, we
should probably just have our exception inherit from std::exception.
On Sun, Feb 6, 2022 at 9:31 AM Dirk Eddelbuettel wrote:
>
> On 6 February 2022 at 18:18, Jeroen Ooms wrote:
> | Well not really, this kind of misses my
it looks like the exception can be caught -- just not via
std::exception.
On Sun, Feb 6, 2022 at 9:21 AM Kevin Ushey wrote:
> Is it possible the issue here is ultimately just that our
> LongjumpException class doesn't inherit from std::exception?
>
> On Sun, Feb 6, 2022 at 9
Is it possible the issue here is ultimately just that our
LongjumpException class doesn't inherit from std::exception?
On Sun, Feb 6, 2022 at 9:18 AM Jeroen Ooms wrote:
> On Sun, Feb 6, 2022 at 5:56 PM Dirk Eddelbuettel wrote:
> >
> >
> > On 6 February 2022 at 17:40, Jeroen Ooms wrote:
> > | We
I assume we're talking about Vector::create()? Anyone curious poking at it
can start by looking here:
https://github.com/RcppCore/Rcpp/blob/940fb23868bf442e587994451e85263baa302d9c/inst/include/Rcpp/vector/Vector.h#L1122-L1126
On Wed, Dec 15, 2021 at 8:51 AM Dirk Eddelbuettel wrote:
>
> Joseph,
I'm a fan. I think we could just have a single header RcppLite.h which
would turn off the "heaviest" pieces of Rcpp; that is, modules + sugar
+ (maybe?) RTTI.
Or, we could allow for #define RCPP_LEAN_AND_MEAN ... ;-)
On Fri, Dec 3, 2021 at 10:57 AM Dirk Eddelbuettel wrote:
>
>
> On 3 December 20
I think you're bumping into the 20 argument limit for our (now rather old)
Vector::create() implementation. I thought we also had a variadic C++11
version for this, but apparently I am mistaken...
A workaround is to use something like the ListBuilder class I put together
a while back here:
https:
On Thu, Feb 18, 2021 at 1:36 AM Andrade Solomon
wrote:
>
> Dear list,
>
> I see here that Rccp strings have both a get_encoding() and a set_encoding()
> member functions, which respectively return and accept a cetype_t enum
> defined in Rinternals.h with options:
> CE_NATIVE = 0,
> CE_UT
Are you able to share a reproducible example?
The CRAN check report from
https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/MatchIt/00check.log
points at MatchIt/src/nnm.cpp:182:24. You could probably distill the code
used in that location into a smaller reproducible example.
Best,
Kevin
On
The most likely cause here is that, even though Rcpp is being compiled
with gcc 9.2.0, an older version of libstdc++ is being found and used
at runtime, and that version of the libstdc++ library doesn't provide
the requested symbol (_ZTVN10__cxxabiv120__si_class_type_infoE).
Best guess: LD_LIBRARY
FWIW, the implementation of of is_finite lives here:
https://github.com/RcppCore/Rcpp/blob/b1254701a899cb187f9a6917cb8d18c7f93290c7/inst/include/Rcpp/traits/is_infinite.h#L34-L37
I would recommend checking equality directly against the R constants
`R_PosInf` and `R_NegInf`.
As for whether this w
> In file included from /usr/local/include/math.h:8:
The problem here is you have a bunch of headers in /usr/local/include
that are shadowing / overriding the "normal" system header files;
/usr/local/include/math.h being one of these (but I imagine there's
more).
To work around this, you'll have
https://godbolt.org/z/dowsE5
But gcc trunk seems okay.
Best,
Kevin
On Sat, Feb 8, 2020 at 5:20 PM Dirk Eddelbuettel wrote:
>
>
> On 8 February 2020 at 16:59, Kevin Ushey wrote:
> | It seems like a bug in gcc 10 to me. IIUC, static local variables in
> | inline functions should still have i
It seems like a bug in gcc 10 to me. IIUC, static local variables in
inline functions should still have internal linkage, and so name
collisions like this should not occur.
I can work around this by making sure that 'fun' is given different
names in the RcppEigen stubs; e.g. fun1 and fun2 and so o
On Sat, Feb 8, 2020 at 12:52 PM Joshua N Pritikin wrote:
>
> On Sat, Feb 08, 2020 at 03:47:49PM -0500, JJ Allaire wrote:
> >On Sat, Feb 8, 2020 at 3:45 PM Joshua N Pritikin
> ><[1]jpriti...@pobox.com> wrote:
> > Sure, but does it *have* to be that way? It seems to me that
> > exc
I think Tomas's post is clear and quite helpful, I just disagree with
the conclusions. IMHO C++ (through Rcpp) is still the best way to
interface with R from compiled code for the majority of users.
Tomas's comments were mainly around the fact that things can go wrong
if you start mixing R longjmp
In general, once an Rcpp API gives you a SEXP, it is unprotected and
the onus is on your to manage its protection.
In your code:
SEXP intSexp = call1.eval();
Language call2("levels",facSexp);
SEXP levelsSexp = call2.eval();
vals = as< std::vector >(
Many of the Solaris quirks are documented in R-exts:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Portable-C-and-C_002b_002b-code
In particular:
Mathematical functions such as sqrt are defined in C++ for
floating-point arguments. It is legitimate in C++ to overload these
with ver
I think this might be worth fixing on the Rcpp side -- there should
really only be one instance of the Rcout object. Would you mind filing
an issue at https://github.com/RcppCore/Rcpp/issues, so we don't lose
track of this?
You could of course just create your own Rcout / Rcerr objects as well
(th
I agree we should be using R_xlen_t here. As always, PRs are welcome.
You might want to file this at https://github.com/RcppCore/Rcpp/issues
just so it doesn't get lost.
Thanks,
Kevin
On Tue, Nov 6, 2018 at 11:23 PM Qiang Kou wrote:
>
> Hi, William,
>
> Can you give us a small piece of code to
I can reproduce if the 'pkgKitten' package is not installed. In that
case, I see in man/-package.Rd:
\examples{
~~ simple examples of the most important functions ~~
}
which of course is just a stub and not valid example code (and so
fails during check).
I think this is just gunk tha
FWIW, there's an associated bug report here:
https://github.com/google/sanitizers/issues/911
that indicates that ubsan emits false positives when attempting to diagnose
functions opened through dlopen(), which IIUC is the standard way that R
loads symbols from compiled libraries in R packages
I think the main problem is that it's easy to use your class incorrectly.
For example:
- What happens if your map is destructed? The SEXPs it is handling are
effectively leaked.
- What if you copy your map? Since SEXPs are pointers, you now have two
maps containing the same pointers, and if you we
What environment are you executing this on? (R in terminal, or with a GUI;
which OS?)
One thing to be cautious of is that many R APIs in graphical environments
will also call for processing of events, and this in turn can also imply a
check for, and handling of, interrupts. Rprintf() is in fact on
I think this is mostly because we still haven't ported the majority of
usages of Rcpp_eval() to the new Rcpp_fast_eval(), so by default users are
still getting the slower Rcpp_eval(). Compare e.g.
Rcpp::sourceCpp(code='
#include
using namespace Rcpp;
// [[Rcpp::export]]
void Rcpp_eval_ol
essionInfo() after running the second
> command, includes nycflights13 in the section "loaded via a namespace (and
> not attached):" This is not the case after pulling the environment into an
> Rcpp variable.
>
> Thanks again for steering me,
> Jack
>
>
>
> On 04
The environments called 'package:foo' are associated with attached
packages; that is, they're located on the search path. You likely want to
find the actual package namespace.
I think we have a static function Environment::namespace_env() for this. Or
you can just call back to R with requireNamesp
In your RcppParallel worker, it looks like you're trying to write to
an Rcpp matrix; e.g. you have:
distmat_(i,j) = local_calculator->calculate(i,j);
where distmat_ is a matrix. You should avoid using Rcpp classes within
RcppParallel workers, as there's no guarantee that the methods
available
My understanding is that `integer64` actually stores its contents in an R
numeric vector, so presumedly you should be able to handle this by
forcefully casting the contents as you access it, e.g.
#include
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector timesTwo(NumericVector input) {
I can't replicate the reported UBSAN issues on my macOS machine (R-devel
compiled with LLVM clang 4.0.1, with address + undefined behavior
sanitizers active).
The warnings look somewhat dubious to me: for example, the first warning:
function_pointers.h:99:12: runtime error: call to function
a1_fn
To be brief -- Rcpp modules are effectively in maintenance mode at this
point; we don't plan to extend / improve modules beyond resolving issues if
and when they come up. We did get to the bottom of the posted issue -- R
packages that use modules need to import the whole Rcpp namespace.
I'm not qu
My best guess is that the issue here is that 'gfortran' is being used for
linking, e.g.
c:/Rtools/mingw_64/bin/gfortran -shared -s
-Wl,--allow-multiple-definition -static-libgcc -o ForTest.dll tmp.def
RcppExports.o VecSum_C.o VecSum_F.o -LC:/R/RLocalSoft/lib/x64
-LC:/R/RLocalSoft/lib -LC:/R/RCurre
I'm pretty sure I saw this post on StackOverflow before. Please don't cross
post, or at least indicate that you are when you do so. It's also nice to
give credit based on the advice you receive...
The main issue in your code, I think, is here:
struct Element : public std::enable_shared_from_this<
The simplest demonstrating example I can think of:
---
#include
using namespace Rcpp;
struct A { ~A() { Rprintf("~A()"); } };
// [[Rcpp::export]]
void ouch() {
A a;
Rf_error("ouch!");
}
/*** R
ouch()
*/
---
Call 'Rcpp::sourceCpp()' on that and you'll see:
> Rcpp::sourceCpp('~/Desktop/U
r you.
On Wed, Aug 3, 2016 at 11:28 AM, Kevin Ushey wrote:
> The problem with your implementation is what happens if R throws an
> error. The R longjmp will cause any C++ objects on the stack to leak,
> their destructors not to run, and you'll essentially be in a bad place
> if y
The problem with your implementation is what happens if R throws an
error. The R longjmp will cause any C++ objects on the stack to leak,
their destructors not to run, and you'll essentially be in a bad place
if you evaluate any R code that might return an error. (For example,
suppose you had a fil
If I had to guess, maybe there is some initialization that occurs when
your mylib::Simulation object is constructed, and you need to ensure
that code is only run once? (Perhaps the code that defines the program
options needs to be hidden behind an initialization flag, or something
like that)
Nonet
Thanks -- it looks to me like there is something more fundamentally
wrong with the 'replace_first' and 'replace_last' methods; ie, I don't
think we want to be using 'find_first_of' and 'find_last_of'
functions.
Ie, when writing
string.replace_first("foo", "bar");
I imagine we want to replace
It sounds like you just need to declare that your package depends on
C++11 in the standard way:
- Add 'SystemRequirements: C++11' to your DESCRIPTION file,
- Create files at 'src/Makevars[.win]', and make sure you have CXX_STD = CXX11
This is documented in more detail in R-exts: see
https://cran.
What about having a 'configure' script that generates this header file
on package install?
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
On Sun, Feb 28, 2016 at 11:18 AM, Baptiste Auguie
wrote:
> Dear Rcpp gurus,
>
> In the process of updating my planar packag
I think this needs to be _WIN32 rather than WIN32. Thanks for pointing this out!
On Thu, Feb 11, 2016 at 2:41 PM, Jonathon Love wrote:
> hi dirk,
>
> i've been compiling RInside on windows with the new RTools based on GCC 4.9.
> with stock settings, this all compiles successfully.
>
> however, if
ls pretty reliably for me. Perhaps we can add this to our unit tests.
On Sat, Jan 30, 2016 at 1:44 PM, Kevin Ushey wrote:
> I think I know what's going on now. Effectively, we're 'evaluating'
> the sugar proxy vector, getting a pointer to a (temporary,
> unprotected) R
hould be able to reproduce this reliably when running under
`gctorture()`...
Kevin
On Sat, Jan 30, 2016 at 7:07 AM, Qiang Kou wrote:
> Another thing confused me is the segfault only happens when the
> IntegerVector is significantly long.
>
> Best,
>
> KK
>
> On Sat, Jan 30, 2
t; |
> | (gdb) p i
> |
> | $1 = 33622
> |
> | (gdb) p indices[i]
> |
> | Cannot access memory at address 0x34c6e000
> |
> | (gdb) p indices_n
> |
> | $2 = 9594546
> |
> |
> | On Fri, Jan 29, 2016 at 2:29 PM, Dirk Eddelbuettel
&g
When I add some debug printing to the associated subscripting line
(https://github.com/awalker89/openxlsx/blob/b92bb3acdd6ea759be928c298c6faeef2f26fa3e/src/cppFunctions.cpp#L2608),
I see:
colNumbers.size(): 98,03,150
charCols.size(): 95,94,546
It looks to me like the package is erroneously
libR.so
> #18 0x77931909 in Rf_applyClosure () from /usr/lib/R/lib/libR.so
> #19 0x00007792bcef in Rf_eval () from /usr/lib/R/lib/libR.so
> #20 0x7792f52e in ?? () from /usr/lib/R/lib/libR.so
> #21 0x7792bf0d in Rf_eval () from /usr/lib/R/lib/libR.so
> #22 0x
A C++ stack trace would be very helpful. Can you try running R with gdb, e.g.
R -d gdb -f example.R
where 'example.R' is the path to your script that reproduces the
segfault? Hopefully, 'gdb' can provide more context on where the error
is occurring.
For what it's worth, the file did open suc
Hi Guillaume,
Compiling with the Makevars you provided, I see a number of warnings
related to sign conversion and loss of integer precision (due to the
use of `-Wconversion` in the Makevars).
I'll add an issue on the GitHub issue tracker just so we don't lose sight of it.
Thanks,
Kevin
On Mon,
You could try building clang yourself with UBSAN and testing with that
to see if you can reproduce; I have a script that mostly automates the
installation from trunk here:
https://github.com/kevinushey/etc/blob/master/Mac/install-llvm.sh
I think Apple's fork of clang has been a bit behind in
Doesn't CRAN R default to using -O2 flags when compiling C++ source
files? (I think the default is -O3 for C source files).
Are you using CRAN R, or a locally built R? You might need to set that
explicitly yourself when configuring R?
On Tue, Aug 25, 2015 at 2:54 PM, Avraham Adler wrote:
> The -
You'll have to share your package if you want more complete help, but some
of my responses are inline. My best guess is you have a funky configure
script or something to that effect.
On Mon, Jul 6, 2015 at 10:10 AM, Peng Yu wrote:
> Hi, I made a package using Rcpp and FORTRAN. But I see the foll
Indeed. I think this has been requested before to R-Core (adding
'inst/include' by default), but at the time they weren't willing to make
such a change. There's a chance they would still be receptive given a
suitable patch, though.
On Fri, Jun 12, 2015 at 10:24 AM Tim Keitt wrote:
>
>
> http://w
c1 is already defined, so you simply want
c1 = as(c1);
That is, when you write
NumericVector c1 = as(c1);
you are effectively trying to create a new NumericVector called `c1` -- but
since an object with the name `c1` already exists in scope, that fails.
Kevin
On Wed, Jun 10, 2015 at 1
Fabio,
Is it possible that is getting included before that header
file is included? If that were the case, that would imply
would be getting #include'd before you're able to make your as / wrap
specializations.
Just a guess...
Kevin
On Thu, May 21, 2015 at 10:15 AM, Dirk Eddelbuettel wrote:
>
That `R_running_as_main_program` error should be fixed R 3.2.0-patched.
See: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15899
If that hot-fix helps then that's good; otherwise, I would suggest
users patching their R headers after installation.
Kevin
On Fri, May 15, 2015 at 6:42 PM, Dir
Hi Randall,
`dataptr` just wraps over the R `DATAPTR` macro / function, so you
could just call that instead (although you might need to manually cast
the pointer type to whatever you need)
Kevin
On Sun, May 10, 2015 at 8:39 PM, Randall MacIntosh wrote:
> I am trying to run the TAM module in R 2
Finally, you could always try placing this in a file located at
`~/.R/Makevars`:
CC=clang
CXX=clang++
This was an 'old' workaround that ensured packages were built with `clang`
on Mavericks and above, when the transition first began...
On Tue, May 5, 2015 at 9:01 PM, Kevin Ushey wr
, Peng Yu wrote:
> On Tue, May 5, 2015 at 10:52 PM, Kevin Ushey wrote:
> > Your error:
> >
> > Error in dyn.load(file, DLLpath = DLLpath, ...) :
> > unable to load shared object
> > '/Users/py/Library/R/3.2/library/Rcpp/libs/Rcpp.so':
> >
Your error:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object
'/Users/py/Library/R/3.2/library/Rcpp/libs/Rcpp.so':
dlopen(/Users/py/Library/R/3.2/library/Rcpp/libs/Rcpp.so, 6): Symbol
not found: __ZNSoD0Ev
says some (mangled) symbol named `__ZNSoD0Ev` could not b
You need to link to GSL as well. RcppGSL provides the appropriate flags
within `RcppGSL::LdFlags()`. See what RcppGSL does itself in its configure
scripts:
https://github.com/eddelbuettel/rcppgsl/blob/2849b8dd777c8057e524c2141dfeaa8e28840350/inst/skeleton/configure.win
.
Kevin
On Tue, May 5, 201
Hi Daniel,
Unfortunately, you cannot use // [[Rcpp::export]] to automagically export
template functions.
The general alternative approach is to define a template implementation,
and then dynamically dispatch to that implementation, e.g.
template
void doStuffImpl() { ... }
with dispatch a
IIUC, from the build errors you're seeing, the compiler can't decide if it
should convert `0U` (unsigned int) to an `unsigned long` or a `char*` (e.g.
as a null pointer). In other words, these two overloads are competing:
void insert (iterator p, size_t n, char c);
string& insert (size_t pos,
This is by design; we pass objects by reference for efficiency. Use
`Rcpp::clone()` to explicitly duplicate objects.
On Tue, Apr 14, 2015 at 10:15 AM, wrote:
> Hello,
>
> I have just noticed that my small Rcpp function changes the original
> matrix on the R side -- why and how to pass by copy?
>
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
t/include/Rcpp/sugar/functions/setdiff.h#L80
>
>
> On Fri, Jan 2, 2015 at 9:23 PM, Qiang Kou wrote:
>>
>> I think the bug is from [1].
>>
>> This line doesn't make much sense.
>>
>> Best,
>>
>> KK
>>
>>
>> [1]
>>
Hi Søren,
Thanks for the bug report -- it looks like you're right, `setequal` is
broken, and we never knew about it because we don't have any unit
tests for it. Whoops!
I'll take a look at what's going on and commit a fix + tests soon --
for now, you can use the workaround with `setdiff` which ap
Hi Wush,
Thanks for investigating this, and I would certainly welcome a fix /
tweak to the END_RCPP macro to avoid this potential memory leak.
However, I am also curious -- where exactly does this memory leak
occur, what exactly is being leaked, and why does your modified
example avoid it?
My bes
I think John's advice is spot on here. The issue is only seen when
`NDEBUG` is not defined.
I can reproduce the crash (assertion failure) by ensuring I have
CXXFLAGS=-UNDEBUG
in my ~/.R/Makevars. Note that:
1. An assertion failure from Eigen implies you are doing something
that you should n
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
you provide an example of a segfault occurring independently of RInside?
Kevin
On Wed, Sep 3, 2014 at 12:49 PM, Kevin Ushey wrote:
> Hi Pratibha,
>
> I highly doubt that the segfault is related to the optimization level.
> FWIW, I still cannot replicate the segfault as you desc
Hi Pratibha,
I highly doubt that the segfault is related to the optimization level.
FWIW, I still cannot replicate the segfault as you described -- Ubuntu
14.04, gcc 4.8.2, and...
Kevin
On Wed, Sep 3, 2014 at 12:34 PM, Pratibha Rana wrote:
> I think I got to the bottom of the issue. I was usi
Hi Xiao,
I can reproduce the error -- but why do you have the includes as such, e.g.:
#include
#include
#include
#include /* for the QR routines */
#include /* for the *sort() routines */
#include
#include
#define BIG DBL_MAX
My best guess is that you'll have to re-organize the incl
Hi Christian,
Thanks for catching this. I think this is an oversight -- this should
return `R_len_t` as well. Or, when long vector support is implemented,
`R_xlen_t` should be used instead (especially since `ListOf` is
more-or-less a fancy interface over a `List` object)
Just pushed a correspondi
The general prescription is:
1. Try running the code with `gctortue(TRUE)` on,
2. Try running with a debugger (gdb, lldb, valgrind),
3. Try running with sanitizers (see e.g. Dirk's docker containers:
https://github.com/eddelbuettel/docker-ubuntu-r)
This should help provide you (and/or us) enough
on in the manual page (mayne you meant this by
> 'added an
> | | example'). Or something tickled via a test script in tests/.
> | |
> | | You submitted a CRAN package. It has testable code. It failed.
> We now
> | need
> | | a
>
Hi Terrance,
Can you please try to construct a reproducible example based on the
(tagged, potentially offending) line of code -- that is,
#4 0x7f79b6541df0 in IGMRFDPMIX
/data/gannet/ripley/R/packages/tests-49x/growfunctions/src/dpmix.cpp:63
which has the line:
C(k,0) = as(Cr[k
may be some packages that need to explicitly link to
libstdc++ even on a Mavericks system for other reasons, though...
That said, most of the initial migration headaches seem to be over so this
probably would have been more useful half a year ago ;)
Cheers,
Kevin
On Sun, Aug 3, 2014 at 1:10 PM, Kev
I think this bit:
The \texttt{clang} and \texttt{clang++} compilers from the LLVM project can
also be used as they are inter-operable with \texttt{gcc} et al. The
\texttt{clang++} compiler is interesting as it emits much more
comprehensible error messages than \texttt{g++} (though \texttt{g++} 4.
Hi Asis,
Sorry, Rcpp doesn't have vectorized subsetting for rows of a data.frame /
matrix. However, if you want columns, you can use vector subsetting:
http://gallery.rcpp.org/articles/subsetting/
But perhaps we can consider added 'rows', 'cols' helper methods that would
pull out rows and co
df.attr("names") ? data.frames do not have a column names attribute.
Neither do matrices, for that matter, which have an (optional) `dimnames`
attribute.
Please see: http://gallery.rcpp.org/articles/setting-object-attributes/,
and also try looking at what e.g. `attributes(data.frame(x=1))`, for
ex
cpp::export]]
DataFrame test_builder(SEXP x, SEXP y, SEXP z) {
return ListBuilder()
.add("foo", x)
.add("bar", y)
.add("baz", z);
}
/*** R
test_builder(1:5, letters[1:5], rnorm(5))
*/
On Tue, Jul 8, 2014 at 2:49 PM, Kevin Ushey wrote:
> Maybe w
Maybe we need a DataFrameBuilder class that someone could use like so:
DataFrame df = DataFrameBuilder::create()
.add("column 1", col1)
.add("column 2", col2)
.add("column 3", col3);
This could be made as a generic VectorBuilder class as well.
Or maybe I've been writi
Hi Finlay,
I'm unable to reproduce this on Mac OS X, although I am running the
development version of devtools. Can you try that?
That said, if you still have this problem after updating I would
recommend posting it at https://github.com/hadley/devtools/issues as
even if there is a problem, I don
Hi Michael,
Thanks for reporting -- things like this signal that we could do better
error reporting, e.g. it might be more appropriate to see
Error in eval(expr, envir, enclos) (from srcConn#6) :
Wrong R type for mapped vector (expected 'double', got 'integer')
or something to that effec
Hi Ramon,
Nice to see that there are people stumbling upon Kmisc and finding it
useful ;) It was developed partially in response to new BioConductor
guidelines requiring packages with source code to register the entry
points, and since that's a pain to do manually, and it was possible to
automate.
It's tucked away a bit at the bottom of the page, but it brings you here:
https://github.com/jjallaire/rcpp-gallery/wiki/Contributing-to-the-Rcpp-Gallery
On Mon, Jun 9, 2014 at 9:45 AM, Tim Keitt wrote:
> I don't see the "contributing" link... ;-)
>
> THK
>
>
> On Mon, Jun 9, 2014 at 10:45
What OS are you running on (Mac, Linux, Windows)? I really can't tease
this out (with Mac + clang) thus far.
On Wed, May 28, 2014 at 9:56 PM, Romain Francois
wrote:
>
> Le 29 mai 2014 à 00:35, John Mous a écrit :
>
> No luck with gctorture on yet, but I haven't run it for very long. It slowed
>
Hi John,
I think we may have tackled this in some of the latest fixes with the
version of Rcpp on GitHub. Can you try installing that version and
trying again? Ie, try
install.packages(devtools); devtools::install_github("RcppCore/Rcpp")
then try running your code again.
Alternatively, plea
find . -name "*.cpp" -exec sed -i 's/std::cout/Rcpp::Rcout/g' {} \;
This, or some variant, should get you there.
I suggest version controlling your files before executing, just in case ;)
Kevin
On May 23, 2014 7:22 PM, "Dirk Eddelbuettel" wrote:
>
> On 23 May 2014 at 21:22, Qiang Kou wrote:
>
BinaryIndexStream.o
>>> ./pwiz/data/common/diff_std.o ./pwiz/data/msdata/SpectrumList_MGF.o
>>> ./pwiz/data/msdata/DefaultReaderList.o
>>> ./pwiz/data/msdata/ChromatogramList_mzML.o ./pwiz/data/msdata/examples.o
>>> ./pwiz/data/msdata/Serializer_mzML.o ./pwiz
ead_data_baseE | c++filt
> typeinfo for boost::detail::thread_data_base
>
> Any suggestions welcome.
>
> Laurent
>
>
> On 14 May 2014 09:07, Laurent Gatto wrote:
>
>> We hope to be able to provide a fix soon - will get back to you later
>> today. Apologies for
Hi Jack,
I've already brought this up with the package maintainer. It's because
they bundle an old, broken version of boost. I asked them to fix it; I
guess they haven't (the BioC build reports also show it failing on
Mavericks) I've appended a copy of my e-mail at the end of this just
so you know
The vignettes build fine for me. Can you provide more information
(perhaps as a GitHub issue)?
I'll take a look at InternalFunction. I think there was something
similar reported earlier.
Cheers,
Kevin
On Sat, May 10, 2014 at 12:44 PM, Gabor Grothendieck
wrote:
> On Sat, Mar 1, 2014 at 2:36 PM,
t;> > |
>> > | Warning: running command
>> > | '"C:\PROGRA~2\MIKTEX~1.9\miktex\bin\texi2dvi.exe" --quiet --pdf
>> > | "Rcpp-FAQ.tex" --max-iterations=20 -I
>> > | "C:/PROGRA~1/R/R-3.1/share/texmf/tex/latex" -I
>> > |
Hi Gabor,
Looks like it was a bug on our end -- R-exts specifies that USE_CXX1X
should be set to any value; we try to set it to nothing (ie, define it
but leave it empty) but apparently that is not accepted.
I just pushed a bug fix to GitHub and it works on my Windows VM; can
you give it another
1 - 100 of 181 matches
Mail list logo
