[R-pkg-devel] Examples with CPU time is greater than elapsed time.
Hi all, I tried to submit an update to the xgboost package but didn't pass the pre-tests with the following note (solved the other one, but this one is a bit confusing): ``` Flavor: r-devel-linux-x86_64-debian-gcc Check: examples, Result: NOTE Examples with CPU time > 2.5 times elapsed time user system elapsed ratio cb.gblinear.history 1.454 0.0170.49 3.002 ``` I can't reproduce the note on win-builder: https://win-builder.r-project.org/ as it's running on Windows but the note appears on debian tests. I'm not able to reproduce it on my local machine either with Ubuntu 22.04. I'm wondering what the note is trying to tell me and how can I resolve it with confidence. The full log is here: https://win-builder.r-project.org/incoming_pretest/xgboost_1.7.1.1_20221104_194252/Debian/00check.log . Many thanks! Jiaming __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Examples with CPU time is greater than elapsed time.
I think it's because it suggests that the package uses more than 250% of CPU load on average, which suggests it runs in parallel with more than two parallel workers, which is the upper limit in the CRAN Policies (https://cran.r-project.org/web/packages/policies.html); "If running a package uses multiple threads/cores it must never use more than two simultaneously: the check farm is a shared resource and will typically be running many checks simultaneously. " >From the R Internals (https://cran.r-project.org/doc/manuals/r-release/R-ints.html): "_R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_: For checks with timings enabled, report examples where the ratio of CPU time to elapsed time exceeds this threshold (and the CPU time is at least one second). This can help detect the simultaneous use of multiple CPU cores. Default: NA." It looks like CRAN incoming sets _R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2.5. If multi-threading is involved, I guess you need to make sure to limit it to ~2 parallel threads. /Henrik On Sat, Nov 5, 2022 at 11:10 AM Jiaming Yuan wrote: > > Hi all, > > I tried to submit an update to the xgboost package but didn't pass the > pre-tests with the following note (solved the other one, but this one is > a bit confusing): > > ``` > Flavor: r-devel-linux-x86_64-debian-gcc > Check: examples, Result: NOTE >Examples with CPU time > 2.5 times elapsed time > user system elapsed ratio >cb.gblinear.history 1.454 0.0170.49 3.002 > > ``` > > I can't reproduce the note on win-builder: > https://win-builder.r-project.org/ as it's running on Windows but the > note appears on debian tests. I'm not able to reproduce it on my local > machine either with Ubuntu 22.04. I'm wondering what the note is trying > to tell me and how can I resolve it with confidence. > > > The full log is here: > https://win-builder.r-project.org/incoming_pretest/xgboost_1.7.1.1_20221104_194252/Debian/00check.log > . > > > Many thanks! > > Jiaming > > __ > 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] Examples with CPU time is greater than elapsed time.
On Sat, 5 Nov 2022 22:41:45 +0800 Jiaming Yuan wrote: >Examples with CPU time > 2.5 times elapsed time > I'm wondering what the note is trying to tell me and how can I > resolve it with confidence. Henrik Bengtsson already gave a good explanation of the problem. Not sure what exactly is the right thing to do, but one way to get rid of this warning could be to pass the argument nthread = min(parallel::detectCores(), 2) to the xgb.cv invocation (if you already use the parallel package anywhere) or maybe to hard-code the use of only one thread in the example. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Writing to users config directory for CRAN package
Hi, I'm considering submitting the package onetime ( https://github.com/hughjonesd/onetime/) to CRAN. Onetime has functions for showing a message or warning only once (ever per user). It does this by writing to a file in the user's configuration directory, as reported by rappdirs::user_config_dir(). I know that CRAN has rules about not writing to the user's file system without permission. What would be an appropriate way to do this? For example, the function onetime_message_confirm() prints a message and then asks "Show this again?[yN]" Would a "no" count as permission to write the file? Cheers, David [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Writing to users config directory for CRAN package
On 5 November 2022 at 19:32, David Hugh-Jones wrote: | I'm considering submitting the package onetime ( | https://github.com/hughjonesd/onetime/) to CRAN. | | Onetime has functions for showing a message or warning only once (ever per | user). It does this by writing to a file in the user's configuration | directory, as reported by rappdirs::user_config_dir(). There is a base R function tools::R_user_dir() which I use in a few packages along with packageName() to store config information across sessions. A quick search at GitHub's 'cran' org mirroring CRAN finds 110 hits: https://github.com/search?q=org%3Acran+R_user_dir&type=code You could keep a hashmap in that directory, and maybe (before it has been written a first time) alert the user that you cannot write without (initial) permission. As I recall, the idea behind the (sensible) CRAN Policy is to not litter user directories with random files with the user knowing. 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
Re: [R-pkg-devel] Examples with CPU time is greater than elapsed time.
Thank you for the detailed explanation, that's really helpful! On 11/6/22 02:22, Henrik Bengtsson wrote: I think it's because it suggests that the package uses more than 250% of CPU load on average, which suggests it runs in parallel with more than two parallel workers, which is the upper limit in the CRAN Policies (https://cran.r-project.org/web/packages/policies.html); "If running a package uses multiple threads/cores it must never use more than two simultaneously: the check farm is a shared resource and will typically be running many checks simultaneously. " From the R Internals (https://cran.r-project.org/doc/manuals/r-release/R-ints.html): "_R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_: For checks with timings enabled, report examples where the ratio of CPU time to elapsed time exceeds this threshold (and the CPU time is at least one second). This can help detect the simultaneous use of multiple CPU cores. Default: NA." It looks like CRAN incoming sets _R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2.5. If multi-threading is involved, I guess you need to make sure to limit it to ~2 parallel threads. /Henrik On Sat, Nov 5, 2022 at 11:10 AM Jiaming Yuan wrote: Hi all, I tried to submit an update to the xgboost package but didn't pass the pre-tests with the following note (solved the other one, but this one is a bit confusing): ``` Flavor: r-devel-linux-x86_64-debian-gcc Check: examples, Result: NOTE Examples with CPU time > 2.5 times elapsed time user system elapsed ratio cb.gblinear.history 1.454 0.0170.49 3.002 ``` I can't reproduce the note on win-builder: https://win-builder.r-project.org/ as it's running on Windows but the note appears on debian tests. I'm not able to reproduce it on my local machine either with Ubuntu 22.04. I'm wondering what the note is trying to tell me and how can I resolve it with confidence. The full log is here: https://win-builder.r-project.org/incoming_pretest/xgboost_1.7.1.1_20221104_194252/Debian/00check.log . Many thanks! Jiaming __ 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] Examples with CPU time is greater than elapsed time.
Thank you for the suggestions! I think I will hard-code the number of threads to 2 in that specific example. On 11/6/22 02:30, Ivan Krylov wrote: On Sat, 5 Nov 2022 22:41:45 +0800 Jiaming Yuan wrote: Examples with CPU time > 2.5 times elapsed time I'm wondering what the note is trying to tell me and how can I resolve it with confidence. Henrik Bengtsson already gave a good explanation of the problem. Not sure what exactly is the right thing to do, but one way to get rid of this warning could be to pass the argument nthread = min(parallel::detectCores(), 2) to the xgb.cv invocation (if you already use the parallel package anywhere) or maybe to hard-code the use of only one thread in the example. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] FW: Writing to users config directory for CRAN package
Further to Dirk's advice, my BrailleR package creates a folder (dumping ground). Users are asked if they want to use one of my choosing, or a temporary one. If they choose temporary, they get asked again and again until they cave in to my wishes! BrailleR also writes files to the current working directory, but these are done because the user has chosen to run a command that has the purpose of creating files. I put a warning in the documentation for such functions. I'm not suggesting my solution is the gold standard, but it is working well enough to keep the CRAN checkers happy. Jonathan -Original Message- From: R-package-devel On Behalf Of Dirk Eddelbuettel Sent: Sunday, 6 November 2022 9:29 am To: David Hugh-Jones Cc: R package devel Subject: Re: [R-pkg-devel] Writing to users config directory for CRAN package On 5 November 2022 at 19:32, David Hugh-Jones wrote: | I'm considering submitting the package onetime ( | https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhughjonesd%2Fonetime%2F&data=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864581576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EbBh9XCyyKsRTACo7eLxASZW3pm%2BTrXxzKjjnxBa%2Fpo%3D&reserved=0) to CRAN. | | Onetime has functions for showing a message or warning only once (ever | per user). It does this by writing to a file in the user's | configuration directory, as reported by rappdirs::user_config_dir(). There is a base R function tools::R_user_dir() which I use in a few packages along with packageName() to store config information across sessions. A quick search at GitHub's 'cran' org mirroring CRAN finds 110 hits: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Dorg%253Acran%2BR_user_dir%26type%3Dcode&data=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864737810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wlqbm0tZX0h25rm0veh%2F15IAwJ5mqP9VNPUovlaPhdY%3D&reserved=0 You could keep a hashmap in that directory, and maybe (before it has been written a first time) alert the user that you cannot write without (initial) permission. As I recall, the idea behind the (sensible) CRAN Policy is to not litter user directories with random files with the user knowing. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864737810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kB8nHrtC5yGEm4tnOTZDOAGT%2FmtDViGblNvieFlZq7g%3D&reserved=0 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] FW: Writing to users config directory for CRAN package
Thank you both. I guess the package can dog food itself by asking one time whether it can store its files. D On Sun, 6 Nov 2022 at 06:33, Jonathan Godfrey wrote: > > Further to Dirk's advice, my BrailleR package creates a folder (dumping > ground). Users are asked if they want to use one of my choosing, or a > temporary one. If they choose temporary, they get asked again and again > until they cave in to my wishes! > > > BrailleR also writes files to the current working directory, but these are > done because the user has chosen to run a command that has the purpose of > creating files. I put a warning in the documentation for such functions. > > I'm not suggesting my solution is the gold standard, but it is working > well enough to keep the CRAN checkers happy. > > Jonathan > > > -Original Message- > From: R-package-devel On Behalf > Of Dirk Eddelbuettel > Sent: Sunday, 6 November 2022 9:29 am > To: David Hugh-Jones > Cc: R package devel > Subject: Re: [R-pkg-devel] Writing to users config directory for CRAN > package > > > On 5 November 2022 at 19:32, David Hugh-Jones wrote: > | I'm considering submitting the package onetime ( > | > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhughjonesd%2Fonetime%2F&data=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864581576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EbBh9XCyyKsRTACo7eLxASZW3pm%2BTrXxzKjjnxBa%2Fpo%3D&reserved=0) > to CRAN. > | > | Onetime has functions for showing a message or warning only once (ever > | per user). It does this by writing to a file in the user's > | configuration directory, as reported by rappdirs::user_config_dir(). > > There is a base R function tools::R_user_dir() which I use in a few > packages along with packageName() to store config information across > sessions. A quick search at GitHub's 'cran' org mirroring CRAN finds 110 > hits: > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Dorg%253Acran%2BR_user_dir%26type%3Dcode&data=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864737810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wlqbm0tZX0h25rm0veh%2F15IAwJ5mqP9VNPUovlaPhdY%3D&reserved=0 > > You could keep a hashmap in that directory, and maybe (before it has been > written a first time) alert the user that you cannot write without > (initial) permission. As I recall, the idea behind the (sensible) CRAN > Policy is to not litter user directories with random files with the user > knowing. > > Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-package-devel@r-project.org mailing list > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C01%7Ca.j.godfrey%40massey.ac.nz%7C33d5f70186284052580908dabf6c7826%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C638032769864737810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kB8nHrtC5yGEm4tnOTZDOAGT%2FmtDViGblNvieFlZq7g%3D&reserved=0 > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Sent from Gmail Mobile [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
