Re: [Rd] Base R examples that write to current working directory
> Henrik Bengtsson
> on Fri, 30 Mar 2018 10:14:04 -0700 writes:
> So, the proposal would then be to write to tempdir(),
> correct? If so, I see three alternatives:
> 1. explicitly use file.path(tempdir(), filename), or
> tempfile() everywhere.
I think it should clearly be '1.',
as both '2.' and '3.' would need new functionality in R.
Ideally we'd get the patch within a day or two, so we can safely
apply it also to R 3.5.0 alpha (before it turns beta!).
I think the 'eval.path' argument to example() is a nice idea,
but also changing its default to tempdir() is definitely out of
the question for R 3.5.0.
Martin
> 2. wrap example code in a withTempDir({ ... }) call.
> 3. Add an 'eval.path' (*) argument to example() and make
> it default to eval.path = tempdir(). This would probably
> be backward compatible and keep the code example clean.
> The downside is when a user runs an example and can't
> locate produced files. (*) or 'wd', 'workdir', ...
> /Henrik
> On Fri, Mar 30, 2018 at 9:25 AM, Uwe Ligges
> wrote:
>>
>>
>> On 30.03.2018 00:08, Duncan Murdoch wrote:
>>>
>>> On 29/03/2018 5:23 PM, Hadley Wickham wrote:
Hi all,
Given the recent CRAN push to prevent examples writing
to the working directory, is there any interest in
fixing base R examples that write to the working
directory? A few candidates are the graphics devices,
file.create(), writeBin(), writeChar(), write(), and
saveRDS(). I'm sure there are many more.
One way to catch these naughty examples would be to
search for unlink() in examples: e.g.,
https://github.com/wch/r-source/search?utf8=✓&q=unlink+extension%3ARd&type=.
Of course, simply cleaning up after yourself is not
sufficient because if those files existed before the
examples were run, the examples will destroy them.
>>>
>>> Why not put together a patch that fixes these? This
>>> doesn't seem to be something that needs discussion,
>>> fixing the bad examples would be a good idea.
>>
>>
>> Seconded. CRAN would not accept these base packages,
>> hence we should urgently give better examples.
>>
>> Best, Uwe
>>
>>
>>
>>> Duncan Murdoch
>>>
>>> __
>>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] recordPlot/replayPlot not working with saveRDS/readRDS
> Paul Murrell
> on Tue, 3 Apr 2018 09:41:56 +1200 writes:
> Hi What you are doing "wrong" is loading a recordedplot
> into the same session that it was created in. The
> saveRDS()/readRDS() works if you save in one R session and
> then read in a different R session. The assumption is
> that if you are still in the same session that created the
> recordedplot you still have the recordedplot (e.g., you
> can just do replayPlot(r) instead of replayPlot(r2). Is
> that a bad assumption ?
Not "bad", really, but somewhat *un*intuitive I believe to most
users, including me.
I would have done the same as Winston to check if saving and
loading of a recorded plot work fine.
Also, the error message we get is not very helpful:
> saveRDS(r, 'recordedplot.rds')
> r <- readRDS('recordedplot.rds')
> png('test2.png')
> replayPlot(r)
Error: NULL value passed as symbol address
{coming from deep down: checkValidSymbolId() in src/main/dotcode.c }
I've pondered a bit and in the end found it easy enough to
tryCatch() the error, and "do the right thing" instead.
As that should typically only happen in exactly such a use case,
the change should be "uniformly >=" the previous state.
Ideally, maybe we (R core) would provide an R level API to a
"TRUE/FALSE" valued version of checkValidSymbolId() or its
caller, so that *from R code* one could check if the
recordedplot 'x' passed to replayPlot() with its external
pointers needs to be fixed up by
x <- restoreRecordedPlot(x)
or not.
But that would be another topic I'd not get envolved deeply just now.
Martin
> Paul
>
> On 03/04/18 05:23, Winston Chang wrote:
> > The documentation for recordPlot says the following:
> >
> >> As of R 3.3.0, it is possible (again) to replay a plot from another R
> >> session using, for example, saveRDS and readRDS.
> >
> > However, I haven't been able to save and restore a plot displaylist
> > and have it work within the same R session, using R 3.4.3 or 3.3.3.
> > Here's an example:
> >
> > # Save displaylist for a simple plot
> > png('test.png')
> > dev.control(displaylist ="enable")
> > plot(1:5, 1:5)
> > r <- recordPlot()
> > dev.off()
> >
> > # Replay plot. This works.
> > png('test1.png')
> > replayPlot(r)
> > dev.off()
> >
> > # Save the plot and load it, then try to replay it. This does not work.
> > saveRDS(r, 'recordedplot.rds')
> > r2 <- readRDS('recordedplot.rds')
> > png('test2.png')
> > replayPlot(r2) ## Error: NULL value passed as symbol address
> > dev.off()
> >
> >
> > Is there something that I'm doing wrong here?
> >
> > __
> > 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] names lost in functions from packages installed by R-devel r74500
Dear list members,
If I install with R-devel r74500 on Windows (sessionInfo below) the
attached 'bugdemo' package with the single function
foo <- function() {
named <- c("bar"=TRUE)
print(named)
return(named)
}
then run
> bugdemo::foo()
[1] TRUE
[1] TRUE
The "bar" name is lost. It is not lost when I define foo in the R
session instead of using its packaged version.
To reproduce:
===
install.packages("bugdemo_0.1.1.tar.gz",type="source",repos=NULL)
bugdemo::foo()
===
I also tested whether this was a problem with the "R CMD build" step or
the "install.packages()" step by building with R 3.4.4 and installing
with R-devel, and reciprocally, and the problem appears to be in the
install step of R-devel.
F.
=
> sessionInfo()
R Under development (unstable) (2018-03-31 r74500)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252
LC_MONETARY=French_France.1252
[4] LC_NUMERIC=C LC_TIME=French_France.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] bugdemo_0.1.1
loaded via a namespace (and not attached):
[1] compiler_3.6.0 tools_3.6.0 withr_2.1.2 memoise_1.1.0
digest_0.6.15 devtools_1.13.5
>
--
François Rousset
CNRS research scientist
- Institut des Sciences de l'Evolution (ISE-M)
Université de Montpellier - Dept. Scientifique B3ESTE
bugdemo_0.1.1.tar.gz
Description: application/gzip
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] names lost in functions from packages installed by R-devel r74500
> Francois Rousset
> on Tue, 3 Apr 2018 16:38:42 +0200 writes:
> Dear list members,
> If I install with R-devel r74500 on Windows (sessionInfo below) the
> attached 'bugdemo' package with the single function
> foo <- function() {
> named <- c("bar"=TRUE)
> print(named)
> return(named)
> }
> then run
>> bugdemo::foo()
> [1] TRUE
> [1] TRUE
> The "bar" name is lost. It is not lost when I define foo in the R
> session instead of using its packaged version.
> To reproduce:
> ===
> install.packages("bugdemo_0.1.1.tar.gz",type="source",repos=NULL)
> bugdemo::foo()
> ===
> I also tested whether this was a problem with the "R CMD build" step or
> the "install.packages()" step by building with R 3.4.4 and installing
> with R-devel, and reciprocally, and the problem appears to be in the
> install step of R-devel.
Confirmed.
It is a bug somewhere between the byte compiler and
(de)serialization .. really beyond my own expertise:
If you install without byte compilation *), foo() behaves as
expected, i.e., does not "lose" the names.
On the other hand, as you mention, if you define foo in the
globalenv, and call it, the JIT kicks in pretty quickly and you
can see that 'foo' is byte compiled as well, but it still does not break.
This is pretty important, so thank you very much for the nice
reproducible report!
Martin Maechler
ETH Zurich
---
*) R-devel CMD INSTALL --no-byte-compile -l ...
> F.
> =
>> sessionInfo()
> R Under development (unstable) (2018-03-31 r74500)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
> Matrix products: default
> locale:
> [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252
> LC_MONETARY=French_France.1252
> [4] LC_NUMERIC=C LC_TIME=French_France.1252
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] bugdemo_0.1.1
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0 tools_3.6.0 withr_2.1.2 memoise_1.1.0
> digest_0.6.15 devtools_1.13.5
>>
> --
> François Rousset
> CNRS research scientist
>
> - Institut des Sciences de l'Evolution (ISE-M)
> Université de Montpellier - Dept. Scientifique B3ESTE
> x[DELETED ATTACHMENT external: bugdemo_0.1.1.tar.gz, application/gzip]
> __
> 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] names lost in functions from packages installed by R-devel r74500
> Martin Maechler
> on Tue, 3 Apr 2018 17:03:02 +0200 writes:
> Francois Rousset
> on Tue, 3 Apr 2018 16:38:42 +0200 writes:
>> Dear list members,
>> If I install with R-devel r74500 on Windows (sessionInfo below) the
>> attached 'bugdemo' package with the single function
>> foo <- function() {
>> named <- c("bar"=TRUE)
>> print(named)
>> return(named)
>> }
>> then run
>>> bugdemo::foo()
>> [1] TRUE
>> [1] TRUE
>> The "bar" name is lost. It is not lost when I define foo in the R
>> session instead of using its packaged version.
>> To reproduce:
>> ===
>> install.packages("bugdemo_0.1.1.tar.gz",type="source",repos=NULL)
>> bugdemo::foo()
>> ===
>> I also tested whether this was a problem with the "R CMD build" step or
>> the "install.packages()" step by building with R 3.4.4 and installing
>> with R-devel, and reciprocally, and the problem appears to be in the
>> install step of R-devel.
> Confirmed.
> It is a bug somewhere between the byte compiler and
> (de)serialization .. really beyond my own expertise:
> If you install without byte compilation *), foo() behaves as
> expected, i.e., does not "lose" the names.
> On the other hand, as you mention, if you define foo in the
> globalenv, and call it, the JIT kicks in pretty quickly and you
> can see that 'foo' is byte compiled as well, but it still does not break.
> This is pretty important, so thank you very much for the nice
> reproducible report!
> Martin Maechler
> ETH Zurich
> ---
> *) R-devel CMD INSTALL --no-byte-compile -l ...
This has been fixed now, both in R-devel (svn rev 74511)
and in R 3.5.0 alpha (r 74513).
I was wrong in that this was related to (de)serialization.
Rather I had forgotten that JIT (just in time) compilation and
explicit compilation may differ in their results.
Thank you again for the report!
Martin Maechler
ETH Zurich
>> =
>>> sessionInfo()
>> R Under development (unstable) (2018-03-31 r74500)
[ ... ]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] names lost in functions from packages installed by R-devel r74500
On Tue, 3 Apr 2018, Martin Maechler wrote:
Martin Maechler
on Tue, 3 Apr 2018 17:03:02 +0200 writes:
Francois Rousset
on Tue, 3 Apr 2018 16:38:42 +0200 writes:
>> Dear list members,
>> If I install with R-devel r74500 on Windows (sessionInfo below) the
>> attached 'bugdemo' package with the single function
>> foo <- function() {
>> named <- c("bar"=TRUE)
>> print(named)
>> return(named)
>> }
>> then run
>>> bugdemo::foo()
>> [1] TRUE
>> [1] TRUE
>> The "bar" name is lost. It is not lost when I define foo in the R
>> session instead of using its packaged version.
>> To reproduce:
>> ===
>> install.packages("bugdemo_0.1.1.tar.gz",type="source",repos=NULL)
>> bugdemo::foo()
>> ===
>> I also tested whether this was a problem with the "R CMD build" step or
>> the "install.packages()" step by building with R 3.4.4 and installing
>> with R-devel, and reciprocally, and the problem appears to be in the
>> install step of R-devel.
> Confirmed.
> It is a bug somewhere between the byte compiler and
> (de)serialization .. really beyond my own expertise:
> If you install without byte compilation *), foo() behaves as
> expected, i.e., does not "lose" the names.
> On the other hand, as you mention, if you define foo in the
> globalenv, and call it, the JIT kicks in pretty quickly and you
> can see that 'foo' is byte compiled as well, but it still does not break.
> This is pretty important, so thank you very much for the nice
> reproducible report!
> Martin Maechler
> ETH Zurich
> ---
> *) R-devel CMD INSTALL --no-byte-compile -l ...
This has been fixed now, both in R-devel (svn rev 74511)
and in R 3.5.0 alpha (r 74513).
I was wrong in that this was related to (de)serialization.
Rather I had forgotten that JIT (just in time) compilation and
explicit compilation may differ in their results.
Actually the difference is that a function defined in a package is
compiled with more optimizations than one defined at session top
level. A change had broken a piece of the optimization code, and has
now been fixed. Thanks for the report.
Best,
luke
Thank you again for the report!
Martin Maechler
ETH Zurich
>> =
>>> sessionInfo()
>> R Under development (unstable) (2018-03-31 r74500)
[ ... ]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] recordPlot/replayPlot not working with saveRDS/readRDS
On Mon, Apr 2, 2018 at 4:41 PM, Paul Murrell wrote: > Hi > > What you are doing "wrong" is loading a recordedplot into the same session > that it was created in. The saveRDS()/readRDS() works if you save in one R > session and then read in a different R session. The assumption is that if > you are still in the same session that created the recordedplot you still > have the recordedplot (e.g., you can just do replayPlot(r) instead of > replayPlot(r2). Is that a bad assumption ? > > Paul For my particular case, the goal is to cache many plots to disk so that they can be replayed later, but still in the same R session. The plots may be replayed in the current session, and they may be replayed in a future one. Using a disk cache seems like a straightforward way to make the cached plots work for both cases. Also, the number of plots is such that a memory-based cache could consume significant amounts of memory. -Winston __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] recordPlot/replayPlot not working with saveRDS/readRDS
Thanks for the fix Martin.
Paul
On 04/04/18 02:07, Martin Maechler wrote:
Paul Murrell
on Tue, 3 Apr 2018 09:41:56 +1200 writes:
> Hi What you are doing "wrong" is loading a recordedplot
> into the same session that it was created in. The
> saveRDS()/readRDS() works if you save in one R session and
> then read in a different R session. The assumption is
> that if you are still in the same session that created the
> recordedplot you still have the recordedplot (e.g., you
> can just do replayPlot(r) instead of replayPlot(r2). Is
> that a bad assumption ?
Not "bad", really, but somewhat *un*intuitive I believe to most
users, including me.
I would have done the same as Winston to check if saving and
loading of a recorded plot work fine.
Also, the error message we get is not very helpful:
> saveRDS(r, 'recordedplot.rds')
> r <- readRDS('recordedplot.rds')
> png('test2.png')
> replayPlot(r)
Error: NULL value passed as symbol address
{coming from deep down: checkValidSymbolId() in src/main/dotcode.c }
I've pondered a bit and in the end found it easy enough to
tryCatch() the error, and "do the right thing" instead.
As that should typically only happen in exactly such a use case,
the change should be "uniformly >=" the previous state.
Ideally, maybe we (R core) would provide an R level API to a
"TRUE/FALSE" valued version of checkValidSymbolId() or its
caller, so that *from R code* one could check if the
recordedplot 'x' passed to replayPlot() with its external
pointers needs to be fixed up by
x <- restoreRecordedPlot(x)
or not.
But that would be another topic I'd not get envolved deeply just now.
Martin
Paul
On 03/04/18 05:23, Winston Chang wrote:
The documentation for recordPlot says the following:
As of R 3.3.0, it is possible (again) to replay a plot from another R session
using, for example, saveRDS and readRDS.
However, I haven't been able to save and restore a plot displaylist
and have it work within the same R session, using R 3.4.3 or 3.3.3.
Here's an example:
# Save displaylist for a simple plot
png('test.png')
dev.control(displaylist ="enable")
plot(1:5, 1:5)
r <- recordPlot()
dev.off()
# Replay plot. This works.
png('test1.png')
replayPlot(r)
dev.off()
# Save the plot and load it, then try to replay it. This does not work.
saveRDS(r, 'recordedplot.rds')
r2 <- readRDS('recordedplot.rds')
png('test2.png')
replayPlot(r2) ## Error: NULL value passed as symbol address
dev.off()
Is there something that I'm doing wrong here?
__
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
--
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/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
