Re: [Rd] Advice debugging M1Mac check errors

[Simon Urbanek]

> On 7/02/2024, at 5:06 AM, Prof Brian Ripley via R-devel 
>  wrote:
> 
> On 04/02/2024 19:41, Holger Hoefling wrote:
>> Hi,
>> I wanted to ask if people have good advice on how to debug M1Mac package
>> check errors when you don´t have a Mac? Is a cloud machine the best option
>> or is there something else?
> 
> I presumed this was about a CRAN package, possibly hdf5r which has a 
> R-devel-only warning from the Apple clang compiler.  And that is not a 'check 
> error' and not something to 'debug'.
> 
> The original poster had errors for his package flsa until yesterday on 
> fedora-clang and M1mac, which were compilation errors with recent LLVM and 
> Apple compilers.  Again, not really something to 'debug' -- the compiler 
> messages were clear and the CRAN notification contained advice on where in 
> our manual to look this up.
> 
> The mac-builder service offers checks for R 4.3.0, the 'development' option 
> being (last time I tried) the same as the 'release' option. (When I asked, 
> Simon said that 'development' checks were only available in the run up to a 
> x.y.0 when he starts package building and checks for R-devel.)
> 


Just to clarify, the above is outdated information - ever since the R-devel 
packages binaries are on CRAN the "development" option in the mac-builder is 
available.

Cheers,
Simon



> 
> We were left to guess, but I doubt this has to do with the lack of 'extended 
> precision' nor long doubles longer than doubles on arm64 macOS.  And issues 
> with that are rather rare (much rarer than numerical issues for non-reference 
> x86_64 BLAS/LAPACKs).  Of the 20,300 CRAN packages just 18 have 
> M1mac-specific errors, none obviously from numerical inaccuracy.  A quick 
> look back suggests we get about 20 a year with M1mac numerical issues, about 
> half of which were mirrored on the x86_64 'noLD' checks.
> 
> -- 
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> 
> __
> 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] Re: NOTE: multiple local function definitions for ?fun? with different formal arguments

[Martin Morgan]

I went looking and found this in codetools, where it's been for 20 years

https://gitlab.com/luke-tierney/codetools/-/blame/master/R/codetools.R?ref_type=heads#L951

I think the call stack in codetools is checkUsagePackage -> checkUsageEnv -> 
checkUsage, and these are similarly established. The call from the tools 
package 
https://github.com/wch/r-source/blame/95146f0f366a36899e4277a6a722964a51b93603/src/library/tools/R/QC.R#L4585
 is also quite old.

I'm not sure this had been said explicitly, but perhaps the original intent was 
to protect against accidentally redefining a local function. Obviously one 
could do this with a local variable too, though that might less often be an 
error…

toto <- function(mode) {
tata <- function(a, b) a * b  # intended
tata <- function(a, b) a / b  # oops
…
}

Another workaround is to actually name the local functions

toto <- function(mode) {
tata <- function(a, b) a * b
titi <- function(u, v, w) (u + v) / w
if (mode == 1)
tata
else
titi
}

… or to use a switch statement

toto <- function(mode) {
## fun <- switch(…) for use of `fun()` in toto
switch(
mode,
tata = function(a, b) a * b,
titi = function(u, v, w) (u + v) / w,
stop("unknown `mode = '", mode, "'`")
)
}

… or similarly to write `fun <- if … else …`, assigning the result of the `if` 
to `fun`. I guess this last formulation points to the fact that a more careful 
analysis of Hervé's original code means that `fun` can only take one value 
(only one branch of the `if` can be taken) so there can only be one version of 
`fun` in any invocation of `toto()`.

Perhaps the local names (and string-valued 'mode') are suggestive of special 
case, so serve as implicit documentation?

Adding `…` to `tata` doesn't seem like a good idea; toto(1)(3, 5, 7) no longer 
signals an error.

There seems to be a lot in common with S3 and S4 methods, where `toto` 
corresponds to the generic, `tata` and `titi` to methods. This 'dispatch' is 
brought out by using `switch()`. There is plenty of opportunity for thinking 
that you're invoking one method but actually you're invoking the other. For 
instance with dplyr, I like that I can tbl |> print(n = 2) so much that I find 
myself doing this with data.frame df |> print(n = 2), which is an error (`n` 
partially matches `na.print`, and 2 is not a valid value); both methods 
silently ignore the typo print(m = 2).

Martin Morgan

From: R-devel  on behalf of Henrik Bengtsson 

Date: Tuesday, February 6, 2024 at 4:34 PM
To: Izmirlian, Grant (NIH/NCI) [E] 
Cc: r-devel@r-project.org 
Subject: Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions for 
?fun? with different formal arguments
Here's a dummy example that I think illustrates the problem:

toto <- function() {
  if (runif(1) < 0.5)
function(a) a
  else
function(a,b) a+b
}

> fcn <- toto()
> fcn(1,2)
[1] 3
> fcn <- toto()
> fcn(1,2)
[1] 3
> fcn <- toto()
> fcn(1,2)
Error in fcn(1, 2) : unused argument (2)

How can you use the returned function, if you get different arguments?

In your example, you cannot use the returned function without knowing
'mode', or by inspecting the returned function.  So, the warning is
there to alert you to a potential bug.  Anecdotally, I'm pretty sure
this R CMD check NOTE has caught at least one such bug in one of
my/our packages.

If you want to keep the current design pattern, one approach could be
to add ... to your function definitions:

toto <- function(mode)
{
 if (mode == 1)
 fun <- function(a, b, ...) a*b
 else
 fun <- function(u, v, w) (u + v) / w
 fun
}

to make sure that toto() returns functions that accept the same
minimal number of arguments.

/Henrik

On Tue, Feb 6, 2024 at 1:15 PM Izmirlian, Grant (NIH/NCI) [E] via
R-devel  wrote:
>
> Because functions get called and therefore, the calling sequence matters. 
> It’s just protecting you from yourself, but as someone pointed out, there’s a 
> way to silence such notes.
> G
>
>
> From: Hervé Pagès 
> Sent: Tuesday, February 6, 2024 2:40 PM
> To: Izmirlian, Grant (NIH/NCI) [E] ; Duncan Murdoch 
> ; r-devel@r-project.org
> Subject: Re: [EXTERNAL] Re: [Rd] NOTE: multiple local function definitions 
> for ?fun? with different formal arguments
>
>
> On 2/6/24 11:19, Izmirlian, Grant (NIH/NCI) [E] wrote:
> The note refers to the fact that the function named ‘fun’ appears to be 
> defined in two different ways.
>
> Sure I get that. But how is that any different from a variable being defined 
> in two different ways like in
>
> if (mode == 1)
> x <- -8
> else
> x <- 55
>
> This is such a common and perfectly fine pattern. Why would this be 
> considered a potential hazard when the variable is a function?
>
> H.
>
> From: Hervé Pagès 
> 
> Sent: Tuesday, February 6, 2024 2:17 PM
> To: Duncan Murdoch 
> ; Izmirlian, Grant 
> 

[Rd] Get list of active calling handlers?

[Duncan Murdoch]

The SO post https://stackoverflow.com/q/77943180 tried to call 
globalCallingHandlers() from a function, and it failed with the error 
message "should not be called with handlers on the stack".  A much 
simpler illustration of the same error comes from this line:


  try(globalCallingHandlers(warning = function(e) e))

The problem here is that try() sets an error handler, and 
globalCallingHandlers() sees it and aborts.


If I call globalCallingHandlers() with no arguments, I get a list of 
currently active global handlers.  Is there also a way to get a list of 
active handlers, including non-global ones (like the one try() added in 
the line above)?


Duncan Murdoch

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

Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions for ?fun? with different formal arguments

[Henrik Bengtsson]

Here's a dummy example that I think illustrates the problem:

toto <- function() {
  if (runif(1) < 0.5)
function(a) a
  else
function(a,b) a+b
}

> fcn <- toto()
> fcn(1,2)
[1] 3
> fcn <- toto()
> fcn(1,2)
[1] 3
> fcn <- toto()
> fcn(1,2)
Error in fcn(1, 2) : unused argument (2)

How can you use the returned function, if you get different arguments?

In your example, you cannot use the returned function without knowing
'mode', or by inspecting the returned function.  So, the warning is
there to alert you to a potential bug.  Anecdotally, I'm pretty sure
this R CMD check NOTE has caught at least one such bug in one of
my/our packages.

If you want to keep the current design pattern, one approach could be
to add ... to your function definitions:

toto <- function(mode)
{
 if (mode == 1)
 fun <- function(a, b, ...) a*b
 else
 fun <- function(u, v, w) (u + v) / w
 fun
}

to make sure that toto() returns functions that accept the same
minimal number of arguments.

/Henrik

On Tue, Feb 6, 2024 at 1:15 PM Izmirlian, Grant (NIH/NCI) [E] via
R-devel  wrote:
>
> Because functions get called and therefore, the calling sequence matters. 
> It’s just protecting you from yourself, but as someone pointed out, there’s a 
> way to silence such notes.
> G
>
>
> From: Hervé Pagès 
> Sent: Tuesday, February 6, 2024 2:40 PM
> To: Izmirlian, Grant (NIH/NCI) [E] ; Duncan Murdoch 
> ; r-devel@r-project.org
> Subject: Re: [EXTERNAL] Re: [Rd] NOTE: multiple local function definitions 
> for ?fun? with different formal arguments
>
>
> On 2/6/24 11:19, Izmirlian, Grant (NIH/NCI) [E] wrote:
> The note refers to the fact that the function named ‘fun’ appears to be 
> defined in two different ways.
>
> Sure I get that. But how is that any different from a variable being defined 
> in two different ways like in
>
> if (mode == 1)
> x <- -8
> else
> x <- 55
>
> This is such a common and perfectly fine pattern. Why would this be 
> considered a potential hazard when the variable is a function?
>
> H.
>
> From: Hervé Pagès 
> 
> Sent: Tuesday, February 6, 2024 2:17 PM
> To: Duncan Murdoch 
> ; Izmirlian, Grant 
> (NIH/NCI) [E] ; 
> r-devel@r-project.org
> Subject: [EXTERNAL] Re: [Rd] NOTE: multiple local function definitions for 
> ?fun? with different formal arguments
>
>
> Thanks. Workarounds are interesting but... what's the point of the NOTE in 
> the first place?
>
> H.
> On 2/4/24 09:07, Duncan Murdoch wrote:
> On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel wrote:
>
>
> Well you can see that yeast is exactly weekday you have.  The way out is to 
> just not name the result
>
> I think something happened to your explanation...
>
>
>
>
> toto <- function(mode)
> {
>  ifelse(mode == 1,
>  function(a,b) a*b,
>  function(u, v, w) (u + v) / w)
> }
>
> It's a bad idea to use ifelse() when you really want if() ... else ... .  In 
> this case it works, but it doesn't always.  So the workaround should be
>
>
> toto <- function(mode)
> {
> if(mode == 1)
> function(a,b) a*b
> else
> function(u, v, w) (u + v) / w
> }
>
>
>
>
>
>
> 
> From: Grant Izmirlian 
> Date: Sun, Feb 4, 2024, 10:44 AM
> To: "Izmirlian, Grant (NIH/NCI) [E]" 
> 
> Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2
>
> Hi,
>
> I just ran into this 'R CMD check' NOTE for the first time:
>
> * checking R code for possible problems ... NOTE
> toto: multiple local function definitions for �fun� with different
>formal arguments
>
> The "offending" code is something like this (simplified from the real code):
>
> toto <- function(mode)
> {
>  if (mode == 1)
>  fun <- function(a, b) a*b
>  else
>  fun <- function(u, v, w) (u + v) / w
>  fun
> }
>
> Is that NOTE really intended? Hard to see why this code would be
> considered "wrong".
>
> I know it's just a NOTE but still...
>
> I agree it's a false positive, but the issue is that you have a function 
> object in your function which can't be called unconditionally.  The 
> workaround doesn't create such an object.
>
> Recognizing that your function never tries to call fun requires global 
> inspection of toto(), and most of the checks are based on local inspection.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
>
> Hervé Pagès
>
>
>
> Bioconductor Core Team
>
> hpages.on.git...@gmail.com
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and are confident 
> the content is safe.
>
>
> --
>
> 

Re: [Rd] NOTE: multiple local function definitions for ?fun? with different formal arguments

[Duncan Murdoch]

On 06/02/2024 2:17 p.m., Hervé Pagès wrote:
Thanks. Workarounds are interesting but... what's the point of the NOTE 
in the first place?


Creating a function that can't be called could be an error.  Presumably 
you are careful and never try to call it with the wrong signature, but 
the check code isn't smart enough to follow every code path, so it gives 
the note to warn you that you might have something wrong.


You still have the same issue with my workaround, but the check code 
isn't smart enough to notice that.


Duncan Murdoch



H.

On 2/4/24 09:07, Duncan Murdoch wrote:
On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel 
wrote:
Well you can see that yeast is exactly weekday you have.  The way out 
is to just not name the result


I think something happened to your explanation...



toto <- function(mode)
{
 ifelse(mode == 1,
 function(a,b) a*b,
 function(u, v, w) (u + v) / w)
}


It's a bad idea to use ifelse() when you really want if() ... else ... 
.  In this case it works, but it doesn't always.  So the workaround 
should be



toto <- function(mode)
{
    if(mode == 1)
    function(a,b) a*b
    else
    function(u, v, w) (u + v) / w
}






From: Grant Izmirlian 
Date: Sun, Feb 4, 2024, 10:44 AM
To: "Izmirlian, Grant (NIH/NCI) [E]" 
Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2

Hi,

I just ran into this 'R CMD check' NOTE for the first time:

* checking R code for possible problems ... NOTE
toto: multiple local function definitions for �fun� with different
   formal arguments

The "offending" code is something like this (simplified from the real 
code):


toto <- function(mode)
{
 if (mode == 1)
 fun <- function(a, b) a*b
 else
 fun <- function(u, v, w) (u + v) / w
 fun
}

Is that NOTE really intended? Hard to see why this code would be
considered "wrong".

I know it's just a NOTE but still...


I agree it's a false positive, but the issue is that you have a 
function object in your function which can't be called 
unconditionally.  The workaround doesn't create such an object.


Recognizing that your function never tries to call fun requires global 
inspection of toto(), and most of the checks are based on local 
inspection.


Duncan Murdoch

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


--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com



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

Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions for ?fun? with different formal arguments

[Izmirlian, Grant (NIH/NCI) [E] via R-devel]

Because functions get called and therefore, the calling sequence matters. It’s 
just protecting you from yourself, but as someone pointed out, there’s a way to 
silence such notes.
G


From: Hervé Pagès 
Sent: Tuesday, February 6, 2024 2:40 PM
To: Izmirlian, Grant (NIH/NCI) [E] ; Duncan Murdoch 
; r-devel@r-project.org
Subject: Re: [EXTERNAL] Re: [Rd] NOTE: multiple local function definitions for 
?fun? with different formal arguments


On 2/6/24 11:19, Izmirlian, Grant (NIH/NCI) [E] wrote:
The note refers to the fact that the function named ‘fun’ appears to be defined 
in two different ways.

Sure I get that. But how is that any different from a variable being defined in 
two different ways like in

if (mode == 1)
x <- -8
else
x <- 55

This is such a common and perfectly fine pattern. Why would this be considered 
a potential hazard when the variable is a function?

H.

From: Hervé Pagès 

Sent: Tuesday, February 6, 2024 2:17 PM
To: Duncan Murdoch ; 
Izmirlian, Grant (NIH/NCI) [E] 
; 
r-devel@r-project.org
Subject: [EXTERNAL] Re: [Rd] NOTE: multiple local function definitions for 
?fun? with different formal arguments


Thanks. Workarounds are interesting but... what's the point of the NOTE in the 
first place?

H.
On 2/4/24 09:07, Duncan Murdoch wrote:
On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel wrote:


Well you can see that yeast is exactly weekday you have.  The way out is to 
just not name the result

I think something happened to your explanation...




toto <- function(mode)
{
 ifelse(mode == 1,
 function(a,b) a*b,
 function(u, v, w) (u + v) / w)
}

It's a bad idea to use ifelse() when you really want if() ... else ... .  In 
this case it works, but it doesn't always.  So the workaround should be


toto <- function(mode)
{
if(mode == 1)
function(a,b) a*b
else
function(u, v, w) (u + v) / w
}







From: Grant Izmirlian 
Date: Sun, Feb 4, 2024, 10:44 AM
To: "Izmirlian, Grant (NIH/NCI) [E]" 

Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2

Hi,

I just ran into this 'R CMD check' NOTE for the first time:

* checking R code for possible problems ... NOTE
toto: multiple local function definitions for �fun� with different
   formal arguments

The "offending" code is something like this (simplified from the real code):

toto <- function(mode)
{
 if (mode == 1)
 fun <- function(a, b) a*b
 else
 fun <- function(u, v, w) (u + v) / w
 fun
}

Is that NOTE really intended? Hard to see why this code would be
considered "wrong".

I know it's just a NOTE but still...

I agree it's a false positive, but the issue is that you have a function object 
in your function which can't be called unconditionally.  The workaround doesn't 
create such an object.

Recognizing that your function never tries to call fun requires global 
inspection of toto(), and most of the checks are based on local inspection.

Duncan Murdoch

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

--

Hervé Pagès



Bioconductor Core Team

hpages.on.git...@gmail.com
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and are confident the 
content is safe.


--

Hervé Pagès



Bioconductor Core Team

hpages.on.git...@gmail.com
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and are confident the 
content is safe.


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] r-oldrel-linux- not in CRAN checks?

[Ivan Krylov via R-package-devel]

В Tue, 6 Feb 2024 18:27:32 +0100
Vincent van Hees  пишет:

> For details see:
> https://github.com/RfastOfficial/Rfast/issues/99

GitHub processed your plain text description of the problem as if it
was Markdown and among other things ate the text that used to be there
between angle brackets:

> #include
>  ^~~

By digging through the raw source code of the issue at
https://api.github.com/repos/RfastOfficial/Rfast/issues/99 it is
possible to find out which header was missing for Rfast:

> ../inst/include/Rfast/parallel.h:20:10:fatal error: tion: No such
> file or directory
> #include 
>  ^~~
>compilation terminated.

Indeed,  is a C++17 header [1]. While g++ version
7.5.0-3ubuntu1~18.04 seems to accept --std=c++17 without complaint, its
libstdc++-7-dev package is missing this header. Moreover, there's still
no  in libstdc++-8-dev. I think that you need libstdc++-9
for that to work, which is not in Bionic; older versions aren't
C++17-compliant enough to compile Rfast, and C++17 is listed in the
SystemRequirements of the package.

Installing clang-10 and editing Makeconf to use clang++-10 instead of
g++ seems to let the compilation proceed. In order to successfully link
the resulting shared object, I also had to edit Makeconf to specify
-L/usr/lib/gcc/x86_64-linux-gnu/7 when linking -lgfortran.

If you plan to use this in production, be very careful. I don't know
about binary compatibility guarantees between g++-7 and clang++-10, so
you might have to recompile every C++-using R package from source with
clang++-10 in order to avoid hard-to-debug problems when using them
together. (It might also work fine. That's the worst thing about such
problems.)

-- 
Best regards,
Ivan

[1] https://en.cppreference.com/w/cpp/header/execution

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

Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions for ?fun? with different formal arguments

[Izmirlian, Grant (NIH/NCI) [E] via R-devel]

The note refers to the fact that the function named ‘fun’ appears to be defined 
in two different ways.

From: Hervé Pagès 
Sent: Tuesday, February 6, 2024 2:17 PM
To: Duncan Murdoch ; Izmirlian, Grant (NIH/NCI) [E] 
; r-devel@r-project.org
Subject: [EXTERNAL] Re: [Rd] NOTE: multiple local function definitions for 
?fun? with different formal arguments


Thanks. Workarounds are interesting but... what's the point of the NOTE in the 
first place?

H.
On 2/4/24 09:07, Duncan Murdoch wrote:
On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel wrote:

Well you can see that yeast is exactly weekday you have.  The way out is to 
just not name the result

I think something happened to your explanation...



toto <- function(mode)
{
 ifelse(mode == 1,
 function(a,b) a*b,
 function(u, v, w) (u + v) / w)
}

It's a bad idea to use ifelse() when you really want if() ... else ... .  In 
this case it works, but it doesn't always.  So the workaround should be


toto <- function(mode)
{
if(mode == 1)
function(a,b) a*b
else
function(u, v, w) (u + v) / w
}






From: Grant Izmirlian 
Date: Sun, Feb 4, 2024, 10:44 AM
To: "Izmirlian, Grant (NIH/NCI) [E]" 

Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2

Hi,

I just ran into this 'R CMD check' NOTE for the first time:

* checking R code for possible problems ... NOTE
toto: multiple local function definitions for �fun� with different
   formal arguments

The "offending" code is something like this (simplified from the real code):

toto <- function(mode)
{
 if (mode == 1)
 fun <- function(a, b) a*b
 else
 fun <- function(u, v, w) (u + v) / w
 fun
}

Is that NOTE really intended? Hard to see why this code would be
considered "wrong".

I know it's just a NOTE but still...

I agree it's a false positive, but the issue is that you have a function object 
in your function which can't be called unconditionally.  The workaround doesn't 
create such an object.

Recognizing that your function never tries to call fun requires global 
inspection of toto(), and most of the checks are based on local inspection.

Duncan Murdoch

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

--

Hervé Pagès



Bioconductor Core Team

hpages.on.git...@gmail.com
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and are confident the 
content is safe.


[[alternative HTML version deleted]]

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

Re: [Rd] NOTE: multiple local function definitions for ?fun? with different formal arguments

[Hervé Pagès]

Thanks. Workarounds are interesting but... what's the point of the NOTE 
in the first place?

H.

On 2/4/24 09:07, Duncan Murdoch wrote:
> On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel 
> wrote:
>> Well you can see that yeast is exactly weekday you have.  The way out 
>> is to just not name the result
>
> I think something happened to your explanation...
>
>>
>> toto <- function(mode)
>> {
>>  ifelse(mode == 1,
>>  function(a,b) a*b,
>>  function(u, v, w) (u + v) / w)
>> }
>
> It's a bad idea to use ifelse() when you really want if() ... else ... 
> .  In this case it works, but it doesn't always.  So the workaround 
> should be
>
>
> toto <- function(mode)
> {
>     if(mode == 1)
>     function(a,b) a*b
>     else
>     function(u, v, w) (u + v) / w
> }
>
>
>>
>>
>> 
>> From: Grant Izmirlian 
>> Date: Sun, Feb 4, 2024, 10:44 AM
>> To: "Izmirlian, Grant (NIH/NCI) [E]" 
>> Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2
>>
>> Hi,
>>
>> I just ran into this 'R CMD check' NOTE for the first time:
>>
>> * checking R code for possible problems ... NOTE
>> toto: multiple local function definitions for �fun� with different
>>    formal arguments
>>
>> The "offending" code is something like this (simplified from the real 
>> code):
>>
>> toto <- function(mode)
>> {
>>  if (mode == 1)
>>  fun <- function(a, b) a*b
>>  else
>>  fun <- function(u, v, w) (u + v) / w
>>  fun
>> }
>>
>> Is that NOTE really intended? Hard to see why this code would be
>> considered "wrong".
>>
>> I know it's just a NOTE but still...
>
> I agree it's a false positive, but the issue is that you have a 
> function object in your function which can't be called 
> unconditionally.  The workaround doesn't create such an object.
>
> Recognizing that your function never tries to call fun requires global 
> inspection of toto(), and most of the checks are based on local 
> inspection.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Fw: MungeSumstats Bioconductor

[Hervé Pagès]

Hi Alan,

The specs of the Linux servers have not changed.

However we've recently observed some of these random kills by the Linux 
kernel for a couple of other packages, and we started an application to 
get funding to increase the amount of RAM on these machines.

These random kills are a desperate attempt by the Linux kernel to keep 
the machine alive when it's under extremely high load and running out of 
resources. Unfortunately this is not something that anybody will be able 
to easily reproduce as it only happens under special circumstances e.g. 
during the daily builds when dozens of packages are being checked 
simultaneously.

Regardless of whether we'll manage to increase the memory on the Linux 
servers, it seems to me that the most memory-hungry unit tests in 
MungeSumstats would be a better fit for the long tests. These tests are 
run once a week instead of daily, and use less workers (4 instead of 
28). This means that each package has access to more resources.

See https://contributions.bioconductor.org/long-tests.html for how to 
set up the long tests in your package.

Let me know if you have questions or need help with this.

Best,

H.

On 2/2/24 09:14, alan murphy wrote:
> Hi,
>
> I'm the maintainer of the MungeSumstats package which is currently failing on 
> the devel nebbiolo1 Linux platform because of RAM requirements of the unit 
> tests. These tests use large reference datasets (like 
> BSgenome.Hsapiens.1000genomes.hs37d5::BSgenome.Hsapiens.1000genomes.hs37d5) 
> which cause the issue, e.g. from the output of the devel linux 
> test:
>
> ```
>
> Validating RSIDs of 92 SNPs using BSgenome::snpsById...
> Killed
>
> ```
> which is from this 
> function:https://github.com/neurogenomics/MungeSumstats/blob/cccf77b2249f52be59fe1749f13a386ffaaae528/R/load_ref_genome_data.R#L49
>
> I would like to keep these units tests as they are very important for me to 
> know if things have gone wrong. I can't scale down the RAM usage, it is only 
> using a few rows of data as it, the issue is that the reference sets are 
> massive rather than the actual set being tested. I currently don't have a lot 
> of these tests set to run on windows/mac platforms so I rely on the Linux 
> machines to run this. I am not sure what has changed but a few releases back, 
> the same tested were not causing this issue and would complete on linux - has 
> the machine spec changed? Is there any chance RAM could be increased for 
> these tests or is there a way to specify not to run the specific unit tests 
> on the Bioconductor server so I can at least keep these for my github actions 
> workflows? See below for the automated message I got about these errors.
>
> Any other suggestions on ways around this would be greatly appreciated!
>
> Thanks,
> Alan.
> 
> From: CoreTeam Bioconductor
> Sent: Friday 2 February 2024 16:43
> To:alanmurp...@hotmail.com  
> Subject: MungeSumstats Bioconductor
>
> Hello Package Maintainer,
>
> We would like to bring to your attention that your package is failing in 
> devel on the linux platform. This is very problematic. Please investigate the 
> issues and fix the package to avoid deprecation.
>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/
> 
>
> If you have further questions or concerns please reach out on 
> thebioc-de...@r-project.org
>
> We appreciate your quick attention to this matter
>
> Cheers,
> On behalf of the Bioconductor Core Team
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

[R-pkg-devel] r-oldrel-linux- not in CRAN checks?

[Vincent van Hees]

Hello,

I noticed that there is no r-oldrel-linux-x86_64... on the CRAN
package results page. Does this mean that CRAN checks no longer run on
old Debian releases?

The reason for asking this is that I am struggling to install Rfast on
Ubuntu 18, which made me wonder whether CRAN/R community no longer
support Ubuntu 18? For details see:
https://github.com/RfastOfficial/Rfast/issues/99

Thanks,

Vincent

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

Re: [Rd] Advice debugging M1Mac check errors

[J C Nash]

M1mac numerical issues should be rare, but when they do pop up they can be 
disconcerting.

The following little script reveals what happens with no extended precision. A 
few months
ago I built this into a "package" and used 
https://mac.r-project.org/macbuilder/submit.html
to run it, getting the indicated result of 0 for (sum(vv1) - 1.0e0), with 
non-zero on my
Ryzen 7 laptop.

JN

# FPExtendedTest.R   J C Nash
loopsum <- function(vec){
   n <- length(vec)
   vsum<-0.0
   for (i in 1:n) { vsum <- vsum + vec[i]}
   vsum
}
small<-.Machine$double.eps/4 # 1/4 of the machine precision
vsmall <- rep(small, 1e4) # a long vector of small numbers
vv1 <- c(1.0, vsmall) # 1 at the front of this vector
vv2 <- c(vsmall, 1.0) # 1 at the end
(sum(vv1) - 1.0e0) # Should be > 0 for extended precision, 0 otherwise
(sum(vv2) - 1.0e0) # Should be > 0
(loopsum(vv1) - 1.0e0) # should be zero
(loopsum(vv2) - 1.0e0) # should be greater than zero



On 2024-02-06 08:06, Prof Brian Ripley via R-devel wrote:



We were left to guess, but I doubt this has to do with the lack of 'extended precision' nor long doubles longer than 
doubles on arm64 macOS.  And issues with that are rather rare (much rarer than numerical issues for non-reference x86_64 
BLAS/LAPACKs).  Of the 20,300 CRAN packages just 18 have M1mac-specific errors, none obviously from numerical 
inaccuracy.  A quick look back suggests we get about 20 a year with M1mac numerical issues, about half of which were 
mirrored on the x86_64 'noLD' checks.




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

Re: [Rd] Advice debugging M1Mac check errors

[Prof Brian Ripley via R-devel]

On 04/02/2024 19:41, Holger Hoefling wrote:

Hi,

I wanted to ask if people have good advice on how to debug M1Mac package
check errors when you don´t have a Mac? Is a cloud machine the best option
or is there something else?


I presumed this was about a CRAN package, possibly hdf5r which has a 
R-devel-only warning from the Apple clang compiler.  And that is not a 
'check error' and not something to 'debug'.


The original poster had errors for his package flsa until yesterday on 
fedora-clang and M1mac, which were compilation errors with recent LLVM 
and Apple compilers.  Again, not really something to 'debug' -- the 
compiler messages were clear and the CRAN notification contained advice 
on where in our manual to look this up.


The mac-builder service offers checks for R 4.3.0, the 'development' 
option being (last time I tried) the same as the 'release' option. (When 
I asked, Simon said that 'development' checks were only available in the 
run up to a x.y.0 when he starts package building and checks for R-devel.)



We were left to guess, but I doubt this has to do with the lack of 
'extended precision' nor long doubles longer than doubles on arm64 
macOS.  And issues with that are rather rare (much rarer than numerical 
issues for non-reference x86_64 BLAS/LAPACKs).  Of the 20,300 CRAN 
packages just 18 have M1mac-specific errors, none obviously from 
numerical inaccuracy.  A quick look back suggests we get about 20 a year 
with M1mac numerical issues, about half of which were mirrored on the 
x86_64 'noLD' checks.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [Rd] NROW and NCOL on NULL

[Simone Giannerini]

I just saw this

r85704 | hornik | 2023-12-19 00:33:07 -0600 (Tue, 19 Dec 2023) | 1 line
Changed paths:
   M /trunk/doc/NEWS.Rd
   M /trunk/src/library/base/R/matrix.R
   M /trunk/src/library/base/man/nrow.Rd
   M /trunk/src/library/profile/Common.R

Have NCOL(NULL) return 0 instead of 1.


Many thanks to Kurt and the whole R-core team!

Simone

On Sat, Sep 23, 2023 at 7:43 PM Simone Giannerini  wrote:
>
> Dear list,
>
> I do not know what would be the 'correct' answer to the following but
> I think that they should return the same value to avoid potential
> problems and hard to debug errors.
>
> Regards,
>
> Simone
> ---
>
> > NCOL(NULL)
> [1] 1
>
> > NROW(NULL)
> [1] 0
>
> > sessionInfo()
> R version 4.3.1 RC (2023-06-08 r84523 ucrt)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 11 x64 (build 22621)
>
> Matrix products: default
>
>
> locale:
> [1] LC_COLLATE=Italian_Italy.utf8  LC_CTYPE=Italian_Italy.utf8
> [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C
> [5] LC_TIME=Italian_Italy.utf8
>
> time zone: Europe/Rome
> tzcode source: internal
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.3.1
>
> --
> ___
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126  Bologna,  ITALY
> Tel: +39 051 2098262  Fax: +39 051 232153
> https://simonegiannerini.net/
> ___



-- 
___

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126  Bologna,  ITALY
Tel: +39 051 2098262  Fax: +39 051 232153
https://simonegiannerini.net/

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