2

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.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
Ray
  • 3,137
  • 8
  • 32
  • 59

3 Answers3

3

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.

Joshua Ulrich
  • 173,410
  • 32
  • 338
  • 418
  • 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 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 Oct 28 '10 at 19:12
  • After a little searching on [rseek.org](http://www.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
2

You can edit the body directly, discussed here:

What ways are there to edit a function in R?

Community
  • 1
  • 1
mdsumner
  • 29,099
  • 6
  • 83
  • 91
0

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.

Steve Lianoglou
  • 7,183
  • 2
  • 25
  • 21
  • 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 01: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 07:30
  • 1
    @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
  • @ucfagls: In this situation, I don't really buy the whole "IT Admin policy" thing. This particular package has no C code and is GPL, so should be particularly easy to build. What IT policy doesn't allow people to add things to their own home directory? It's pretty easy to make an R library in your home directory that you can install custom packages into and use "normally." – Steve Lianoglou Oct 28 '10 at 14:06
  • 1
    @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
  • @ucfagls: I actually don't know much about the building packages on Windows aside from it being a pain in the butt. I can easily buy the fact that these are legitimate problems, and am also quite happy to learn about other ways to work around these issues ... on the other hand, one could actually just sourceDir() [see the Examples section in ?source) an appropriately modified PerformanceAnalytics2/R directory and skip loading packages/fix/loadInNamespace junk altogether :-) – Steve Lianoglou Oct 29 '10 at 03:45