Re: [Rd] regenerate Rscript after moving R installation
Murray, On Sep 24, 2013, at 2:18 AM, Murray Stokely wrote: > Simon, do you have some examples of packages with this attribute? As Brian pointed out, some of them concern linking (I'm typically worried about OS X and Dirk has fixed Rcpp there), but there are also others that store package paths in variables or in supplementary files. Others store system paths as well (i.e. you can move R but not any dependent resources). Unfortunately this is hard to detect, because of lazy-loading (all lazy-load files have the paths baked in the namespace, so they will always include the path that you installed to originally) -- one example of a hard-coded variable is race. > Removing the hard-coding of paths in base R and Rscript is one of the many > local patches we've maintained in the R I use at my workplace since at least > the R 2.5 days. We do this to enable us to send R and all its dependencies > off to build farms, unit test clusters, and production clusters for running > parallel computations among other use cases where the path of the build > server is irrelevant to the server running the R code. > > I don't recall running into any packages where an absolute path from the > build host was hard-coded into the package such that we had to update code to > get it to work. But maybe I'm just not using those packages. > It is hard to detect. The linking ones typically fail right away, but those with hard-coded paths inside may fail only in some use cases. Cheers, Simon > - Murray > > > On Sat, Sep 21, 2013 at 6:45 PM, Simon Urbanek > wrote: > I forgot to mention that some packages bake-in paths as well, so even if you > fix both R and Rscript, it will still not work in general. > > On Sep 22, 2013, at 3:42 AM, Simon Urbanek > wrote: > > > On Sep 21, 2013, at 8:43 PM, Tobias Verbeke > > wrote: > > > >> L.S. > >> > >> In this bug report > >> > >> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14493#c1 > >> > >> it is mentioned that after moving an R installation > >> one should regenerate the Rscript executable. > >> > >> Is there an easy way to do so (after an R installation has been > >> moved)? > >> > > > > You cannot move installed R. Once you run make install, there are several > > places in which paths get baked in - mainly Rscript and the R start script. > > What I typically do for deployment on the Labs machines is to use make > > install rhome= where is some path that I can always create a > > symlink in (I also use DESTDIR so that path doesn't actually need to exist > > on the build machine and it avoid polluting --prefix which is not needed). > > That way you can move R wherever you want as long so you keep that one > > symlink up to date. > > > > Cheers, > > Simon > > > > > >> I have not found any information in the R installation and > >> administration manual. > >> > >> Many thanks in advance for any pointer. > >> > >> Best wishes, > >> Tobias > >> > >> P.S. The background to this question is the usage of Rscript > >> calls in the Makevars files of some R packages on CRAN, so > >> the 'broken' Rscript prevents installation of certain R packages. > >> > >> -- > >> > >> Tobias Verbeke > >> Manager > >> > >> OpenAnalytics BVBA > >> Jupiterstraat 20 > >> 2600 Antwerp > >> Belgium > >> > >> E tobias.verb...@openanalytics.eu > >> M +32 499 36 33 15 > >> http://www.openanalytics.eu > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistency/bug in recordPlot/replayPlot
https://stat.ethz.ch/pipermail/r-devel/2013-September/067563.html
Same instructions still apply -- this is a self-subscription list.
M
On Sep 24, 2013, at 0:42, Eric Malitz wrote:
> take me off here
>
>
> On Mon, Sep 23, 2013 at 10:31 PM, Gabriel Becker wrote:
>
>> Paul,
>>
>> Thanks for the response.
>>
>>
>> On Mon, Sep 23, 2013 at 7:43 PM, Paul Murrell >> wrote:
>>
>>>
>>> par(bg="white")
>>>
>>> plot(1:10)
>>> recplot = recordPlot()
>>> png("bgreplay.png")
>>> replayPlot(recplot)
>>> dev.off()
>>>
>>> Would that satisfy your use case ?
>>
>> Unfortunately it does not, as my use-case is in a caching/dynamic document
>> setting. Thus I am capturing plotting from evaluation of an arbitrary piece
>> of code within a series of such evaluations. I cannot be guaranteed the
>> code doesn't call dev.off() or explicitly create a new device and I
>> wouldn't want to clobber any non-white background set in previous code.
>>
>> I thought putting par(bg="white") after the call to png() (or bg="white" in
>> the png call) might work, but it appears that replayPlot is actively
>> setting the background to transparent so that didn't fly.
>>
>> Any other ideas or advice would be appreciated.
>> ~G
>>
>>
>>>
>>> Paul
>>>
>>>
>>> On 09/14/13 09:17, Gabriel Becker wrote:
>>>
Hey all,
I've run accross what seems to be a bug in the recordPlot/replayPlot
functionality (or at least the lack of a feature which seems pretty
reasonable to expect to be there)
When drawing to a file-based graphics device (I tested with png()), the
file resulting from calling replayPlot on a recordedplot object does not
contain an identical image to that captured by the same graphics device
when used on the plot that was recorded.
Reproducible (at least for me on linux) example:
png("noreplay.png")
plot(1:10)
dev.off()
plot(1:10)
recplot = recordPlot()
png("withreplay.png")
replayPlot(recplot)
dev.off()
The resulting png files are attached. You'll notice that the
>> noreplay.png
has the expected white background, while withoutreplay.png has no/a
transparent background.
This seems likely to be related to the note in ?dev.print :
"
Note that these functions copy the _device region_ and not a plot:
the background colour of the device surface is part of what is
copied. Most screen devices default to a transparent background,
which is probably not what is needed when copying to a device such
as âpngâ.
"
Now this may be as intended because it is "not allowed" to draw
recordedplot objects to devices other than the one they were recorded on
(AFAIK the primary purpose of recordedplot objects is fast redraws
internally), but alas that is what my use-case calls for. Furthermore,
>> I
don't think I'm alone in thinking wistfully about how useful it would be
to
have an actual, transportable object class which can fully represent an
>> R
plot in any R-based context.
I'm pretty sure I can compile a patch which does this if it would be
considered, though there would be a delay of a week or two before I
>> could
burrow out from under the mound of other stuff I currently need to be
doing
sessionInfo below, and I have also confirmed that the behavior remains
unchanged in the current trunk.
Thanks,
~G
sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.0.1 tools_3.0.1
__**
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/**listinfo/r-devel<
>> https://stat.ethz.ch/mailman/listinfo/r-devel>
>>> --
>>> Dr Paul Murrell
>>> Department of Statistics
>>> The University of Auckland
>>> Private Bag 92019
>>> Auckland
>>> New Zealand
>>> 64 9 3737599 x85392
>>> p...@stat.auckland.ac.nz
>>> http://www.stat.auckland.ac.**nz/~paul/<
>> http://www.stat.auckland.ac.nz/~paul/>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>>
>>[[alternative HTML version deleted]]
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>[[alt
Re: [Rd] Capture output of install.packages (pipe system2)
On Mon, Sep 23, 2013 at 6:50 PM, Duncan Murdoch
wrote:
> x <- system2("Rscript", "-e \"install.packages('MASS',
> repos='http://probability.ca/cran')\"", stdout=TRUE, stderr=TRUE)
Thank you, this suggestion seems to work (although I agree that
starting 3 procs to install a single package seems suboptimal). One
additional question: is it safe to assume that the "Rscript"
executable can always be found by the R process (cross platform), or
do I need to modify the example in case Rscript is not in the system
search path?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capture output of install.packages (pipe system2)
You shouldn't assume - use file.path(R.home("bin"), "R")
Hadley
On Tue, Sep 24, 2013 at 9:37 AM, Jeroen Ooms wrote:
> On Mon, Sep 23, 2013 at 6:50 PM, Duncan Murdoch
> wrote:
>> x <- system2("Rscript", "-e \"install.packages('MASS',
>> repos='http://probability.ca/cran')\"", stdout=TRUE, stderr=TRUE)
>
> Thank you, this suggestion seems to work (although I agree that
> starting 3 procs to install a single package seems suboptimal). One
> additional question: is it safe to assume that the "Rscript"
> executable can always be found by the R process (cross platform), or
> do I need to modify the example in case Rscript is not in the system
> search path?
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capture output of install.packages (pipe system2)
On Mon, Sep 23, 2013 at 6:34 PM, Simon Urbanek
wrote:
> On top of my head for full capture I can only think of custom C code that
> will re-direct stderr/out FDs as desired (it's really trivial to re-direct to
> files, for dynamic capture it's a little more involved but there are examples
> that do that).
I had secretly been hoping that system2("whoami", stdout=stdout(),
stderr=stderr()) would capture output streams from the child process
and concatenate to stdout() and stderr() in the parent just as if they
were sent by cat("foo", file=stdout()) and cat("bar", file=stderr())
such that they could be captured from sink() in the parent. However
thinking twice about this, it is probably very difficult to implement
without threads. The event loop in the parent process would need to
poll for buffered output in the child while waiting for it to return
or something.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] recordPlot() on non-interactive graphics device?
Hi.
Q. Is there a way to record a plot using grDevices::recordPlot()
without opening an interactive (=visible GUI window) graphics device
(not even for a flash of a second)?
Related: help("recordPlot", package="grDevices") says:
"These functions record and replay the displaylist of the current
graphics device."
Is the intention that recordPlot() should be able to record from _any
type_ of graphics device, or only for _interactive_ ones? For
instance,
windows(); plot(1:10); g <- recordPlot(); dev.off();
x11(); plot(1:10); g <- recordPlot(); dev.off();
Cairo::CairoWin(); plot(1:10); g <- recordPlot(); dev.off();
all produce 'recordplot' objects that replot the figure with
replayPlot(g), whereas for instance
png("foo.png"); plot(1:10); g <- recordPlot(); dev.off();
pdf("foo.pdf"); plot(1:10); g <- recordPlot(); dev.off();
produce "empty" replayPlot(g) outputs.
Q. It it just a coincident that it appear that
recordPlot()/replayPlot() only works for
grDevices::deviceIsInteractive() graphics devices? If not, should
?recordPlot clarify that "These functions record and replay the
displaylist of the current [interactive] graphics device."?
Q. ...or is just the fact that currently png(), pdf() etc. won't
populate "the displaylist" (whatever that is), but if they would, then
recordPlot()/replayPlot() would indeed generate an non-empty plot? If
so, a note like "Note, recordPlot() will often record an empty plot on
non-interactive graphics devices as they do not populate the
displaylist." may be add to the help.
Thanks,
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] recordPlot() on non-interactive graphics device?
Henrik,
This works for me:
> png("test.png")
> dev.control(displaylist="enable")
> plot(1:10)
> rp = recordPlot()
> dev.off()
X11cairo
2
> rp
HTH,
~G
sessionInfo():
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.0.1
On Tue, Sep 24, 2013 at 11:14 AM, Henrik Bengtsson wrote:
> Hi.
>
> Q. Is there a way to record a plot using grDevices::recordPlot()
> without opening an interactive (=visible GUI window) graphics device
> (not even for a flash of a second)?
>
>
> Related: help("recordPlot", package="grDevices") says:
>
> "These functions record and replay the displaylist of the current
> graphics device."
>
> Is the intention that recordPlot() should be able to record from _any
> type_ of graphics device, or only for _interactive_ ones? For
> instance,
>
> windows(); plot(1:10); g <- recordPlot(); dev.off();
> x11(); plot(1:10); g <- recordPlot(); dev.off();
> Cairo::CairoWin(); plot(1:10); g <- recordPlot(); dev.off();
>
> all produce 'recordplot' objects that replot the figure with
> replayPlot(g), whereas for instance
>
> png("foo.png"); plot(1:10); g <- recordPlot(); dev.off();
> pdf("foo.pdf"); plot(1:10); g <- recordPlot(); dev.off();
>
> produce "empty" replayPlot(g) outputs.
>
> Q. It it just a coincident that it appear that
> recordPlot()/replayPlot() only works for
> grDevices::deviceIsInteractive() graphics devices? If not, should
> ?recordPlot clarify that "These functions record and replay the
> displaylist of the current [interactive] graphics device."?
>
> Q. ...or is just the fact that currently png(), pdf() etc. won't
> populate "the displaylist" (whatever that is), but if they would, then
> recordPlot()/replayPlot() would indeed generate an non-empty plot? If
> so, a note like "Note, recordPlot() will often record an empty plot on
> non-interactive graphics devices as they do not populate the
> displaylist." may be add to the help.
>
>
> Thanks,
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] recordPlot() on non-interactive graphics device?
To be a little less terse:
I agree that notes/discussion about what recordPlot/replayPlot do when
there is no display list and that non-interactive devices don't create a
displaylist by default but can be instructed to do so via dev.control (at
least some, I don't claim to have checked them all) would probably be
helpful, as well as a see also link to dev.control.
~G
On Tue, Sep 24, 2013 at 11:25 AM, Gabriel Becker wrote:
> Henrik,
>
> This works for me:
>
> > png("test.png")
> > dev.control(displaylist="enable")
> > plot(1:10)
> > rp = recordPlot()
> > dev.off()
> X11cairo
>2
> > rp
>
> HTH,
> ~G
>
> sessionInfo():
> R version 3.0.1 (2013-05-16)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=C LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_3.0.1
>
>
>
> On Tue, Sep 24, 2013 at 11:14 AM, Henrik Bengtsson
> wrote:
>
>> Hi.
>>
>> Q. Is there a way to record a plot using grDevices::recordPlot()
>> without opening an interactive (=visible GUI window) graphics device
>> (not even for a flash of a second)?
>>
>>
>> Related: help("recordPlot", package="grDevices") says:
>>
>> "These functions record and replay the displaylist of the current
>> graphics device."
>>
>> Is the intention that recordPlot() should be able to record from _any
>> type_ of graphics device, or only for _interactive_ ones? For
>> instance,
>>
>> windows(); plot(1:10); g <- recordPlot(); dev.off();
>> x11(); plot(1:10); g <- recordPlot(); dev.off();
>> Cairo::CairoWin(); plot(1:10); g <- recordPlot(); dev.off();
>>
>> all produce 'recordplot' objects that replot the figure with
>> replayPlot(g), whereas for instance
>>
>> png("foo.png"); plot(1:10); g <- recordPlot(); dev.off();
>> pdf("foo.pdf"); plot(1:10); g <- recordPlot(); dev.off();
>>
>> produce "empty" replayPlot(g) outputs.
>>
>> Q. It it just a coincident that it appear that
>> recordPlot()/replayPlot() only works for
>> grDevices::deviceIsInteractive() graphics devices? If not, should
>> ?recordPlot clarify that "These functions record and replay the
>> displaylist of the current [interactive] graphics device."?
>>
>> Q. ...or is just the fact that currently png(), pdf() etc. won't
>> populate "the displaylist" (whatever that is), but if they would, then
>> recordPlot()/replayPlot() would indeed generate an non-empty plot? If
>> so, a note like "Note, recordPlot() will often record an empty plot on
>> non-interactive graphics devices as they do not populate the
>> displaylist." may be add to the help.
>>
>>
>> Thanks,
>>
>> Henrik
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capture output of install.packages (pipe system2)
On 13-09-24 10:37 AM, Jeroen Ooms wrote:
On Mon, Sep 23, 2013 at 6:50 PM, Duncan Murdoch
wrote:
x <- system2("Rscript", "-e \"install.packages('MASS',
repos='http://probability.ca/cran')\"", stdout=TRUE, stderr=TRUE)
Thank you, this suggestion seems to work (although I agree that
starting 3 procs to install a single package seems suboptimal).
For something that I only do every few weeks or months, I'd rather
optimize the use of the programmer's time than that of the processor. I
get paid more per hour!
Duncan Murdoch
One
additional question: is it safe to assume that the "Rscript"
executable can always be found by the R process (cross platform), or
do I need to modify the example in case Rscript is not in the system
search path?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] recordPlot() on non-interactive graphics device?
Thanks Gabriel. It works - I did not know about dev.control() and its
help page clearly says that "Initially recording is on for screen
devices, and off for print devices".
I've submitted a patch (PR#15472) for adding a "see also" linking to
dev.control():
Bug 15472 - PATCH: Adding see also link for help("recordPlot",
package="grDevices")
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15472
/Henrik
On Tue, Sep 24, 2013 at 11:43 AM, Gabriel Becker wrote:
> To be a little less terse:
>
> I agree that notes/discussion about what recordPlot/replayPlot do when there
> is no display list and that non-interactive devices don't create a
> displaylist by default but can be instructed to do so via dev.control (at
> least some, I don't claim to have checked them all) would probably be
> helpful, as well as a see also link to dev.control.
>
> ~G
>
>
>
> On Tue, Sep 24, 2013 at 11:25 AM, Gabriel Becker
> wrote:
>>
>> Henrik,
>>
>> This works for me:
>>
>> > png("test.png")
>> > dev.control(displaylist="enable")
>> > plot(1:10)
>> > rp = recordPlot()
>> > dev.off()
>> X11cairo
>>2
>> > rp
>>
>> HTH,
>> ~G
>>
>> sessionInfo():
>> R version 3.0.1 (2013-05-16)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=C LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> loaded via a namespace (and not attached):
>> [1] tools_3.0.1
>>
>>
>>
>> On Tue, Sep 24, 2013 at 11:14 AM, Henrik Bengtsson
>> wrote:
>>>
>>> Hi.
>>>
>>> Q. Is there a way to record a plot using grDevices::recordPlot()
>>> without opening an interactive (=visible GUI window) graphics device
>>> (not even for a flash of a second)?
>>>
>>>
>>> Related: help("recordPlot", package="grDevices") says:
>>>
>>> "These functions record and replay the displaylist of the current
>>> graphics device."
>>>
>>> Is the intention that recordPlot() should be able to record from _any
>>> type_ of graphics device, or only for _interactive_ ones? For
>>> instance,
>>>
>>> windows(); plot(1:10); g <- recordPlot(); dev.off();
>>> x11(); plot(1:10); g <- recordPlot(); dev.off();
>>> Cairo::CairoWin(); plot(1:10); g <- recordPlot(); dev.off();
>>>
>>> all produce 'recordplot' objects that replot the figure with
>>> replayPlot(g), whereas for instance
>>>
>>> png("foo.png"); plot(1:10); g <- recordPlot(); dev.off();
>>> pdf("foo.pdf"); plot(1:10); g <- recordPlot(); dev.off();
>>>
>>> produce "empty" replayPlot(g) outputs.
>>>
>>> Q. It it just a coincident that it appear that
>>> recordPlot()/replayPlot() only works for
>>> grDevices::deviceIsInteractive() graphics devices? If not, should
>>> ?recordPlot clarify that "These functions record and replay the
>>> displaylist of the current [interactive] graphics device."?
>>>
>>> Q. ...or is just the fact that currently png(), pdf() etc. won't
>>> populate "the displaylist" (whatever that is), but if they would, then
>>> recordPlot()/replayPlot() would indeed generate an non-empty plot? If
>>> so, a note like "Note, recordPlot() will often record an empty plot on
>>> non-interactive graphics devices as they do not populate the
>>> displaylist." may be add to the help.
>>>
>>>
>>> Thanks,
>>>
>>> Henrik
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistency/bug in recordPlot/replayPlot
Hi
Unfortunately, my main advice would be not to rely on recordPlot()
because it (or at least the underlying display list format) was never
intended for this sort of thing. I doubt that helps though :)
I might be able to help more, or look at developing a "transportable
object class for R graphics", if I had a better understanding of what
you want to do. Perhaps off list?
Paul
On 09/24/13 15:31, Gabriel Becker wrote:
Paul,
Thanks for the response.
On Mon, Sep 23, 2013 at 7:43 PM, Paul Murrell mailto:p...@stat.auckland.ac.nz>> wrote:
par(bg="white")
plot(1:10)
recplot = recordPlot()
png("bgreplay.png")
replayPlot(recplot)
dev.off()
Would that satisfy your use case ?
Unfortunately it does not, as my use-case is in a caching/dynamic
document setting. Thus I am capturing plotting from evaluation of an
arbitrary piece of code within a series of such evaluations. I cannot be
guaranteed the code doesn't call dev.off() or explicitly create a new
device and I wouldn't want to clobber any non-white background set in
previous code.
I thought putting par(bg="white") after the call to png() (or bg="white"
in the png call) might work, but it appears that replayPlot is actively
setting the background to transparent so that didn't fly.
Any other ideas or advice would be appreciated.
~G
Paul
On 09/14/13 09:17, Gabriel Becker wrote:
Hey all,
I've run accross what seems to be a bug in the recordPlot/replayPlot
functionality (or at least the lack of a feature which seems pretty
reasonable to expect to be there)
When drawing to a file-based graphics device (I tested with
png()), the
file resulting from calling replayPlot on a recordedplot object
does not
contain an identical image to that captured by the same graphics
device
when used on the plot that was recorded.
Reproducible (at least for me on linux) example:
png("noreplay.png")
plot(1:10)
dev.off()
plot(1:10)
recplot = recordPlot()
png("withreplay.png")
replayPlot(recplot)
dev.off()
The resulting png files are attached. You'll notice that the
noreplay.png
has the expected white background, while withoutreplay.png has no/a
transparent background.
This seems likely to be related to the note in ?dev.print :
"
Note that these functions copy the _device region_ and not a
plot:
the background colour of the device surface is part of
what is
copied. Most screen devices default to a transparent
background,
which is probably not what is needed when copying to a
device such
as ‘png’.
"
Now this may be as intended because it is "not allowed" to draw
recordedplot objects to devices other than the one they were
recorded on
(AFAIK the primary purpose of recordedplot objects is fast redraws
internally), but alas that is what my use-case calls for.
Furthermore, I
don't think I'm alone in thinking wistfully about how useful it
would be to
have an actual, transportable object class which can fully
represent an R
plot in any R-based context.
I'm pretty sure I can compile a patch which does this if it would be
considered, though there would be a delay of a week or two
before I could
burrow out from under the mound of other stuff I currently need
to be doing
sessionInfo below, and I have also confirmed that the behavior
remains
unchanged in the current trunk.
Thanks,
~G
sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.0.1 tools_3.0.1
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/__listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.
