[R-pkg-devel] Checking the number of cores used
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 and I did not enable parallel processing in the examples and tests (except for one test, which is always skipped by skip()). However, I was told that somewhere in the package more than 2 cores are used. I checked several times and even added a temporary 'stop()` to "trap" parallel processing but still could not find where the source of the problem is. I checked the timing in the log in R CMD check results from winbuilder but everything seems OK. The user time and elapsed time are similar for all the examples. Is there any quick way to check where things go wrong regarding the number of cores? It is not easy to find the source of the problems when there are many examples and tests. Regards, Shu Fai __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking the number of cores used
Thanks a lot. I don't have a physical linux box and so I need to use
rhub. But I don't know why there are no "-Ex.timings" files in the
check. E.g,
check(platform = "debian-gcc-release", show_status = FALSE, check_args
= "--as-cran")
I can only see these files in artifacts:
[ ]00check.log2023-09-20 08:00 3.4K
[ ]00install.out2023-09-20 08:00 702
[ ]Rdlatex.log2023-09-20 08:00 30K
[ ]modelbpp-Ex.Rout2023-09-20 08:00 28K
[ ]modelbpp-manual.log2023-09-20 08:00 19K
The case is the same for this, no "-Ex.timings" files:
check(platform = "windows-x86_64-release", show_status = FALSE,
check_args = "--as-cran")
Although I think I need to, I tried adding "--timings" but still do
not see the "-Ex.timings".
However, if I run the check locally in Windows 10 using R CMD check
with --as-cran, I can find the "-Ex.timings" files.
I can find the total time at the end of "-Ex.Rout" but I think this is
not what I need:
> base::cat("Time elapsed: ", proc.time() - base::get("ptime", pos =
> '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 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 and I did not enable parallel processing in the examples and
> > tests (except for one test, which is always skipped by skip()).
> > However, I was told that somewhere in the package more than 2 cores
> > are used.
> >
> > I checked several times and even added a temporary 'stop()` to "trap"
> > parallel processing but still could not find where the source of the
> > problem is.
> >
> > I checked the timing in the log in R CMD check results from winbuilder
> > but everything seems OK. The user time and elapsed time are similar
> > for all the examples.
> >
> > Is there any quick way to check where things go wrong regarding the
> > number of cores? It is not easy to find the source of the problems
> > when there are many examples and tests.
>
> If you run R CMD check at the command line, it will produce a
> directory *.Rcheck containing a number of files. One of those files
> will be *-Ex.timings, which will give the individual timings of each of
> the examples in your package. Maybe you can recognize from those which
> of the examples are problematic ones, and add `proc.time()` calls to the
> example to figure out which line(s) cause the issue.
>
> I don't remember whether winbuilder keeps the timings file when it runs
> a check.
>
> Duncan Murdoch
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking the number of cores used
Thanks for the suggestion. I will use rhub and a virtual machine to check again.
I read some previous posts and I thought I need to check the times to
see if there is any unintended usage of parallel processing, e.g., CPU
time > 2 x elapsed time. May I ask a few questions on this part?
This is from the "-Ex.Rout" file:
> base::cat("Time elapsed: ", proc.time() - base::get("ptime", pos =
> 'CheckExEnv'),"\n")
Time elapsed: 14.94 0.27 15.26 NA NA
First, is this something I can ignore, unless the CPU time is
substantially larger than elapsed time? This is the total time but the
parallel process may be triggered in only one of the many examples.
Second, are the files "-Ex.timings", showing per-example timing, only
available on some platforms? I could get it locally in Windows, and
can find it in Winbuilder output. However, I could not find them in
the rhub platforms I tried, not even in the Windows platform. I
suppose adding "--as-cran" will also add "--timings"?
Third, the "testthat.Rout" file only shows the total time:
> proc.time()
user system elapsed
13.530 0.291 29.492
I believe the user time is not useful as we can use two processes in
testthat. How can we detect the use of more than two cores in the
tests?
Last, how can we detect the use of more than two cores in vignettes? I
checked and couldn't find similar timing information on vignettes.
Sorry for asking so many questions. I would like to have a reliable
way to detect hidden use of parallel processing such that I can
prevent the problem from happening. I have some ideas which package I
imported is causing the problem but I have used it before without
problem. Therefore, I would 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 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 and I did not enable parallel processing in the examples and
> > tests (except for one test, which is always skipped by skip()).
> > However, I was told that somewhere in the package more than 2 cores
> > are used.
> >
> > I checked several times and even added a temporary 'stop()` to "trap"
> > parallel processing but still could not find where the source of the
> > problem is.
> >
> > I checked the timing in the log in R CMD check results from winbuilder
> > but everything seems OK. The user time and elapsed time are similar
> > for all the examples.
> >
> > Is there any quick way to check where things go wrong regarding the
> > number of cores? It is not easy to find the source of the problems
> > when there are many examples and tests.
>
> If it is OK on winbuilder but not on Linux, then likely something makes
> use of multithreading.
>
> Best,
> Uwe Ligges
>
>
>
> > Regards,
> > Shu Fai
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission
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/
This is similar to some of the suggestions. The vignette is rendered
locally. It uses the trick that, If we render the vignette by calling
knitr::knit() directly, the extension of the source file does not
matter. The output, although with the extension ".Rmd", actually
contains the results of the code, in chunks starting with "```r", not
"```{r}".
When this pre-buiult .Rmd file is built again, it will just convert
the file to an HTML file, with no need to rerun the code.
The method uses an extension for the source Rmd file (".orig" in the
post) to make sure the "real" source files are ignored when building
the vignettes.
Perhaps this is also a feasible solution for long running vignettes?
Regards,
Shu Fai
On Wed, Oct 18, 2023 at 6:51 AM John Fox wrote:
>
> Dear John,
>
> Unless I'm mistaken, the *installation* time of the package isn't really
> at issue. If a user installs a package from a tarball provided by CRAN,
> the vignettes aren't normally rebuilt.
>
> Best,
> John
>
> On 2023-10-17 6:30 p.m., John Harrold wrote:
> > Caution: External email.
> >
> >
> > I ask myself the question: Who is the vignette for? It does server two
> > purposes. One is testing but primarily it's for the users to learn how to
> > use a package. I think the testing is secondary, and if it slows down
> > installation or general usability I'd sacrifice the testing. If it's that
> > important, then the tests can be added explicitly in tests/.
> >
> > On Tue, Oct 17, 2023 at 3:04 PM Dirk Eddelbuettel wrote:
> >
> >>
> >> On 18 October 2023 at 08:51, Simon Urbanek wrote:
> >> | John,
> >> |
> >> | the short answer is it won't work (it defeats the purpose of vignettes).
> >>
> >> Not exactly. Everything is under our (i.e. package author) control, and
> >> when
> >> we want to replace 'computed' values with cached values we can.
> >>
> >> All this is somewhat of a charade. "Of course" we want vignettes to run
> >> tests. But then we don't want to fall over random missing .sty files or
> >> fonts
> >> (macOS machines have been less forgiving than others), not to mention
> >> compile
> >> time.
> >>
> >> So for simplicity I often pre-make pdf vignettes that get included in other
> >> latex code as source. Works great, never fails, CRAN never complained --
> >> which is somewhat contrary to your statement.
> >>
> >> It is effectively the same with tests. We all want maximum test surfaces.
> >> But
> >> when tests fail, or when they run too long, or [insert many other reasons
> >> here] so many packages run tests conditionally. Such is life.
> >>
> >> Dirk
> >>
> >>
> >> | However, this sounds like a purely hypothetical question - CRAN policies
> >> allow long-running vignettes if they declared.
> >> |
> >> | Cheers,
> >> | Simon
> >> |
> >> |
> >> | > On 18/10/2023, at 3:02 AM, John Fox wrote:
> >> | >
> >> | > Hello Dirk,
> >> | >
> >> | > Thank you (and Kevin and John) for addressing my questions.
> >> | >
> >> | > No one directly answered my first question, however, which was whether
> >> the approach that I suggested would work. I guess that the implication is
> >> that it won't, but it would be nice to confirm that before I try something
> >> else, specifically using R.rsp.
> >> | >
> >> | > Best,
> >> | > John
> >> | >
> >> | > On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
> >> | >> Caution: External email.
> >> | >> On 16 October 2023 at 10:42, Kevin R Coombes wrote:
> >> | >> | Produce a PDF file yourself, then use the "as.is" feature of the
> >> R.rsp
> >> | >> | package.
> >> | >> For completeness, that approach also works directly with Sweave.
> >> Described in
> >> | >> a blog post by Mark van der Loo in 2019, and used in a number of
> >> packages
> >> | >> including a few of mine.
> >> | >> That said, I also used the approach described by John Harrold and
> >> cached
> >> | >> results myself.
> >> | >> Dirk
> >> | >> --
> >> | >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >> | >> __
> >> | >> R-package-devel@r-project.org mailing list
> >> | >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> | >
> >> | > __
> >> | > R-package-devel@r-project.org mailing list
> >> | > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> | >
> >> |
> >> | __
> >> | R-package-devel@r-project.org mailing list
> >> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> --
> >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mail
[R-pkg-devel] PkgA imports PkgB, and PkgB suggests PkgA?
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 helpers from PkgA) Is this allowed on CRAN? Regards, Shu Fai __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] PkgA imports PkgB, and PkgB suggests PkgA?
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ó: >> >> 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 helpers from PkgA) > > > Or some tests are based on PkgA, or... > >> Is this allowed on CRAN? > > > Yes, it is. For example: testthat imports a bunch of packages to do is thing, > and those packages suggest testthat because their test suite is based on it. > > Cycles of hard dependencies (Depends, Imports) are not allowed for obvious > reasons. But packages should install and work without soft dependencies, so > there's no problem there. > > Iñaki __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] callr and CRAN policy on the max number of cores
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? Because even just one call to callr will start a new R session, should I limit the use of callr such that at any one time, only one background R session created by callr is active? Regards, Shu Fai __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] A function in one of my package is now a method in base R
Hi All,
I have a function (not a method), sort_by(), in one of my packages. A
new method with the same name was introduced in the recent versions of
R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
conflict in users' code.
Certainly, users can simply use pkg_name::function_name() to solve the
conflict. However, I would like to be consistent with base R and so I
am thinking about converting my function to a method for the class for
which my function is intended to work on (e.g, est_table).
However, my function has arguments different from those in the base R sort_by():
Base R:
sort_by(x, y, ...)
My function:
sort_by(
object,
by = c("op", "lhs", "rhs"),
op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
number_rows = TRUE
)
If I write the function sort_by.est_table(), I would need to match the
argument names of the base R sort_by(). However, I think it is a bad
idea to rename the arguments in my function and it will break existing
code.
Any suggestions on how I should proceed? Is keeping my function as-is
a better option? Name conflict is 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
Re: [R-pkg-devel] A function in one of my package is now a method in base R
Thanks a lot for both suggestions! I haven't thought about these
approaches, They may solve my problem without breaking existing code.
I may just keep the original arguments for backward compatibility.
Coincidentally, "object" and "by" have the same meanings as "x" 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("op", "lhs", "rhs"),
> object = x,
> by = y,
> op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
> number_rows = TRUE, ...) {
>
>
>
> }
>
> -Deepayan
>
> On Sat, 3 Aug 2024 at 00:13, Duncan Murdoch wrote:
>>
>> On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:
>> > Hi All,
>> >
>> > I have a function (not a method), sort_by(), in one of my packages. A
>> > new method with the same name was introduced in the recent versions of
>> > R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
>> > conflict in users' code.
>> >
>> > Certainly, users can simply use pkg_name::function_name() to solve the
>> > conflict. However, I would like to be consistent with base R and so I
>> > am thinking about converting my function to a method for the class for
>> > which my function is intended to work on (e.g, est_table).
>> >
>> > However, my function has arguments different from those in the base R
>> > sort_by():
>> >
>> > Base R:
>> >
>> > sort_by(x, y, ...)
>> >
>> > My function:
>> >
>> > sort_by(
>> >object,
>> >by = c("op", "lhs", "rhs"),
>> >op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
>> >number_rows = TRUE
>> > )
>> >
>> > If I write the function sort_by.est_table(), I would need to match the
>> > argument names of the base R sort_by(). However, I think it is a bad
>> > idea to rename the arguments in my function and it will break existing
>> > code.
>> >
>> > Any suggestions on how I should proceed? Is keeping my function as-is
>> > a better option? Name conflict is 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.
>>
>> I think it's impossible to avoid some inconvenience to your users.
>>
>> Here's what I'd suggest:
>>
>> - Create a method for base::sort_by(), as you suggested you could. Use
>> the generic's variable names for compatibility, but also add your extra
>> variable names as additional arguments, e.g.
>>
>> sort_by.est_table <- function(x, y, object,
>> by = c("op", "lhs", "rhs"),
>> op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
>> number_rows = TRUE, ...) {
>>
>># This test seems unlikely: how would we have dispatch here if we
>> specified object explicitly?
>>
>>if (!missing(object) {
>> if (!missing(x))
>>stop("both x and object specified!")
>> x <- object
>>}
>>
>># This one is more likely to do something:
>>
>>if (!missing(by)) {
>> if (!missing(y))
>>stop("both y and by specified!")
>> y <- by
>>}
>>
>># Now proceed using x and y
>>
>>...
>> }
>>
>> - Create a separate function, e.g. sort_by_old() which is exactly
>> compatible with your old sort_by(). For users where the above doesn't
>> just work, they can switch to sort_by_old().
>>
>> Duncan Murdoch
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Depending on R 4.5.0 because a related package depends on it?
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 packages that import Package C, including Package B, do not require R 4.5.0. They also did not fail in all the CRAN package checks, including those r-oldrel-* checks. Does it mean that I can safely ignore that failure and submit a new version of my package to CRAN? I can change Package A to depend on R 4.5.0 if necessary. I just wonder whether I have to do so. Regards, Shu Fai __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Depending on R 4.5.0 because a related package depends on it?
Thanks a lot! Yes, the specific package I encountered that problem is semptools. I didn't specify that (I should have, sorry for that) because I am also curious about what we should do in this kind of case in general. Even if the package could somehow pass the CRAN checks without changing the version of R it depends on, is it recommended to change the version that semptools depends on to R 4.5.0 because OpenMx has this requirement? If yes, I would do so to meet CRAN requirements. Regards, Shu Fai On Sun, Jun 29, 2025 at 4:35 PM Ivan Krylov wrote: > > В Sun, 29 Jun 2025 13: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 require R 4.5.0. They also did not fail in all the CRAN > > package checks, including those r-oldrel-* checks. > > Is it semptools -> semPlot -> OpenMx? > > The situation is indeed suboptimal, because while it's easy to install > a binary build of the previous version of OpenMx for r-oldrel from > CRAN, installing a compatible version of OpenMx from source requires > visiting <https://cran.r-project.org/src/contrib/Archive/OpenMx/> and > resolving dependencies manually, one by one. (There's no dependency > index of archived packages.) > > The latest version of semPlot does seem to work with the old version of > OpenMx, seeing as it passes the r-oldrel checks. I think that the > r-oldrel builders and checkers on CRAN won't notice any problem with > semptools either, because they still have the old version of OpenMx > installed. > > -- > Best regards, > Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Depending on R 4.5.0 because a related package depends on it?
Sorry, I have misread Ivan's message. I understand more about this particular case now. Thanks for your clarification. Regards, Shu Fai On Sun, Jun 29, 2025 at 10:38 PM Uwe Ligges wrote: > > Ivan explained this already, but as you asked again, I will repeat > Ivan's message: > you do not need to specify version requirements if your package can live > with older versions of the package you depend on. Then users on old > versions of R can use your package with an older version of OpenMX. > > And even if you depend on a newer version of OpenMx, then that is 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 encountered that problem is > > semptools. I didn't specify that (I should have, sorry for that) > > because I am also curious about what we should do in this kind of case > > in general. > > > > Even if the package could somehow pass the CRAN checks without > > changing the version of R it depends on, is it recommended to change > > the version that semptools depends on to R 4.5.0 because OpenMx has > > this requirement? If yes, I would do > > so to meet CRAN requirements. > > > > Regards, > > Shu Fai > > > > > > On Sun, Jun 29, 2025 at 4:35 PM Ivan Krylov wrote: > >> > >> В Sun, 29 Jun 2025 13: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 require R 4.5.0. They also did not fail in all the CRAN > >>> package checks, including those r-oldrel-* checks. > >> > >> Is it semptools -> semPlot -> OpenMx? > >> > >> The situation is indeed suboptimal, because while it's easy to install > >> a binary build of the previous version of OpenMx for r-oldrel from > >> CRAN, installing a compatible version of OpenMx from source requires > >> visiting <https://cran.r-project.org/src/contrib/Archive/OpenMx/> and > >> resolving dependencies manually, one by one. (There's no dependency > >> index of archived packages.) > >> > >> The latest version of semPlot does seem to work with the old version of > >> OpenMx, seeing as it passes the r-oldrel checks. I think that the > >> r-oldrel builders and checkers on CRAN won't notice any problem with > >> semptools either, because they still have the old version of OpenMx > >> installed. > >> > >> -- > >> Best regards, > >> Ivan > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
