(now with some links): Le 28 mai 2014 à 16:31, John Mous <john.mo...@gmail.com> a écrit :
> The object really is just built as part of the return statement. i.e. the > lines from my prior e-mail exist as-is in the full code, Sure. What happens is that Rcpp::export generates something that calls wrap( std::map<std::string,int> ). > there's just more that actually builds the variables X1-X4 beforehand. It should not be relevant. > So I'm not sure where to debug from the client side. I'm a C/C++ developer, > but have no experience with Rcpp internals or the general interface between R > and C. I can insert some debug statements on the Rcpp side if you can guide > me to where wrap is defined. well wrap is defined here: https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28 It then performs a series of dispatch, that eventually lead to something that handles std::map<std::string,int>: https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255 template <typename InputIterator, typename T> inline SEXP range_wrap_dispatch___impl__cast( InputIterator first, InputIterator last, ::Rcpp::traits::false_type ){ size_t size = std::distance( first, last ) ; const int RTYPE = ::Rcpp::traits::r_sexptype_traits<typename T::second_type>::rtype ; Shield<SEXP> x( Rf_allocVector( RTYPE, size ) ); Shield<SEXP> names( Rf_allocVector( STRSXP, size ) ) ; typedef typename ::Rcpp::traits::storage_type<RTYPE>::type CTYPE ; CTYPE* start = r_vector_start<RTYPE>(x) ; size_t i =0; std::string buf ; for( ; i<size; i++, ++first){ start[i] = (*first).second ; buf = (*first).first ; SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ; } ::Rf_setAttrib( x, R_NamesSymbol, names ) ; return wrap_extra_steps<T>( x ) ; } what I suspect to be the problem is this line: ::Rf_setAttrib( x, R_NamesSymbol, names ) ; > What Romain says makes sense to me, despite my lack of expertise in this > area.. the really intermittent nature of the problem and the fact that I > can't recreate it in a small / fast running example suggests that perhaps > this manifests when R happens to garbage collect at an unfortunate time (if I > understood correctly). Thanks again. Something like that. as hadley hinted, please try this under gc torture, or preferably through a debugger. > On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel <e...@debian.org> wrote: > > On 28 May 2014 at 10:02, John Mous wrote: > | Hmm, unfortunately the GitHub version failed also. > > Darn. > > | The attributes on the failed > | object are a little different though, here's what they look like: > | > | Browse[1]> str(results) > | atomic [1:4] 1 1 2270 0 > | - attr(*, "")= symbol sim > | - attr(*, "value")= promise to NULL > > I am not sure what we can do without a reproducible example. :-/ > The code just got a review / refreshment over the last few months. > > You best bet may the slow and tedious insertion of debug statements to see > when / if the object changes. > > Dirk > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.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
_______________________________________________ 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
