Re: [R-pkg-devel] dtrti2 error on CRAN checks
Benjamin, did you try with rhub? Gábor makes a great effort there to keep it up to date with CRAN machines. And even if you still are not able to reproduce it with the current config, you could try to modify the docker file yourself. Iñaki On Thu, 18 Apr 2019 at 07:53, Benjamin Christoffersen wrote: > > Thanks for the quick reply. First a correction. I meant Ubuntu 18.04.2 > of course, sorry. > > > In short, you need to look more closely. > Is there a way to tell which BLAS and LAPACK is used on the Debian > machines on CRAN? I checked the "CRAN Package Check Flavors" page but > there is no information there regarding BLAS or LAPACK. > > I have tried to test the package with Atlas, OpenBlas, and the > reference implementation with gcc 7.3.0 and 8.2.0. It all worked > without any errors. > > It seems that gcc has changed since January from version 8.2.0 and > 7.3.0 to 8.3.0 on the tests on CRAN. Further, it is now Debian version > 8.3.0-2 instead of Debian 8.2.0-7 and Debian 7.3.0-29. I do not know > whether this can matter. > > Sincerely yours, > Benjamin Christoffersen > > > > > > > > Den ons. 17. apr. 2019 kl. 11.38 skrev Dirk Eddelbuettel : > > > > > > On 17 April 2019 at 11:06, Benjamin Christoffersen wrote: > > | Since the start of April, I have gotten some errors on the Debian > > | machines on the check on CRAN for my package dynamichazard. The places > > | where I get the errors seems to come down to LAPACK's dtrtri routine. > > | I have tried to reproduce the error on Debian 18.04.2 with clang 8.0.0 > > | but I cannot reproduce them. > > | > > | The errors came suddenly and the tests passed before. I see similar > > | issues (I think) in the following package: > > | - RcppHMM > > | - BNPmix > > | - themetagenomics > > | - tidytext > > | - stm > > | > > | Any ideas what the error may be? Here is the relevant code parts for > > | one of the failed tests: > > | > > https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/for_tests.cpp#L216 > > | > > https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/arma_BLAS_LAPACK.cpp#L26 > > | > > https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L67 > > > > There are four or more different sources of LAPACK and BLAS on Debian as we > > (since the late 1990s !!) utilize the nature of the _interface_ allowing > > different packages to fill in. > > > > So there could be > > i) the R internal source with a partial library -- Fedora/CentOS use > > this > >but the Debian distro builds do not > > ii) "reference BLAS", external, unoptimized > > iii) OpenBLAS, the successor to Goto, parallel via multithreading > > iv) Atlas, "tuned" but not mulitthreading > > and more as eg Intel MKL via a quick script (see my blog). > > > > As a historical aside, and way-back-when, ii) earned us year's long growling > > from the direction of Oxfordshire because some early/old versions of LAPACK > > had bugs. But it cuts both ways: the external versions tend to be complete > > whereas what R ships with internally contains a subset -- and at least one > > (early) user of RcppArmadillo was bitten when R built from sources using > > defaults would not have the complex operations he needed. To R Core's credit > > these missing functions got filled in over the years. > > > > In short, you need to look more closely. On the Ubuntu 18.10 machine that I > > type this on, sessionInfo()'s second paragraph has > > > > Matrix products: default > > BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 > > LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.3.so > > > > which IIRC is also the default (via some Debian/Ubuntu internal 'ordering' > > of > > the available alternatives). > > > > Hth, Dirk > > > > -- > > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Iñaki Úcar __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] dtrti2 error on CRAN checks
On 18.04.19 07:53, Benjamin Christoffersen wrote: >> In short, you need to look more closely. > Is there a way to tell which BLAS and LAPACK is used on the Debian > machines on CRAN? I am sure CRAN machines use BLAS and LAPACK as shipped with R, i.e. not *any* variant of system BLAS/LAPACK. cheerio ralf -- Ralf Stubner Senior Software Engineer / Trainer daqana GmbH Dortustraße 48 14467 Potsdam T: +49 331 23 61 93 11 F: +49 331 23 61 93 90 M: +49 162 20 91 196 Mail: ralf.stub...@daqana.com Sitz: Potsdam Register: AG Potsdam HRB 27966 Ust.-IdNr.: DE300072622 Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze signature.asc Description: OpenPGP digital signature __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] long file names in tar
My Boom package makes a C++ library available to package authors (mainly me). The wrapped library is used outside of R and must comply with external style rules such as UseLongDescriptiveNames, and files must be named for the class they contain. From time to time a LongDescriptiveFileName, when paired with its full directory path, exceeds 100 characters. This creates a conflict with CRAN's rules about long file names, which stems from tar. I'm wondering what this community thinks about asking for that rule to be relaxed. Both gnu tar and posix tar now allow unlimited length filenames, and the ustar format allows names up to 256 characters. I'm interested in the opinions of people on this list about whether this rule has outlived its usefulness. Thanks. [[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] long file names in tar
On 18 April 2019 at 10:37, Steven Scott wrote: | My Boom package makes a C++ library available to package authors (mainly | me). The wrapped library is used outside of R and must comply with | external style rules such as UseLongDescriptiveNames, and files must be | named for the class they contain. From time to time a | LongDescriptiveFileName, when paired with its full directory path, exceeds | 100 characters. | | This creates a conflict with CRAN's rules about long file names, which | stems from tar. I'm wondering what this community thinks about asking for | that rule to be relaxed. Both gnu tar and posix tar now allow unlimited | length filenames, and the ustar format allows names up to 256 characters. | | I'm interested in the opinions of people on this list about whether this | rule has outlived its usefulness. Thanks. There are no "opinions". There is CRAN Repo Policy. The BH package your Boom depends upon is actually named BH in part because having a two-letter name shrunk the set of files violating this very constraint. Yet at every release I still get to renamed one file, and update one include statement. All documented in the ChangeLog. So I would change the filenames, and move on. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] long file names in tar
Thanks Dirk, Yes, I've done the same, and I agree the rules are the rules. Rules should be updated when they're no longer helpful, or when their cost outweighs their benefit. I'm curious whether that might be the case here. Cheers, Steve On Thu, Apr 18, 2019 at 10:54 AM Dirk Eddelbuettel wrote: > > On 18 April 2019 at 10:37, Steven Scott wrote: > | My Boom package makes a C++ library available to package authors (mainly > | me). The wrapped library is used outside of R and must comply with > | external style rules such as UseLongDescriptiveNames, and files must be > | named for the class they contain. From time to time a > | LongDescriptiveFileName, when paired with its full directory path, > exceeds > | 100 characters. > | > | This creates a conflict with CRAN's rules about long file names, which > | stems from tar. I'm wondering what this community thinks about asking > for > | that rule to be relaxed. Both gnu tar and posix tar now allow unlimited > | length filenames, and the ustar format allows names up to 256 characters. > | > | I'm interested in the opinions of people on this list about whether this > | rule has outlived its usefulness. Thanks. > > There are no "opinions". There is CRAN Repo Policy. > > The BH package your Boom depends upon is actually named BH in part because > having a two-letter name shrunk the set of files violating this very > constraint. Yet at every release I still get to renamed one file, and > update > one include statement. All documented in the ChangeLog. > > So I would change the filenames, and move on. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > [[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] long file names in tar
You could go down this rabbit hole if you like, but I suspect it has something to do with maintaining compatibility with multiple operating systems and I doubt R Core will explore the consequences of this change for you. Windows, for example, allows long file names but has some nasty corners that break if your total path+filename is 260+ characters and packages do get installed in directories fairly deep into the directory structure on a regular basis (e.g. packrat). Other tools that the R ecosystem depends on could also have internal constraints that come up when one tool builds on another and so on. Have fun with that! On April 18, 2019 11:02:15 AM PDT, Steven Scott wrote: >Thanks Dirk, >Yes, I've done the same, and I agree the rules are the rules. Rules >should >be updated when they're no longer helpful, or when their cost outweighs >their benefit. I'm curious whether that might be the case here. >Cheers, >Steve > > >On Thu, Apr 18, 2019 at 10:54 AM Dirk Eddelbuettel >wrote: > >> >> On 18 April 2019 at 10:37, Steven Scott wrote: >> | My Boom package makes a C++ library available to package authors >(mainly >> | me). The wrapped library is used outside of R and must comply with >> | external style rules such as UseLongDescriptiveNames, and files >must be >> | named for the class they contain. From time to time a >> | LongDescriptiveFileName, when paired with its full directory path, >> exceeds >> | 100 characters. >> | >> | This creates a conflict with CRAN's rules about long file names, >which >> | stems from tar. I'm wondering what this community thinks about >asking >> for >> | that rule to be relaxed. Both gnu tar and posix tar now allow >unlimited >> | length filenames, and the ustar format allows names up to 256 >characters. >> | >> | I'm interested in the opinions of people on this list about whether >this >> | rule has outlived its usefulness. Thanks. >> >> There are no "opinions". There is CRAN Repo Policy. >> >> The BH package your Boom depends upon is actually named BH in part >because >> having a two-letter name shrunk the set of files violating this very >> constraint. Yet at every release I still get to renamed one file, >and >> update >> one include statement. All documented in the ChangeLog. >> >> So I would change the filenames, and move on. >> >> Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > > [[alternative HTML version deleted]] > >__ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Sent from my phone. Please excuse my brevity. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
