Re: [Rcpp-devel] Error during wrapup
Hmm, unfortunately the GitHub version failed also. 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 On Tue, May 27, 2014 at 6:10 PM, John Mous john.mo...@gmail.com wrote: Hi Kevin, Thanks. I will give the GitHub version a try -- the error usually manifests only after running for about a day or so, so it may take a while to do that. Unfortunately I am having trouble creating a small reproducible example -- a function with just the assignments as written in my previous e-mail works fine when executed thousands of times in a loop. The full code is not that long (~165 lines), but is also non-trivial. It's odd that something else is causing things to fail with the end result being that only the field *names*, which are hardcoded, and not the values, not coming through properly. Since you said you suspect the problem may be fixed, can you give me a hint of what you think it may be related to? This might help me isolate the piece of offending code. On Tue, May 27, 2014 at 5:46 PM, Kevin Ushey kevinus...@gmail.com wrote: Hi John, I think we may have tackled this in some of the latest fixes with the version of Rcpp on GitHub. Can you try installing that version and trying again? Ie, try install.packages(devtools); devtools::install_github(RcppCore/Rcpp) then try running your code again. Alternatively, please supply a small reproducible example that we can try to run ourselves. You may be able to tease this error out reproducibly if you run it with gctorture(TRUE) on. Thanks, Kevin On Tue, May 27, 2014 at 2:42 PM, John Mous john.mo...@gmail.com wrote: Hello, I am passing back a very simple std::mapstd::string, int from Rcpp as follows: std::mapstd::string, int result; result[X1] = X1; result[X2] = X2; result[X3] = X3; result[X4] = X4; return wrap(result); The keys are hardcoded as shown, and the values X1-X4 are ints. Almost always everything works fine, however, very intermittently, a vector is returned on the R side _without_ named fields. For example: Browse[1] results [1] 1 2 863 0 Error during wrapup: 'getCharCE' must be called on a CHARSXP Browse[1] str(results) atomic [1:4] 1 2 863 0 - attr(*, )= symbol X1 - attr(*, )= language `[[-`(`*tmp*`, sim, value = 1L) results[[X1]] works, but results[[X1]] does not, and X2-X4 can be retrieved only by index. However, again, most runs are successful: Browse[1] results X1 X2 X3 X4 11 32540 Browse[1] str(results) Named int [1:4] 1 1 3254 0 - attr(*, names)= chr [1:4] X1 X2 X3 X4 I am using R 3.1.0 and Rcpp 0.11.1. Does the message Error during wrapup: 'getCharCE' must be called on a CHARSXP within this context hint anything to anyone familiar with Rcpp's internals? I realize it's almost impossible to diagnose with the given information -- is there a way to get Rcpp to display more debugging information? Thank you. ___ 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] Error during wrapup
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
Re: [Rcpp-devel] Error during wrapup
This looks like a protection issue. For whomever this makes sense to: From the code that wraps such object, i would investigate the call to setAttrib. Perhaps we are supposed to get the result of it and protect it. So i would tend to use an Armor instead of a Shield. Romain Le 28 mai 2014 à 16:02, John Mous john.mo...@gmail.com a écrit : Hmm, unfortunately the GitHub version failed also. 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 On Tue, May 27, 2014 at 6:10 PM, John Mous john.mo...@gmail.com wrote: Hi Kevin, Thanks. I will give the GitHub version a try -- the error usually manifests only after running for about a day or so, so it may take a while to do that. Unfortunately I am having trouble creating a small reproducible example -- a function with just the assignments as written in my previous e-mail works fine when executed thousands of times in a loop. The full code is not that long (~165 lines), but is also non-trivial. It's odd that something else is causing things to fail with the end result being that only the field *names*, which are hardcoded, and not the values, not coming through properly. Since you said you suspect the problem may be fixed, can you give me a hint of what you think it may be related to? This might help me isolate the piece of offending code. On Tue, May 27, 2014 at 5:46 PM, Kevin Ushey kevinus...@gmail.com wrote: Hi John, I think we may have tackled this in some of the latest fixes with the version of Rcpp on GitHub. Can you try installing that version and trying again? Ie, try install.packages(devtools); devtools::install_github(RcppCore/Rcpp) then try running your code again. Alternatively, please supply a small reproducible example that we can try to run ourselves. You may be able to tease this error out reproducibly if you run it with gctorture(TRUE) on. Thanks, Kevin On Tue, May 27, 2014 at 2:42 PM, John Mous john.mo...@gmail.com wrote: Hello, I am passing back a very simple std::mapstd::string, int from Rcpp as follows: std::mapstd::string, int result; result[X1] = X1; result[X2] = X2; result[X3] = X3; result[X4] = X4; return wrap(result); The keys are hardcoded as shown, and the values X1-X4 are ints. Almost always everything works fine, however, very intermittently, a vector is returned on the R side _without_ named fields. For example: Browse[1] results [1] 1 2 863 0 Error during wrapup: 'getCharCE' must be called on a CHARSXP Browse[1] str(results) atomic [1:4] 1 2 863 0 - attr(*, )= symbol X1 - attr(*, )= language `[[-`(`*tmp*`, sim, value = 1L) results[[X1]] works, but results[[X1]] does not, and X2-X4 can be retrieved only by index. However, again, most runs are successful: Browse[1] results X1 X2 X3 X4 11 32540 Browse[1] str(results) Named int [1:4] 1 1 3254 0 - attr(*, names)= chr [1:4] X1 X2 X3 X4 I am using R 3.1.0 and Rcpp 0.11.1. Does the message Error during wrapup: 'getCharCE' must be called on a CHARSXP within this context hint anything to anyone familiar with Rcpp's internals? I realize it's almost impossible to diagnose with the given information -- is there a way to get Rcpp to display more debugging information? Thank you. ___ 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 ___ 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] Error during wrapup
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, there's just more that actually builds the variables X1-X4 beforehand. 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. 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. 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
Re: [Rcpp-devel] Error during wrapup
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. If it's a gc problem, gctorture(TRUE) might help spring it more reliably. Hadley -- http://had.co.nz/ ___ 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] Error during wrapup
(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::mapstd::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::mapstd::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_traitstypename
T::second_type::rtype ;
ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
CTYPE* start = r_vector_startRTYPE(x) ;
size_t i =0;
std::string buf ;
for( ; isize; 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_stepsT( 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
[Rcpp-devel] C++11 in Windows R package
Dear Rcpp developers, I am working on a package https://github.com/mfasiolo/mvnfast which uses Rcpp/RcppArmadillo, OpenMP and C++11. Everything works fine under Linux: the package passes R CMD check --as-cran, while tests and vignettes work fine. I uploaded the package on win-builder, but I keep getting the error at the bottom. I have included the line CXX_STD = CXX11 in makefile.win as written in Writing R extensions. I have read comments on SOhttp://stackoverflow.com/questions/18971177/building-r-package-with-c11-rcpp-on-windows regarding Rtools not supporting many C++11 features. Is that the reason for the error or am I missing something? Thanks, Matteo *** arch - i386 g++ -std=c++0x -ID:/RCompile/recent/R-3.1.0/include -DNDEBUG -Id:/RCompile/CRANpkg/lib/3.1/Rcpp/include -Id:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include -Id:/Rcompile/CRANpkg/extralibs215/local215/include -O2 -Wall -mtune=core2 -c dmvnCpp.cpp -o dmvnCpp.o In file included from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloForward.h:28:0, from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadillo.h:30, from mvnfast.h:4, from dmvnCpp.cpp:1: d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloConfig.h:90:35: fatal error: RcppArmadilloLapack.h: No such file or directory compilation terminated. make: *** [dmvnCpp.o] Error 1 Warning: running command 'make -f Makevars.win -f D:/RCompile/recent/R-3.1.0/etc/i386/Makeconf -f D:/RCompile/recent/R-3.1.0/etc/i386/Makevars.site -f D:/RCompile/recent/R-3.1.0/share/make/winshlib.mk CXX='$(CXX1X) $(CXX1XSTD)' CXXFLAGS='$(CXX1XFLAGS)' CXXPICFLAGS='$(CXX1XPICFLAGS)' SHLIB_LDFLAGS='$(SHLIB_CXX1XLDFLAGS)' SHLIB_LD='$(SHLIB_CXX1XLD)' SHLIB=mvnfast.dll OBJECTS=dmvnCpp.o mahaCpp.o msCpp.o rmvnCpp.o' had status 2 g++ -std=c++0x -ID:/RCompile/recent/R-3.1.0/include -DNDEBUG -Id:/RCompile/CRANpkg/lib/3.1/Rcpp/include -Id:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include -Id:/Rcompile/CRANpkg/extralibs215/local215/include -O2 -Wall -mtune=core2 -c dmvnCpp.cpp -o dmvnCpp.o In file included from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloForward.h:28:0, from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadillo.h:30, from mvnfast.h:4, from dmvnCpp.cpp:1: d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloConfig.h:90:35: fatal error: RcppArmadilloLapack.h: No such file or directory compilation terminated. make: *** [dmvnCpp.o] Error 1 Warning: running command 'make -f Makevars.win -f D:/RCompile/recent/R-3.1.0/etc/i386/Makeconf -f D:/RCompile/recent/R-3.1.0/etc/i386/Makevars.site -f D:/RCompile/recent/R-3.1.0/share/make/winshlib.mk CXX='$(CXX1X) $(CXX1XSTD)' CXXFLAGS='$(CXX1XFLAGS)' CXXPICFLAGS='$(CXX1XPICFLAGS)' SHLIB_LDFLAGS='$(SHLIB_CXX1XLDFLAGS)' SHLIB_LD='$(SHLIB_CXX1XLD)' SHLIB=mvnfast.dll OBJECTS=dmvnCpp.o mahaCpp.o msCpp.o rmvnCpp.o symbols.rds' had status 2 ERROR: compilation failed for package 'mvnfast' * removing 'd:/RCompile/CRANguest/R-release/lib/mvnfast' ___ 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] C++11 in Windows R package
Hi Matteo, On 28 May 2014 at 22:58, Matteo Fasiolo wrote: | Dear Rcpp developers, | | I am working on a package which uses Rcpp/RcppArmadillo, OpenMP and C++11. | | Everything works fine under Linux: the package passes R CMD check --as-cran, | while tests and vignettes work fine. Nice. | I uploaded the package on win-builder, but I keep getting the error at the | bottom. | | I have included the line CXX_STD = CXX11 in makefile.win as written in Writing | R extensions. I have read comments on SO regarding Rtools not supporting many | C++11 | features. Is that the reason for the error or am I missing something? That could a bug of my making. Look at the sources -- on Unix / OS X we run the (standard script configure) which moves RcppArmadilloLapack.h.in to RcppArmadilloLapack.h and adjust one setting (based on which BLAS / LAPACK libraries are used; this is due to a change from last fall). I am wondering if I overlooked something for Windows here... Could so a simple check with a smaller package without any of the other added complexities (maybe even via RcppArmadillo.package.skeleton()) and see if that works? If it does, try adding the other pieces one by one and see where it breaks. It may well be a little unlikely that I broke all Windows builds or I would have heard from Uwe, but it still seems somewhat probably that this is related. Dirk | Thanks, | | Matteo | | | *** arch - i386 | g++ -std=c++0x -ID:/RCompile/recent/R-3.1.0/include -DNDEBUG -Id:/RCompile/CRANpkg/lib/3.1/Rcpp/include -Id:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include -Id:/Rcompile/CRANpkg/extralibs215/local215/include -O2 -Wall -mtune=core2 -c dmvnCpp.cpp -o dmvnCpp.o | In file included from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloForward.h:28:0, | from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadillo.h:30, | from mvnfast.h:4, | from dmvnCpp.cpp:1: | d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloConfig.h:90:35: fatal error: RcppArmadilloLapack.h: No such file or directory | compilation terminated. | make: *** [dmvnCpp.o] Error 1 | Warning: running command 'make -f Makevars.win -f D:/RCompile/recent/R-3.1.0/etc/i386/Makeconf -f D:/RCompile/recent/R-3.1.0/etc/i386/Makevars.site -f D:/RCompile/recent/R-3.1.0/share/make/winshlib.mk CXX='$(CXX1X) $(CXX1XSTD)' CXXFLAGS='$(CXX1XFLAGS)' CXXPICFLAGS='$(CXX1XPICFLAGS)' SHLIB_LDFLAGS='$(SHLIB_CXX1XLDFLAGS)' SHLIB_LD='$(SHLIB_CXX1XLD)' SHLIB=mvnfast.dll OBJECTS=dmvnCpp.o mahaCpp.o msCpp.o rmvnCpp.o' had status 2 | g++ -std=c++0x -ID:/RCompile/recent/R-3.1.0/include -DNDEBUG -Id:/RCompile/CRANpkg/lib/3.1/Rcpp/include -Id:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include -Id:/Rcompile/CRANpkg/extralibs215/local215/include -O2 -Wall -mtune=core2 -c dmvnCpp.cpp -o dmvnCpp.o | In file included from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloForward.h:28:0, | from d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadillo.h:30, | from mvnfast.h:4, | from dmvnCpp.cpp:1: | d:/RCompile/CRANpkg/lib/3.1/RcppArmadillo/include/RcppArmadilloConfig.h:90:35: fatal error: RcppArmadilloLapack.h: No such file or directory | compilation terminated. | make: *** [dmvnCpp.o] Error 1 | Warning: running command 'make -f Makevars.win -f D:/RCompile/recent/R-3.1.0/etc/i386/Makeconf -f D:/RCompile/recent/R-3.1.0/etc/i386/Makevars.site -f D:/RCompile/recent/R-3.1.0/share/make/winshlib.mk CXX='$(CXX1X) $(CXX1XSTD)' CXXFLAGS='$(CXX1XFLAGS)' CXXPICFLAGS='$(CXX1XPICFLAGS)' SHLIB_LDFLAGS='$(SHLIB_CXX1XLDFLAGS)' SHLIB_LD='$(SHLIB_CXX1XLD)' SHLIB=mvnfast.dll OBJECTS=dmvnCpp.o mahaCpp.o msCpp.o rmvnCpp.o symbols.rds' had status 2 | ERROR: compilation failed for package 'mvnfast' | * removing 'd:/RCompile/CRANguest/R-release/lib/mvnfast' | | | | | ___ | 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 -- 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
Re: [Rcpp-devel] C++11 in Windows R package
Matteo, I may have found it. It is not as broken as I feared. At the end of RcppArmadilloConfig.h we have // R can be built with its own Rlapack library, or use an external // one. Only the latter has zgesdd, a complex-valued SVD using divide-and-conquer #ifdef WIN32 // on Windows we do not assume ZGESDD #define ARMA_DONT_USE_CX_GESDD 1 #else // on the other OSs we test via LAPACK_LIBS (in configure) which // updates this include file #include RcppArmadilloLapack.h #endif so it was supposed to only include the library RcppArmadilloLapack.h if NOT on Windows. Somehow your configuration has undefined WIN32. We need to figure out why / who / where and correct it, and / or find a better #ifdef here. 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
Re: [Rcpp-devel] Error during wrapup
No luck with gctorture on yet, but I haven't run it for very long. It
slowed things down to a complete crawl, but maybe in the long run it can
recreate the problem faster than running the original code (about 12 hours,
the previous estimate of a day was too high), so this may still be
worthwhile.
On a whim I did try changing the two instances of Shield to Armor this
morning (I was able to locate the code in wrap.h by digging around before I
saw your e-mail) and ran the original full code without gctorture on, and
the problem still persists.
On Wed, May 28, 2014 at 3:44 PM, Romain Francois
rom...@r-enthusiasts.comwrote:
(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::mapstd::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::mapstd::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_traitstypename
T::second_type::rtype ;
ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
CTYPE* start = r_vector_startRTYPE(x) ;
size_t i =0;
std::string buf ;
for( ; isize; 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_stepsT( 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.orgwrote:
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
Re: [Rcpp-devel] C++11 in Windows R package
Hi Dirk, many thanks for the prompt reply. Tomorrow I will simplify the package to locate the origin of the bug (which should be caused by one of the dependencies I guess). Matteo On Wed, May 28, 2014 at 11:23 PM, Dirk Eddelbuettel e...@debian.org wrote: Matteo, I may have found it. It is not as broken as I feared. At the end of RcppArmadilloConfig.h we have // R can be built with its own Rlapack library, or use an external // one. Only the latter has zgesdd, a complex-valued SVD using divide-and-conquer #ifdef WIN32 // on Windows we do not assume ZGESDD #define ARMA_DONT_USE_CX_GESDD 1 #else // on the other OSs we test via LAPACK_LIBS (in configure) which // updates this include file #include RcppArmadilloLapack.h #endif so it was supposed to only include the library RcppArmadilloLapack.h if NOT on Windows. Somehow your configuration has undefined WIN32. We need to figure out why / who / where and correct it, and / or find a better #ifdef here. 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
Re: [Rcpp-devel] Error during wrapup
Le 29 mai 2014 à 00:35, John Mous john.mo...@gmail.com a écrit :
No luck with gctorture on yet, but I haven't run it for very long. It slowed
things down to a complete crawl, but maybe in the long run it can recreate
the problem faster than running the original code (about 12 hours, the
previous estimate of a day was too high), so this may still be worthwhile.
On a whim I did try changing the two instances of Shield to Armor this
morning (I was able to locate the code in wrap.h by digging around before I
saw your e-mail) and ran the original full code without gctorture on, and the
problem still persists.
Would not be enough, you'd also have to do:
x = ::Rf_setAttrib( x, R_NamesSymbol, names ) ;
so that the result of setAttrib gets protected even if it is a new SEXP, which
AFAIU can happen with setAttrib.
But I'm not sure this is the problem.
Romain
On Wed, May 28, 2014 at 3:44 PM, Romain Francois rom...@r-enthusiasts.com
wrote:
(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::mapstd::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::mapstd::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_traitstypename
T::second_type::rtype ;
ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
CTYPE* start = r_vector_startRTYPE(x) ;
size_t i =0;
std::string buf ;
for( ; isize; 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_stepsT( 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
Re: [Rcpp-devel] Error during wrapup
What OS are you running on (Mac, Linux, Windows)? I really can't tease
this out (with Mac + clang) thus far.
On Wed, May 28, 2014 at 9:56 PM, Romain Francois
rom...@r-enthusiasts.com wrote:
Le 29 mai 2014 à 00:35, John Mous john.mo...@gmail.com a écrit :
No luck with gctorture on yet, but I haven't run it for very long. It slowed
things down to a complete crawl, but maybe in the long run it can recreate
the problem faster than running the original code (about 12 hours, the
previous estimate of a day was too high), so this may still be worthwhile.
On a whim I did try changing the two instances of Shield to Armor this
morning (I was able to locate the code in wrap.h by digging around before I
saw your e-mail) and ran the original full code without gctorture on, and
the problem still persists.
Would not be enough, you'd also have to do:
x = ::Rf_setAttrib( x, R_NamesSymbol, names ) ;
so that the result of setAttrib gets protected even if it is a new SEXP,
which AFAIU can happen with setAttrib.
But I'm not sure this is the problem.
Romain
On Wed, May 28, 2014 at 3:44 PM, Romain Francois rom...@r-enthusiasts.com
wrote:
(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::mapstd::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::mapstd::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_traitstypename
T::second_type::rtype ;
ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
CTYPE* start = r_vector_startRTYPE(x) ;
size_t i =0;
std::string buf ;
for( ; isize; 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_stepsT( 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
___
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
