[R] Source awareness?

[Mark Dalphin]

Well, Bill, at risk of embarrassing myself, in my case, I have gone this 
sort of route out of plain wrong thinking. I took way too many years to 
learn about R packages; it seemed that hurdle was too high (it wasn't 
really) and so I followed the kinds of tricks that I needed to do in 
other languages. Sourcing sets of scripts was one of those tricks. 
Today, in most cases, I have found that when I travel this thinking 
path, I need to re-think and set up a package to do the work.

That said, I have on occasion dropped projects that I couldn't figure 
out a clean way to do within R. In those cases, it was simply easier to 
do in Perl, Python or even csh. Still, because R is so powerful, I find 
myself doing more and more of the basic parsing and processing within R 
and this leads to models of processing more similar to that using in 
those other languages. For example, making a "filter" (in the Unix 
sense) out of R turns out to be challenging to write in a concise manner 
('littler' solves this, but I have had some stability issues with it); 
I've standardised my filters now based on a generic Makefile, generic 
csh-script which is processed by sed, plus the actual R-code. It isn't 
really pretty, but it is smooth now. It didn't fit the standard R model 
of data and code in one directory, however, so it became a bit uglier.

The specific question below could be used to set up built in test 
functions, in a manner similar to what is done in Python. That is 
probably not the way to build in unit tests in R, but it is similar to 
the way I did it for years in other languages. Another place that had 
caused me trouble is when I have my data stored in one location (I work 
at a company where the laboratory deposits large data sets in a 
predefined set of locations and I don't have write access there) and my 
analysis scripts are in another location which is part of a CVS source 
tree. If someone else checks out my scripts from CVS, they need to run 
properly on data in the fixed location, regardless of where they started 
from, yet produce their results in script, not the data directory. We 
can all think of ways to make that work, however, one possible approach 
involves the script "knowing" where it is.

I'm not saying that any of this is "right", merely speculating on the 
cause of people thinking about "source awareness" as I have gone that 
route myself. And in some cases, as I said, it was wrong, and in other 
cases, less well defined (as I can't think of the specifics now), it was 
the only way I could find to make some code work (as I couldn't think of 
a solution, that code doesn't exist); this was usually code that was to 
be deployed for a user to run as a command line tool on a data set.

One particular use I would like for the path to the R script is for 
"reproducible research". I currently log many aspects of any particular 
processing run with "sessionInfo()" and other tools. However, the only 
way I have to record the actual script name is via CVS and a string 
within R, something like "$Id$" or "$RCSfile$". I usually end up 
processing that thru a 'gsub' to strip out the '$' so that the log file, 
which is stored in CVS as well doesn't get updated further. It is easy 
to have multiple versions of a script for processing some data; knowing 
the script name and directory path can help in logging what was done 
with some data.

Regards,
Mark

William Dunlap wrote:
> Over the years I've seen lots of requests concerning
> how to conveniently call scripts from other scripts.
> The S (R & S+) language is oriented towards functions,
> not scripts (or macros), and many of the requests are
> for things easy to do in functions (or packages of functions)
> but not in scripts.  Some would be easier if one used
> a package of scripts (built with the usual R package
> building tools).
>
> I'd like to know from people who do this sort of thing
> what pushes them toward using sets of scripts instead
> of functions.  I can think of several possible reasons
> but would like to hear from people who actually do this
> sort of thing.   E.g., is the clarity and concreteness
> of a script the important thing?  Is it difficult to
> make a package of functions?  Is it that people are
> used to another language where scripts or macros are
> the preferred way to go?  Or are other reasons?
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com  
>
>   
>> -----Original Message-----
>> From: r-help-bounces at r-project.org 
>> [mailto:r-help-bounces at r-project.org] On Behalf Of Ralf B
>> Sent: Wednesday, October 06, 2010 8:50 AM
>> To: r-help Mailing List
>> Subject: [R] Source awareness?
>>
>> Here the general (perhaps silly question) first: Is it possible for a
>> script to find out if it was sourced by another script or run
>> directly?
>>
>> Here a small example with two scripts:
>>
>> # script A
>> print ("This is script A")
>>
>> # script B
>> source("C:/scriptA.R")
>> print ("This is script B")
>>
>> I would like to modify script A in a way so that it only outputs 'This
>> is script A' if it was called directly, but keeps quiet in the other
>> case.
>>
>> In addition to that, is it possible to access the stack of script
>> calls from the environment?
>>
>> Ralf
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>>     
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>   

--