search for: rlibkriging

...; backs to two threads as warned. I think you're right about your tests de-facto using two threads, but it might be a good idea to _default_ to up to two threads in tests and examples. This is especially valuable for third-party developers who have to mass-test packages (one of which could be rlibkriging) in parallel. > - is there any reason that could explain that fedora-*-devel is so > slow for this package or compilation of Rcpp/testthat ? Compilation time is definitely not the reason. Something in tests/* actually runs for 30 minutes by itself. > - is there any chance that I can get...

...hink you're right about your tests de-facto using two threads, but >>> it might be a good idea to _default_ to up to two threads in tests and >>> examples. This is especially valuable for third-party developers who >>> have to mass-test packages (one of which could be rlibkriging) in >>> parallel. >>> >>>> - is there any reason that could explain that fedora-*-devel is so >>>> slow for this package or compilation of Rcpp/testthat ? >>> >>> Compilation time is definitely not the reason. Something in tests/* >>...

...>> I think you're right about your tests de-facto using two threads, but >> it might be a good idea to _default_ to up to two threads in tests and >> examples. This is especially valuable for third-party developers who >> have to mass-test packages (one of which could be rlibkriging) in >> parallel. >> >>> - is there any reason that could explain that fedora-*-devel is so >>> slow for this package or compilation of Rcpp/testthat ? >> >> Compilation time is definitely not the reason. Something in tests/* >> actually runs for 30 mi...

...s warned. > > I think you're right about your tests de-facto using two threads, but > it might be a good idea to _default_ to up to two threads in tests and > examples. This is especially valuable for third-party developers who > have to mass-test packages (one of which could be rlibkriging) in > parallel. > >> - is there any reason that could explain that fedora-*-devel is so >> slow for this package or compilation of Rcpp/testthat ? > > Compilation time is definitely not the reason. Something in tests/* > actually runs for 30 minutes by itself. > &gt...

...ight about your tests de-facto using two threads, >>> but it might be a good idea to _default_ to up to two threads in >>> tests and examples. This is especially valuable for third-party >>> developers who have to mass-test packages (one of which could be >>> rlibkriging) in parallel. >>> >>>> - is there any reason that could explain that fedora-*-devel is so >>>> slow for this package or compilation of Rcpp/testthat ? >>> >>> Compilation time is definitely not the reason. Something in tests/* >>> actual...

...th fedora (clang & gcc) devel. >> >> Our issue is that the rhub docker is not well sync with the CRAN >> fedora-clang-devel config: >> - failing on CRAN (without clear reason): >> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-c >> lang/rlibkriging-00check.html > I see? 2 candidates for? reasons of failing on CRAN: > ?1. test time is 30 min while 15 min are allowed; > ?2. your code try to get 30 threads Oops, it was 10 threads not 30 but it does not change the nature of a possible issue. > while CRAN limits them to 2; > > T...

...our tests de-facto using two threads, >>>> but it might be a good idea to _default_ to up to two threads in >>>> tests and examples. This is especially valuable for third-party >>>> developers who have to mass-test packages (one of which could be >>>> rlibkriging) in parallel. >>>> >>>>> - is there any reason that could explain that fedora-*-devel is so >>>>> slow for this package or compilation of Rcpp/testthat ? >>>> >>>> Compilation time is definitely not the reason. Something in tests/* &...

...g with almost all CRAN targets, but a problem remains with fedora (clang & gcc) devel. Our issue is that the rhub docker is not well sync with the CRAN fedora-clang-devel config: - failing on CRAN (without clear reason): https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rlibkriging-00check.html - passing on rhub: https://builder.r-hub.io/status/rlibkriging_0.7-3.tar.gz-20f7dc7562726497af7c678ab41f4dea So we cannot investigate and fix the problem. Note that we did quite strange things with the fedora platforms: include explicitely slapack to provide simple precision for our...

...all CRAN targets, but a problem remains with fedora (clang & gcc) devel. > > Our issue is that the rhub docker is not well sync with the CRAN fedora-clang-devel config: > - failing on CRAN (without clear reason): https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rlibkriging-00check.html I see? 2 candidates for? reasons of failing on CRAN: ?1. test time is 30 min while 15 min are allowed; ?2. your code try to get 30 threads while CRAN limits them to 2; Try to make your tests shorter ( < 15 min) on 2 threads. May be it will help. Best, Serguei. > - passing o...

...remains with fedora (clang & gcc) devel. >> >> Our issue is that the rhub docker is not well sync with the CRAN >> fedora-clang-devel config: >> - failing on CRAN (without clear reason): >> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rlibkriging-00check.html > I see? 2 candidates for? reasons of failing on CRAN: > ?1. test time is 30 min while 15 min are allowed; > ?2. your code try to get 30 threads Oops, it was 10 threads not 30 but it does not change the nature of a possible issue. > while CRAN limits them to 2; > >...