R devel - Jun 2009 - beginner's guide to C++ programming with R packages?

Hello, again.

I'm interested to learn how programmers develop & test C/C++ code with
R packages in Linux.  I've been reading R source and the manual on
Writing R Extensions but there are just a couple of details I can't
understand.  I wish I could watch over a developer's shoulder to see
how people actually do this.

I've tested a bit.  I am able to take package.tar.gz file, open it up,
fiddle the source code, and then run

R CMD check package-dir

from the directory above "package-dir" ,

R CMD build package-dir

and

R CMD INSTALL

on the tarball that is produced. Then in R, I can load the package and use it.

That part is "all good", but somewhat tedious.  I don't want to
entirely recompile and reinstall the whole package just to test one
function.  I notice that R CMD check creates a new directory called
"package.Rcheck" and the shared objects and example code of the
package are in there.  Can I force R to use those *.so files instead
of the ones in /usr/lib/R ?


I also wonder "what is wrong with gprof?   In the Writing R Extensions
manual, it describes "oprofile" and "sprof" for Linux. I
will try
them, but they are unfamilar to me.  I've used gprof in the past in C
projects, and it is a pretty painless thing to add a compiler flag
-pg, run the program, and then review gmon.out.  The Writing R
Extensions manual does not mention gprof in its section on Linux, but
it does mention it under Solaris.  There is a somewhat ambiguous
statement:

3.4.2 Solaris

On 64-bit (only) Solaris, the standard profiling tool gprof collects
information from shared libraries compiled with -pg.

Does "(only)" here mean to differentiate Solaris from other Linux/Unix
systems?  Or does it differentiate 64bit Solaris from other Solaris?

But this draws me back to the basic question.  I don't want to run R
CMD INSTALL 20 times per hour.  How do developers "actually" test
their code?

pj
-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

> But this draws me back to the basic question. ?I don't want to run R
> CMD INSTALL 20 times per hour. ?How do developers "actually" test
> their code?
check out RUnit for tests.
http://cran.r-project.org/web/packages/RUnit/index.html

as for testing c++ code.  I have taken an approach which is probably
different than most.  I try to build my package as a c++ library that
can be used independent of R.  Then you can test your library with
whatever c++ test suite that you prefer.  Once you are happy, then
simply write bindings to convert R's SEXP objects into something
consumable by your library (usually this is just whatever the SEXP
points at). Using git submodules is a nice way to keep your library
separate from the R interface.

here's an example for you.
tslib, which has it's own c++ test suite (using boost.test):
http://github.com/armstrtw/tslib/blob/5b0fe2fc5ecb393d1dca097c2c19008227eb6c7e/test/test.cpp
and fts which simply implements wrappers to call
tslib:http://github.com/armstrtw/fts/blob/2b6cb4045f852211b9334b43730409a13dd353c0/src/interface.cpp

Also, check out Dirk's Rcpp package, which should make your life
easier if you use c++, and check out my RAbstraction package which
tries to do what Rcpp does using templates.

http://cran.r-project.org/web/packages/Rcpp/index.html
http://github.com/armstrtw/rabstraction/tree/master

-Whit

If your just looking to build and test a single function written in C/C 
++ you can try:

R CMD SHLIB my.c

Which will produce a object that can be loaded in R with 'dyn.load'.

A simple R script including dyn.load('my.so') with your basic tests  
can then be run with:

R --vanilla < my.R

HTH
Jeff

Jeffrey A. Ryan
jeffrey.ryan at insightalgo.com

ia: insight algorithmics
www.insightalgo.com

On Jun 26, 2009, at 2:43 PM, Paul Johnson <pauljohn32 at gmail.com> wrote:
> Hello, again.
>
> I'm interested to learn how programmers develop & test C/C++ code
with
> R packages in Linux.  I've been reading R source and the manual on
> Writing R Extensions but there are just a couple of details I can't
> understand.  I wish I could watch over a developer's shoulder to see
> how people actually do this.
>
> I've tested a bit.  I am able to take package.tar.gz file, open it up,
> fiddle the source code, and then run
>
> R CMD check package-dir
>
> from the directory above "package-dir" ,
>
> R CMD build package-dir
>
> and
>
> R CMD INSTALL
>
> on the tarball that is produced. Then in R, I can load the package  
> and use it.
>
> That part is "all good", but somewhat tedious.  I don't want
to
> entirely recompile and reinstall the whole package just to test one
> function.  I notice that R CMD check creates a new directory called
> "package.Rcheck" and the shared objects and example code of the
> package are in there.  Can I force R to use those *.so files instead
> of the ones in /usr/lib/R ?
>
>
> I also wonder "what is wrong with gprof?   In the Writing R Extensions
> manual, it describes "oprofile" and "sprof" for Linux.
I will try
> them, but they are unfamilar to me.  I've used gprof in the past in C
> projects, and it is a pretty painless thing to add a compiler flag
> -pg, run the program, and then review gmon.out.  The Writing R
> Extensions manual does not mention gprof in its section on Linux, but
> it does mention it under Solaris.  There is a somewhat ambiguous
> statement:
>
> 3.4.2 Solaris
>
> On 64-bit (only) Solaris, the standard profiling tool gprof collects
> information from shared libraries compiled with -pg.
>
> Does "(only)" here mean to differentiate Solaris from other
Linux/Unix
> systems?  Or does it differentiate 64bit Solaris from other Solaris?
>
> But this draws me back to the basic question.  I don't want to run R
> CMD INSTALL 20 times per hour.  How do developers "actually" test
> their code?
>
> pj
> -- 
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

On Fri, Jun 26, 2009 at 2:43 PM, Paul Johnson<pauljohn32 at gmail.com>
wrote:
> Hello, again.
>
> I'm interested to learn how programmers develop & test C/C++ code
with
> R packages in Linux. ?I've been reading R source and the manual on
> Writing R Extensions but there are just a couple of details I can't
> understand. ?I wish I could watch over a developer's shoulder to see
> how people actually do this.
>
> I've tested a bit. ?I am able to take package.tar.gz file, open it up,
> fiddle the source code, and then run
>
> R CMD check package-dir
>
> from the directory above "package-dir" ,
>
> R CMD build package-dir
>
> and
>
> R CMD INSTALL
For your purposes it is probably better to avoid building a new tar.gz
file and combine the last two steps as

R CMD INSTALL package-dir

The install process uses the make utility which will check which of
the object files need to be recompiled.  If you only modify one source
file it will be the only file recompiled.
> on the tarball that is produced. Then in R, I can load the package and use
it.
>
> That part is "all good", but somewhat tedious. ?I don't want
to
> entirely recompile and reinstall the whole package just to test one
> function. ?I notice that R CMD check creates a new directory called
> "package.Rcheck" and the shared objects and example code of the
> package are in there. ?Can I force R to use those *.so files instead
> of the ones in /usr/lib/R ?
>
>
> I also wonder "what is wrong with gprof? ? In the Writing R Extensions
> manual, it describes "oprofile" and "sprof" for Linux.
I will try
> them, but they are unfamilar to me. ?I've used gprof in the past in C
> projects, and it is a pretty painless thing to add a compiler flag
> -pg, run the program, and then review gmon.out. ?The Writing R
> Extensions manual does not mention gprof in its section on Linux, but
> it does mention it under Solaris. ?There is a somewhat ambiguous
> statement:
>
> 3.4.2 Solaris
>
> On 64-bit (only) Solaris, the standard profiling tool gprof collects
> information from shared libraries compiled with -pg.
>
> Does "(only)" here mean to differentiate Solaris from other
Linux/Unix
> systems? ?Or does it differentiate 64bit Solaris from other Solaris?
>
> But this draws me back to the basic question. ?I don't want to run R
> CMD INSTALL 20 times per hour. ?How do developers "actually" test
> their code?
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>