Skip to content

[Bioc-devel] 'tokay1' error but passed other OS

10 messages · Venu Thatikonda, Kasper Daniel Hansen, Shepherd, Lori +1 more

Original
Venu Thatikonda
# 
Hi,

One of my packages during the review is giving an error in bioc windows
system. When I build and check from my side in a windows system, there is
no error.

It's been over a week, not sure what's happening? Should I do something
from my side?

Bioc issue: https://github.com/Bioconductor/Contributions/issues/1215

Build report:
http://bioconductor.org/spb_reports/ALPS_buildreport_20190827110407.html

Any update/suggestions would be helpful.

Thank you.
Kasper Daniel Hansen
# 
Well, yes, its the status on the build system which matters.

In your case it looks like you're doing BigWig parsing. Unfortunately, some
of the tools we have for reading BigWig (tracklayer) does not work reliably
on Windows - sometimes it works, sometimes it doesn't. My _guess_ is that
you're running into this.

It would be great to get this fixed, although that is not your package's
issue.  One possible alternative is https://github.com/dpryan79/libBigWig
which Brent Peterson recommends. I don't know if that works on Windows, but
at least its not Kent tools.

Best,
Kasper

On Wed, Sep 4, 2019 at 11:45 AM Venu Thatikonda <thatikonda92 at gmail.com>
wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Shepherd, Lori
    

    

      
      #
    

  


  

      
I looked into this more on our builders.  The examples run fine on 64 bit.  This seems to be caused by a 32-bit Windows specific ERROR from the rtracklayer summary() function for BigWigFile objects.

I will open an issue with rtracklayer (when I can come up with a minimal reproducible example) and will post the issue link in your open issue on the Contributions tracker to also monitor.


In the meantime you could add a file  .BBSoptions that contains the line UnsupportedPlatforms: win32  to get an accurate build report and avoid building on the 32 bit window until the issue is resolved.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Also note that since the error is specific to 32-bit Windows, you need 
to run 'R CMD check --force-multiarch' on your package source tarball in 
order to reproduce the error. Without the --force-multiarch flag, 'R CMD 
check' only runs the examples and unit tests for the default arch, 
which, for 99.99% of Windows users is the 64-bit arch.

H.

        
On 9/4/19 10:51, Shepherd, Lori wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Kasper Daniel Hansen
    

    

      
      #
    

  


  

      
Thanks

My experience with rtracklayer, bigwig and windows is indeed on some
windows machines it works, and others it don't. Not sure what the deciding
factor is, but if it is truly 32 vs 64 bit, that's interesiting

On Wed, Sep 4, 2019 at 1:51 PM Shepherd, Lori <Lori.Shepherd at roswellpark.org>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Venu Thatikonda
    

    

      
      #
    

  


  

      
@Daniel, I guess using libBigWig cause even more problems while build,
check commands as this is an non R library. But I'm not sure if this works
out.

@Lori, Thanks a lot for looking into the error. Interesting to see what's
missing from win32. I will add the .BBSoptions file and bump the version as
suggested. I can create a small example to reproduce the error(?), to open
an issue at rtracklayer, please let me know if that's okay.

Thank you.

On Wed, Sep 4, 2019 at 8:50 PM Kasper Daniel Hansen <

        
kasperdanielhansen at gmail.com> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Shepherd, Lori
    

    

      
      #
    

  


  

      
Venu,
If you can produce a minimal example that can reproduce it and open the issue on rtracklayer github that would be great.  Please tag me when you do so I can keep track of it also @lshep on GitHub
Cheers

Get Outlook for Android<https://aka.ms/ghei36>

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Kasper Daniel Hansen
    

    

      
      #
    

  


  

      
Venu, you should really follow Herve's suggestion and use R CMD check
--force-multiarch and report back the result.

On Wed, Sep 4, 2019 at 3:32 PM Shepherd, Lori <Lori.Shepherd at roswellpark.org>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Venu Thatikonda
    

    

      
      #
    

  


  

      
@Lori, sure. I will open the issue with an example.

@Daniel, I didn't understand, I thought this suggestion is for Lori (?).

Do I need to run `R CMD check --force-multiarch` on a windows 32bit system
from my side? If that's the case, It won't be practical from my side,
because I have to borrow someone's system who is using win32. If not, I ran
it on macOS with '--force-multiarch' and it's clean. Except one note about
'.BBSoptions' file, I guess it's okay? Any clarifications would be
appreciated.

Thank you.


On Wed, Sep 4, 2019 at 9:38 PM Kasper Daniel Hansen <

        
kasperdanielhansen at gmail.com> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
On 9/4/19 14:10, Venu Thatikonda wrote:

            

      
      
      
    

        
Short answer: The suggestion to run 'R CMD check --force-multiarch' was 
for you so you can reproduce the error.

Long answer: Any Windows system I know from the last 15 years or so can 
run processes in 64-bit or 32-bit mode. As you can see here

   https://cran.r-project.org/bin/windows/base/

the Windows binary for R that is available on CRAN is a 32/64 bit 
binary. This means that it can be run in either mode. You can choose the 
mode in which you want to run R by specifying --arch x64 or --arch i386 
when invoking R. The 64-bit mode is the default so starting R with 'R 
--arch x64' is the same as just starting it with 'R'. The startup 
message tells you if R is running in 64-bit or 32-bit mode.

Now about packages: You can check your package with 'R --arch x64 CMD 
check' (or just 'R CMD check') in which case all the examples and unit 
tests are run in 64-bit mode. If you check your package with 'R --arch 
i386 CMD check' then all the examples and unit tests are run in 32-bit 
mode. If you check your package with 'R CMD check --force-multiarch' 
then all the examples and unit tests are run in both 32-bit and 64-bit. 
This is the recommended way to fully check a package on Windows. Note 
that this is also what our build system does. See for example the 
command used to check the Biobase package on our Windows server tokay1:
https://bioconductor.org/checkResults/3.10/bioc-LATEST/Biobase/tokay1-checksrc.html

AFAIK almost nobody runs R in 32-bit mode on Windows these days so it is 
not a big deal to mark your package as unsupported on 32-bit Windows. 
The only reason we check that packages run fine on 32-bit Windows is 
because we **distribute** Windows binary packages that are also 32/64 
bit binaries (like R itself) and we want to make sure that the bi-arch 
binaries work as expected. And the only reason we distribute these 
Windows bi-arch binaries is because that's what the CRAN folks do.

Hope this helps,

H.