Hi All,
I know we should not use more than 2 cores in tests, vignettes, etc. I
encountered and solved this issue before. However, I still committed
this mistake in a new package and would like find out where the cause
is.
I have a package that already has parallel processing disabled by
default a
7;CheckExEnv'),"\n")
Time elapsed: 10.963 0.161 13.589 0.302 0.081
Regards,
Shu Fai
On Tue, Sep 19, 2023 at 5:59 PM Duncan Murdoch wrote:
>
> On 18/09/2023 10:10 a.m., Shu Fai Cheung wrote:
> > Hi All,
> >
> > I know we should not use more than 2 cores i
like to see if I overlooked anything.
Regards,
Shu Fai
On Tue, Sep 19, 2023 at 5:02 PM Uwe Ligges
wrote:
>
>
>
> On 18.09.2023 16:10, Shu Fai Cheung wrote:
> > Hi All,
> >
> > I know we should not use more than 2 cores in tests, vignettes, etc. I
> > encountered and s
Please pardon me if I suggest something unrelated below. Many experts
have made suggestions that I would also like to consider because I
also have a similar issue with some packages.
This is an approach I found, for Rmarkdown vignettes:
https://www.kloppenborg.ca/2021/06/long-running-vignettes/
Hi All,
I vaguely recall that, on CRAN, if PkgA imports PkgB, then PkgB cannot
import PkgA. (Please correct me if I am wrong.)
How about this?
PkgA imports PkgB (because PkgA has some helper functions for using PkgB)
PkgB suggests PkgA (because some vignettes or examples in PkgB use
those helper
Many many thanks for the clarification, which is very clear! The case
of testthat is a very good example, as many packages suggest it.
Regards,
Shu Fai
On Sat, Nov 4, 2023 at 4:41 PM Iñaki Ucar wrote:
>
>
>
> El sáb., 4 nov. 2023 5:43, Shu Fai Cheung escribió:
>>
>>
Hil,
I am exploring the use of callr in a package. I know that for packages
that do parallel computing, we should not use more than two cores in
examples, tests, etc. when being checked on CRAN.
I believe I can use callr in tests and examples. How should I use
callr in compliance with CRAN policy
not unusual across packages and so
users need to learn how to solve this problem anyway. Nevertheless, if
possible, I would like to solve the conflict internally such that
users do not need to do anything.
Regards,
Shu Fai Cheung
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
uot; and
"y" in base::sort_by() and so the matching makes sense.
Regards,
Shu Fai Cheung
On Sat, Aug 3, 2024 at 7:13 PM Deepayan Sarkar
wrote:
>
> I haven't thought about this carefully, but shouldn't this mostly work?
>
> sort_by.est_table <- function(x, y = c(
Hi All,
I would like to ask a quick question.
I am the maintainer of Package A, which imports Package B, and Package
B imports Package C.
An R-CMD-check action on an old release of R, conducted by GitHub
action, failed, because Package C depends on R 4.5.0. However, I found
that several other pa
56:36 +0800
> Shu Fai Cheung пишет:
>
> > An R-CMD-check action on an old release of R, conducted by GitHub
> > action, failed, because Package C depends on R 4.5.0. However, I found
> > that several other packages that import Package C, including Package
> > B, do not r
fine
> as install.packages() finds out on older versions of R that neither the
> required version OpenMx is not installable nor your package.
>
> Best,
> Uwe Ligges
>
>
> On 29.06.2025 10:49, Shu Fai Cheung wrote:
> > Thanks a lot! Yes, the specific package I encountere
12 matches
Mail list logo