On Sun, Jan 9, 2011 at 1:52 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
> > On 9 January 2011 at 12:41, Douglas Bates wrote: > | I'm sorry to say that I will need to abandon the debugging of this. > | > | I have converted the code in Rcpp/R/exceptions.R to using a R > | functions with a common environment to keep track of the error > | conditions. I can get access to those from within the C++ code > | through values established during the execution of R_init_Rcpp but the > | next time I try to use them in the C++ code they are gone, although > | they are still there are the R side. It is bizarre - I have no idea > | what is going on. > | > | Anyway, I need to turn my attention back to lme4a. I am giving a > | short course starting tomorrow and must have a version of lme4a that > | can compile and run. I have been converting it to use Rcpp Modules > | and it looks like I will need to strip all that code out. I hope that > | the problems with memory protection are isolated in the Modules > | sections of Rcpp. > > Thanks for all your help on modules. > > You have been pushing this harder and further than anybody else, and it is > too bad that it turned out to be inapplicable for your use case, at least > in > the current state of affairs. > > Modules work for my use case. I may upload the wrapping of Boost Date_Time > to > CRAN one of these days. Should write some more documentation though. > Writing that small package was a rather pleasant experience. > It seems to me that memory corruption issues are not a matter of "use case" and fixing them should be given the highest priority. Am I missing something here? > > In case anybody wants to look at that, it is on R-Forge inside the Rcpp > repo. > > 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
