2

In order to avoid having to call print() to display graphics output, produced by ggplot2::qplot, I used @cbeleites' answer to this SO question: ggplot's qplot does not execute on sourcing. However, an attempt to run the script generates the following error:

Error in exists(name, envir = env, mode = mode) : argument "env" is missing, with no default

Here's the traceback output:

11 exists(name, envir = env, mode = mode)
10 find_global(scale_name, env, mode = "function")
 9 scales_add_missing(plot, c("x", "y"))
 8 ggplot_build(x)
 7 print.ggplot(p)
 6 print(p) at graphics.R#15
 5 qplot(data[["Project Age"]], data = data, geom = "histogram", binwidth = 1) at edaSourceForge.R#8
 4 eval(expr, envir, enclos)
 3 eval(ei, envir)
 2 withVisible(eval(ei, envir))
 1 source("~/diss-floss/analysis/edaSourceForge.R")

Finally, an additional note on how I run the script. I feel that it's important, as I believe the error is due to lack of visibility of a particular R environment. I run the script analysis/edaSourceForge.R in RStudio, with current working directory import:

source('~/diss-floss/analysis/edaSourceForge.R')

That doesn't seem to be a problem IMHO, as relative paths to the user-defined qplot() from the working directory and from the calling module match ("../utils/graphics.R"), but, of course, I might be wrong here.

My project's directory structure (~ is ruser's home directory):

+- ~/diss-floss (Project's root)
|- ...
|- import (current working directory)
|- analysis (edaSourceForge.R)
|- utils (graphics.R)
|- ...

The redefining function for ggplot::qplot is located in the graphics.R module:

qplot <- function (x, y = NULL, z = NULL, ...) {
  p <- ggplot2::qplot (x = x, y = y, z = z, ...)
  print (p)
}

Actual call to the user-defined qplot function is located in the edaSourceForge.R module

if (!suppressMessages(require(ggplot2))) install.packages('ggplot2')

source("../utils/graphics.R")

Since, as I said, I thought that the error is related to failure to find a particular R environment, I tried to use various environment-related R functions, but so far it wasn't helpful.

Your help and advice will be very much appreciated, as always!

Community
  • 1
  • 1
Aleksandr Blekh
  • 2,462
  • 4
  • 32
  • 64
  • 1
    I'm not sure that suggestion is all that great. One problem is that by nesting inside another function, you're changing the environment where the function will resolve variable names. Also other functions might expect `qplot` to actually return a `ggplot` object, but the `print` seems to strip the class information, or nest it inside a list. – MrFlick May 25 '14 at 02:42
  • @MrFlick: Thank you for the comment! In regard to the environment part of it, what function(s) could I use to fix the situation (`parentenv()`, etc.)? As far as the class information goes, I hope Hadley will chime in and clarify this point. Good thing is that "Plan B" is readily available - if all the above won't work, I'll just use `print()` calls. – Aleksandr Blekh May 25 '14 at 02:54
  • 2
    Use the `print()` calls! This is a written script. No point in being lazy. You can fix with a find/replace and be done with it. You're not really saving any time or keystrokes here. No need to mess with a function like that. It's just mean really. – MrFlick May 25 '14 at 03:00
  • 1
    But you can use things like `match.call` and `eval` to change the environment stack, but in this case that's totally overkill. – MrFlick May 25 '14 at 03:01
  • @MrFlick: Thanks! I already switched to using `print()`. I was not being lazy :-), I just thought that approach results in cleaner looking and, thus, more readable code. – Aleksandr Blekh May 25 '14 at 03:05
  • 1
    But anyone who actually knew anything about `qplot` reading the code would be confused (you're likely to be the only one who knows about the super-secret special definition). I would strongly recommend against changing the default behavior of such a standard function unless it is absolutely necessary. Or at least give the new version a different name. – MrFlick May 25 '14 at 03:10
  • @MrFlick: You're right, it makes total sense. Again, thank you for your help! Would you be so kind to take a quick look at my another SO question, also on R (http://stackoverflow.com/questions/23518121/implementation-of-simple-polling-of-results-file) - it had no feedback at all for quite some time... Thank you in advance for consideration! – Aleksandr Blekh May 25 '14 at 03:21
  • 1
    plus, if you `source` the file with the analysis code consisting `qplot`, you can use `source('~/diss-floss/analysis/edaSourceForge.R', print.eval=TRUE)` to get the interactive command-line-like printing behaviour without `print` nor any need to redefine `qplot` – cbeleites unhappy with SX May 25 '14 at 10:59
  • 1
    @cbeleites: That's very nice. It's good to know this. Thank you for the comment! R continues to amaze me with frequently overwhelming number of options for (approaches to) solving problems. I guess, it's both a blessing and a curse. – Aleksandr Blekh May 25 '14 at 12:00

0 Answers0