Re: [R-pkg-devel] Missing ggPMX causing failure for nlmixr2rpt

[John Harrold]

Howdy everyeone,

I think I misunderstood how suggests works. I always thought they would ble
available on CRAN but not necessarily on the end users computer. I've fixed
everything and will resubmit it this weekend.

Thank you both Ivan and Lluís. This was helpful.

John

On Fri, Jun 2, 2023 at 12:18 AM Lluís Revilla 
wrote:

> Dear John,
>
> I think the problem is that the package ggPMX is suggested, but
> nlmixr2rpt isn't prepared for when it isn't available.
> In such cases, a package shouldn't fail the checks.
>
> From the CRAN policies
> https://cran.r-project.org/web/packages/policies.html :
> "A package listed in ‘Suggests’ or ‘Enhances’ should be used
> conditionally in examples or tests if it cannot straightforwardly be
> installed on the major R platforms. (‘Writing R Extensions’ recommends
> that they are always used conditionally.)"
>
> Among other things in the file test-rptnlmixr.R you load several
> suggested packages without checking if they are available.
> You should only run those tests and examples that need those packages
> if they are available.
> Checking via:  if (requireNamespace("ggPMX", verbose = FALSE) could be
> enough
>
> There's also an example that seems to be failing, I didn't understand
> the reason behind it but it might be related.
>
> Best,
>
> Lluís
>
>
> On Fri, 2 Jun 2023 at 02:49, John Harrold 
> wrote:
> >
> > Hello,
> >
> > I recently got a "Dear Maintainer" email from Brian Ripley. It was
> > concerning the nlmixr2rpt package I maintain:
> >
> > https://cran.r-project.org/web/checks/check_results_nlmixr2rpt.html
> >
> > It looks like there is an error on r-release-linux-x86_64 that is causing
> > it. If I'm reading that correctly there is a problem finding ggPMX on
> that
> > flavor. If I look at the check results for ggPMX it seems to be building
> > fine there:
> >
> > https://cran.r-project.org/web/checks/check_results_ggPMX.html
> >
> > Am I reading that correctly that ggPMX not being found is the cause of my
> > issues? If that's the case and it seems to be present now, can I just
> wait
> > and let CRAN machines find it? Or should I just resubmit with those
> pieces
> > removed from the version I submit to CRAN?
> >
> > --
> > Thank you,
> > John
> > :wq
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

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

[Rd] infelicity in `na.print = ""` for numeric columns of data frames/formatting numeric values

[Ben Bolker]

  format(c(1:2, NA)) gives the last value as "NA" rather than 
preserving it as NA, even if na.encode = FALSE (which does the 
'expected' thing for character vectors, but not numeric vectors).


  This was already brought up in 2008 in 
https://bugs.r-project.org/show_bug.cgi?id=12318 where Gregor Gorjanc 
pointed out the issue. Documentation was added and the bug closed as 
invalid. GG ended with:


> IMHO it would be better that na.encode argument would also have an
effect for numeric like vectors. Nearly any function in R returns NA 
values and I expected the same for format, at least when na.encode=FALSE.


  I agree!

  I encountered this in the context of printing a data frame with 
na.print = "", which works as expected when printing the individual 
columns but not when printing the whole data frame (because 
print.data.frame calls format.data.frame, which calls format.default 
...).  Example below.


  It's also different from what you would get if you converted to 
character before formatting and printing:


print(format(as.character(c(1:2, NA)), na.encode=FALSE), na.print ="")

  Everything about this is documented (if you look carefully enough), 
but IMO it violates the principle of least surprise 
https://en.wikipedia.org/wiki/Principle_of_least_astonishment , so I 
would call it at least an 'infelicity' (sensu Bill Venables)


  Is there any chance that this design decision could be revisited?

  cheers
   Ben Bolker


---

  Consider

dd <- data.frame(f = factor(1:2), c = as.character(1:2), n = 
as.numeric(1:2), i = 1:2)

dd[3,] <- rep(NA, 4)
print(dd, na.print = "")


print(dd, na.print = "")
  f c  n  i
1 1 1  1  1
2 2 2  2  2
3 NA NA

This is in fact as documented (see below), but seems suboptimal given 
that printing the columns separately with na.print = "" would 
successfully print the NA entries as blank even in the numeric columns:


invisible(lapply(dd, print, na.print = ""))
[1] 1 2
Levels: 1 2
[1] "1" "2"
[1] 1 2
[1] 1 2

* ?print.data.frame documents that it calls format() for each column 
before printing
* the code of print.data.frame() shows that it calls format.data.frame() 
with na.encode = FALSE
* ?format.data.frame specifically notes that na.encode "only applies to 
elements of character vectors, not to numerical, complex nor logical 
‘NA’s, which are always encoded as ‘"NA"’.


   So the NA values in the numeric columns become "NA" rather than 
remaining as NA values, and are thus printed rather than being affected 
by the na.print argument.


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

[Rd] codetools wrongly complains about lazy evaluation in S4 methods

[Mikael Jagan]

In a package, I define a method for not-yet-generic function 'qr.X' like so:

> setOldClass("qr")
> setMethod("qr.X", signature(qr = "qr"), function(qr, complete, ncol) NULL)

The formals of the newly generic 'qr.X' are inherited from the non-generic
function in the base namespace.  Notably, the inherited default value of
formal argument 'ncol' relies on lazy evaluation:

> formals(qr.X)[["ncol"]]
if (complete) nrow(R) else min(dim(R))

where 'R' must be defined in the body of any method that might evaluate 'ncol'.
To my surprise, tools:::.check_code_usage_in_package() complains about the
undefined symbol:

qr.X: no visible binding for global variable 'R'
qr.X,qr: no visible binding for global variable 'R'
Undefined global functions or variables:
  R

I claim that it should _not_ complain, given that lazy evaluation is a really
a feature of the language _and_ given that it already does not complain about
the formals of functions that are not S4 methods.

Having said that, it is not obvious to me what in codetools would need to change
here.  Any ideas?

I've attached a script that creates and installs a test package and reproduces
the check output by calling tools:::.check_code_usage_in_package().  Hope it
gets through.

Mikaelnm <- "TestPackage"
dir.create(tmp <- file.path(tempdir(), nm))
dir.create(file.path(tmp, "R"))

cat(file = file.path(tmp, "DESCRIPTION"), "
Package: TestPackage
Version: 0.0-0
License: GPL (>= 2)
Description: A (one paragraph) description of what
  the package does and why it may be useful.
Title: My First Collection of Functions
Author: First Last [aut, cre]
Maintainer: First Last 
Imports: methods
")

cat(file = file.path(tmp, "NAMESPACE"), "
importFrom(methods, setMethod, setOldClass)
exportMethods(qr.X)
export(xyz)
")

cat(file = file.path(tmp, "R", paste0(nm, ".R")), "
setOldClass(\"qr\")
setMethod(\"qr.X\", signature(qr = \"qr\"), function(qr, complete, ncol) NULL)
xyz <- function(x, y = z) { z <- 1; x + y }
")

install.packages(tmp, repos = NULL)
tools:::.check_code_usage_in_package(nm)
## qr.X: no visible binding for global variable 'R'
## qr.X,qr: no visible binding for global variable 'R'
## Undefined global functions or variables:
##   R

unloadNamespace(nm)
remove.packages(nm)
unlink(tmp)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] why does [A-Z] include 'T' in an Estonian locale?

[Ben Bolker]

  Thanks, I do know about the docs you quoted.  Thanks for pointing me 
to the comment in the code.


 I've posted an issue (a request to make the documentation match the 
code) at the TRE repository:


https://github.com/laurikari/tre/issues/88


On 2023-06-01 5:53 a.m., Tomas Kalibera wrote:


On 5/30/23 17:45, Ben Bolker wrote:

Inspired by this old Stack Overflow question

https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions

I was wondering why this is TRUE:

Sys.setlocale("LC_ALL", "et_EE")
grepl("[A-Z]", "T")

TRE's documentation at 
 says that a 
range "is shorthand for the full range of characters between those two 
[endpoints] (inclusive) in the collating sequence".


Yet, T is *not* between A and Z in the Estonian collating sequence:

 sort(LETTERS)
 [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" 
"Q" "R" "S"

[20] "Z" "T" "U" "V" "W" "X" "Y"

  I realize that this may be a question about TRE rather than about R 
*per se* (FWIW the grepl() result is also TRUE with `perl = TRUE`, so 
the question also applies to PCRE), but I'm wondering if anyone has 
any insights ...  (and yes, I know that the correct answer is "use 
[:alpha:] and don't worry about it")


The correct answer depends on what you want to do, but please see 
?regexp in R:


"Because their interpretation is locale- and implementation-dependent, 
character ranges are best avoided."


and

"The only portable way to specify all ASCII letters is to list them all 
as the character class

‘[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz]’."

This is from POSIX specification:

"In the POSIX locale, a range expression represents the set of collating 
elements that fall between two elements in the collation sequence, 
inclusive. In other locales, a range expression has unspecified 
behavior: strictly conforming applications shall not rely on whether the 
range expression is valid, or on the set of collating elements matched. 
A range expression shall be expressed as the starting point and the 
ending point separated by a  ( '-' )."


If you really want to know why the current implementation of R, TRE and 
PCRE2 works in a certain way, you can check the code, but I don't think 
it would be a good use of the time given what is written above.


It may be that TRE has a bug, maybe it doesn't do what was intended (see 
comment "XXX - Should use collation order instead of encoding values in 
character ranges." in the code), but I didn't check the code thoroughly.


Best
Tomas



(In contrast, the ICU engine underlying stringi/stringr says "[t]he 
characters to include are determined by Unicode code point ordering" - 
see


https://stackoverflow.com/questions/76365426/does-stringrs-regex-engine-translate-a-z-into-abcdefghijklmnopqrstuvwyz/76366163#76366163

for links)

__
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: [Bioc-devel] fail to register as a maintainer

[Kern, Lori]

We will look into the support site issue. I do see you registered on the 
support site and the api is not registering correctly.  We will try to rectify 
shortly.

There is an account registered on the Bioc credentials account with that email. 
I see it is not activated. Please activate the email before trying to log in.

If your package is in review, you can reference this mailing list post to 
temporarily ignore the support site ERROR while we investigate what is going on 
with this particular instance.


Cheers,


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Pan, Yue via 
Bioc-devel 
Sent: Friday, June 2, 2023 3:40 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] fail to register as a maintainer

Hello!

I tried to sign up as a maintainer for my first Bioconductor package. However, 
I can not get the confirmation email. Even though I'm able to log in at 
https://secure-web.cisco.com/1HxAnR2Yqikh4FrB7QKM0TgL6vvmZ9eWYZrn3ot7kXmTZPRDdRW7KP7YopWzFrTDTW8t0_emVJDU1ywA7o0nwCCFgQhEnWYZuEcLkdIyakeiGuFq9kgUzqAmuoXJNMC2t_y8ewpuds-xaGcKbq9sdwonYQgC-gRClyDAAttNPb2hUgvyeOALOWt7sSl8JpPf-t0pNue1FRO8-H-jT4e3axBaWviWsrWR6wUtkccx_Ad2ZXiz7BbIxJQYd9Xx5j8FMtVxheOoXiwPkXDEAKTbjl9bujB3he692nbGucUWPiFvcPOvJYSez_O8bTuLHNuR6/https%3A%2F%2Fsupport.bioconductor.org%2Faccounts%2Fsignup%2F,
 I always get error like "Maintainer must register at the support site" when I 
do BiocCheck::BiocCheck().  In addition, under this website (Bioconductor Git 
Credentials),
 it is said that my email is not associated with a maintainer of a Bioconductor 
package. Could you please help?

The email I used to sign up was: yue@stjude.org.

Thank you!
Yue



Email Disclaimer: 
http://secure-web.cisco.com/1oHsBFTAbncANyHU-osHvCSkL9nKyWGKD0ibEjo4C6VPMK0k8UQLk1u33C1GIr0uqN3f73uE21TOZRO0K-rPv0LzYRaEW-3rFXVFKhOHLrOO2za0i2UlqJ1aKFryasLF1iHENJIcvhZKajMoCDgy0zZ5cjts1d_8zBDyNHP6PoYcjSHCZ8u48XjGQ1anv2-ehhOr3D4CBZktooQiKCSvqqGgJncd4Ag3S5c3rEGUSeJjKOEujwDwxeppsk-bm9hozZ6FFGJ3P_lJhDBDSgIxqkaLSe9iDnhx9e0gMGp-gW2kBTW2KBM_O1hg0moGbysIl/http%3A%2F%2Fwww.stjude.org%2Femaildisclaimer
Consultation Disclaimer: 
http://secure-web.cisco.com/1YXVmSSww0CiyZ8daCCpMpli9LNK33J6sSCVwlme4D_IdEcL6RonjuzKrBYmuOP68JaUPFh2nCesghEo5NPmmIKlAU1NyYnx4bpP4NMFhAAfOSSjMMEK5H_aKFldz5DkqWwV7DgPqeA2dcoVPjEVxFLKF2hDAije4RKva9ZlgBzA4X1lDl3kzY6R2g6q5TZmuJasqYMrwgySZt-CO4WnzLczKZwoRS5zthgFq6rNasQs4FPu3gmsaN_MT_kmXGO6WQKabDLaOaCvnYMCH_81X5WkABmjjjNtAOUFQJ4F4h8i4gu4CLjm_RHa51BSfCO6A/http%3A%2F%2Fwww.stjude.org%2Fconsultationdisclaimer

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1LAJd758XD_QVUco8khkMIYO942YURjI-AaM-WpQUy3o59fTxF-86aRcuGmt1VI8z4i6nGTqMabkQX1DJxbogWb-RxwXL02lhFO73xaDW55JgHE-5hqWB52PFCQQQhXCZWrUvMH2rMpieDrrpcY_t-PGOJ1ngLzsjWWlHHnnpIzsD0lxjQ36hUPfHDt1zXIW2GC05BkOK9RNAt2iBFs4L6aR2UeZ9Fe4fAeWXNXWpFTu6xOx3MgUGjlxmezgs7zEJDx2_b7Htg7zwzKA_OoaDuQuZ0ArblWz6WFHR5qW8wFPmWkqU7LBGnoA3p3qoBKcz/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] BioConductor package vulnerabilities to R-spatial evolution process

[Roger Bivand]

Packages: GSCA, Cardinal, cellmigRation, flowDensity, MoleculeExperiment, 
SPIAT, stJoincount, structToolbox, synergyfinder have strong dependencies on 
CRAN package sp; mtbls2 has a weak dependency. 

The evolution project https://github.com/r-spatial/evolution, 
https://www.r-consortium.org/all-projects/awarded-projects/2021-group-2#Preparing%20CRAN%20for%20the%20Retirement%20of%20rgdal,%20rgeos%20and%20maptools,
 has now published four reports, most recently 
https://r-spatial.org/r/2023/05/15/evolution4.html with links to the three 
previous ones. 

The sp package was written before the rgdal and rgeos packages, but rgdal, 
rgeos and maptools are being retired/archived in October 2023 because better 
alternatives exist, through the CRAN sf and terra packages. The continued use 
of sp is possible, rather for older existing packages, by coercion to and from 
classes used in sf and terra.

The new BioConductor package MoleculeExperiment has a new strong dependency on 
sp; I have raised an issue there: 
https://github.com/SydneyBioX/MoleculeExperiment/issues/1, but feel that 
BioConductor developers generally need to be warned off unconsidered new use of 
sp in ignorance of impending changes. sp 1.6-1 now on load issues a message 
informing of the need for care, so one can hope that maintainers will be 
attentive. Please alert any potentially affected as soon as possible, and post 
issues on https://github.com/r-spatial/evolution/issues - I do not follow this 
list carefully.

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel