Re: [Rd] LOGNAME env var in the check code

2021-11-18 Thread Kurt Hornik 
> Gábor Csárdi writes:

Thanks.  c81206 changes to use 

  user <- Sys.info()[["effective_user"]]

which afawct should always give the same  as the uname for files created
by the current user.  Pls check: if not, we can go for something like

foo <- function() {
writeLines("ABC", tf <- tempfile())
on.exit(unlink(tf))
file.info(tf)$uname
}

Best
-k


> While trying to reproduce a NOTE for
> * checking for new files in some other directories ... NOTE

> I noticed that the check code uses

> Sys.getenv("LOGNAME")

> to query the name of the current user. However on many systems this is
> not set, so this is the empty string, and then no NOTE is shown. (Only
> files owned by the current user generate a NOTE.)

> An alternative would be to call `id -un` to query the username, or
> create a file and then use `file.info()` to query its owner. Using one
> of these alternatives would make this check more reproducible.

> Thanks,
> Gabor

> __
> 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] [External] DOCS: Exactly when, in the signaling process, is option 'warn' applied?

2021-11-18 Thread luke-tierney 

On Thu, 18 Nov 2021, Henrik Bengtsson wrote:


Hi,

the following question sprung out of a package settings option warn=-1
to silence warnings, but those warnings were still caught by
withCallingHandlers(..., warning), which the package author did not
anticipate. The package has been updated to use suppressWarnings()
instead, but as I see a lot of packages on CRAN [1] use
options(warn=-1) to temporarily silence warnings, I wanted to bring
this one up. Even base R itself [2] does this, e.g.
utils::assignInMyNamespace().

Exactly when is the value of 'warn' options used when calling warning("boom")?



In the default handler; it doesn't affect signaling.

Much of the documentation pre-dates the condition system; happy to
consider patches.

Best,

luke


I think the docs, including ?options, would benefit from clarifying
that. To the best of my understanding, it should also mention that
options 'warn' is meant to be used by end-users, and not in package
code where suppressWarnings() should be used.

To clarify, if we do:


options(warn = -1)
tryCatch(warning("boom"), warning = function(w) stop("Caught warning: ", 
conditionMessage(w), call. = FALSE))

Error: Caught warning: boom

we see that the warning is indeed signaled.  However, in Section '8.2
warning' of the 'R Language Definition' [3], we can read:

"The function `warning` takes a single argument that is a character
string. The behaviour of a call to `warning` depends on the value of
the option `"warn"`. If `"warn"` is negative warnings are ignored.
[...]"

The way this is written, it may suggest that warnings are
ignored/silences already early on when calling warning(), but the
above example shows that that is not the case.

From the same section, we can also read:

"[...] If it is zero, they are stored and printed after the top-level
function has completed. [...]"

which may hint at the 'warn' option is applied only when a warning
condition is allowed to "bubble up" all the way to the top level.
(FWIW, this is how always though it worked, but it's only now I looked
into the docs and see it's ambiguous on this).

/Henrik

[1] 
https://github.com/search?q=org%3Acran+language%3Ar+R%2F+in%3Afile%2Cpath+options+warn+%22-1%22&type=Code
[2] 
https://github.com/wch/r-source/blob/0a31ab2d1df247a4289efca5a235dc45b511d04a/src/library/utils/R/objects.R#L402-L405
[3] https://cran.r-project.org/doc/manuals/R-lang.html#warning

__
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

[Rd] DOCS: Exactly when, in the signaling process, is option 'warn' applied?

2021-11-18 Thread Henrik Bengtsson 
Hi,

the following question sprung out of a package settings option warn=-1
to silence warnings, but those warnings were still caught by
withCallingHandlers(..., warning), which the package author did not
anticipate. The package has been updated to use suppressWarnings()
instead, but as I see a lot of packages on CRAN [1] use
options(warn=-1) to temporarily silence warnings, I wanted to bring
this one up. Even base R itself [2] does this, e.g.
utils::assignInMyNamespace().

Exactly when is the value of 'warn' options used when calling warning("boom")?

I think the docs, including ?options, would benefit from clarifying
that. To the best of my understanding, it should also mention that
options 'warn' is meant to be used by end-users, and not in package
code where suppressWarnings() should be used.

To clarify, if we do:

> options(warn = -1)
> tryCatch(warning("boom"), warning = function(w) stop("Caught warning: ", 
> conditionMessage(w), call. = FALSE))
Error: Caught warning: boom

we see that the warning is indeed signaled.  However, in Section '8.2
warning' of the 'R Language Definition' [3], we can read:

"The function `warning` takes a single argument that is a character
string. The behaviour of a call to `warning` depends on the value of
the option `"warn"`. If `"warn"` is negative warnings are ignored.
[...]"

The way this is written, it may suggest that warnings are
ignored/silences already early on when calling warning(), but the
above example shows that that is not the case.

>From the same section, we can also read:

"[...] If it is zero, they are stored and printed after the top-level
function has completed. [...]"

which may hint at the 'warn' option is applied only when a warning
condition is allowed to "bubble up" all the way to the top level.
(FWIW, this is how always though it worked, but it's only now I looked
into the docs and see it's ambiguous on this).

/Henrik

[1] 
https://github.com/search?q=org%3Acran+language%3Ar+R%2F+in%3Afile%2Cpath+options+warn+%22-1%22&type=Code
[2] 
https://github.com/wch/r-source/blob/0a31ab2d1df247a4289efca5a235dc45b511d04a/src/library/utils/R/objects.R#L402-L405
[3] https://cran.r-project.org/doc/manuals/R-lang.html#warning

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute

2021-11-18 Thread Martin Maechler 
> Duncan Murdoch 
> on Mon, 15 Nov 2021 13:06:23 -0500 writes:

> I'd recommend responding now with a pointer to that bug
> report: whoever at CRAN is dealing with your package
> doesn't necessarily know about the bug report.  You might
> or might not need to make a change in the end, but if you
> do, it could be hard to meet the two week deadline.

> Duncan Murdoch

With thanks to Duncan and Adrian:

Just in case, Adrian  hasn't been following R's bugzilla PR#18232
i.e.  https://bugs.r-project.org/show_bug.cgi?id=18232

There have been extra patches to fix more cases of deparsing
while being more back compatible than what's been in R-devel for
a couple of days.

Notably the changes do revert to previous behavior for the
example you give;  and indeed QCA  passes its own checks again,
after applying the patches.

The changes are under review currently, but the plan is to
commit the changes within a few days.
(read on)

> On 15/11/2021 12:58 p.m., Adrian Dușa wrote:
>> Thank you, I was given a deadline of two weeks to
>> respond, hopefully this will be settled by then.  Best
>> wishes, Adrian
>> 
>> On Mon, 15 Nov 2021 at 19:28, Duncan Murdoch
>> > > wrote:
>> 
>> This looks as though it is related to the recent patch in
>> 
>> https://bugs.r-project.org/show_bug.cgi?id=18232
>> 
>> 
>> I think you should probably wait until that settles down
>> before worrying about it.
>> 
>> Duncan Murdoch
>> 
>> On 15/11/2021 12:18 p.m., Adrian Dușa wrote: > Dear R
>> wizards,
>> >
>> > I have recently been informed about some build errors
>> of my package QCA, > which I was able to trace down to
>> the base function substitute(), with the > following
>> replication example:

foo <- function(x) return(substitute(x))

## In the stable R version 4.0.5, I get the expected result:

foo(A + ~B + C~D)
## A + ~B + C ~ D

BTW: no need for foo()  {and even less for a return(.) in a 1-liner !}

Be assured that we agree that

quote(A + ~B + C~D)

should not "gain" any parentheses, indeed, and what you've been
seeing can well be considered an intermediate step in iterations
to get to improved deparsing in subtle situations.


Thank you for the report, and best regards,
Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R-patched tarball at https://stat.ethz.ch/R/daily/ outdated

2021-11-18 Thread Martin Maechler 
> Gábor Csárdi 
> on Wed, 17 Nov 2021 16:11:43 +0100 writes:

> Hi all,

> AFAICT https://stat.ethz.ch/R/daily/R-patched.tar.gz is
> still R 4.0.5 patched.

> Probably needs a branch bump. FYI, Gabor

Yes; this has been an oversight by me (back in March).
It's amazing nobody has seen the issue till now.
I've fixed it a bit more than 3 hours ago.

Thank you, Gábor !

Martin

--
Martin Maechler, ETH Zurich and R Core team

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel