An other possibility is to insert new features in your package once you
feel pretty confident with your new code. "R CMD SHLIB myfile.c" will
build the SHared LIBrary and then load it in R by invoking
"dyn.load("myfile.so")" in an R console.Once you're satisfied with your code, just do as you did before - R CMD build mypkg". Cheers, Mathieu Le lundi 29 juin 2009 à 11:49 +0200, Douglas Bates a écrit : > On Fri, Jun 26, 2009 at 2:43 PM, Paul Johnson<pauljoh...@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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
