July 24, 2020 11:02
To: Duncan Murdoch
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Duncan Murdoch wrote on 2020-07-24 01:05:
> On 23/07/2020 5:11 p.m., Helmut Sch�tz wrote:
>> I'm not a native speaker of English but for me "shoul
Duncan Murdoch wrote on 2020-07-24 01:05:
On 23/07/2020 5:11 p.m., Helmut Schütz wrote:
I'm not a native speaker of English but for me "should not write" !=
"must not write".
And "may be allowed" is not "will be allowed".
Which leaves the question open _who_ may -- or may not -- allow it.
R-4.0 introduced a new function, tools::R_user_dir(package, which),
where which is one of "data", "config", and "cache". It gives
standard directory names in which to place package-and-user-specific
files which you want to last longer than one R session.
I suppose you will still have to ask the
On 23/07/2020 5:11 p.m., Helmut Schütz wrote:
Hi Dirk,
Dirk Eddelbuettel wrote on 2020-07-23 15:16:
Helmut,
For previous uploads you affirmed that you read the CRAN Repository Policy
which states
[...]
Your package appears to violate that requirement.
As I wrote previously the
Hi Dirk,
Dirk Eddelbuettel wrote on 2020-07-23 15:16:
Helmut,
For previous uploads you affirmed that you read the CRAN Repository Policy
which states
[...]
Your package appears to violate that requirement.
As I wrote previously the statement continues with
"Limited exceptions may be
Hi Sebastian,
Sebastian Meyer wrote on 2020-07-23 16:52:
Back to the original topic:
THX!
Calling graphics.off() in example code will also disturb standard R CMD
check. Before running the examples, R CMD check opens a pdf device to
store any graphics output [1]. You will find the resulting
Back to the original topic: graphics.off() is probably not what you
want. It shuts down *all* open graphics devices, not just the current
one. Example code or your plotting functions should not do that.
Calling graphics.off() in example code will also disturb standard R CMD
check. Before running
Helmut,
For previous uploads you affirmed that you read the CRAN Repository Policy
which states
* The code and examples provided in a package should never do anything
which might be regarded as malicious or anti-social. The following are
illustrative examples from past
On 23/07/2020 8:18 a.m., Helmut Schütz wrote:
Hi David,
David Cortes wrote on 2020-07-23 13:16:
It is explained here:
https://cran.r-project.org/web/packages/policies.html
Section about source packages:
"Packages should not write in the user’s home filespace (including
clipboards), nor
Hi David,
David Cortes wrote on 2020-07-23 13:16:
It is explained here:
https://cran.r-project.org/web/packages/policies.html
Section about source packages:
"Packages should not write in the user’s home filespace (including
clipboards), nor anywhere else on the file system apart from the R
It is explained here:
https://cran.r-project.org/web/packages/policies.html
Section about source packages:
"Packages should not write in the user’s home filespace (including
clipboards), nor anywhere else on the file system apart from the R
session’s temporary directory (or during installation in
Dear Duncan,
Duncan Murdoch wrote on 2020-07-22 23:48:
On 22/07/2020 5:40 p.m., Helmut Schütz wrote:
Duncan Murdoch wrote on 2020-07-22 21:42:
During a check, it probably wouldn't, because you aren't allowed to
write to "~/". Your package should be writing to tempdir(), or a
location
On 22/07/2020 5:40 p.m., Helmut Schütz wrote:
Duncan Murdoch wrote on 2020-07-22 21:42:
On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
[...]
The problem is that I cannot reproduce it as well. Only CHECK laments
about dev.off() which I changed to graphics.off() in the meantime.
Duncan Murdoch wrote on 2020-07-22 21:42:
> On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
>> [...]
>> The problem is that I cannot reproduce it as well. Only CHECK laments
>> about dev.off() which I changed to graphics.off() in the meantime.
>>
>> library(grDevices)
>> foo <- TRUE # shall we
On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
Hi Serguei,
Serguei Sokol wrote on 2020-07-22 15:51:
Hmm... I see 2 possibilities for still getting an error while the
concerned part of code is not supposed to be run:
- either you are running not updated version of your package;
I _can_
Hi Serguei,
Serguei Sokol wrote on 2020-07-22 15:51:
Hmm... I see 2 possibilities for still getting an error while the
concerned part of code is not supposed to be run:
- either you are running not updated version of your package;
I _can_ built the package and it runs as intended. Only the
On 22/07/2020 8:36 a.m., Helmut Schütz wrote:
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected
I suspect your foo and bar variables are not logical anymore... insufficient
info. However, why aren't you using short-circuit && and || operators?
On July 22, 2020 5:36:06 AM PDT, "Helmut Schütz"
wrote:
>Dear all,
>
>I have two variables, foo and bar. The first is TRUE if a png should be
>
Le 22/07/2020 à 14:36, Helmut Schütz a écrit :
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected in all versions of my package built in R up
20 matches
Mail list logo
