Raw Message

Message-ID: <4B47CD93.6070702@bitwrit.com.au>
Date: 2010-01-09T00:28:03Z
From: Jim Lemon
Subject: how to organize a lot of R source files
In-Reply-To: <07e7f36b7d984e7c4af35f9a1e611ff6.squirrel@webmail.andrew.cmu.edu>

Hi Jeff,
Your request makes a lot of sense. I often modify files in the packages 
I maintain, typically by loading the package, then working on a copy of 
the function, continually "sourcing" the new code until it works 
correctly, and then checking and building the package. Apart from the 
official packages I maintain, I keep a few local packages with odd 
functions that I don't think are worth uploading to an already loaded 
CRAN. This shell script can be used to automate the building of a package.

#!/bin/sh
cp $1 $2/R
if R CMD check $2; then
  R CMD build $2;
  R CMD INSTALL $3;
else
  echo "Problem with R check of $2"
fi

If I had modified the "clinsig.R" file in the clinsig package, I could 
call this script like this:

Rpackage /home/jim/R/clinsig.R /home/jim/R/clinsig clinsig_1.0-1.tar.gz

and it would rebuild the package with the new function. Because I 
usually keep the files I am modifying in /home/jim/R I could simplify 
the command line a bit. This may seem like a lot of work, but when I 
worked out a way to get a function to check the timestamp of its source 
file and compare it against the timestamp of the latest package:

if(max(file.info(system("find /home/jim/R -name 'clinsig.R'
  -type f",intern=TRUE))$mtime) >
  max(file.info(system("find /home/jim/R -name 'clinsig_*'
  -type f",intern=TRUE))$mtime))
  source("/home/jim/R/clinsig.R")

a lot of hard coding of file locations ends up in your function file.

Jim