From murdoch@dunc@n @end|ng |rom gm@||@com  Wed Jan 11 00:35:57 2023
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Tue, 10 Jan 2023 18:35:57 -0500
Subject: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack
In-Reply-To: <8cb80424-2264-4faa-b16f-e137b9f85bd4@fau.de>
References: <334d6d8de5094164a99c8d4b26d77246@irsn.fr>
 <72de7b54-ff87-166f-4f8a-2b91381488cb@insa-toulouse.fr>
 <ffef02ea-52ae-a27a-1a8e-3d2046fd092c@insa-toulouse.fr>
 <ba0f6126425d4a43a3e1e3b0009e4105@irsn.fr> <20230110220545.5d213d2d@Tarkus>
 <44168649-5146-9cb0-a416-fbdb8b020029@gmail.com>
 <8cb80424-2264-4faa-b16f-e137b9f85bd4@fau.de>
Message-ID: <84e94d6c-3408-014a-3845-76e66e88a779@gmail.com>

On 10/01/2023 4:07 p.m., Sebastian Meyer wrote:
> Am 10.01.23 um 21:28 schrieb Duncan Murdoch:
>> On 10/01/2023 2:05 p.m., Ivan Krylov wrote:
>>> On Tue, 10 Jan 2023 16:27:53 +0000
>>> RICHET Yann <yann.richet at irsn.fr> wrote:
>>>
>>>> In facts, 10 threads are asked by armadillo for some LinAlg, which
>>>> 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 a deeper log of what happened ?
>>>
>>> If you split your tests into separate files under tests/*.R instead of
>>> using a single tests/testthat.R calling the rest of the tests, R will
>>> be able to show you the individual test file that hung and maybe the
>>> line where it happened. (Also, you'll get per-file timing.) But that
>>> is potentially a huge investment: you may have to rewrite the tests to
>>> work outside the testthat harness, and you'd also have to prepare
>>> another CRAN submission just to have those tests run. It's also against
>>> CRAN policy to knowingly submit a package with unfixed ERRORs.
>>>
>>> (Currently, R can only tell you that the tests hung in the
>>> test_check('rlibkriging') call in the tests/testthat.R, which isn't
>>> precise enough.)
>>
>> You can specify a different "reporter" in the test_check() call, and it
>> will print more useful information.? I don't think there's a perfect
>> one, but
>>
>>   ? test_check('rlibkriging', reporter = "progress")
>>
>> should at least show you the tests that finished running before the
>> timeout.
> 
> I had similar problems with testthat and timeouts when mass-checking
> packages on patched R versions. My notes say
> 
>> ## testthat's 'LocationReporter' does cat() after each expectation
>> ## so we can see results even if timeout is reached
>> options(testthat.default_check_reporter = c("Location", "Check"))
> 
> The help("LocationReporter") says: "This reporter simply prints the
> location of every expectation and error. This is useful if you're trying
> to figure out the source of a segfault, or you want to figure out which
> code triggers a C/C++ breakpoint"
> 
> HTH!

Yes, that looks like it would pin down the location of the problem. 
Here's some sample output from it:

   Running ?testthat.R? [41s/42s]
Running the tests in ?tests/testthat.R? failed.
Last 13 lines of output:
   Start test: can use constructed calls in verify_output() (#945)
     'test-verify-output.R:55' [success]
   End test: can use constructed calls in verify_output() (#945)

   Start test: verify_output() doesn't use cli unicode by default
     'test-verify-output.R:65' [success]
     'test-verify-output.R:73' [success]
   End test: verify_output() doesn't use cli unicode by default

   Start test: verify_output() handles carriage return
     'test-verify-output.R:82' [success]
   End test: verify_output() handles carriage return

   Error: Test failures
   Execution halted

One other thing:  you enabled this by using

   options(testthat.default_check_reporter = c("Location", "Check"))

before running the tests; the package writer could do the same thing by 
using

   test_check('rlibkriging', reporter = c("Location", "Check"))

Duncan Murdoch



[Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Duncan Murdoch