<div dir="ltr"><div>The idea with IntegerVector for shape is great. I had to fix some minor stuff in xtensor but it appears to be working. </div><div><br></div><div>Ok, good to know about the shape copy!</div><div><br></div><div>Yeah, this is literally a weekend project for now (and I haven't used R before) so this was just a quick-n-dirty test script.</div><div><br></div><div>Cheers, </div><div><br></div><div>Wolf</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-07 3:59 GMT-07:00 Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 7 June 2017 at 09:29, Romain Francois wrote:<br>
| Hi,<br>
|<br>
| Instead of doing that:<br>
|<br>
| const int vtype = traits::r_sexptype_traits<int><wbr>::rtype;<br>
| SEXP shape_sxp = Rf_allocVector(vtype, shape.size());<br>
|<br>
| Perhaps your rxarray object could hold an IntegerVector. Also not quite sure<br>
| why you use the first line at all, which does not depend on T, so vtype is<br>
| always going to be INTSXP.<br>
|<br>
| Also, you should avoid using std::cout in <a href="https://github.com/QuantStack/" rel="noreferrer" target="_blank">https://github.com/QuantStack/</a><br>
| xtensor-r/blob/master/src/<wbr>rcpp_hello_xtensor.cpp#L14<br>
|<br>
| You can use Rcpp::Rcout instead, or Rprintf.<br>
<br>
</span>Yep. And 'install_and_test.R' builds via build() and installs the package<br>
which is muddled; the demo code is better in inst/demo/ or inst/scripts.<br>
<br>
For what it is worth I looked into taking the xtensor .deb package and<br>
creating an Ubuntu 16.04 package via the <a href="http://launchpad.net" rel="noreferrer" target="_blank">launchpad.net</a> service. I have that<br>
in 'my' PPA (<a href="https://launchpad.net/~edd/+archive/ubuntu/misc/+packages" rel="noreferrer" target="_blank">https://launchpad.net/~edd/+<wbr>archive/ubuntu/misc/+packages</a>) and<br>
will try the same for a 14.04 package at which point we could use Travis<br>
easily. I may create a simple 'more standard R package' PR.<br>
<br>
Dirk<br>
<div><div class="h5"><br>
| And the memory is going to be freed again, at some point. And calling<br>
| Rcpp_ReleaseObject(m_sexp) would also clear the shape_sxp "attribute",<br>
| right?<br>
|<br>
| The shape_sxp object you create here (and don’t protect)<br>
| <a href="https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/" rel="noreferrer" target="_blank">https://github.com/QuantStack/<wbr>xtensor-r/blob/master/inst/<wbr>include/xtensor-r/</a><br>
| rxarray.hpp#L152<br>
|<br>
| Is probably duplicated here:<br>
| <a href="https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/" rel="noreferrer" target="_blank">https://github.com/QuantStack/<wbr>xtensor-r/blob/master/inst/<wbr>include/xtensor-r/</a><br>
| rxarray.hpp#L160<br>
|<br>
| As part of allocArray’s business:<br>
| <a href="https://github.com/wch/r-source/blob/d60c742aa8acc764874db87e3c748e27986e1134/" rel="noreferrer" target="_blank">https://github.com/wch/r-<wbr>source/blob/<wbr>d60c742aa8acc764874db87e3c748e<wbr>27986e1134/</a><br>
| src/main/array.c#L259<br>
|<br>
| Romain<br>
|<br>
|<br>
|<br>
|<br>
| Le 7 juin 2017 à 03:01, Wolf Vollprecht <<a href="mailto:w.vollprecht@gmail.com">w.vollprecht@gmail.com</a>> a écrit :<br>
|<br>
| Ok, I think I got the idea.<br>
|<br>
| In the R->xtensor bindings, we always work directly on memory allocated<br>
| through R (either passed in from R or allocated from C++ code).<br>
|<br>
| The review-relevant lines are really only ~10 lines: <a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a><br>
| QuantStack/xtensor-r/blob/<wbr>master/inst/include/xtensor-r/<wbr>rxarray.hpp#L145<br>
|<br>
| const int vtype = traits::r_sexptype_traits<int><wbr>::rtype;<br>
| SEXP shape_sxp = Rf_allocVector(vtype, shape.size());<br>
|<br>
| int* r_shape = INTEGER(shape_sxp);<br>
| // set shape values ...<br>
| m_sexp = Rf_allocArray(SXP, shape_sxp);<br>
|<br>
| So afterwards, the idea would be to make a call to<br>
|<br>
| Rcpp_PreserveObject(m_sexp);<br>
|<br>
| right? And if the destructor of the object is called (and the object is<br>
| owned from C++) we would just call<br>
|<br>
| Rcpp_ReleaseObject(m_sexp);<br>
|<br>
| And the memory is going to be freed again, at some point. And calling<br>
| Rcpp_ReleaseObject(m_sexp) would also clear the shape_sxp "attribute",<br>
| right?<br>
|<br>
| Thanks for your reply!<br>
</div></div>| [cleardot]<br>
<div class="HOEnZb"><div class="h5">| Wolf<br>
|<br>
|<br>
| 2017-06-06 16:27 GMT-07:00 Dirk Eddelbuettel <<a href="mailto:edd@debian.org">edd@debian.org</a>>:<br>
|<br>
|<br>
| On 6 June 2017 at 17:06, Dirk Eddelbuettel wrote:<br>
| | The general idea when working with R objects is that<br>
| |<br>
| | -- on the way in from R to the C++ functions we construct object<br>
| such that<br>
| | the existing memory (from R) is used; one example is how<br>
| RcppArmadillo<br>
| | uses the 'advanced' constructors of Armadillo allowing to<br>
| operate<br>
| | without copies; hence R managed memory is used while C++<br>
| functions are<br>
| | called; in general this side of the conversion is the templates<br>
| as<>()<br>
| | converters;<br>
| |<br>
| | -- on the way back we use the *alloc functions from the C-level API<br>
| of R to<br>
| | construct objects that use memory from R's pool, once we return<br>
| these<br>
| | objects to R as SEXP they are indistinguishable to R from its<br>
| own; these<br>
| | are the wrap() functions (and I think we may make on occassion<br>
| make "one<br>
| | final copy" at his level, but I'd have to double-check).<br>
|<br>
| Actually, let me rephrase: "in most cases not involving native R types"<br>
| do we<br>
| make one copy at the return.<br>
|<br>
| The general approach is iterator based, see internal/wrap.h. But there<br>
| is a<br>
| lot of template magic...<br>
|<br>
| Dirk<br>
|<br>
| | I haven't had a chance to look at what Wes is doing with Apache<br>
| Arrow, and<br>
| | what is happening with xtensor -- so thanks for getting the ball<br>
| rolling.<br>
| |<br>
| | Dirk<br>
| |<br>
| | --<br>
| | <a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
| | ______________________________<wbr>_________________<br>
| | Rcpp-devel mailing list<br>
| | <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
| | <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/</a><br>
| rcpp-devel<br>
|<br>
| --<br>
| <a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
|<br>
|<br>
| ______________________________<wbr>_________________<br>
| Rcpp-devel mailing list<br>
| <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
| <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a><br>
|<br>
|<br>
| ______________________________<wbr>_________________<br>
| Rcpp-devel mailing list<br>
| <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
| <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a><br>
<br>
--<br>
<a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
</div></div></blockquote></div><br></div>