Re: [Rcpp-devel] Wrapping a c++ class with singleton using RCPP Module
Could you please provide more details about what you tried so far and what
are the issues you found? A link to a public repo with a test case would be
even better.
Iñaki
El mié., 21 feb. 2024 7:34, Nikhil Garg escribió:
> Hi,
>
> I am looking for some advice or hoping someone can point me in the right
> direction for wrapping a C++ class with singleton using Rcpp. I have been
> using RCPP modules for some of this work but got stuck with a C++ object
> which returns a singleton.
>
> Here is the general structure of the object
>
> class Foo {
> public:
> Foo();
> ~Foo();
>
> static Foo ();
> Foo(Foo const&) = delete;
> void operator=(Foo const&) = delete;
> }
>
> Regards,
> Nikhil
> ___
> 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] Rf_error() format string
See https://github.com/RcppCore/Rcpp/pull/1288
Iñaki
On Tue, 28 Nov 2023 at 14:49, Serguei Sokol wrote:
>
> Hi,
>
> I've got a request from CRAN to correct my package rmumps using Rcpp:
> https://cran.r-project.org/web/checks/check_results_rmumps.html
>
> The problems come from RcppExports.cpp automatically generated lines like:
>
> Rf_error(CHAR(rcpp_msgSEXP_gen));
>
> With a message saying:
>
> Found the following significant warnings:
> RcppExports.cpp:58:18: warning: format string is not a string
> literal (potentially insecure) [-Wformat-security]
> ...
>
> The fix may be as trivial as:
>
>Rf_error("%s", CHAR(rcpp_msgSEXP_gen));
>
> However, if I do it manually, it will be overwritten at the next
> RcppExports.cppbuild.
> Are there some plans to incorporate this fix in Rcpp?
> Am I alone in this case?
>
> Best,
> Serguei.
> ___
> 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
--
Iñaki Úcar
Assistant Professor of Statistics
Director of the Master in Computational Social Science
Department of Statistics | Big Data Institute
Universidad Carlos III de Madrid
Av. de la Universidad 30, 28911 Leganés, Spain
Office: 7.3.J25, Tel: +34 916248804
___
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] Life-cycle of Rcpp::XPtr
Hi Ralf,
On Sat, 23 Sept 2023 at 14:56, Dirk Eddelbuettel wrote:
>
>
> Hi Ralf,
>
> On 23 September 2023 at 08:28, Ralf Stubner wrote:
> | I have a question concerning the file-cycle of Rcpp::XPtr: Consider a
> | XPtr with the default delete finalizer wrapping some pointer. If I use
> | the copy constructor to create another XPtr, this is pointing at the
> | same underlying object as expected. What happens if one of these
> | pointers goes out of scope and is at some point garbage collected? Is
> | the underlying object deleted leaving the other XPtr with a broken
> | pointer? Or is the object protected by the existence of the other
> | pointer? From my experiments I have the impression that the latter is
> | the case, which would be the desired behaviour. But it would be nice
> | if one could be sure.
The answer is yes, XPtr works as a shared_ptr, so you can be sure that
the object will be protected until the last reference to it is
deleted. A quick check:
#include
using namespace Rcpp;
class Test {
public:
Test() { Rcout << this << " created" << std::endl; }
~Test() { Rcout << this << " deleted" << std::endl; }
};
// [[Rcpp::export]]
SEXP test_new() {
return XPtr(new Test());
}
// [[Rcpp::export]]
SEXP test_copy(SEXP x_) {
XPtr x(x_);
return x;
}
/*** R
x <- test_new()
#> 0x55a93e3845d0 created
y <- test_copy(x)
rm(x); invisible(gc())
rm(y); invisible(gc())
#> 0x55a93e3845d0 deleted
*/
Best,
Iñaki
--
Iñaki Úcar
Assistant Professor of Statistics
Director of the Master in Computational Social Science
Department of Statistics | Big Data Institute
Universidad Carlos III de Madrid
Av. de la Universidad 30, 28911 Leganés, Spain
Office: 7.3.J25, Tel: +34 916248804
___
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] Something strange with the package check and calls to C abort
Oh, I receive emails from the list again. Nice. On Tue, 1 Nov 2022 at 03:58, Dirk Eddelbuettel wrote: > > On 31 October 2022 at 11:01, Kevin Ushey wrote: > | 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-compiler-flags-stack-protection-gcc-and-clang > > Not to get into distro wars ... but over here where I build I had the benefit > of kernel and compiler savvy people setting up defaults for many years now. > > Without ever creating a single issue for my (rather frequent) R package > checking. All this is just to say that Debian and Ubuntu have treated me well. No offense taken. :) Debian has a pretty good policy on hardening flags [1], and, in fact, there are only two differences between Debian and Fedora flags, because both have stack protection and so on: 1. Debian specifies -D_FORTIFY_SOURCE=2, while Fedora specifies -Wp,-D_FORTIFY_SOURCE=2. I don't understand what's the difference between them, but R seems to dislike the second one. However, there are some gcc maintainers among the people that define these flags in Fedora, so I suppose it's fine. I think it's just that R flags any -W... option, no matter what. 2. Fedora adds -Wp,-D_GLIBCXX_ASSERTIONS, which enables run-time bounds checking for STL containers. I've seen numerous upstream bugs uncovered by this flag (and upstream maintainers responding "just don't use that flag" to the bug report... which of course is not a solution). So I think it's a cheap, nice thing to have. If Debian/Ubuntu are quieter than Fedora about those flags is due to [2]. ;-) I'm however reluctant to set this by default, because if a package adds one of these flags (maybe unlikely, but who knows), the checks would pass locally but would raise a NOTE on CRAN. So I'm more inclined to document this and let the user decide whether to set this or modify the check flags with a R_MAKEVARS_USER as described in a previous posting. Iñaki [1] https://wiki.debian.org/Hardening [2] https://salsa.debian.org/edd/r-base/-/blob/master/debian/Renviron.site#L37 > | It might be useful if you could share your package / the code used when > | compiling the C++ code in your package. > > Indeed. It generally never hurts to let other people have a peek. > > Dirk > > -- > 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 -- Iñaki Úcar ___ 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_USE_UNWIND_PROTECT by default
Thanks all. My summary here differs a bit though:
1. The point that a longjump does not necessarily represent an error
is crucial here. That's the rationale behind Lionel's implementation
of this exception. My understanding then is that client packages
should *never ever* catch it, and thus it shouldn't inherit from
std::exception.
2. UnwindProtect is a mechanism introduced in R back in 2017 for fast
and safe C++ stack unwinding, so I think it's time we stick to it.
When enabled, Rcpp leverages this via Rcpp_fast_eval. Before that,
Rcpp_eval was/is... kind of hackish (no offense intended; it was the
best thing to do before R properly supported C++ via UnwindProtect),
because it relied on tryCatch, which sometimes resulted in several
tryCatch stacked together. Rcpp_fast_eval is called in a number of
places in Rcpp, and thus client packages would greatly benefit from
finally switching to UnwindProtect, including V8.
3. But then, V8 *really needs* to catch R errors in the JS virtual
machine. So the solution... is to add *a* tryCatch in the proper place
(not a matrioska of tryCatches, as it happens without UnwindProtect).
And this is exactly what Jeroen did [1]. I think that the solution is
brilliant and the proper way to go here (as it happens, that tryCatch
was in place before, for other reasons I suppose, and now it has been
repurposed to properly catch errors too).
4. Another way to address this was mentioned by Lionel: Rcpp_eval is
still there. Arguably though, this interface is not very
user-friendly, and Rcpp::Function is much nicer. I don't think that
Rcpp::Function should switch to Rcpp_eval, but we could offer some
kind of Rcpp::TryCatchFunction (ok, the name can be improved) that
uses Rcpp_eval, or some kind of wrapper class that forces
Rcpp::Function to use Rcpp_eval instead.
[1] https://github.com/jeroen/V8/commit/3258ce61dd02eaed51edef5391dc5afcd456d16c
Iñaki
On Mon, 7 Feb 2022 at 03:11, Kevin Ushey wrote:
>
> Thanks, I think I understand the issue better now. Ultimately, it comes down
> to the fact that UnwindProtect doesn't really allow handling of R conditions
> in the "regular" way as e.g. tryCatch() does; instead, it gives us just
> enough to properly unwind the C++ stack when an R error occurs. If I can
> summarize:
>
> 1. Client packages can catch the Rcpp LongjumpException and handle it
> themselves if they need to, but it's not obvious how to do this correctly.
> 2. R error messages are printed by R when the error is emitted.
> 3. It's not clear to the LongJumpException handler what R error triggered the
> longjmp exception.
>
> In particular, for (1), Rcpp is normally responsible for unprotecting its
> unwind token, and then continuing the unwind:
>
> https://github.com/RcppCore/Rcpp/blob/1c8a1946db56e4d8041593906eddcb0da8ba07a0/inst/include/Rcpp/exceptions.h#L148-L157
>
> If we want to make it safe for client packages to catch these exceptions,
> we'd need to provide a helper for cleaning up Rcpp's unwind state, or make
> that happen automatically. (Maybe the token's protection status could be
> managed as part of the exception's lifetime? Not sure.) However, the fact
> that the LongjumpException needs special handling implies that it probably
> shouldn't inherit from std::exception.
>
> For (2), I don't see a clean way of handling this beyond setting the
> 'show.error.messages' option to false. Unfortunately, because UnwindProtect
> is not a "real" R condition handler, it gets processed only after the
> "regular" R error machinery runs (which includes printing the error before
> actually jumping).
>
> I'm similarly not aware of any solution for (3).
>
> In other words, my understanding is that if you're a client of Rcpp and 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.
>
> Thanks,
> Kevin
>
>
>
>
> On Sun, Feb 6, 2022 at 9:39 AM Jeroen Ooms wrote:
>>
>> 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 we're still printing the R error message seems undesirable,
>> > but it looks like the exception can be caught -- just not via
>> > std::exception.
>>
>> Yes that is also what Iñaki and me alluded to above. But I think this
>> way, what we are catching is not the R error itself (which seems lost
>> after it was printed), but rather a token that tells the application
>> we should let Rcpp unwind all the way back to the R console. Which is
>> what happens if we don't catch it, then it makes sense. But if we _do_
>> want to handle the situation in
[Rcpp-devel] RCPP_USE_UNWIND_PROTECT by default
Hi Lionel,
I've been setting this for years in my own packages, and particularly
in a simulator that greatly benefits from this due to its heavy usage
of R calls from the C++ simulation loop. Now, we're looking into
setting this feature on by default in the next release of Rcpp to
improve the performance of other packages, such as httpuv [1], as
well.
Dirk has run a full revdep check that looks very promising, with just
one new failure (the V8 package), and it would be great if you could
take a look when you have time. It seems that the UNWIND_PROTECT
mechanism somehow collides with v8's exception handling:
> test_check("V8")
terminate called after throwing an instance of 'Rcpp::LongjumpException'
Aborted
V8 sees this exception, doesn't know what to do with it, and then the
program is aborted. This is kind of a Russian Doll, and probably an
extreme case, but we are wondering whether we can do something on the
Rcpp side to support v8's engine. V8 can always undefine
UNWIND_PROTECT if we ship this by default, but this is clearly one of
those packages that could benefit from the improved performance that
this feature enables.
So far, I found that Rcpp::LongjumpException is the only exception in
Rcpp that doesn't inherit from std::exception (which is what V8
expects). Is this intended/required? I checked that, if
LongjumpException inherits from std::exception, V8 doesn't crash there
(the exception is recognized), but then two errors are shown in the R
console, which is not ideal either:
> ctx <- V8::v8()
> ctx$eval("console.r.eval('doesnotexists')")
Error in eval(ei, envir) : object 'doesnotexists' not found
Error: std::exception
> x <- try(ctx$eval("console.r.eval('doesnotexists')"))
Error : std::exception
> x
[1] "Error : std::exception\n"
attr(,"class")
[1] "try-error"
attr(,"condition")
Please let us know if you have some time for this. Any help would be
appreciated.
Cheers,
Iñaki
[1] https://github.com/rstudio/httpuv/issues/244
--
Iñaki Úcar
___
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] RcppThread.h:12 ThreadPool.hpp:11 warning: 'new' of type 'quickpool::ThreadPool'
On Wed, 26 Jan 2022 at 19:02, Joseph Park wrote: > > Dear RcppDev, > > A new warning has emerged in mingw compilation on CRAN. The message: > > *** arch - x64 > make[1]: Entering directory > '/d/temp/RtmpsZcaWL/R.INSTALLb59426674c3e/rEDM/src-x64' > d:/Compiler/rtools40/mingw64/bin/g++ -std=gnu++11 > -I"D:/RCompile/recent/R-4.1.2/include" -DNDEBUG -I./cppEDM/src -I../ > -I'd:/RCompile/CRANpkg/lib/4.1/Rcpp/include' > -I'd:/RCompile/CRANpkg/lib/4.1/RcppThread/include' > -I"d:/Compiler/gcc-4.9.3/local330/include" -O2 -Wall -mfpmath=sse -msse2 > -mstackrealign -c CCM.cpp -o CCM.o > In file included from > d:/RCompile/CRANpkg/lib/4.1/RcppThread/include/RcppThread/ThreadPool.hpp:11, > from > d:/RCompile/CRANpkg/lib/4.1/RcppThread/include/RcppThread.h:12, > from RcppEDMCommon.h:12, > from CCM.cpp:2: > d:/RCompile/CRANpkg/lib/4.1/RcppThread/include/RcppThread/quickpool.hpp: In > static member function 'static quickpool::ThreadPool& > quickpool::ThreadPool::global_instance()': > d:/RCompile/CRANpkg/lib/4.1/RcppThread/include/RcppThread/quickpool.hpp:719:31: > warning: 'new' of type 'quickpool::ThreadPool' with extended alignment 64 > [-Waligned-new=] > static auto ptr = new ThreadPool; >^~ > d:/RCompile/CRANpkg/lib/4.1/RcppThread/include/RcppThread/quickpool.hpp:719:31: > note: uses 'void* operator new(std::size_t)', which does not have an > alignment parameter > d:/RCompile/CRANpkg/lib/4.1/RcppThread/include/RcppThread/quickpool.hpp:719:31: > note: use '-faligned-new' to enable C++17 over-aligned new support > > -- > > Any ideas to address this? The packages uses C++11. RcppThread is not part of RcppCore. The upstream repo is [1]. Please, report it there. Version 2.0.0 was released yesterday on CRAN and it's currently failing on a couple of platforms [2]. [1] https://github.com/tnagler/RcppThread [2] https://cran.rstudio.com/web/checks/check_results_RcppThread.html -- Iñaki Úcar ___ 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::plugins - Unwinding protection
On Fri, 3 Dec 2021 at 19:27, Dirk Eddelbuettel wrote: > > > On 3 December 2021 at 17:03, Iñaki Ucar wrote: > | On Fri, 3 Dec 2021 at 15:44, Víthor Rosa wrote: > | > > | > Thank you for your response. Adding my functions to an R package and > changing the Makevars file as suggested reduced the runtime by half. Excited > for Rcpp 1.0.8! :) > | > | Excellent! Glad it helped. > > I have been sitting on a branch at GitHub that defines new / easier / > alternate header files as entry points. So instead of starting with Rcpp.h > (possibly combined with #define statements) one could now pick exactly one > off these three > >#include > >#include > >#include > > which turn off, respectively, Modules, RTTI and Sugar. See the commit at [1] > for more and full code, it's essentially a define each and simple nesting. > > Each of these shaves a little bit of the compile times. (I need to rebase it > to current master, it's a few months old.) > > But I had not yet convinced myself it would be useful / of interest. But as > this thread shows, there may be interest. Any comments? Yay? Nay? Mmmh, no strong opinions here. I think it doesn't matter much whether it's an include or a define. What matters most is whether this is discoverable and the user understands what it does. In this particular case, Víthor is interested in runtime performance. Disabling modules and RTTI (and Sugar if he's not using that) will save some compilation time, but won't help with runtime performance. @Víthor, the TL;DR is that you can append -DRCPP_NO_RTTI to your PKG_CPPFLAGS in the Makevars file. This disables some functionality that you are probably not using, and compilation will be faster too. Iñaki > (And as discussed turning UNWIND_PROTECT on globally is also a good idea but > may need a proper transition, and is hence for now outside the scope of this > branch.) > > Dirk > > > [1] > https://github.com/RcppCore/Rcpp/commit/5cf57ff663d06acf42124feae51d469f3f77be52#diff-05c80375618a46d399d73e4f32a3006aa698b9bb293a37c6d2e431a1c541b7bb > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- Iñaki Úcar ___ 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::plugins - Unwinding protection
On Fri, 3 Dec 2021 at 15:44, Víthor Rosa wrote: > > Hi Iñaki and Dirk, > > Thank you for your response. Adding my functions to an R package and changing > the Makevars file as suggested reduced the runtime by half. Excited for Rcpp > 1.0.8! :) Excellent! Glad it helped. Iñaki > > Best, > > Em qui., 2 de dez. de 2021 às 18:22, Dirk Eddelbuettel > escreveu: >> >> >> On 2 December 2021 at 17:48, Iñaki Ucar wrote: >> | My simulation package makes heavy use of calls to R user functions from a >> | C++ simulation loop, and therefore greatly benefits from this feature too, >> | which I think we should promote to default. >> >> I agree and believe I looked into it once before -- but found 'shrapnel' from >> other packages being affected. We are eight months into the (simpler !!) >> transition to default to STRICT_R_HEADERS which will go in with Rcpp 1.0.8 in >> January (and yay, yesterday brought several updates, so my thanks to >> everybody who folded patches or PRs I sent in and uploaded; current score is >> now 70 out 92 done, see https://github.com/RcppCore/Rcpp/issues/1158 ) >> >> So maybe in 2022... >> >> | Meanwhile, take a look at this >> | Makevars file to see how to activate it: >> | https://github.com/r-simmer/simmer/blob/master/src/Makevars >> >> Yep. >> >> Dirk >> >> -- >> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > > -- > Prof. Ph.D. Víthor Rosa Franco > Universidade São Francisco (USF), Campinas, SP, Brazil > Phone: +55 61 994602228 > Curriculum > > No amount of experimentation can ever prove me right; a single experiment can > prove me wrong. -- Iñaki Úcar ___ 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::plugins - Unwinding protection
Hi Víthor,
My simulation package makes heavy use of calls to R user functions from a
C++ simulation loop, and therefore greatly benefits from this feature too,
which I think we should promote to default. Meanwhile, take a look at this
Makevars file to see how to activate it:
https://github.com/r-simmer/simmer/blob/master/src/Makevars
Iñaki
El jue., 2 dic. 2021 17:32, Víthor Rosa escribió:
> Hi everyone,
>
> I am using Rcpp to develop my own package and one of my functions calls
> back into R for a given amount of iterations. To speed up the process, I
> wanted to use Rcpp::unwindProtect. However, I couldn't find
> on Rcpp's documentation what is the correct way to use this plugin.
> Therefore, I would like to ask you for some guidance, if possible.
>
> Reproducible toy example:
>
>
> require(Rcpp)
> Rcpp::cppFunction("
> NumericVector test_f(NumericMatrix x, Function f) {
> NumericVector out(x.ncol());
>
> for (int iter = 0; iter < x.ncol(); iter++) {
> out[iter] = as(f(x(_ , iter)));
> }
>
> return out;
> }
> ")
>
> x <- matrix(1.2:9.2, 3, 3)
>
> colSums(x)
> f <- function(x) sum(x)
> test_f(x, f)
>
> require(rbenchmark)
> rbenchmark::benchmark("R1"=colSums(x),
> "R2"=test_f(x, f),
> replications=1)
>
>
> Best,
> Vithor
> ___
> 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 function results are different on different systems
On Thu, 19 Aug 2021 at 04:53, Dirk Eddelbuettel wrote: > > > Naeem, > > I would simplify, simplify, simplify -- as 'Rcpp FAQ 7.31' reminds us all, > testing _equality_ of doubles is challenging anyway. > > Besides, it may make sense to would ascertain first you get what you want in > _purely serial modes_ and then move to OpenMP. Exactly. Serial execution should be fine. I.e., if you set the number of threads to 1, then all platforms will return the same result. However, you have defined a number of variables outside the parallel region, and then you modify them inside the parallel region. OpenMP takes those variables as shared by default, which leads to the unexpected results you are getting. You need to tell OpenMP that those variables are threadprivate. Or you could just define them inside the parallel region, so that OpenMP knows that they are private without additional hints. -- Iñaki Úcar ___ 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 with results in "shared object 'nloptC.so' not found"
On Wed, 18 Aug 2021 at 16:37, Simon Zehnder
wrote:
>
> Hi folks,
>
> apologies, if I am double posting - I had problems with my mail.
>
> I need some help here from experienced Rcpp developers.
>
> I am coding since some time on an R-package using Rcpp and nlopt. Lately I
> found out that I could probably use 'nloptr' to include nlopt in my C++ code,
> which would give a great advantage to users of my package (instead of
> installing nlopt on their systems by hand).
> I followed the example on
> https://github.com/jchiquet/RcppArmadilloNLoptExample (the nloptC one) and
> modified my code accordingly. When I compile my package I get the error
>
> " Error: package or namespace load failed for ‘finmix’ in library.dynam(lib,
> package, package.lib):
> shared object ‘nloptC.so’ not found"
>
> In my DESCRIPTION I use in the 'Imports' and the 'LinkingTo' field 'nloptr'.
> In my NAMESPACE I load 'nloptC' via 'useDynLib(nloptC)'.
Remove this. The example has useDynLib(nloptC) because the package is
called nloptC. Your package is called finmix, so you just need
useDynLib(finmix) in the NAMESPACE.
> What I saw in the example's 'RcppExports.cpp' file is
>
> RcppExport void R_init_nloptC(DllInfo *dll) {
> R_registerRoutines(dll, NULL, CallEntries, NULL, NULL);
> R_useDynamicSymbols(dll, FALSE);
> }
You have R_init_finmix instead, same reason as above.
--
Iñaki Úcar
___
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] Any recent change that would remove Rcpp_precious_remove?
On Thu, 15 Jul 2021 at 10:27, ma wh wrote: > > Hi list > > Colleague of mine wrote some R last week that was working OK, and hasn't been > changed in itself since that time. This week it's ceased working( I've tried > it on my machine and also see a fail, the following error is encountered: > > Error in C_valid_tz(tzone): Function 'Rcpp_precious_remove' not provided by > package 'Rcpp' TL;DR: update your library. It seems that you are using a package (lubridate) compiled against the most recent Rcpp release, but you are trying to load it using an old version of Rcpp. We try hard to smooth things out so that the transition "forward" (i.e., updating Rcpp) is as painless as possible. In fact, the recent v1.0.7 landed on CRAN with 2.3k+ reverse depends and only a couple of issues that got resolved with a rebuild. This is the inverse situation: the rest of the packages are updated (built against the newest Rcpp), but the local Rcpp version is an old one. This is not supported and cannot be supported; otherwise, our hands would be tied to make any progress or innovation. -- Iñaki Úcar ___ 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] Help with R CMD CHECK for rtree package
Hi Kent, On Wed, 5 May 2021 at 17:54, Kent Johnson wrote: > > Hi, > > I am a maintainer of this package - https://github.com/akoyabio/rtree - > originally inspired by this example - > https://gallery.rcpp.org/articles/Rtree-examples/. This package wraps the > rtree implementation from BH 1.7.2.0-3 to provide fast methods for finding > points nearby to other points in large data sets. > > I want to submit the package to CRAN but I have a CMD CHECK warning on > Windows that I can't resolve. > > Running CMD CHECK from GitHub Actions, on Microsoft Windows Server 2019 > 10.0.17763, I get this error message: > > -- R CMD check results rtree 0.2.0 > > Duration: 1m 42.7s > > > checking whether package 'rtree' can be installed ... WARNING > See below... > > 0 errors v | 1 warning x | 0 notes v > Error: Error: R CMD check found WARNINGs > Execution halted > Error: Process completed with exit code 1. > > The full output is here: > https://github.com/akoyabio/rtree/runs/2502841486?check_suite_focus=true > The message says "See below..." but there is nothing below? Below I see this: * checking whether package 'rtree' can be installed ... WARNING Found the following significant warnings: D:/a/_temp/Library/BH/include/boost/geometry/index/detail/varray_detail.hpp:544:13: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'struct std::pair, unsigned int>' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess] D:/a/_temp/Library/BH/include/boost/geometry/index/detail/varray_detail.hpp:578:13: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'struct std::pair, unsigned int>, boost::geometry::index::quadratic<16>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators, unsigned int> >, std::pair, unsigned int>, boost::geometry::index::quadratic<16>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node, unsigned int>, boost::geometry::index::quadratic<16, 4>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators, unsigned int> >, std::pair, unsigned int>, boost::geometry::index::quadratic<16, 4>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag> >*>' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess] D:/a/_temp/Library/BH/include/boost/geometry/index/detail/varray_detail.hpp:237:13: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'struct std::pair, unsigned int>' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess] See 'D:/a/rtree/rtree/check/rtree.Rcheck/00install.out' for details. And even more details if you download the artifacts of your build and review that file. So it's a Boost thing, and there's probably nothing you can do about it beyond talking to CRAN. There are packages on CRAN with these warnings. > Running on my local Windows 10 PC I get this warning and a note: > > -- R CMD check results rtree 0.2.0 > > Duration: 1m 2.2s > > > checking whether package 'rtree' can be installed ... WARNING > See below... > > > checking compiled code ... NOTE > Note: information on .o files for x64 is not available > File 'C:/Research/rtree.Rcheck/rtree/libs/x64/rtree.dll': > Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) > Found 'exit', possibly from 'exit' (C), 'stop' (Fortran) > Found 'printf', possibly from 'printf' (C) This is problably a false positive. -- Iñaki Úcar ___ 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] A clean way to handle character/strings between R and Rcpp
On Sat, 3 Apr 2021 at 16:28, prezzemolo wrote:
>
> Hey.
>
> I am wondering if there's some general guidance on what the 'right' options
> are to cleanly handle character arguments passed from R to Rcpp.
>
> It is all rather simple: let's say I have a human-readable argument vector
> c("tree", "herb", "shrub") [It could also be a factor in R], which I can send
> to an Rcpp function along with other arguments for evaluation.
> What would be the cleanest way to define those arguments (plant types) in R
> to then have as little trouble sending them over to Rcpp for use in cases
> like if() statements?
You can use the == operator with standard strings:
Rcpp::cppFunction('
void test(std::string x) {
if (x == "flower")
Rcout << "flower" << std::endl;
else if (x == "tree")
Rcout << "tree" << std::endl;
else
Rcout << "string " << x << " not found" << std::endl;
}
')
test("flower")
#> flower
test("tree")
#> tree
test("other")
#> string other not found
Iñaki
>
>
> The use of enums comes to mind:
>
> // beginningoffile
> enum class var_type { flower, tree };
>
> RCPP_EXPOSED_ENUM_NODECL(var_type)
>
> // [[Rcpp::export]]
> int charHandle1(var_type text_arg = var_type::flower) {
> if(text_arg == var_type::flower) {
> Rcout << static_cast(text_arg) << " says '0 (flower)'.\n";
> } else if(text_arg == var_type::tree) {
> Rcout << static_cast(text_arg) << " says '1 (tree)'.\n";
> }
> return 0;
> }
> // endoffile
>
> This however, doesn't seem to work. I understand R would have to know the
> var_type for it to work.
> Then I can do it simply by comparing the const char * argument. This will
> work, but the strcmp() comparison isn't very straightforward for someone who
> doesn't know C++ (and perhaps for some other reasons).
>
> // [[Rcpp::export]]
> int charHandle2(const char* text_arg = "flower") {
> if(strcmp(text_arg, "flower") == 0) {
> Rcout << text_arg << " says 'flower'.\n";
> } else if(strcmp(text_arg, "tree") == 0) {
> Rcout << text_arg << " says 'tree'.\n";
> }
> return 0;
> }
>
> I am looking for some good practice guidance on how to handle this safely and
> legibly to avoid sending people to function definitions. An argument could be
> made, for instance, that a list of plant type used as function arguments
> could be stored as factor in R and then sent and used in some way in Rcpp.
> What other options are there? To my best knowledge, support for enums is
> limited - I glanced over the vignettes and couldn't find any significant
> mention of enums (or factors, really), so I guess some other way of handling
> such cases should be taken. Has anyone dealt with such cases and has
> recommendations?
>
> Regards,
> Angelo (Greetings from Genoa)
> ___
> 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
--
Iñaki Úcar
___
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] Passing template class as argument in Rcpp function
Excellent. Note that the clone method was required for my use case, but it
may be superfluous for yours.
Iñaki
El vie., 5 mar. 2021 17:15, Subhomoy Ghosh escribió:
> Thanks, Iñaki! Your package gave me enough hints to create the following
> attempt which seemed to have worked.
>
> #include
>
> using namespace Rcpp;
> using namespace arma;
>
> // [[Rcpp::depends(RcppArmadillo)]]
>
> class Distribution {
>
> public:
> virtual Distribution* clone() {return (new Distribution(*this));}
> virtual ~Distribution() {}
>
> };
>
> template
> class Uniform : public Distribution {
>
> public:
> virtual Uniform* clone() {return (new Uniform(*this));}
> Uniform(const T ,int i_) :
> max(max), i(i_) {}
>
> ~Uniform(){};
>
> T max;
> int i;
> };
>
>
>
> // [[Rcpp::export]]
> XPtr getUniformParam( SEXP max,int i,int type) {
> // create pointer to an Uniform object and
> // wrap it as an external pointer for base class
> if(type==1) {
> return Rcpp::XPtr (new
> Uniform(as(max), i) );
> } else if(type==2) {
> return Rcpp::XPtr (new Uniform(as(max),
> i) );
>
>}
> // return the external pointer to the R side
> return Rcpp::XPtr(R_NilValue);
> }
>
>
>
> // [[Rcpp::export]]
> double test2(double z, XPtr xp, int type) {
>
> Distribution* d=xp->clone();
> double tt=1;
> // convert the base pointer to derived class pointer
> if(type==1){
>Uniform *f = dynamic_cast *>(d);
>tt = z * f->max;
> } else if (type==2){
> Uniform *f = dynamic_cast *>(d);
>tt =z * f->max;
> }
>
> return tt;
> }
>
> // R side
> xp<- getUniformParam(2.3,2,1)
> test2(2,xp,1)
>
>
> On Thu, Mar 4, 2021 at 2:58 PM Iñaki Ucar wrote:
>
>> On Thu, 4 Mar 2021 at 20:31, Subhomoy Ghosh wrote:
>> >
>> > Thanks, for the solution. I tried what you suggested and it shows "no
>> matching constructor for initialization of 'Rcpp::XPtr'".
>> Below here is my attempt:
>> >
>> > class Distribution {
>> >
>> > public:
>> > template
>> > class Uniform2 {
>>
>> This is a nested class, which makes little sense in this context.
>> Uniform2 should *inherit* from Distribution. Again, see my package as
>> an example, which does exactly what you want.
>>
>> --
>> Iñaki Úcar
>>
>
>
> --
> Subhomoy
>
___
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] Passing template class as argument in Rcpp function
On Thu, 4 Mar 2021 at 20:31, Subhomoy Ghosh wrote:
>
> Thanks, for the solution. I tried what you suggested and it shows "no
> matching constructor for initialization of 'Rcpp::XPtr'". Below
> here is my attempt:
>
> class Distribution {
>
> public:
> template
> class Uniform2 {
This is a nested class, which makes little sense in this context.
Uniform2 should *inherit* from Distribution. Again, see my package as
an example, which does exactly what you want.
--
Iñaki Úcar
___
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] Install failure undefined symbol
On Thu, 11 Jun 2020 at 17:41, Fuhriman, Nathanael [US] (IS) (Contr) wrote: > > /share/apps/gcc/9.2.0/bin/gcc -m64 -shared -L/share/apps/update/lib -o > Rcpp.so api.o attributes.o barrier.o date.o module.o rcpp_init.o Note that line. It's probably picking up whatever it's in there instead of /share/apps/gcc/9.2.0/lib. Things would be probably easier using scl's devtoolset-8, with gcc 8.3.1. And if you need something newer, CentOS 6 is not the right environment. It's almost EOL, with so many issues; so please, consider an upgrade. -- Iñaki Úcar ___ 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] gcc 10 error: symbol `fun' is already defined
FYI, reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643 On Sun, 9 Feb 2020 at 12:14, Iñaki Ucar wrote: > > BTW, I've noticed that, if you remove the extern "C" declaration and > compile your example as C code with gcc 9.2.1, there's a warning: > > broken.c:16:16: warning: ‘f’ is static but declared in inline function > ‘f2’ which is not static > 16 | static void (*f)(); > |^ > broken.c:9:16: warning: ‘f’ is static but declared in inline function > ‘f1’ which is not static >9 | static void (*f)(); > |^ > > and then the linker fails with undefined references to f1 and f2. > Declaring f1 and f2 as static inline solves the issue in C and also in > C++ for gcc 10. > > Maybe it would be better to declare those RcppEigen stubs as static inline? > > Iñaki > > On Sun, 9 Feb 2020 at 11:47, Iñaki Ucar wrote: > > > > On Sun, 9 Feb 2020 at 03:36, Kevin Ushey wrote: > > > > > > Here's an example program that fails to compile with gcc-10 for me: > > > > > > https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c > > > > > > So I think we can conclude this is a gcc-10 bug. It also fails with > > > the contracts branch of gcc on godbolt (although with a different > > > error): > > > > > > https://godbolt.org/z/dowsE5 > > > > > > But gcc trunk seems okay. > > > > Thanks for looking into this. Now I'm more confident bringing this upstream. > > > > Iñaki > > > > -- > Iñaki Úcar -- Iñaki Úcar ___ 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] gcc 10 error: symbol `fun' is already defined
BTW, I've noticed that, if you remove the extern "C" declaration and compile your example as C code with gcc 9.2.1, there's a warning: broken.c:16:16: warning: ‘f’ is static but declared in inline function ‘f2’ which is not static 16 | static void (*f)(); |^ broken.c:9:16: warning: ‘f’ is static but declared in inline function ‘f1’ which is not static 9 | static void (*f)(); |^ and then the linker fails with undefined references to f1 and f2. Declaring f1 and f2 as static inline solves the issue in C and also in C++ for gcc 10. Maybe it would be better to declare those RcppEigen stubs as static inline? Iñaki On Sun, 9 Feb 2020 at 11:47, Iñaki Ucar wrote: > > On Sun, 9 Feb 2020 at 03:36, Kevin Ushey wrote: > > > > Here's an example program that fails to compile with gcc-10 for me: > > > > https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c > > > > So I think we can conclude this is a gcc-10 bug. It also fails with > > the contracts branch of gcc on godbolt (although with a different > > error): > > > > https://godbolt.org/z/dowsE5 > > > > But gcc trunk seems okay. > > Thanks for looking into this. Now I'm more confident bringing this upstream. > > Iñaki -- Iñaki Úcar ___ 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] gcc 10 error: symbol `fun' is already defined
On Sat, 8 Feb 2020 at 23:50, Dirk Eddelbuettel wrote:
>
>
> On 8 February 2020 at 22:36, Iñaki Ucar wrote:
> | lme4 fails to compile with this misterious message in Fedora Rawhide
> | with gcc10 (see the build log and more details in [1]). There is no
> | "fun" in lme4, but there are several local definitions of "fun" in
> | RcppEigen, used by lme4, under inst/include/RcppEigenStubs.h. These
>
> Shouldn't what is in RcppEigen be protected by namespaces?
>
> Also, the ever-vigilant Prof Ripley emailed dozens of people last year about
> gcc10 changes (for C, though). If this were systemic I cam sure we'd hear
> from him.
Prof. Ripley was probably looking for issues listed in the gcc 10
porting guide (omissions of "extern" in C, and argument mismatches in
Fortran). This is about C linkage in a C++ package, and a quite
strange error: lme4 is the only package on CRAN showing this issue
with RcppEigen, so maybe it went unnoticed.
> | are the relevant lines from the assembler output:
> |
> | fun:
> | .zero 8
> | .section .rodata
> | .LC5:
> | .string "cholmod_free_factor"
> |
> | ...
> |
> | fun:
> | .zero 8
> | .section .rodata
> | .LC8:
> | .string "cholmod_start"
> |
> | So it seems that, unless lme4 is doing something improper in
> | src/lme4CholmodDecomposition.h, this is a bug in RcppEigen due to the
> | use of inline and static (or in gcc 10?). Thoughts? Should I open an
> | issue in RcppEigen?
>
> Better yet, provide a fix?
I'd be more than happy to provide a fix, but I have no clue about
what's happening here, why gcc 10 generates duplicated symbols for
these functions (where previous versions did not), and where is the
issue to fix (lme4, RcppEigen or even gcc 10). And that's why I'm
posting here.
> You're the one with a reproducible system :)
How so, gcc 10 is all it's needed. And Fedora Rawhide can be used
through docker to avoid the burden of installing a new toolchain:
$ docker run -it --rm fedora:rawhide
$ dnf install R
$ Rscript -e 'install.packages("lme4", repos="https://cloud.r-project.org;)'
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] gcc 10 error: symbol `fun' is already defined
Hi, lme4 fails to compile with this misterious message in Fedora Rawhide with gcc10 (see the build log and more details in [1]). There is no "fun" in lme4, but there are several local definitions of "fun" in RcppEigen, used by lme4, under inst/include/RcppEigenStubs.h. These are the relevant lines from the assembler output: fun: .zero 8 .section .rodata .LC5: .string "cholmod_free_factor" ... fun: .zero 8 .section .rodata .LC8: .string "cholmod_start" So it seems that, unless lme4 is doing something improper in src/lme4CholmodDecomposition.h, this is a bug in RcppEigen due to the use of inline and static (or in gcc 10?). Thoughts? Should I open an issue in RcppEigen? [1] https://github.com/lme4/lme4/issues/558 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
Re: [Rcpp-devel] Rcpp::exception + threads = disaster
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
Re: [Rcpp-devel] RInside: C/C++ function(s) passed to R?
Sorry about the attachments in my last mail.
On Fri, 8 Nov 2019 at 11:15, Iñaki Ucar wrote:
>
> There's an article about this in the Rcpp Gallery [1], but it seems
> that some commit dropped half of the article (?). Anyway, there's a
> cached version in [2], and you can always go directly to the Rmd [3].
>
> [1]
> https://gallery.rcpp.org/articles/passing-cpp-function-pointers-rcppxptrutils/
> [2]
> https://web.archive.org/web/20171029135311/https://gallery.rcpp.org/articles/passing-cpp-function-pointers-rcppxptrutils/
> [3]
> https://github.com/RcppCore/rcpp-gallery/blob/gh-pages/src/2017-08-04-passing-cpp-function-pointers-rcppxptrutils.Rmd
>
> Iñaki
>
>
> On Fri, 8 Nov 2019 at 11:06, LEVRA-JUILLET William
> wrote:
> >
> > Hi all,
> >
> >
> >
> > I’m evaluating RInside/Rcpp to interact our C++ project with R.
> >
> > I’ve seen the samples to get/set data (matrix, dataframes, etc) to/from R
> > and it builds/works fine.
> >
> > (Using gcc/mingw compiler from RTools on Windows)
> >
> >
> >
> > My questions is about functions…
> >
> > My project is C++, and it uses RInside to call R from our code.
> >
> > Let’s say I have a C++ function implemented in my project, and I want to
> > pass that c++ function to R so it can be “used” as a R function (typically
> > passed as argument to optim/optimize)
> >
> > I couldn’t find a way to do that using RInside.
> >
> >
> >
> > Ideally, I’d like to achieve something like:
> >
> >
> >
> > #include
> >
> >
> >
> > double Banana(double x, double y)
> >
> > {
> >
> > return (1-x)*(1-x)+100*(y-x*x)*(y-x*x);
> >
> > }
> >
> >
> >
> > Int main()
> >
> > {
> >
> > RInside R(argc,, argv);
> >
> > R[“fn”] = Banana;
> >
> > R.parseEval(“optim(c(-2,-2), fn”);
> >
> > }
> >
> >
> >
> > I believe it’s similar to
> > https://stackoverflow.com/questions/53729493/rinside-wrapping-a-c-function-for-use-in-an-r-function
> >
> > But I can’t really understand the Rcpp::XPtr suggestion from Dirk.
> >
> > Any help or pointers welcome J
> >
> > Thx a mil
> >
> >
> >
> >
> >
> >
> >William LEVRA-JUILLET
> >Senior Software Architect
> >ADDACTIS Software
> >+33 (0)4 81 92 13 00
> >
> >
> >www.addactis.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >William LEVRA-JUILLET
> >Senior Software Architect
> >ADDACTIS Software
> >+33 (0)4 81 92 13 00
> >
> >
> >www.addactis.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
>
>
>
> --
> Iñaki Úcar
--
Iñaki Úcar
___
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] RInside: C/C++ function(s) passed to R?
There's an article about this in the Rcpp Gallery [1], but it seems
that some commit dropped half of the article (?). Anyway, there's a
cached version in [2], and you can always go directly to the Rmd [3].
[1]
https://gallery.rcpp.org/articles/passing-cpp-function-pointers-rcppxptrutils/
[2]
https://web.archive.org/web/20171029135311/https://gallery.rcpp.org/articles/passing-cpp-function-pointers-rcppxptrutils/
[3]
https://github.com/RcppCore/rcpp-gallery/blob/gh-pages/src/2017-08-04-passing-cpp-function-pointers-rcppxptrutils.Rmd
Iñaki
On Fri, 8 Nov 2019 at 11:06, LEVRA-JUILLET William
wrote:
>
> Hi all,
>
>
>
> I’m evaluating RInside/Rcpp to interact our C++ project with R.
>
> I’ve seen the samples to get/set data (matrix, dataframes, etc) to/from R and
> it builds/works fine.
>
> (Using gcc/mingw compiler from RTools on Windows)
>
>
>
> My questions is about functions…
>
> My project is C++, and it uses RInside to call R from our code.
>
> Let’s say I have a C++ function implemented in my project, and I want to pass
> that c++ function to R so it can be “used” as a R function (typically passed
> as argument to optim/optimize)
>
> I couldn’t find a way to do that using RInside.
>
>
>
> Ideally, I’d like to achieve something like:
>
>
>
> #include
>
>
>
> double Banana(double x, double y)
>
> {
>
> return (1-x)*(1-x)+100*(y-x*x)*(y-x*x);
>
> }
>
>
>
> Int main()
>
> {
>
> RInside R(argc,, argv);
>
> R[“fn”] = Banana;
>
> R.parseEval(“optim(c(-2,-2), fn”);
>
> }
>
>
>
> I believe it’s similar to
> https://stackoverflow.com/questions/53729493/rinside-wrapping-a-c-function-for-use-in-an-r-function
>
> But I can’t really understand the Rcpp::XPtr suggestion from Dirk.
>
> Any help or pointers welcome J
>
> Thx a mil
>
>
>
>
>
>
>William LEVRA-JUILLET
>Senior Software Architect
>ADDACTIS Software
>+33 (0)4 81 92 13 00
>
>
>www.addactis.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>William LEVRA-JUILLET
>Senior Software Architect
>ADDACTIS Software
>+33 (0)4 81 92 13 00
>
>
>www.addactis.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
--
Iñaki Úcar
___
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] Upload library with object files
On Wed, 20 Feb 2019 at 09:33, Sergio Bra wrote: > > Hi community, > > In the near future I'll be trying to publish a package in the CRAN and after > reading "Writing R extensions" I have some doubts. > > I have some c++ functions, available from the R-side with Rcpp. These c++ > functions have calls to some C packages. In the src directory I have the > source code of these C libraries, and a directory with the .o files of the .c > files, and informed in the PKG_LIBS variable. I've included the compiled > files for different platforms: ubuntu x32, x64, and windows x32, x64 (I'll > probably include support for OSX) and in the Makevars I select the .o files > to use depending on the OS and arch. > > If I execute the R CMD check command, I have no errors but some warnings like > "Object files/libraries should not be included in a source package". The > message and the documentation just recommend not to use them but doesn't say > that it is forbidden. It's a recommendation because there may be unavoidable exceptions. But in general, take it as a "must". > Can I have problems if I try to attemp the upload of the library in this > circumstance? In short, yes, don't do that. And anyway, what's the point if you have the source code of these libraries? Just provide it with the proper setup to compile them during package installation. There are plenty of examples on CRAN of packages bundling third-party libraries. 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
Re: [Rcpp-devel] Export only C function symbols?
On Mon, 4 Feb 2019 at 14:59, Watal M. Iwasaki wrote: > > Dear Iñaki, > > Thanks for the comments. But I know the switch you mentioned. The levels I > was talking are within the unexported functions. Here are my imaginary levels: > > 1. Listed in NAMESPACE; always visible > 2. Not listed in NAMESPACE; exposed by load_all(export_all = TRUE) or ::: > 3. Not listed in NAMESPACE; only accessible from .Call() Compiled functions are only accessible from .Call if you don't use symbol registration (see 5.4 Registering native routines). But AFAIK, this is required by CRAN, and thus Rcpp automatically generates symbol registration for you. 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
Re: [Rcpp-devel] Export only C function symbols?
On Mon, 4 Feb 2019 at 13:45, Watal M. Iwasaki wrote: > > Dear Dirk, > > Thank you for the prompt answer. > Currently all the C++ functions with [[Rcpp::export]] tag are exposed to me > by `devtools::load_all()` in the dev process. But some of them are only > useful in other functions and undesired in the interactive environment. So I > wondered if by any chance it is possible to control the level of exposure. It > is not a big problem. Good to know the answer is no. The "level of exposure" is controlled by the NAMESPACE in a package, not by Rcpp. And in this case, by devtools. This is what I got from the function's help: export_all If TRUE (the default), export all objects. If FALSE, export only the objects that are listed as exports in the NAMESPACE file. Regards, 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
Re: [Rcpp-devel] Debugging Rcpp for Solaris
On Wed, 9 Jan 2019 at 15:04, mike guggis wrote: > > Hello, > > I submitted a package to CRAN that passed all checks in RStudio but failed > when it was tested on Solaris (after it was on CRAN). Now I need to correct > the error and resubmit to CRAN. I would like to avoid using CRAN as a > debugging tool. Is there a way to check packages on Solaris? I am using > Windows 10. > > The packages checks are here > https://cran.r-project.org/web/checks/check_results_BiProbitPartial.html > > An excerpt of the error is below > > BiProbitPartialMCMC.cpp:424:49: error: call of overloaded ‘log(bool)’ is > ambiguous > double SupportRatio = log(abs(rhoStar)<1) - log(abs(rho)<1); > ^ > > There is a similar error for the second log function. It seems I can simply > fix it with an if/else statement, but I would like to check it before > submitting back to CRAN. I had a bug once only arising in Solaris SPARC. I found a forgotten storage room in the university packed with old stuff, and rescued a dusty Sun SPARC server. A professor allowed me to attach it in the department's server room and, surprisingly enough, it worked except for a fan. Then I installed all the stuff needed with great pain, and finally found and solved the bug. In fact, it was in Rcpp. So go figure, I was very sad when the SPARC machine on CRAN died. But I digress. Now there's just the x86 Solaris machine, so you can test this in a virtual machine, using e.g. VirtualBox. Or you can try the Solaris box on rhub: https://builder.r-hub.io/advanced 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
Re: [Rcpp-devel] Different Rcout object for each translation unit
On Mon, 3 Dec 2018 at 20:33, Kevin Ushey wrote: > > 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? Sure, no problem. > You could of course just create your own Rcout / Rcerr objects as well > (the Rstreambuf class is public and part of the Rcpp namespace). Yeap, but that's suboptimal. I agree that this might be worth fixing on the Rcpp side. I asked first here because I'm not sure if that's possible, because packages cannot (in general) link to other packages. 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] Different Rcout object for each translation unit
Hi, Rcout is defined in iostream/Rstreambuf.h as a static object. This means that different translation units see a different Rcout, while they see the same std::cout (I have a minimal package showing this if needed). As a result, for example, one object allocated in a certain .cpp cannot redirect the output of other object allocated in another .cpp. Is there any solution to this (apart from putting everything in a huge .cpp)? Regards, -- Iñaki Úcar ___ 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 with Rcout
On Tue, 27 Nov 2018 at 17:22, Barth Riley wrote: > > Thanks for your reply. No, I’m not calling this using parallelization, and to > my knowledge at least I have not redirected stdout (how would I check this?). > The function is meant to be called by another function, but I am testing it > directly from the R console. Is this publicly available somewhere? If not, you could write a script, or a dummy package if that's not possible, so that we can execute it and reproduce the issue. Otherwise, we cannot help you, because the function and your Rcout usage is fine. 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
Re: [Rcpp-devel] Problems with Rcout
On Tue, 27 Nov 2018 at 17:06, Barth Riley wrote:
>
> Here is a more complete example. Note that I want to output text strings for
> debugging purposes as the code for treatAsVector = true is never executed.
The contents of the function are irrelevant. If I compile and execute
this in a clean session, it works fine. I.e.:
Rcpp::cppFunction('
NumericVector getValidCount(Rcpp::NumericMatrix m,
bool treatAsVector) {
Rcpp::Rcout << "getValidCount BEGINS" << std::endl;
int N = m.cols();
NumericVector u, vec;
NumericVector count (N);
if(!treatAsVector) {
Rcpp::Rcout << "Treating as matrix" << std::endl;
for(int i = 0; i < N; i++) {
vec = m(_,i);
vec = vec[!Rcpp::is_na(vec)];
u = Rcpp::unique(vec);
count[i] = u.length();
}
} else {
Rcpp::Rcout << "treating as vector" << std::endl;
vec = as(m);
vec = vec[!Rcpp::is_na(vec)];
u = Rcpp::unique(vec);
count.fill(u.length());
}
return count;
}
')
getValidCount(matrix(), FALSE)
#> getValidCount BEGINS
#> Treating as matrix
#> [1] 0
So where are you calling this? Are you redirecting the stdout? Are you
parallelising, are you calling this inside a subprocess?
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
Re: [Rcpp-devel] Problems with Rcout
On Tue, 27 Nov 2018 at 16:35, Barth Riley wrote:
>
> Dear Rcppers
>
> I am encountering a problem with Rcout. Even with basic string output, when I
> run the function containing the call to Rcout, no output is generated. Here
> is a simple example of what I’m trying to do:
>
> // [[Rcpp::export]]
> void testFunc() {
>Rcpp::Rcout << "testFunc begins" << std:endl;
>. . .
> }
Note that it should be "std::endl", with double colon. Assuming this
is a transcription error, you'll have to provide more context (and,
ideally, some kind of reproducible example), because this works just
fine.
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
Re: [Rcpp-devel] [ANN] Rcpp 1.0.0 (Yay !!)
Probably the most successful and impactful project after R itself! Congrats! Iñaki On Thu, 8 Nov 2018 at 03:43, Dirk Eddelbuettel wrote: > > > Those of you who follow Twitter, or RSS feeds from RBloggers or RWeekly, may > have seen that I posted about > - the ten year anniversary of Rcpp (!!) > - the fact that I used the 1 and 0 to declare release 1.0.0 (!!!) > - and the just announced 1.0.0 release on CRAN. > > If you missed it, my two blog posts are at > - http://dirk.eddelbuettel.com/blog/2018/11/05#rcpp_at_ten_welcome_one_oh > - http://dirk.eddelbuettel.com/blog/2018/11/07#rcpp_1.0.0 > - or my Twitter account at https://twitter.com/eddelbuettel > > As I tried to say there: It is a really nice story of what we all managed to > accomplish together, so a big fat thank you to everybody who helped along the > way: of course everybody in Rcpp Core (and Dominick and Romain before that), > but also every code contributor, bug reporter, mailing list participant here > and, of course, all users! We have come a long way and now have a pretty > nice tool, but we aren't done. There is always something else to do and try > (ALTREP, anyone? Maybe as GSoC 2019?) but we will continue to do it in a way > that keeps existing code valid and working. > > Again, big thanks everyone. It's been a terrific journey so far. > > 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 -- Iñaki Úcar ___ 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] installing Rcpp and working a compilation with C++
On Wed, 31 Oct 2018 at 12:07, Benjamin Levy wrote: > > Reply: bash: PKG_CXXFLAGS=-I/usr/local/lib/R/site-library[B/Rcpp/include: No > such file or directory Note the "[B" after "site-library". Was this line manually entered or copied from somewhere? Maybe you involuntarily copied a backspace character. -- Iñaki Ucar ___ 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 on performance
El dom., 23 sept. 2018 13:01, Iñaki Ucar escribió: > Also you can try adding > > // [[Rcpp::plugins(unwindProtect)]] > > to InsideLoop.cpp. That should boost the performance too with the > latest version of Rcpp. > Taking a look now, and I realize there are just calls to C++, not to R. So, please, forget about what I've said. The dangers of skimming through code in a mobile device and speaking too soon. Iñaki > Iñaki > El dom., 23 sept. 2018 a las 12:46, Kyle Baron () > escribió: > > > > > > I got mOutput mixed up with mResults in the last message; it mResults > that gets created up front and then every iteration. > > > > > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_Rcpp.R#L45 > > > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/InsideLoop.cpp#L12 > > > > > > > > > > > > On Sun, Sep 23, 2018 at 5:38 AM Kyle Baron wrote: > >> > >> > >> It seems like the sourceCpp thing is the biggie. That dropped about a > second of the time from something like 2.7 to 1.7 seconds > >> > >> They also create mOutput and then re-create it every time it goes into > InsideLoop > >> > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_Rcpp.R#L41 > >> > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/InsideLoop.cpp#L12 > >> > >> I just passed mOutput into InsideLoop and modified it there > >> > https://github.com/kylebmetrum/Comparison-Programming-Languages-Economics/commit/89015a72a0cf673739e83e38d4a545db4886b879 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Sat, Sep 22, 2018 at 1:21 PM Dirk Eddelbuettel > wrote: > >>> > >>> > >>> On 22 September 2018 at 12:36, Michael Weylandt wrote: > >>> | I don't have time right now, but the offending line is here: > >>> | > >>> | > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_Rcpp.R#L62 > >>> | > >>> | which calls `sourceCpp` repeatedly on each loop iteration. > >>> | > >>> | Should be a one line change to move it outside the loop and un-sully > the > >>> | good name of Rcpp. > >>> > >>> Nice catch!! You should _definitely_ send him a PR. I also suggest to > move > >>> the sourceCpp() outside the timed segment as I do not think he > accounts for > >>> compilation in the other approaches (eg C++). > >>> > >>> 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 > > > > -- > Iñaki Ucar > ___ 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 on performance
El dom., 23 sept. 2018 14:39, Dirk Eddelbuettel escribió: > > On 23 September 2018 at 13:01, Iñaki Ucar wrote: > | Also you can try adding > | > | // [[Rcpp::plugins(unwindProtect)]] > | > | to InsideLoop.cpp. That should boost the performance too with the > | latest version of Rcpp. > > Maybe, maybe not. Are there lots of calls happening here? Should be easy > enough to add and then (micro)benchmark() from R. > The Rcpp function is called inside a loop, so I would expect some gain. Iñaki > Another endeavour may be to take the rewritten C++ version by MattDB in > > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_CPP_2.cpp > and wrap that. > > 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] Question on performance
Also you can try adding // [[Rcpp::plugins(unwindProtect)]] to InsideLoop.cpp. That should boost the performance too with the latest version of Rcpp. Iñaki El dom., 23 sept. 2018 a las 12:46, Kyle Baron () escribió: > > > I got mOutput mixed up with mResults in the last message; it mResults that > gets created up front and then every iteration. > > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_Rcpp.R#L45 > https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/InsideLoop.cpp#L12 > > > > > > On Sun, Sep 23, 2018 at 5:38 AM Kyle Baron wrote: >> >> >> It seems like the sourceCpp thing is the biggie. That dropped about a >> second of the time from something like 2.7 to 1.7 seconds >> >> They also create mOutput and then re-create it every time it goes into >> InsideLoop >> https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_Rcpp.R#L41 >> https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/InsideLoop.cpp#L12 >> >> I just passed mOutput into InsideLoop and modified it there >> https://github.com/kylebmetrum/Comparison-Programming-Languages-Economics/commit/89015a72a0cf673739e83e38d4a545db4886b879 >> >> >> >> >> >> >> >> >> >> >> >> On Sat, Sep 22, 2018 at 1:21 PM Dirk Eddelbuettel wrote: >>> >>> >>> On 22 September 2018 at 12:36, Michael Weylandt wrote: >>> | I don't have time right now, but the offending line is here: >>> | >>> | >>> https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_Rcpp.R#L62 >>> | >>> | which calls `sourceCpp` repeatedly on each loop iteration. >>> | >>> | Should be a one line change to move it outside the loop and un-sully the >>> | good name of Rcpp. >>> >>> Nice catch!! You should _definitely_ send him a PR. I also suggest to move >>> the sourceCpp() outside the timed segment as I do not think he accounts for >>> compilation in the other approaches (eg C++). >>> >>> 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 -- Iñaki Ucar ___ 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 on performance
FYI, you can find the code here: https://github.com/jesusfv/Comparison-Programming-Languages-Economics El sáb., 22 sept. 2018 a las 15:11, Dirk Eddelbuettel () escribió: > > > Jordi, > > On 22 September 2018 at 09:18, Georgi Boshnakov wrote: > | I don’t see any code going with the revised version, but > | looking at the code coming with the original paper, see > http://economics.sas.upenn.edu/~jesusfv/RBC_codes.zip, > | the following points come up: > > All excellent points. Jordi, you should ask for the code. It really sounds > like something done either naively, or with a goal in mind. "Rcpp code is > C++ code" so any "N times" is silly -- setup costs, extra copies, ... etc pp. > > We may of course copy at the end from, say, bespoke C++ data structures to > ours. But for any non-trivial example the cost of that will be well under, > say, 1% > while still getting a "many times" speedup over alternative R solutions. So > a win for most people. Hence 1444 packages on CRAN using it. Those people > aren't all fools ... > > 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 -- Iñaki Ucar ___ 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] Passing pointers to objects between libs results in weird UBSAN warning
El lun., 20 ago. 2018 a las 22:16, Jan van der Laan () escribió: > > On 20-08-18 17:59, Iñaki Ucar wrote: > > El lun., 20 ago. 2018 a las 16:18, Jan van der Laan > > () escribió: > >>> pkg2 compiles a shared library using pkg1's headers, but it does not > >>> link against libpkg1.so (in general, this is not possible in R). So > >>> both libpkg2.so and libpkg1.so define two copies of the same types, > >>> Foo and FooBar. pkg2 allocates FooBar from libpkg1.so and then > >>> dynamically casts it as FooBar from libpkg2.so. This is why clang > >>> complains. It has to do with how RTTI comparisons are done across > >>> dynamic objects (see, e.g., > >>> https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/). > >> This is roughly what I suspected. However, if I understand that article > >> correctly problems should only occur with clang (which I am using; > >> didn't mention that) and not with g++. However, the problems also occur > >> with g++ > >> (https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/ldat/ldat-Ex.Rout). > > I don't know, maybe things have changed in recent versions of gcc. > > > >>> I'd say that these errors can be safely ignored, because types are > >>> exactly the same. Anyway, shouldn't it be easier to export get_foobar > >>> in pkg1? > >> Don't know how easy it is to convince the CRAN members to ignore the > >> warnings. Of course, in this simple case, it is easier to define > >> get_foobar in pkg1, but in the general case, for performance reasons, I > >> would like to be able to access FooBar from other packages from c++ code. > > I've just submitted a PR to your repo that fixes the issue: > > https://github.com/djvanderlaan/lvec_ubsan/pull/1 > > > > Copy of the explanation there, for the interest of this list: > > > > Instead of using useDynLib in the NAMESPACE, this patch loads the > > library using library.dynam in .onLoad. In this way, we can take > > advantage of library.dynam's dots, which are mapped into the > > subsequent dyn.load call. This call has local=TRUE by default, i.e., > > dlopen is called with the RTLD_LOCALattribute. Instead, local=FALSE > > sets RTLD_GLOBAL, which makes type_info from pkg1 available globally, > > and thus the RTTI error goes away. > > OK, this seems to fix it. Not sure if the CRAN people like it when I > register my symbols globally as this could bite other packages with the > same symbol names. If I understand correctly; I am trying to read in on > this stuff :-S This is something that could be done on CRAN in those machines that perform UBSAN checks. I suggested it here: https://stat.ethz.ch/pipermail/r-devel/2018-August/076636.html One thing you could do is to try to detect whether lvec is being compiled with sanitizers and then set that flag. But probably it's not worth it so much trouble. Iñaki > > Tomorrow I will check with lvec and ldat. > > Thanks. > > Jan > > > > > > > > > > > Iñaki > > > >> > >> Thanks for the response. > >> > >> Jan > >> > >> > >> > >> > >> > >> > >> > >>> Iñaki > >>> > >>>> So, help!? > >>>> > >>>> Jan > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ___ > >>>> 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 > >>> > >>> > > > > > -- Iñaki Ucar ___ 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] Passing pointers to objects between libs results in weird UBSAN warning
El lun., 20 ago. 2018 a las 16:18, Jan van der Laan () escribió: > > > pkg2 compiles a shared library using pkg1's headers, but it does not > > link against libpkg1.so (in general, this is not possible in R). So > > both libpkg2.so and libpkg1.so define two copies of the same types, > > Foo and FooBar. pkg2 allocates FooBar from libpkg1.so and then > > dynamically casts it as FooBar from libpkg2.so. This is why clang > > complains. It has to do with how RTTI comparisons are done across > > dynamic objects (see, e.g., > > https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/). > > This is roughly what I suspected. However, if I understand that article > correctly problems should only occur with clang (which I am using; > didn't mention that) and not with g++. However, the problems also occur > with g++ > (https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/ldat/ldat-Ex.Rout). I don't know, maybe things have changed in recent versions of gcc. > > I'd say that these errors can be safely ignored, because types are > > exactly the same. Anyway, shouldn't it be easier to export get_foobar > > in pkg1? > > Don't know how easy it is to convince the CRAN members to ignore the > warnings. Of course, in this simple case, it is easier to define > get_foobar in pkg1, but in the general case, for performance reasons, I > would like to be able to access FooBar from other packages from c++ code. I've just submitted a PR to your repo that fixes the issue: https://github.com/djvanderlaan/lvec_ubsan/pull/1 Copy of the explanation there, for the interest of this list: Instead of using useDynLib in the NAMESPACE, this patch loads the library using library.dynam in .onLoad. In this way, we can take advantage of library.dynam's dots, which are mapped into the subsequent dyn.load call. This call has local=TRUE by default, i.e., dlopen is called with the RTLD_LOCALattribute. Instead, local=FALSE sets RTLD_GLOBAL, which makes type_info from pkg1 available globally, and thus the RTTI error goes away. Iñaki > > > Thanks for the response. > > Jan > > > > > > > > > > > Iñaki > > > >> > >> So, help!? > >> > >> Jan > >> > >> > >> > >> > >> > >> ___ > >> 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 > > > > > > -- Iñaki Ucar ___ 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] Passing pointers to objects between libs results in weird UBSAN warning
-devel list seems somewhat similar: > http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2017-July/009656.html. > I thought that it might be caused by the fact that I am passing pointers > to template classes between libraries. I also couldn't find much about > that. I did find some messages on passing pointers to STL objects > between libraries. That should be ok, as long as the same compiler is > used for both libraries. Although that might technically still make it > undefined behaviour. pkg2 compiles a shared library using pkg1's headers, but it does not link against libpkg1.so (in general, this is not possible in R). So both libpkg2.so and libpkg1.so define two copies of the same types, Foo and FooBar. pkg2 allocates FooBar from libpkg1.so and then dynamically casts it as FooBar from libpkg2.so. This is why clang complains. It has to do with how RTTI comparisons are done across dynamic objects (see, e.g., https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/). I'd say that these errors can be safely ignored, because types are exactly the same. Anyway, shouldn't it be easier to export get_foobar in pkg1? Iñaki > > So, help!? > > Jan > > > > > > ___ > 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 -- Iñaki Ucar ___ 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
