Take the 2-minute tour ×

I am looking for a way to embed the fix() function within a script. Basically, here's what I'm currently doing:

  1. I load a certain package. For example, library(PerformanceAnalytics)
  2. I call the fix() function to edit a couple functions within the loaded package. Example, fix(VaR).
  3. Then, using R's built-in editor, I copy-paste my function over the one originally loaded from the package.
  4. Finally, I source in my .R script which calls the above functions I fixed and performs the computations I need.

Essentially, I'd like to streamline Step 3 above. Rather than having to manually type fix(function) and copy-paste over the original functions within the loaded package, I'd rather just have it done within a script I source.

Is there anyway to accomplish this?

FYI, I have reached out to the package's creator and loading a re-compiled version of the package with my modified code is out of the question.

share|improve this question
in step 1, did you mean "library(PerformanceAnalytics)"? –  Spacedman Oct 28 '10 at 7:26
@Spacedman: fixed –  Richie Cotton Oct 28 '10 at 9:38
add comment

3 Answers

Maybe source your functions and then use assignInNamespace?

EDIT #1:
The above won't work because assignInNamespace doesn't alter objects that have been exported. Instead,

  1. put your functions in a file (foo.R)
  2. load the package
  3. then source(foo.R) or sys.source(foo.R, envir=attach(NULL, name="myenv"))

Your functions will be higher up on the search list if you load them after the package, so R will find them before getting to the package's functions with the same name.

EDIT #2:
I didn't realize VaR called unexported functions in the namespace. That's why EDIT #1 doesn't work. To get it to work, you would need to explicitly reference all unexported PerformanceAnalytics functions used in VaR (e.g. change VaR.Gaussian to PerformanceAnalytics:::VaR.Gaussian).

See this post on R-devel for a couple other approaches. I couldn't quickly get Prof. Ripley's solution to work (I get the same error as in EDIT #1) and I didn't try Gabor's solution.

share|improve this answer
Here's what I did: VaR.mod <- function(...) {...}. Then, assignInNamespace("VaR",value=VaR.mod,ns="PerformanceAnalytics") Then, I loaded my pkg library(PerformanceAnalytics) . Now, when I call the VaR function, it doesn't seem to work because many of the other nested functions within it are under the "PerformanceAnalytics" environment. Am I missing something? –  Ray Bao Oct 28 '10 at 18:40
assignInNamespace doesn't alter functions that have already been exported, so it won't work. See my edit for another alternative. –  Joshua Ulrich Oct 28 '10 at 18:55
Thanks for getting back to me Joshua. Unfortunately, I tried the above and it doesn't seem to work. My edits are very simple and the functions still call other functions within the package (in my case, one example would be the "VaR.Gaussian" function, which I do not want to alter). So when I go to call VaR(...) for example, it says that it cannot find VaR.Gaussian and errors out. –  Ray Bao Oct 28 '10 at 19:12
After a little searching on rseek.org, I can see why Prof. Ripley and Gabor said it is hard not a good idea to modify functions with a namespace. See my edits. –  Joshua Ulrich Oct 30 '10 at 11:53
add comment

You can download the packages source from CRAN. Edit the function (it will be found in PackageName/R), then install this package into R and just use it that way.

You can even change the package name in the DESCRIPTION file ... call it "PerformanceAnalytics2", then in R you just library(PerformanceAnalytics2) and use it as you would the original package.

share|improve this answer
He explicit said he couldn't do this: "a re-compiled version of the package with my modified code is [sic] out've the question." –  Joshua Ulrich Oct 28 '10 at 1:10
Then quite what the question is is unclear. The package PerformanceAnalytics is on CRAN with a GPL license - if that's what we're talking about here then the only barrier to modification is the user's ability to set up an R package build environment, which is well-documented. Why is it out of the question? –  Spacedman Oct 28 '10 at 7:30
@Sapcedman; not everyone can install the R package build tools - local IT Admin policy etc. Also, there are valid R ways of manipulating the R code within packages for just such minor changes. The OP just needs to move beyond the fixation with fix(), and automate the process as per Joshua's answer, for example. –  Gavin Simpson Oct 28 '10 at 11:20
@Joshua: I see -- somehow I joined that part of the sentence with its first half and thought he was trying to get the author of the package to recompile it for him, or something ... it wasn't clear. –  Steve Lianoglou Oct 28 '10 at 14:03
@Steve: It's been a long time since I used Windows, but I didn't think you could build Windows binaries (R ones - even without compiled code) without the R build toolchain? Maybe this is easier now with R being used to replace Perl etc, but there are still requirements (TeX for example). Some of these tools might be provided with installers that won't run in some closed IT shops. Whether you buy it or not, people do have such problems, and as there are R functions to allow them to work round those problems they can be promoted. Note my comment was in response to Spacedman, not your answer. –  Gavin Simpson Oct 28 '10 at 14:27
show 2 more comments

Your Answer


