[R-pkg-devel] spp package error "Package required but not available: ‘Rsamtools’"
Hi all, I have a question regarding the CRAN checks for package spp: https://cran.r-project.org/web/checks/check_results_spp.html We didn't update or change anything in the package, but since a few weeks the CRAN check for OSX gives an error saying that a dependency is not available: Package required but not available: ‘Rsamtools’ Rsamtools is available on Bioconductor and the error shows up only on MAC. Is Rsamtools missing in the repository of the architecture? Thanks, Carmen [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] spp package error "Package required but not available: ‘Rsamtools’"
Perhaps ask Simon Urbanek, the CRAN Mac maintainer, what is going on here. Best, Uwe Ligges On 18.06.2018 11:33, Carmen M. Livi wrote: Hi all, I have a question regarding the CRAN checks for package spp: https://cran.r-project.org/web/checks/check_results_spp.html We didn't update or change anything in the package, but since a few weeks the CRAN check for OSX gives an error saying that a dependency is not available: Package required but not available: ‘Rsamtools’ Rsamtools is available on Bioconductor and the error shows up only on MAC. Is Rsamtools missing in the repository of the architecture? Thanks, Carmen [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] spp package error "Package required b ut not available: ‘Rsamtools’"
Dear Simon Urbanek, Since a few weeks I am getting a CRAN-check error under OSX for the package "spp" (https://cran.r-project.org/web/checks/check_results_spp.html): "Package required but not available: ‘Rsamtools’ Rsamtools is available on Bioconductor and the error shows up only on MAC. Is it possible that Rsamtools is missing in the repository of the architecture? Thank you very much, Carmen Uwe Ligges (lig...@statistik.tu-dortmund.de) wrote: > > Perhaps ask Simon Urbanek, the CRAN Mac maintainer, what is going on here. > > Best, > Uwe Ligges > > > > > On 18.06.2018 11:33, Carmen M. Livi wrote: > > Hi all, > > > > I have a question regarding the CRAN checks for package spp: > > > > https://cran.r-project.org/web/checks/check_results_spp.html > > > > We didn't update or change anything in the package, but since a few > > weeks the CRAN check for OSX gives an error saying that a dependency is > > not available: > > > > Package required but not available: ‘Rsamtools’ > > > > Rsamtools is available on Bioconductor and the error shows up only on > > MAC. Is Rsamtools missing in the repository of the architecture? > > > > Thanks, > > Carmen > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > -- Carmen Maria Livi Post Doctoral Researcher Ferrari Lab IFOM - Fondazione Istituto firc Oncologia Molecolare Via Adamello 16 20139 Milano, Italy __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Recommended procedure for solving "Additional issues"?
On Sun, Jun 17, 2018 at 2:13 AM Uwe Ligges wrote: > > > > On 16.06.2018 21:46, Marius Hofert wrote: > > Dear DevelopeRs, > > > > Is there a recommended procedure for addressing "Additional issues" if > > they appear on CRAN checks? > > > > Say you have some C code in a package which checks fine (Status OK for > > all flavors) but shows "Additional issues" due to a potential memory > > problems. One can compile an R version configured with valgrind > > support and run a corresponding check on the package, but that > > a) ... sometimes shows false positives (on Mac, for example, as some > > have reported, see > > https://stackoverflow.com/questions/29312335/valgrind-on-os-x-yosemite-giving-bogus-errors) > > b) ... sometimes doesn't provide useful information (at least not in a > > case I recently ran into). > > c) Also, one can virtually not always check for all the "Additional > > issues" that might appear *before* submitting a package to CRAN -- or > > can one? > > > > Concerning c), it would be great if there was a way to 'see' the > > "Additional issues" *before* submitting to CRAN (like a winbuilder or > > so). Is there? (I couldn't find anything in WRE). Otherwise, one can > > do the usual (like --as-cran), hope everything is fine, wait until the > > CRAN checks are reported, and then, if there are problems, carefully > > look at the code again, try and find the problem and resubmit in the > > hope that the problem is fixed => but that's not a good 'procedure' as > > it creates more work for CRAN etc. > > > Well, you can try to run with valgrind and the sanitizers before you > submit to CRAN yourself. Hi Uwe, thanks for helping. valgrind reported false positives, and 'ASAN' I still struggle with (setting the flags in ~/.R/Makevars as in WRE led me to some 'Interceptors not working' errors -- might post a question on this one, not sure if I understood that part correctly). > Or use R-hub which offers to use builds with > enabled sanitizers. I tried that, thanks for this hint. I got some weird bioconductor errors (which seem to have nothing to do with my package). I contacted ad...@r-hub.io but didn't get a response yet (don't think that's the right way to contact them, but found no other way...). > > But you are right, running with valgrind + sanitizers + rchk (protection > stack imbalance checks) + different BLAS installations is not feasible > in case you do not suspect problems. > > That is also the reason why CRAN does not always detect these issues in > the incoming checks, as these checks run only on different specific > machines in batches. Would of course be great if we could use exactly the same machines, so uploading the .tar.gz would reproduce the 'Additional issues' and one could try that until all issues are resolved (without the need for local tinkering) before officially submitting a package to CRAN. Cheers, M > > Best, > Uwe Ligges > > > > > > > Am I missing anything? > > > > Thanks & cheers, > > Marius > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] How to check memory access (understanding Section 4.3 WRE)
Hi, I tried to understand how to check memory access of an R package with C code; see https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access I'm about 90% sure I understood WRE Section 4.3.2 about valgrind. In essence: 1) When configuring R before make, use the configure flags '-C --with-valgrind-instrumentation=2 --with-system-valgrind-headers' to get a memory-profiling-enabled version of R. This I found on https://www.stats.ox.ac.uk/pub/bdr/memtests/README.txt and it's also described at the bottom of https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Configuration-options 2) Then use 'R CMD check --use-valgrind' or directly check examples via 'R -d "valgrind --tool=memcheck --leak-check=full" --vanilla < mypkg-Ex.R' I also seems to work (but reports false positives for Mac as others have reported). I'm still struggling with 4.3.3, see https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Address-Sanitizer. It says "The simplest way to make use of this is to build a version of R with something like..." and CC="gcc -std=gnu99 -fsanitize=address" CFLAGS="-fno-omit-frame-pointer -g -O2 -Wall -pedantic -mtune=native" I set these flags via 'configure CC="gcc -std=gnu99 -fsanitize=address" CFLAGS="-fno-omit-frame-pointer -g -O2 -Wall -pedantic -mtune=native"' before 'make'. I used R-devel for it and the installation was fine. Is there any option 'R CMD check' would need to obtain (like the '--use-valgrind' above)? 'R CMD check mypkg.tar.gz' doesn't seem to do any memory access checking. Would I also need to set "MAIN_LDFLAGS=-fsanitize=address" for configure? (it's a bit unclear from WRE whether this applies to both of the approaches mentioned or just to the one based on Makevars) I also tried the second approach based on "~/.R/Makevars" and put the following in "~/.R/Makevars" as suggested in WRE: CC = gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer CXX = g++ -fsanitize=address -fno-omit-frame-pointer F77 = gfortran -fsanitize=address FC = gfortran -fsanitize=address 'R CMD check mypkg.tar.gz' then fails and 00install.out shows (on macOS 10.13.5, R-3.5.0 here): * installing *source* package ‘mypkg’ ... ** libs ... * R ** demo ** byte-compile and prepare package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded sh: line 1: 14016 Abort trap: 6 '/usr/local/R/R-3.5.0_build/bin/R' --no-save --slave 2>&1 < '/var/folders/cb/drz6kv896317dzbg52flzn_rgn/T//RtmpTha0EH/file369f755a95ad' ==14016==ERROR: Interceptors are not working. This may be because AddressSanitizer is loaded too late (e.g. via dlopen). Please launch the executable with: DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.1.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib "interceptors not installed" && 0 ERROR: loading failed * removing ‘/Users/mhofert/pro/mypkg/mypkg.Rcheck/mypkg’ Any ideas where the 'DYLD_INSERT_LIBRARIES' should go? Thanks & cheers, Marius __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Recommended procedure for solving "Additional issues"?
On 18.06.2018 16:38, Marius Hofert wrote: On Sun, Jun 17, 2018 at 2:13 AM Uwe Ligges wrote: On 16.06.2018 21:46, Marius Hofert wrote: Dear DevelopeRs, Is there a recommended procedure for addressing "Additional issues" if they appear on CRAN checks? Say you have some C code in a package which checks fine (Status OK for all flavors) but shows "Additional issues" due to a potential memory problems. One can compile an R version configured with valgrind support and run a corresponding check on the package, but that a) ... sometimes shows false positives (on Mac, for example, as some have reported, see https://stackoverflow.com/questions/29312335/valgrind-on-os-x-yosemite-giving-bogus-errors) b) ... sometimes doesn't provide useful information (at least not in a case I recently ran into). c) Also, one can virtually not always check for all the "Additional issues" that might appear *before* submitting a package to CRAN -- or can one? Concerning c), it would be great if there was a way to 'see' the "Additional issues" *before* submitting to CRAN (like a winbuilder or so). Is there? (I couldn't find anything in WRE). Otherwise, one can do the usual (like --as-cran), hope everything is fine, wait until the CRAN checks are reported, and then, if there are problems, carefully look at the code again, try and find the problem and resubmit in the hope that the problem is fixed => but that's not a good 'procedure' as it creates more work for CRAN etc. Well, you can try to run with valgrind and the sanitizers before you submit to CRAN yourself. Hi Uwe, thanks for helping. valgrind reported false positives, and 'ASAN' I still struggle with (setting the flags in ~/.R/Makevars as in WRE led me to some 'Interceptors not working' errors -- might post a question on this one, not sure if I understood that part correctly). Or use R-hub which offers to use builds with enabled sanitizers. I tried that, thanks for this hint. I got some weird bioconductor errors (which seem to have nothing to do with my package). I contacted ad...@r-hub.io but didn't get a response yet (don't think that's the right way to contact them, but found no other way...). Not sure, Gabor Czardi is a main maintainer of that service, I am sure he will respond quickly. But you are right, running with valgrind + sanitizers + rchk (protection stack imbalance checks) + different BLAS installations is not feasible in case you do not suspect problems. That is also the reason why CRAN does not always detect these issues in the incoming checks, as these checks run only on different specific machines in batches. Would of course be great if we could use exactly the same machines, so uploading the .tar.gz would reproduce the 'Additional issues' and one could try that until all issues are resolved (without the need for local tinkering) before officially submitting a package to CRAN. Yes, but unfortunately that is not possible for the machines we are talking about. Best, Uwe Cheers, M Best, Uwe Ligges Am I missing anything? Thanks & cheers, Marius __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
