On 25 August 2023 at 15:37, Uwe Ligges wrote:
|
|
| On 23.08.2023 16:00, Scott Ritchie wrote:
| > Hi Uwe,
| >
| > I agree and have also been burnt myself by programs occupying the
| > maximum number of cores available.
| >
| > My understanding is that in the absence of explicit parallelisati
l@r-project.org>
mailto:r-package-devel@r-project.org>>
> Subject: Re: [R-pkg-devel] Trouble with long-running tests on
CRAN debian server
>
> Thanks Dirk and Ivan,
>
> I took a slightly different work-around of forcing the number of
27;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.
>>>>
>>>> Re
w, it might be nicer to set that in the
examples + tests.
Regards,
Berry
From: R-package-devel on behalf of Scott
Ritchie
Sent: Monday, August 21, 2023 19:23
To: Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Trouble with long-ru
om a software design point of view, it might be nicer to set that in
> the examples + tests.
> >
> > Regards,
> > Berry
> >
> >
> > From: R-package-devel on behalf
> of Scott Ritchie
> > Sent: Monday, August 21, 2023 19:23
> > To:
gt; examples + tests.
>>
>> Regards,
>> Berry
>>
>>
>> From: R-package-devel on behalf of
>> Scott Ritchie
>> Sent: Monday, August 21, 2023 19:23
>> To: Dirk Eddelbuettel
>> Cc: r-package-devel@r-projec
ugust 21, 2023 19:23
To: Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
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 datas
__
From: R-package-devel on behalf of
Scott Ritchie
Sent: Monday, August 21, 2023 19:23
To: Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
Thanks Dirk and Ivan,
I took a slightly different work-around of
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
#
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
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/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 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
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 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
15 matches
Mail list logo
