initial plugin support

[eddelbuettel]

This now works:

edd@brad:~/git/rcppsmc(feature/plugin)$ Rscript -e \   # line breaks just for display 
             'Rcpp::cppFunction("bool foo(arma::vec x) { \
                    return smc::stableLogSumWeights(x); }", \
            depends=c("RcppSMC"))'
edd@brad:~/git/rcppsmc(feature/plugin)$ 

But the stub RcppSMC.h is of course too bare. So @mlysy @adamjohansen : what classes should we expose / headers should be include? All of tem?

Also: @mlysy if you have a better example handy ... just post it here. I'll include it proper copyright attribution to you.

[adamjohansen]

Good stuff.

I haven't thought deeply about this because I still think of the C++ end as being the main business with the R "wrapper" as something of an afterthought when writing code (old habits...), but it would probably be useful to make most if not all of the classes within the library available unless there's a compelling reason not to. Certainly the sampler and particle classes will be essential for it to be much use.

@eddelbuettel : Might this be worth including in the GSOC wishlist?

[eddelbuettel]

Me too. But R as a REPL around C++ code has its charms.

Both modes can coexist nicely too though. So I guess one vote for "all header" ?

[adamjohansen]

I see very little disadvantage with all header in this situation, objectively, and I'm certainly not voting against it. I was just (aiming at) explaining my rather naive view of what would be needed not suggesting my anachronistic worldview was a good one. Hopefully @mlysy might have a more nuanced view of what it would be most useful/essential to have access to.

[mlysy]

I've never actually used or created Rcpp plugins -- just the Rcpp::depends mechanism which I assumed would give access to the whole inst/include folder. But it makes sense that some of the header files there may be of limited value to others. I'm thinking of those for specific examples, e.g., blockpfgaussianopt.h, LinReg_LA_adapt.h, etc.

Then again, my Rcpp::depends test (see end of #29) essentially copied pfLineart.cpp but referred to inst/include/pflineart.h, so in some sense the examples could be useful for testing...

Overall though, my personal opinion is that the example headers are not broadly usable enough to export, and can easily be copy-pasted for testing purposes. So I guess I'd only include adaptMethods.h, history.h, moveset.h, population.h, sampler.h, smc-exception.h, smctc.h, staticModelAdapt.h.

[eddelbuettel]

That's a useful set to start, I agree.