he
> JS
> stack and thread the unwind token back to a safe place and resume the jump.
>
> Best,
> Lionel
>
>
> On 2/6/22, Jeroen Ooms wrote:
> > We can try to take V8 out of the equation, and see what actually
> > causes the change. V8 uses (and tests!) the
On Sun, Feb 6, 2022 at 6:25 PM Kevin Ushey wrote:
>
> If I tweak your example package code so that all exceptions are caught via a
> catch (...) {} block, I can see something like:
>
> > uptest::uptest()
> Error in (function () : Ouch from R
> Caught some other exception.
>
> The fact that
On Sun, Feb 6, 2022 at 5:56 PM Dirk Eddelbuettel wrote:
>
>
> On 6 February 2022 at 17:40, Jeroen Ooms wrote:
> | We can try to take V8 out of the equation, and see what actually
> | causes the change. V8 uses (and tests!) the Rcpp feature to call an R
> | function from C++.
We can try to take V8 out of the equation, and see what actually
causes the change. V8 uses (and tests!) the Rcpp feature to call an R
function from C++. This behaves quite differently when using
RCPP_UNWIND_PROTECT.
Here is a dummy package to demonstrate this: https://github.com/jeroen/uptest
I found that Rcpp packages compiled with -fsanitize=address frequently
crash on OS-X. I cannot reproduce this problem on linux so perhaps I
am not using asan correctly, or perhaps it is related to the fact that
R for Mac has been compiled on osx 10.9 and I'm using 10.11. For
regular C packages,
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
On Thu, Dec 11, 2014 at 12:24 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
I'm interfacing a c++ library which assumes strings are UTF-8. However
strings from R can have various encodings. It's not clear to me how I
need to account for that in Rcpp.
Follow-up on this: from what I have
I'm interfacing a c++ library which assumes strings are UTF-8. However
strings from R can have various encodings. It's not clear to me how I
need to account for that in Rcpp. For example:
// [[Rcpp::export]]
std::string echo(std::string src){
return src;
}
This program does not work on windows
On Thu, Dec 11, 2014 at 2:16 PM, Dirk Eddelbuettel e...@debian.org wrote:
Maybe the same way? ;-)
OK I am not completely back at the C api, and it still doesn't work
when called via Rcpp:
// [[Rcpp::export]]
SEXP echo(SEXP src){
const char* utf8str = Rf_translateCharUTF8(Rf_asChar(src));
On Fri, Dec 5, 2014 at 12:54 AM, Romain François
rom...@r-enthusiasts.com wrote:
You are looking for XPtr.
Thanks guys, exactly what I needed indeed. One follow-up question:
Is there a way to use the XPtr object to prevent the c++ object it
points to from going out of scope? It seems like the
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
On Mon, Dec 2, 2013 at 4:25 AM, Dirk Eddelbuettel e...@debian.org wrote:
As I said when we hashed this out some more in private mail, I'd try
setting
TMPDIR in /etc/profile or alike. Or just try to have a working /tmp
directory.
Surely you are not the only AppArmor user with that issue?
I noticed that RcppEigen fails to install on my servers because it requires
more than 1gb of memory to compile. Is this expected? Are there any flags
or options I could set to trade of some memory for cpu? A short simulation:
library(RAppArmor)
rlimit_as(1e9)
$hardlim
[1] 1e+09
$softlim
[1]
Hi all :)
I'm experiencing an issue with building Rcpp packages inside the OpenCPU
sandbox. I think this issue was introduced with the upgrade to Rcpp 0.10.6.
The problem is that g++ seems to ignore the TMPDIR environment variable,
and instead always tries to use the default /tmp. When /tmp is
On Sun, Dec 1, 2013 at 6:33 PM, Dirk Eddelbuettel e...@debian.org wrote:
I don't think this is us, and I don't think something changed. See below.
I'll ask on r-devel if anyone is aware of install.packages unsetting
TMPDIR when calling g++.
I think I'd start by setting TMPDIR. But here
15 matches
Mail list logo
