Dear Dr. Wolf:
I understand your concern that the mechanics of writing an R
package can be difficult. It was hard for me when I started.
I came to embrace it, because I actually got more done in less
time doing so. In my previous experience, as code I wrote got more
complicated, it became more difficult to find bugs. Then I started
writing R packages, beginning by writing the documentation including
examples that became unit tests
(http://en.wikipedia.org/wiki/Unit_testing). Then I wrote code to the
test. For example, I would first write function A. Then I write B that
calls A. Then I write C that also uses A. In the process of writing C,
I modify A. When I run "R CMD check", I learn that my change to A broke
B. I learn that instantly. Without the R package discipline, it could
be 6 months before I learned that I had a bug. Then finding and fixing
it was very difficult and time consuming. Now, whenever I stumble over
a new bug, I add it to my tests in the "examples" on the help page.
People tell me I shouldn't put too much in the "examples", because the
complicated examples can confuse users. Fortunately, with "\dontshow",
not all "examples" need to be shown to the users of the help page.
By using the R package development process, I get more
trustworthy software -- fewer bugs -- with less time, work, blood, sweat
and tears. The savings comes from less time spent debugging. Moreover,
the resulting software is generally better designed, because the process
of writing the standard help page with the standard parts helps me think
through what each function should do and how they all should work
together. I save so much debugging time that I essentially get the
documentation for free. This makes it much easier to share my code with
others -- and to revisit code I wrote previously but had forgotten many
details.
I started writing Fortran in 1963, and I had many bad software
development habits. I had read a lot about software productivity and
the virtues various software productivity practices. It was only when I
started writing R packages that I began to actually use those
recommended practices productively.
I've never read the entire "Writing R Extensions" manual, though
I have used it repeatedly as a reference. Fortunately, there are
simpler introductions to R package development. Have you checked the
"contributed" page on CRAN for the word "package"? I just found 9
matches, including 4 documents on creating R packages, two in English,
one in French, and one in Italian. Leider, kein Deutsch.
Hope this helps.
Spencer
On 2/11/2011 3:03 AM, Barry Rowlingson wrote:
On Fri, Feb 11, 2011 at 7:52 AM, Dr. Michael Wolf<m-w...@muenster.de> wrote:
Dear R colleagues,
is there an easier way to write R packages for the own use - without RTools
and TeX?
There are simpler ways of maintaining R source code than building
packages. I bashed out a quick way of keeping code in directories as
source and reading in on demand. All you need is two functions:
import<- function(dir){
e = attach(NULL,name=dir)
assign("__path__",dir,envir=e)
reload(e)
invisible(e)
}
reload<- function(e){
path = get("__path__",e)
files =
list.files(path,".R$",full.names=TRUE,recursive=TRUE,ignore.case=TRUE)
for(f in files){
sys.source(f,envir=e)
}
}
Now put the source code in some folder/directory somewhere. You can
even make subdirs if you wish to organise it that way.
I've got some .R files in "lib1". I do;
> import("lib1")
and that runs 'source' on all the .R files in there and loads them
into position 2 on the search list. ls(pos=2) shows them.
If you edit the source code, just do reload(2) (assuming it hasn't
moved because you've loaded another package) and your stuff will be
updated. It just sources everything again. Do detach(2) to get rid of
it.
If you want to distribute your code in "source" format, just make a
zip or tar of the folder with the code in, and make sure your users
have the import and reload functions (I should probably put them in a
package one day...).
To distribute in 'binary' format, do an import, and then save as .RData:
> save(list=ls(pos=2),file="lib1.RData", envir=as.environment(2)) #
not well tested....
Then your users just need to attach("lib1.RData") to get your functions.
Now this scheme could get more complex - for example it doesn't deal
with C or Fortran code, or documentation, or tests, or examples, or
version numbering. Adding any of those would be pointless - if you
want any of that either use packages and learn to write R docs
(roxygen helps) or add it to my code yourself. You'll end up
rebuilding the R package system anyway.
Hope this helps. Doubtless someone else will come up with a simple
way to build proper packages without all the bondage and discipline
that annoys you.
Barry
______________________________________________
R-help@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@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.
