Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ggsave is not working when executed via Rscript. #2752

Closed
abeeCrombie opened this issue Jul 11, 2018 · 17 comments
Closed

ggsave is not working when executed via Rscript. #2752

abeeCrombie opened this issue Jul 11, 2018 · 17 comments

Comments

@abeeCrombie
Copy link

abeeCrombie commented Jul 11, 2018

sorry this is a bit above my pay grade but I just spent all afternoon trying to figure out why a script I run wasnt working. I loaded the new ggplot package yesterday and now all my scripts that I run via task scheduler dont execute the ggsave command.

here is the error message I got
Error in (function (file = if (onefile) "Rplots.pdf" else "Rplot%03d.pdf", : cannot open file 'Rplots.pdf' Calls: ggsave ... withVisible -> eval -> eval -> <Anonymous> -> <Anonymous> Execution halted

code works fine in Rstudio and R command but not via Rscript.exe.

I see there were some recent commits. Hopefully you guys are smarter than me to figure out why its not working

@baptiste
Copy link
Contributor

Sometimes I find that the pdf reader (e.g. Adobe reader) prevents other programs from changing the file; presumably some locking mechanism. Maybe try another filename.

@abeeCrombie
Copy link
Author

hi baptiste,

I was actually outputing a PNG file. I search all over stack/github for the issue. Tried many work arounds like setting image size, output type etc. but nothing worked. I uninstalled the new version of ggplot and reinstalled the old version and the problem was solved, so I am pretty sure it was something in the new update. There were a few changes made to ggsave function recently, perhaps that is why it doesnt work when running from Rscript.

As I said, it works fine when you execute in R or Rstudio, just not from Rscript.exe.

That error message was sent I think from the following documentation.,

https://stat.ethz.ch/R-manual/R-devel/library/grDevices/html/pdf.html

@clauswilke
Copy link
Member

Can you please provide a minimal reproducible example? From what you have provided in your issue description it's impossible to guess what's going on.

@abeeCrombie
Copy link
Author

abeeCrombie commented Jul 12, 2018

clauswilke, unfortunatly I already reinstalled the old version of ggplot2 on my machine so the issue is fixed.

What I can say is try running any script that creates a standard ggplot2 chart from a file, and do so running via task scheduler / Rscript.exe. That is basically what I did and still go the same error. The issue was only about saving the plot calling ggsave, ONLY from Rscript.exe

I am on a windows 10 machine. Hope that helps.

`
library(ggplot2)

set.seed(1234)
df <- data.frame(
sex=factor(rep(c("F", "M"), each=200)),
weight=round(c(rnorm(200, mean=55, sd=5), rnorm(200, mean=65, sd=5)))
)
p = ggplot(df, aes(x=weight)) + geom_histogram()
ggsave("C:/myDirectory/myFile.png", plot = p, width = 5, height = 5, units = "in")

`

@clauswilke
Copy link
Member

Could you run a script that contains the following one line of code and see if it triggers the error?

grDevices::dev.set(1)

@clauswilke
Copy link
Member

Also, I assume that as a workaround, adding the following to the script should prevent the error:

setwd("C:/myDirectory/")

I don't run Windows, so I can't debug this directly.

@abeeCrombie
Copy link
Author

setting the directory hasnt been a problem, as long as the output file has a complete path + file name.

Its probably more related to the dev.set(1).

I just ran on a version of R with ggplot2 new version and with the older version, and got the same results. Old ggplot 2 worked, new ggplt didnt

If I set the grDevices::dev.set(1) the file does not run via Rscript.exe, even using the old ggplot2 package. Hope that is clear.

Sorry I can't be of more help. But let me me know if there is something else I can do to troubleshoot this isse

the full code uused to produce the file

`library(ggplot2)

set.seed(1234)
df <- data.frame(
sex=factor(rep(c("F", "M"), each=200)),
weight=round(c(rnorm(200, mean=55, sd=5), rnorm(200, mean=65, sd=5)))
)
p = ggplot(df, aes(x=weight)) + geom_histogram()
#grDevices::dev.set(1)
ggsave("D:/RFiles/myFile.png", plot = p, width = 5, height = 5, units = "in")`

@clauswilke
Copy link
Member

@abeeCrombie We need to be systematic about things. Please try the following two tests:

  1. Make a file that contains one single line of code, grDevices::dev.set(1), and nothing else. What happens when you run this file? Do you get any error messages? If yes, please let me know what they say.

  2. Please take the original script that caused you trouble, add setwd("C:/myDirectory/") (or whatever the correct working directory is for your project) to the top of the script, and run with ggplot2 3.0.0. Does this change anything? I realize that you can save files directly with absolute paths. That's not what this is testing.

@clauswilke
Copy link
Member

Actually, and one more test. What happens if you place pdf(NULL) immediately before the ggsave() command. Does this fix things?

@isteves
Copy link

isteves commented Jul 12, 2018

@clauswilke I ran a few tests on my Windows machine with the script above (& @dpseidel 's guidance). Hopefully this can help clarify the problem discussed above:

When I ran Rscript myscript.r using the script above, I got the following outputs to my folder:
image 1

Using R CMD BATCH myscript.R, I get 2 extra files
image

For both, I get the same behavior with grDevices::dev.set(1) and pdf(NULL)

  • grDevices::dev.set(1) in myscript.r gives me the message null device 1 but no error
  • pdf(NULL) gives me the same output minus the RPlots.pdf file

@dpseidel suspects that it might be something to do with looping/the task scheduler, possibly unrelated to Windows/Mac (I think she got similar results)

@dpseidel
Copy link
Collaborator

Admittedly this isn't directly reproducing the creation of an .exe file and use of a task scheduler, so hopefully it's not a red herring, but I'm getting the same behaviour when testing with ggplot2 2.2.1: without pdf(NULL), Rplots.pdf is created from terminal even when a non-pdf driver is called; admittedly I don't understand why this happens, it does not when running from R or Rstudio. So perhaps this error isn't related to the new version. The original error suggested to me that the graphics device was trying to write Rplots.pdf but couldn't, potentially because it was still in use from an earlier ggsave process despite the fact that a file name and non-pdf device is specified? Hard to know without a simple reprex.

@abeeCrombie
Copy link
Author

my mistake. That simple script is working on both ggplot versions.
It must be something with my specific plot that isnt working. I will try to show a reproducible code, it just a long script & complicated chart and I didnt think it mattered

Sorry to bother everyone.

@abeeCrombie
Copy link
Author

or magically the windows update my PC did last night solved the issue ;-)

@dpseidel
Copy link
Collaborator

Great, closing this now.

@clauswilke
Copy link
Member

I made a PR that will likely fix this issue. It would be great if somebody could test. See here:
#2363 (comment)

@mfansler
Copy link

I just want to confirm that @clauswilke's PR(2758) fixes a related issue I am seeing with ggsave as of ggplot2 v3.0.0. Namely, on CentOS 7 lacking an X11 device, a common workaround is to set options(bitmapType = 'cairo'). However, when ggsave v3.0.0 restores the previous device, it attempts to default back to an X11 device, which results in the error:

Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize,    : 
  unable to start device X11

A simple workaround is to set an available device before calling ggsave, for instance,

options(bitmapType = 'cairo', device = 'png')

Not that big a deal, but having @clauswilke's fix merged to master would be preferable.

@lock
Copy link

lock bot commented Jan 26, 2019

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/

@lock lock bot locked and limited conversation to collaborators Jan 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants