From jeff.a.ryan at gmail.com  Fri Jun 26 23:12:36 2009
From: jeff.a.ryan at gmail.com (J Ryan)
Date: Fri, 26 Jun 2009 16:12:36 -0500
Subject: [Rd] beginner's guide to C++ programming with R packages?
In-Reply-To: <13e802630906261243s7b071010ldfe6416e8c0ae304@mail.gmail.com>
References: <13e802630906261243s7b071010ldfe6416e8c0ae304@mail.gmail.com>
Message-ID: <D45F7FEE-3B7C-46A3-9BD8-7F98EE9316FB@gmail.com>

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



[Rd] beginner's guide to C++ programming with R packages?
J Ryan