The question should be, in how many cases is the current behaviour a
problem? In a shared environment, sure, you have to be more careful. I'd
say don't let the teenagers in there. The CRAN build server does need to do
something to protect itself and I don't greatly mind the 2 thread limit, I
impl
On 25 August 2023 at 18:48, Jeff Newmiller wrote:
| You have a really bizarre way of twisting what others are saying, Dirk. I
have seen no-one here saying 'limit R to 2 threads' except for you, as a way to
paint opposing views to be absurd.
That's too cute.
Nobody needs to repeat it, and some
You have a really bizarre way of twisting what others are saying, Dirk. I have
seen no-one here saying 'limit R to 2 threads' except for you, as a way to
paint opposing views to be absurd.
What _is_ being said is that users need to be in control_, but _the default
needs to do least harm_ until
On 26 August 2023 at 12:05, Simon Urbanek wrote:
| In reality it's more people running R on their laptops vs the rest of the
world.
My point was that we also have 'single user on really Yuge workstation'.
Plus we all know that those users are often not sysadmins, and do not have
our levels of
> On Aug 26, 2023, at 11:01 AM, Dirk Eddelbuettel wrote:
>
>
> On 25 August 2023 at 18:45, Duncan Murdoch wrote:
> | The real problem is that there are two stubborn groups opposing each
> | other: the data.table developers and the CRAN maintainers. The former
> | think users should by def
Sanity seems to be in the eye of the beholder. FWIW I am certainly not CRAN or
R Core, but I pretty strongly disagree with any package that defaults to using
more than 2 cores. If I am using a shared HPC I can get in trouble if I
over-consume cpu resources ... i.e. I may be given access to 10 co
On 25 August 2023 at 18:45, Duncan Murdoch wrote:
| The real problem is that there are two stubborn groups opposing each
| other: the data.table developers and the CRAN maintainers. The former
| think users should by default dedicate their whole machine to
| data.table. The latter think use
To be fair, data.table defaults to using 1/2 the available cores; they do not
take the entire machine by default.
Avi
Sent from my iPhone
> On Aug 25, 2023, at 6:46 PM, Duncan Murdoch wrote:
>
> On 25/08/2023 6:13 p.m., Toby Hocking wrote:
>> Thanks Dirk. I agree.
>> data.table is not in a
I've been lurking on this discussion and have a question.
What does data.table do to pass CRAN tests? If this is a problem for
packages that use data.table, then it certainly is a problem for data.table
itself.
On Fri, Aug 25, 2023 at 3:46 PM Duncan Murdoch
wrote:
> On 25/08/2023 6:13 p.m., Tob
On 25/08/2023 6:13 p.m., Toby Hocking wrote:
Thanks Dirk. I agree.
data.table is not in a situation to update very soon, so the easiest
solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
to 2 on the Windows and Debian machines doing this test.
Otherwise the 1400+ packages with
Thanks Dirk. I agree.
data.table is not in a situation to update very soon, so the easiest
solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
to 2 on the Windows and Debian machines doing this test.
Otherwise the 1400+ packages with hard dependencies on data.table will
each have
В Fri, 25 Aug 2023 11:27:46 -0400
Stephen Meyers пишет:
> /error: implicit declaration of function 'rand_unif' is invalid in
> C99 [-Werror,-Wimplicit-function-declaration]// //double
> F77_SUB(getunif)(void) { return rand_unif();
I think you meant unif_rand(), not rand_unif():
https://cran.r-p
Hello everyone,
I'm updating the 'astrochron' R package, and I am trying to remove the Fortran
intrinsic RANDOM_NUMBER from source code, and replace it with R's rand_unif.
I've followed this approach:
https://cran.r-project.org/doc/manuals/R-exts.html#Calling-C-from-Fortran-and-vice-versa
but
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
On 24 August 2023 at 07:42, Fred Viole wrote:
| Hi, I am receiving a NOTE upon submission regarding the re-building of
| vignettes for CPU time for the Debian check.
|
| I am unable to find any documented instances or solutions to this issue.
| The vignettes currently build in 1m 54.3s locally a
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 parallelisation, use
of data.table in a package should not lead to this type of behavi
* checking re-building of vignette outputs ... [577s/63s] NOTE
Re-building vignettes had CPU time 9.2 times elapsed time
--> Do not use more than 2 cores
Best,
Uwe Ligges
On 24.08.2023 13:42, Fred Viole wrote:
Hi, I am receiving a NOTE upon submission regarding the re-building of
vignettes
Hi, I am receiving a NOTE upon submission regarding the re-building of
vignettes for CPU time for the Debian check.
I am unable to find any documented instances or solutions to this issue.
The vignettes currently build in 1m 54.3s locally and in 56s on the Win
check.
https://win-builder.r-project
18 matches
Mail list logo
