[R-pkg-devel] gdb availability on r-devel-linux-x86_64-fedora-gcc
Hello list,
Our package gadget3[0] has just started failing the "donttest"
additional check[1] on r-devel-linux-x86_64-fedora-gcc, specifically:-
> # Build the model in an isolated R session w/debugger
> writeLines(TMB::gdbsource(g3_tmb_adfun(cpp, compile_flags = "-g",
output_script = TRUE)))
Error in system(cmd, intern = TRUE, ignore.stdout = FALSE,
ignore.stderr = TRUE) :
error in running command
Calls: writeLines -> -> system
Execution halted
The system call in question is done by the TMB package[2], and not ours
to tinker with:
cmd <- paste("R --vanilla < ",file," -d gdb --debugger-args=\"-x",
gdbscript,"\"")
txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
My only vaguely reasonable guess is that gdb isn't available on the host
in question (certainly R will be!). How likely is this? Is it worth
trying to resubmit with the call wrapped with an "if (gdb is on the
path)"?
If this is a silly idea, which I suspect it is, would a resubmission
removing the example be accepted or just raise red flags? This is
obviously cheating---and it's a useful example I'd rather keep---but I'm
not sure we have many other options available to us.
This example isn't a problem when run elsewhere. The TMB package itself
isn't failing[3], but there doesn't seem to be any examples exercising
TMB::gdbsource() there.
Thanks for any help!
[0] https://CRAN.R-project.org/package=gadget3
[1] https://www.stats.ox.ac.uk/pub/bdr/donttest/gadget3.out
[2]
https://github.com/kaskr/adcomp/blob/master/TMB/R/gdbsource.R#L40-L42
[3] https://cran.r-project.org/web/checks/check_results_TMB.html
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] gdb availability on r-devel-linux-x86_64-fedora-gcc
On 12.08.2023 15:10, Jamie Lentin wrote:
Hello list,
Our package gadget3[0] has just started failing the "donttest"
additional check[1] on r-devel-linux-x86_64-fedora-gcc, specifically:-
> # Build the model in an isolated R session w/debugger
> writeLines(TMB::gdbsource(g3_tmb_adfun(cpp, compile_flags = "-g",
output_script = TRUE)))
Error in system(cmd, intern = TRUE, ignore.stdout = FALSE,
ignore.stderr = TRUE) :
error in running command
Calls: writeLines -> -> system
Execution halted
The system call in question is done by the TMB package[2], and not ours
to tinker with:
cmd <- paste("R --vanilla < ",file," -d gdb --debugger-args=\"-x",
gdbscript,"\"")
txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
My only vaguely reasonable guess is that gdb isn't available on the host
in question (certainly R will be!). How likely is this? Is it worth
trying to resubmit with the call wrapped with an "if (gdb is on the path)"?
I guess it is really not available as that system got an update.
Note that you package does not declare any SystemRequirements. Please do
so and mention gdb.
Wrapping it in "if (gdb is on the path)" seems a good solution.
Best,
Uwe Ligges
If this is a silly idea, which I suspect it is, would a resubmission
removing the example be accepted or just raise red flags? This is
obviously cheating---and it's a useful example I'd rather keep---but I'm
not sure we have many other options available to us.
This example isn't a problem when run elsewhere. The TMB package itself
isn't failing[3], but there doesn't seem to be any examples exercising
TMB::gdbsource() there.
Thanks for any help!
[0] https://CRAN.R-project.org/package=gadget3
[1] https://www.stats.ox.ac.uk/pub/bdr/donttest/gadget3.out
[2] https://github.com/kaskr/adcomp/blob/master/TMB/R/gdbsource.R#L40-L42
[3] https://cran.r-project.org/web/checks/check_results_TMB.html
__
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] gdb availability on r-devel-linux-x86_64-fedora-gcc
On 12 August 2023 at 18:12, Uwe Ligges wrote:
| On 12.08.2023 15:10, Jamie Lentin wrote:
| > The system call in question is done by the TMB package[2], and not ours
| > to tinker with:
| >
| > cmd <- paste("R --vanilla < ",file," -d gdb --debugger-args=\"-x",
| > gdbscript,"\"")
| > txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
| >
| > My only vaguely reasonable guess is that gdb isn't available on the host
| > in question (certainly R will be!). How likely is this? Is it worth
| > trying to resubmit with the call wrapped with an "if (gdb is on the path)"?
|
|
| I guess it is really not available as that system got an update.
| Note that you package does not declare any SystemRequirements. Please do
| so and mention gdb.
|
| Wrapping it in "if (gdb is on the path)" seems a good solution.
Seconded esp as some systems may have lldb instead of gdb, or neither.
Adding a simple `if (nzchar(Sys.which("gdb")))` should get you there.
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] gdb availability on r-devel-linux-x86_64-fedora-gcc
On 12.08.2023 23:19, Dirk Eddelbuettel wrote:
On 12 August 2023 at 18:12, Uwe Ligges wrote:
| On 12.08.2023 15:10, Jamie Lentin wrote:
| > The system call in question is done by the TMB package[2], and not ours
| > to tinker with:
| >
| > cmd <- paste("R --vanilla < ",file," -d gdb --debugger-args=\"-x",
| > gdbscript,"\"")
| > txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
| >
| > My only vaguely reasonable guess is that gdb isn't available on the host
| > in question (certainly R will be!). How likely is this? Is it worth
| > trying to resubmit with the call wrapped with an "if (gdb is on the path)"?
|
|
| I guess it is really not available as that system got an update.
| Note that you package does not declare any SystemRequirements. Please do
| so and mention gdb.
|
| Wrapping it in "if (gdb is on the path)" seems a good solution.
Seconded esp as some systems may have lldb instead of gdb, or neither.
Adding a simple `if (nzchar(Sys.which("gdb")))` should get you there.
Dirk
Note that also
1. The machine does not have R on the path (but Rdev)
2. you need to use a current pandoc. Citing Professor Ripley: "The
platforms failing are using pandoc 3.1.6 or (newly updated, M1mac) 3.1.6.1"
Best,
Uwe Ligges
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Examples are too long in computation for CRAN
Hello all, Not sure how to handle this, as it had not been an issue on my previous CRAN submissions. It appears that some of my examples/tests are taking too long to run for CRAN's standards. Is there a way around this other than the simple "change the example" or "change the test"? Moreover, is there any insight as to why this would happen on the third update of the package rather than on the first or second? Thanks in advance, and see below for the NOTE: Flavor: r-devel-linux-x86_64-debian-gcc Check: examples, Result: NOTE Examples with CPU (user + system) or elapsed time > 5s user system elapsed panelsummary 9.574 0.273 0.817 panelsummary_raw 6.048 0.164 0.450 Examples with CPU time > 2.5 times elapsed time user system elapsed ratio panelsummary_raw 6.048 0.164 0.450 13.804 panelsummary 9.574 0.273 0.817 12.053 clean_raw3.684 0.064 0.514 7.292 Flavor: r-devel-linux-x86_64-debian-gcc Check: tests, Result: NOTE Running 'testthat.R' [54s/6s] Running R code in 'testthat.R' had CPU time 9.3 times elapsed time [[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] Examples are too long in computation for CRAN
В Sat, 12 Aug 2023 22:49:01 -0700 Michael Topper пишет: > It appears that some of my examples/tests are taking too > long to run for CRAN's standards. I don't think they are running too long; I think they are too parallel. The elapsed time is below 1s, but the "user" time (CPU time spent in the process) is 7 to 13 times that. This suggests that your code resulted in starting more threads than CRAN allows (up to 2 if you have to test parallellism). Are you using OpenMP? data.table? makeCluster()? It's simplest to always to default to a parallelism factor of 2 in examples an tests, because determining the right number is a hard problem. (What if the computer is busy doing something else? What if the BLAS is already parallel enough?) > Moreover, is there any insight as to why this would happen on the > third update of the package rather than on the first or second? The rule has always depended on the particular system running the checks (five seconds on my 12-year-old ThinkPad or on my ultraportative with an Intel Atom that had snails in its ancestry?). Maybe some dependency of your package has updated and started creating threads where it previously didn't. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Examples are too long in computation for CRAN
On 13.08.2023 08:14, Ivan Krylov wrote: В Sat, 12 Aug 2023 22:49:01 -0700 Michael Topper пишет: It appears that some of my examples/tests are taking too long to run for CRAN's standards. I don't think they are running too long; I think they are too parallel. The elapsed time is below 1s, but the "user" time (CPU time spent in the process) is 7 to 13 times that. This suggests that your code resulted in starting more threads than CRAN allows (up to 2 if you have to test parallellism). Are you using OpenMP? data.table? makeCluster()? It's simplest to always to default to a parallelism factor of 2 in examples an tests, because determining the right number is a hard problem. (What if the computer is busy doing something else? What if the BLAS is already parallel enough?) Moreover, is there any insight as to why this would happen on the third update of the package rather than on the first or second? The rule has always depended on the particular system running the checks (five seconds on my 12-year-old ThinkPad or on my ultraportative with an Intel Atom that had snails in its ancestry?). Maybe some dependency of your package has updated and started creating threads where it previously didn't. Good points, not only for examples and tests, but also for defaults. On shared resources (such as clusters) users may not expect the parallelization you use and then overallocate the resources. Example: 20 cores available to the user who runs makeCluster() for paallelization, but the underlying code does multihreading on 20 cores. Then we end up in 20*20 threads on the machine slowing down the machine and processes of other uers. Hence, defaults should also not be more than 2. Simply allow the user to ask for more. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
