Re: [Rd] Suppressed "graphical parameter" warnings reviving themselves magically

[Duncan Murdoch]

I don't know what's going on, but I see a version of it in R 4.4.2 on 
MacOS in the console, but not in R.app.


The difference is I only get one of the warnings, and only on the first 
attempt:



$ R

R version 4.4.2 (2024-10-31) -- "Pile of Leaves"
Copyright (C) 2024 The R Foundation for Statistical Computing
Platform: aarch64-apple-darwin20

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


plot.new(); suppressWarnings({ points(0, 0, foo = TRUE) })
NULL

NULL
Warning message:
"foo" is not a graphical parameter 

plot.new(); suppressWarnings({ points(0, 0, foo = TRUE) })
NULL

NULL


In R.app I don't seem to see it at all.

Duncan Murdoch



On 2025-03-21 1:51 a.m., Henrik Bengtsson wrote:

What's going on here?

$ R --vanilla --quiet

plot.new(); suppressWarnings({ points(0, 0, foo = TRUE) })
NULL

NULL
Warning messages:
1: "foo" is not a graphical parameter
2: "foo" is not a graphical parameter

Note how the warnings are revived in that second "NULL" call.  I can
reproduce this in R 4.4.3 and R-devel (2025-03-19 r88003). This might
be specific to "graphical parameter" warnings, because it won't happen
with, say, suppressWarnings({ log(-1) }).

It also doesn't appear if I call split up the first call into to
different REPL calls;

$ R --vanilla --quiet

plot.new()
suppressWarnings({ points(0, 0, foo = TRUE) })
NULL

NULL

/Henrik

PS. I thought I had sent this many months ago, but I just now found
this message in my draft folder, so now I'm not sure. Sorry, if this
is a duplicate.

__
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] structure(, ...) is sticky: a bug, or should it be an error?

[Henrik Bengtsson]

> I'm pretty convinced we should fix it by checking for primitive
> functions inside the C code of `attributes<-` :
> arguably the bug is really there, rather than in structure().
>
> Patches are welcome (via R's Bugzilla or just here).

Thank you Martin. I'll make sure I create a brief BugZilla report on
this, and hopefully a follow with a patch later on.

One question on urgency or not: Is it too late to get such a change in
for the R 4.5.0 release? I suspect so, because it has a potential of
breaking existing packages. But if there's a possibility of fixing
this in R 4.5.0, I'll make this a top priority.  Please let me know.

/Henrik

On Thu, Mar 20, 2025 at 3:31 AM Martin Maechler
 wrote:
>
> > Henrik Bengtsson
> > on Wed, 19 Mar 2025 10:58:46 -0700 writes:
>
> > Hello.
> > I just (re-)discovered that structure(sum, init = 100) is "sticky",
> > i.e. it stays with base::sum(). Here's an minimal example:
>
> > $ R --vanilla --quiet
> >> void <- structure(sum, some_attr = TRUE)
> >> str(sum)
> > function (..., na.rm = FALSE)
> > - attr(*, "some_attr")= logi TRUE
>
> >> From my very basic troubleshooting, it looks like this is happening
> > for primitive functions. I think I understand that this comes down to
> > primitive functions cannot be copied and baseenv() being special, i.e.
> > in structure() there will be no copy made of the primitive function,
> > and then attributes()<- ends up modifying the original primitive
> > function. Even if this is a documented feature, I believe, it is a
> > silent feature with risky side effects. We might already have code out
> > there that silently produces incorrect results, because of this
> > behavior. For example, I was about to a custom reduce() function where
> > I control the initial value via an "init" attribute of the reducer
> > function, e.g.
>
> > x <- 1:10
> > sum1 <- reduce(x, `+`)
> > sum2 <- reduce(x, structure(`+`, init = 100))  # == 100 + sum1
>
> > If I then call:
>
> > sum3 <- reduce(x, `+`)
>
> > the 'init' attribute that was set in the sum2 statement will affect
> > sum3 such that sum3 == sum2, not sum3 == sum1 as one would expect.
>
>
> > SUGGESTIONS:
>
> > If this is a bug, then I think it needs to be fixed. If it cannot be
> > fixed, maybe this could be protected against, e.g.
>
> >> void <- structure(sum, some_attr = TRUE)
> > Error: You must not set attributes on a primitive function: sum
>
> > Maybe it's sufficient to implement a protection against this in
> > attr()<-, attributes()<-, and class()<-.
>
> > Comments?
>
> > /Henrik
>
> Yes, this is a bug -- a version of your code above:
>
> > void <- structure(sum, foo = TRUE)
> > identical(void, sum)
> [1] TRUE
> > sum
> function (..., na.rm = FALSE)  .Primitive("sum")
> attr(,"foo")
> [1] TRUE
> >
>
> Above, you are already looking at ways to deal with it; and that
> *is* more delicate, indeed:
>
> One thing we (R core) found previously (a couple of years ago)
>  was that the  `structure(..)` function was
> already too "slow" for it to be used in some base R functions,
> and adding another  if(..) to it will not help making it faster ...
>
> OTOH, structure() being a pure R function (no direct .Internal(), .Call() ..)
> is also important I think,  as it keeps its code nicely self documenting.
>
> I'm pretty convinced we should fix it by checking for primitive
> functions inside the C code of `attributes<-` :
> arguably the bug is really there, rather than in structure().
>
> Patches are welcome (via R's Bugzilla or just here).
>
> Martin

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

[Rd] request for discussion on lonely doc patch suggestion

[Ben Bolker]

  Aki Vehtari and I suggested a revision to some of the man pages 
involving NA/is.nan/is.na about a year ago, but it never seems to have 
gotten any traction.


https://bugs.r-project.org/show_bug.cgi?id=18691

Discussion here:

https://fediscience.org/@aveht...@bayes.club/112043521852737720

  The patch file is attached (also available at bugzilla, if it doesn't 
get through to the list). I find the patch format a little hard to read, 
so I'm reproducing just the *new* text below.


  Any ideas or suggestions would be welcome.

  cheers
   Ben Bolker



src/library/base/man/NA.Rd:

 The generic function \code{is.na} indicates which elements are missing
  (\code{NA}) or \sQuote{Not a Number} (\code{link{NaN}}).

in examples from this page:

is.na(c(1, NA, NA_real_, NaN))#> FALSE  TRUE  TRUE  TRUE
is.na(paste(c(1, NA, NA_real_, NaN))) #> FALSE FALSE FALSE FALSE

# When NaN should not be considered as missing value
is.na(c(1, NA, NA_real_, NaN)) & !is.nan(c(1, NA, NA_real_, NaN))

  (POSSIBLE EDITS: more explanatory comments, especially explaining 
that paste() is converting NA values to "NA" strings ...)


---
From src/library/base/man/is.finite.Rd:

whereas \code{NaN} means \sQuote{Not a Number}.  \code{Inf} and
  \code{NaN} are class of \code{numeric} and type of \code{double},
  and can be used in real and imaginary parts of complex values, but not
  as values in integer vectors.

 (POSSIBLE EDITS: "class of", "type of" -> "of class"/"of type" or 
"have class"/"have type" ?)


  in "See Also":

\code{\link{NA}}, \sQuote{\emph{Not Available}}, which is usually used
  to denote a missing value. The default mode of \code{NA} is
  \code{logical}, unlike \code{NaN}, which is always of mode
  \code{double}.

---
From src/library/base/man/numeric.Rd

\code{is.numeric} is a more general test of an object being
  interpretable as numbers. These include special numeric objects
  \code{\link{Inf}}, \code{\link{NaN}}, \code{\link{NA_integer_}},
  and \code{\link{NA_real_}}.
Index: src/library/base/man/NA.Rd
===
--- src/library/base/man/NA.Rd  (revision 86216)
+++ src/library/base/man/NA.Rd  (working copy)
@@ -25,7 +25,8 @@
   other atomic vector types which support missing values: all of these
   are \link{reserved} words in the \R language.
 
-  The generic function \code{is.na} indicates which elements are missing.
+  The generic function \code{is.na} indicates which elements are missing
+  (\code{NA}) or \sQuote{Not a Number} (\code{link{NaN}}). 
 
   The generic function \code{is.na<-} sets elements to \code{NA}.
 
@@ -122,9 +123,12 @@
   on how methods can be tuned to deal with missing values.
 }
 \examples{
-is.na(c(1, NA))#> FALSE  TRUE
-is.na(paste(c(1, NA))) #> FALSE FALSE
+is.na(c(1, NA, NA_real_, NaN))#> FALSE  TRUE  TRUE  TRUE
+is.na(paste(c(1, NA, NA_real_, NaN))) #> FALSE FALSE FALSE FALSE
 
+# When NaN should not be considered as missing value
+is.na(c(1, NA, NA_real_, NaN)) & !is.nan(c(1, NA, NA_real_, NaN))
+
 (xx <- c(0:4))
 is.na(xx) <- c(2, 4)
 xx #> 0 NA  2 NA  4
Index: src/library/base/man/is.finite.Rd
===
--- src/library/base/man/is.finite.Rd   (revision 86216)
+++ src/library/base/man/is.finite.Rd   (working copy)
@@ -18,9 +18,10 @@
   and not missing) or infinite.
 
   \code{Inf} and \code{-Inf} are positive and negative infinity
-  whereas \code{NaN} means \sQuote{Not a Number}.  (These apply to numeric
-  values and real and imaginary parts of complex values but not to
-  values of integer vectors.)  \code{Inf} and \code{NaN} (as well as
+  whereas \code{NaN} means \sQuote{Not a Number}.  \code{Inf} and
+  \code{NaN} are class of \code{numeric} and type of \code{double},
+  and can be used in real and imaginary parts of complex values, but not
+  as values in integer vectors. \code{Inf} and \code{NaN} (as well as
   \code{\link{NA}}) are
   \link{reserved} words in the \R language.
 }
@@ -85,11 +86,12 @@
   \code{dimnames} and \code{names} attributes are preserved.
 }
 \seealso{
-  \code{\link{NA}}, \sQuote{\emph{Not Available}} which is not a number
-  as well, however usually used for missing values and applies to many
-  modes, not just numeric and complex.
-
-  \code{\link{Arithmetic}}, \code{\link{double}}.
+  \code{\link{NA}}, \sQuote{\emph{Not Available}}, which is usually used
+  to denote a missing value. The default mode of \code{NA} is
+  \code{logical}, unlike \code{NaN}, which is always of mode
+  \code{double}.
+  
+  \code{\link{Arithmetic}}, \code{\link{double}}, \code{\link{is.na}}.
 }
 \references{
   The IEC 60559 standard, also known as the
@@ -117,7 +119,7 @@
 }
 \examples{
 pi / 0 ## = Inf a non-zero number divided by zero creates infinity
-0 / 0  ## =  NaN
+0 / 0  ## =  NaN as defined in IEC 60559 standard
 
 1/0 + 1/0 # Inf
 1/0 - 1/0 # NaN
Index: src/library/base/man/numeric.Rd
=

Re: [Rd] request for discussion on lonely doc patch suggestion

[Duncan Murdoch]

Thanks for the suggestion.  I did a quick scan of the delta manual, but 
couldn't spot anything on integration with svn, just git.  Have you 
worked out the necessary config options for svn so that it would work 
with diffs like Ben's, or for running `svn diff` on some local changes?


Currently I don't use svn for anything but the R sources, but I suspect 
that will continue for some time...


Duncan Murdoch



On 2025-03-24 4:05 p.m., Tim Taylor wrote:
FWIW, on the command line I’m a happy 'delta' user for a quick side by 
side comparison (https://github.com/dandavison/delta 
)



 On 24 Mar 2025, at 19:32, J C Nash  wrote:

For Linux users, meld is quite nice for side by side editing, though 
I've never tried using it for
display. Just checking now suggests it isn't obvious how to "print" 
side by side display.


I've made meld easier for my own use by creating an icon in Double 
Commander (DC allows
the user to create iconized links to scripts and programs). There are 
two panes in the DC
file manager. I highlight one file in each then click. This saves 
typing two full paths in

a command

  meld  path/to/file1 path/to/file2

I suspect the highlight and click makes my use of meld reasonably 
attractive. I'm not sure

I'd use it in the raw command line mode.

Like Duncan, I welcome suggestions for similar tools, especially if 
there's a display option.


John Nash

On 2025-03-24 15:21, Duncan Murdoch wrote:
I sent some comments directly to Ben.  I just want to reply publicly 
to this part:

On 2025-03-24 1:18 p.m., Ben Bolker wrote:
    The patch file is attached (also available at bugzilla, if it 
doesn't

get through to the list). I find the patch format a little hard to read,
so I'm reproducing just the *new* text below.
I agree absolutely about the lack of readability of patch files.  A 
side by side display is much nicer.  If anyone out there isn't using 
one, you should.
I really like the one I use ("Beyond Compare"), but it's not open 
source.  I've been using it for a very long time (20 years or more, I 
think), and I suspect there are very good open source competitors out 
there now (and may have been for all the time I've been using BC). 
Suggestions?

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

[Rd] Bad URLs in DESCRIPTION files

[Colin Gillespie]

Hi All,

Just want to flag a few packages:

MatrixLDA: https://cran.r-project.org/web/packages/MatrixLDA/index.html
The URL is technically valid - ajmols...@github.io/ - but returns a
404. Almost certainly a typo.

redistmetrics: https://cran.r-project.org/web/packages/redistmetrics/index.html
Not a valid URL: https::/github.com/alarm-redist/redistmetrics/

yarrr: https://cran.r-project.org/web/packages/yarrr/
It looks like a lapsed domain, and Cypro folks have grabbed it.

Thanks

Colin

Ps I only found the last package because the name caught my attention

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

Re: [Rd] Patch for RJSONIO

[Kurt Hornik]

> Dirk Eddelbuettel writes:

Great, thanks!  Will put up a fixed RJSONIO shortly ...

Best
-k

> I can never remember where the canonical sources are for the effectively-CRAN
> maintained packages so I am dropping it here -- yesterday's update to RJSONIO
> does not build on anything older than r-devel.  This patch helps, feel free
> to adjust as needed.

> Dirk


> diff -ru RJSONIO.orig/src/RJSON.c RJSONIO/src/RJSON.c
> --- RJSONIO.orig/src/RJSON.c  2025-03-24 02:10:08.0 -0500
> +++ RJSONIO/src/RJSON.c   2025-03-25 17:49:50.490016649 -0500
> @@ -2,6 +2,7 @@
 
>  #include 
>  #include 
> +#include 
 
>  #include "ConvertUTF.h"
 
> @@ -70,7 +71,11 @@
>   ptr = REAL(tmp);
>   break;
>   case VECSXP:
> +#if R_VERSION >= R_Version(4,5,0)
>   ptr = (void *) VECTOR_PTR_RO(tmp);
> +#else
> + ptr = (void *) VECTOR_PTR(tmp);
> +#endif
>   break;
>   default:
>   ptr = NULL;


> -- 
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

> __
> 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