Hi Steve, Thanks for the nicely detailed email which was very well reasoned. I'll be brief as I just got back from Europe and am a little fried from travelling. But if I don't reply now it may fall to the wayside...
On 4 July 2011 at 10:09, Steve Lianoglou wrote: | On Mon, Jul 4, 2011 at 4:00 AM, Dirk Eddelbuettel <[email protected]> wrote: | Yeah, I'm actually writing a third/custom wrapper that talks straight | to the "core" shogun c++ library (not a SWIG wrapped something). [shogun details omitted] | With my library, it's more of what an R user would expect, eg: | | svm <- SVM(traindat, trainlab, kernel='gaussian', width=40, C=10) | predict(svm, ...) Totally agreed. That's what we'd want in the long run! | > I guess you also looked into altering their wrapper? | | I did -- I also thought about just wrapping their wrappers, but (i) I | don't think I could make it as flexible as I would like; (ii) there is | actually some problem with swig in R-land that (I think) causes a Correct. The one dude working on Swig for R actually used it for QuantLib so he get very deep into R internals mojo. That said, I only once got his R/QuantLib SWIG bindings built, and he seems to float away from maintaining for extended periods. So I don't do Swig either -- hence Rcpp and possibly more manual approaches. | > You could use our XPtr class instead too. I do so in RcppDE to wrap a | > pointer to a user-supplied C function. | | I do use it (XPtr mojo) when I'm "unwrapping" a pointer to an object | that was sent back to C++ from R, but I don't know how to use it the | first time -- ie, when I finish building the shogun object for the | first time and package it up to send back to R-land (for later use) | since I need this custom 'on delete' function. | | I poked around in the RcppDE source but couldn't find an example of | that particular use case -- perhaps I missed it? It is in src/evaluate.h and contained in a pretty small class layer that generalises how a user-defined utility function is being brought in. Either as an R function, or via XPtr as a C function. Might well be too simple an example for you. Also no ref counting and all that. | > But where would the logic to deal with 'SomeShogunObject' come from? | | I've already written it, the "destruction" of all shogun object are | the same, and is already written in my `_shogun_ref_count_down` | function I am currently registering like so: | | R_RegisterCFinalizer(xp, _shogun_ref_count_down) Ack. If the XPtr leaves the object alone (as it should) then R_RegisterCFinalizer may be appropriate. Might be best to test on a really small and self-contained example. | > Because the persistence stuff is harder. It helps to know the other projects | > internals well enough. So my advice would be to keep the fancy stuff for | > 'version 2.0'. Unless you have plenty of time to learn and try fancy things. | | Yeah -- it's good advice, actually ... Same for external pointer objects and getting lifetimes and memory management right. If you get the basics right, the rest 'should' be easy :) | Would it be possible to overload the XPtr::setDeleteFinalizer function | so it has a version that takes a function pointer? So I could do | something like: | | Rcpp::XPtr<SomeShogunObject> so(new SomeShogunObject(what,ever), false); | so->setDeleteFinalizer(&my_finalizer_function); | | (I don't know if that's the correct syntax to pass functions around(?)) Dunno. Possibly. Romain may know, but not sure if he currently reads the list. | > In a way Rcpp modules is orthogonal, and also more restricted (but easier for | > simple connections to libraries). | | Indeed -- as I was reading over it more, I don't think RcppModules | would fit here since (i) there are lots of overloaded methods for | shogun classes I'd need to "wire"; and (ii) shogun has pretty deep | class hierarchies (and I think "inheritance" is part of the "Future | extensions" of the RcppModules, anyway). Correct on all counts. | > Hope this helps, Dirk | | Yup -- thanks for taking the time to chew on the email. Pleasure! It is pretty neat to see Rcpp pop up in exciting places like this. Cheers, Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.com _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
