Skip to content

[R-pkg-devel] Warning that are Unintentionally OS-Specific (Maybe Bug in warning?)

6 messages · François Michonneau, MTurgeon, Ben Bolker +1 more

Original
Bill Denney
# 
Hi,

I'm developing the PKNCA package, and I've got an odd difference between 
warning behavior on different operating systems that I can't figure out.

When I run the following code on Windows 10 (with R 3.3.0), I get the 
following warning:

library(PKNCA)
source("https://raw.githubusercontent.com/billdenney/pknca/master/tests/testthat/generate.data.R")
tmpconc <- generate.conc(2, 1, 0:24)
tmpconc$conc <- 0
tmpdose <- generate.dose(tmpconc)
myconc <- PKNCAconc(tmpconc, conc~time|treatment+ID)
mydose <- PKNCAdose(tmpdose, dose~time|treatment+ID)
mydata <- PKNCAdata(myconc, mydose)
myresult <- pk.nca(mydata)

Warning messages:
1: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
   Too few points for half-life calculation (min.hl.points=3 with only 0 
points)
2: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
   Too few points for half-life calculation (min.hl.points=3 with only 0 
points)

When I run the code on Linux (Ubuntu 16.04 with R 3.3.1), I do not get a 
warning.  When I run the code on Linux after "options(warn=1)", I get 
the warning.  I have confirmed that the same code path is taken in both 
Windows and Linux by simply inserting a print statement next to the 
warning.  The actual warning code is:

     warning(sprintf(
       "Too few points for half-life calculation (min.hl.points=%g with 
only %g points)",
       min.hl.points, nrow(dfK)))

This platform inconsistency is causing issues with my package because 
the package expects the warnings, and the user should know about the 
warnings.  I've got test cases expecting the warnings, and they fail 
everywhere but Windows 
(https://cran.r-project.org/web/checks/check_results_PKNCA.html).

Does anyone have an idea why warnings may behave differently on Windows 
compared to non-Windows platforms?  Is this a bug in R somewhere?  (I've 
not been able to make a simpler example that triggers the issue, 
unfortunately.)

Thanks,

Bill
François Michonneau
# 
Hi Bill,

  The problem is not with the warning() function but with your if()
test that triggers the warning. It probably has something to do with
slight differences in rounding. I suggest you use debug() or browser()
on each platform to see why your condition is TRUE or FALSE.

  Cheers,
  -- Fran?ois
On Wed, Jul 20, 2016 at 2:42 PM, Bill Denney <bill at denney.ws> wrote:
Bill Denney
# 
Hi Fran?ois,

I thought that was the issue, too, but I confirmed it wasn't that by 
adding a print statement right above the warning in my code. The print 
statement displays the message even when the warning (one line below 
with no conditionals between) doesn't show anything.

Also, why would it behave differently when options(warn=1) is set rather 
than the default of options(warn=0)?

Thanks,

Bill
On 7/20/2016 3:06 PM, Fran?ois Michonneau wrote:
MTurgeon
# 
Hi Bill,

This is just a hypothesis, but it could have something to do with the 
fact that you're using parallel::mclapply inside your function pk.nca? 
This would certainly explain why you have different behaviours on 
Windows and Unix systems. It would also explain why you get a different 
behaviour between options(warn=0) and options(warn=1), since the master 
receives the exceptions at different times in both cases.

Max
On 16-07-20 01:13 PM, Bill Denney wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
Digging into the code (specifically by setting
options(warn=2,error=recover), I see that the warning is happening
during this call:

    tmp.results <- parallel::mclapply(X = conc.dose, FUN =
pk.nca.intervals,
    intervals = data$intervals, options = data$options)

Since mclapply "relies on forking and hence is not available on Windows
unless ?mc.cores = 1?" (from ?mclapply), I can imagine that it's *not*
actually being run in parallel on Windows.  It also wouldn't surprise me
at all if it took a little bit of care to make sure that warnings were
correctly passed back from code chunks run in parallel.

  This StackOverflow post seems to ask the same question as yours:

http://stackoverflow.com/questions/21486658/warnings-suppressed-with-mclapply-in-r

  based on the discussion there, it seems as though it might be worth
bringing this up on r-devel/submitting a bug report ...

   Ben Bolker

        
On 16-07-20 03:13 PM, Bill Denney wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Bill Denney
    

    

      
      #
    

  


  

      
Max and Ben got the right answer.  It is a bug with mclapply dropping 
warnings.  I confirmed by a quick change to the code to just use lapply, 
and the warnings appeared as expected.

I've submitted the bug at 
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17122

Thanks for the help!

Bill

        
On 7/20/2016 3:40 PM, Ben Bolker wrote: