Re: [Rcpp-devel] Export only C function symbols?

2019-02-04 Thread Watal M. Iwasaki
Iñaki Ucar wrote: > 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 > le

Re: [Rcpp-devel] Export only C function symbols?

2019-02-04 Thread Watal M. Iwasaki
NAMESPACE; only accessible from .Call() I hope this helps clarify the (no) problem. Best, Watal On Mon, Feb 4, 2019 at 10:42 PM Iñaki Ucar wrote: > On Mon, 4 Feb 2019 at 13:45, Watal M. Iwasaki > wrote: > > > > Dear Dirk, > > > > Thank you for the prompt a

Re: [Rcpp-devel] Export only C function symbols?

2019-02-04 Thread Watal M. Iwasaki
is possible to control the level of exposure. It is not a big problem. Good to know the answer is no. Best, Watal On Mon, Feb 4, 2019 at 8:49 PM Dirk Eddelbuettel wrote: > > On 4 February 2019 at 16:45, Watal M. Iwasaki wrote: > | Hi all, > | > | Adding `[[Rcpp::export]]` t

[Rcpp-devel] Export only C function symbols?

2019-02-03 Thread Watal M. Iwasaki
of curiosity, is it possible to suppress the latter reaction and get only `_mypkg_myfun` for .Call-ing? Best, Watal M. Iwasaki ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] How to handle std::cout/std::cerr in shared libraries

2018-10-26 Thread Watal M. Iwasaki
Yes, escaping from the check seems difficult. I have created a quick PR on this for further discussion. Watal On Sat, Oct 27, 2018 at 2:13 AM Dirk Eddelbuettel wrote: > > Hi Watal, > > Thanks for being patient with me :) > > On 27 October 2018 at 01:26, Watal M. Iwasaki wrote

Re: [Rcpp-devel] How to handle std::cout/std::cerr in shared libraries

2018-10-26 Thread Watal M. Iwasaki
std::cout << "to stdout; BAD\n"; Rcpp::Rcout << "to R's i/o\n"; } ``` In other words, we don't have to replace std::cout with Rcpp::Rcout. We only have to change its buffer. Thanks, Watal On Sat, Oct 27, 2018 at 12:09 AM Dirk Eddelbuettel wrote:

Re: [Rcpp-devel] How to handle std::cout/std::cerr in shared libraries

2018-10-26 Thread Watal M. Iwasaki
just stick to std::cout. Best, Watal On Fri, Oct 26, 2018 at 10:12 PM Dirk Eddelbuettel wrote: > > On 26 October 2018 at 22:03, Watal M. Iwasaki wrote: > | Dear Dirk, > | > | Thank you for the prompt response. Good to know there is no easy way. I > | have made up my mind to chang

Re: [Rcpp-devel] How to handle std::cout/std::cerr in shared libraries

2018-10-26 Thread Watal M. Iwasaki
26 October 2018 at 16:31, Watal M. Iwasaki wrote: > | I have been working on an R interface package to a shared library written > | in C++. It works almost perfectly, but the output to std::cout is not > shown > | on R console (on Linux). Of course Rcpp::Rcout should be used instead o

[Rcpp-devel] How to handle std::cout/std::cerr in shared libraries

2018-10-26 Thread Watal M. Iwasaki
not call entry points which might terminate R nor write to stdout/stderr instead of to the console, nor use Fortran I/O nor system RNGs. ``` Can I suppress this note? or should I just ignore it? any other good solution? Thanks, Watal M. Iwasaki ___ Rcpp

Re: [Rcpp-devel] Strange behavior with boost::program_options

2016-07-06 Thread Watal M. Iwasaki
hidden behind an initialization flag, or something > like that) > > Nonetheless, this isn't really an Rcpp question, and it's hard to know > for sure without seeing how your Simulation object is defined. > > On Tue, Jul 5, 2016 at 10:56 PM, Watal M. Iwasaki > wrote: > > Hi

[Rcpp-devel] Strange behavior with boost::program_options

2016-07-05 Thread Watal M. Iwasaki
s how C++ objects are cached in R environments. Is this a bug in Rcpp? Or am I missing something? Thanks, -- Watal M. Iwasaki / 岩嵜 航 SOKENDAI, Graduate University for Advanced Studies, Hayama, Kanagawa 240-0193, Japan +81-46-858-1576 https://heavywatal.github.io/ ___