Dear all,
I'm currently having issues submitting an update to the ukbnmr package to
CRAN as the checks on their debian server are generating a NOTE due to long
running tests.
The offending test code is much faster on my own machine, and on all other
CRAN servers (running in < 1 second), and I tri
On Mon, 21 Aug 2023 12:02:55 +0100
Scott Ritchie wrote:
> remotes::install_github("sritchie73/ukbnmr")
> library(ukbnmr)
> system.time({ remove_technical_variation(test_data) })
data.tables, you say? Can you show us the NOTE message you're getting?
It could be that your example takes too much CP
Hi Ivan,
Here is the NOTE generated by CRAN:
* checking examples ... [5s/2s] NOTE
Examples with CPU time > 2.5 times elapsed time
user system elapsed ratio
remove_technical_variation 2.603 0.0270.94 2.798
This doesn't appear to be related to data.table threads, h
On 21 August 2023 at 15:16, Ivan Krylov wrote:
| On Mon, 21 Aug 2023 12:02:55 +0100
| Scott Ritchie wrote:
|
| > remotes::install_github("sritchie73/ukbnmr")
| > library(ukbnmr)
| > system.time({ remove_technical_variation(test_data) })
|
| data.tables, you say? Can you show us the NOTE messag
On 21/08/2023 14:34, Dirk Eddelbuettel wrote:
On 21 August 2023 at 15:16, Ivan Krylov wrote:
| On Mon, 21 Aug 2023 12:02:55 +0100
| Scott Ritchie wrote:
|
| > remotes::install_github("sritchie73/ukbnmr")
| > library(ukbnmr)
| > system.time({ remove_technical_variation(test_data) })
|
| data.ta
On Mon, 21 Aug 2023 13:28:54 +0100
Scott Ritchie wrote:
> Examples with CPU time > 2.5 times elapsed time
> user system elapsed ratio
> remove_technical_variation 2.603 0.0270.94 2.798
In this context, "user" means the time spent executing userspace code
(as oppo
On 21 August 2023 at 16:05, Ivan Krylov wrote:
| Dirk is probably right that it's a good idea to have OMP_THREAD_LIMIT=2
| set on the CRAN check machine. Either that, or place the responsibility
| on data.table for setting the right number of threads by default. But
| that's a policy question: sh
Thanks Dirk and Ivan,
I took a slightly different work-around of forcing the number of threads to
1 when running functions of the test dataset in the package, by adding the
following to each user facing function:
```
# Check if running on package test_data, and if so, force data.table to
be
#
If you add that to each exported function, isn't that a lot of code to read +
maintain?
Also, it seems like unnecessary computational overhead.
>From a software design point of view, it might be nicer to set that in the
>examples + tests.
Regards,
Berry
From:
