similar to: Very hard to reproduce bug (?) in R-devel

Small correction to my previous email: the error can also be replicated by installing the package and then sourcing the tests. This is slightly faster than running R CMD check. It is also how we ran the tests with gdb. This will run the tests in a Docker container and raise the same error. (To run outside of a Docker container, simply leave out the first line). docker run --rm -ti pooltest

) On Wed, Apr 5, 2017 at 2:59 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Winston Chang <winstonchang1 at gmail.com> > >>>>> on Tue, 4 Apr 2017 15:29:40 -0500 writes: > > > I've done some more investigation into the problem, and it is very > > difficult to pin down. What it looks like is

> > >> I've done some more investigation into the problem, and it is very difficult to pin down. What it looks like is happening is roughly like this: - `p` is an environment and `p$e` is also an environment. - There is a loop. In each iteration, it looks for one item in `p$e`, saves it in a variable `x`, then removes that item from `p$e`. Then it invokes `x()`. The loop runs

On Wed, Apr 5, 2017 at 2:24 PM, Robert McGehee <rmcgehee at walleyetrading.net> wrote: > Winston, > I had a similar experience to you tracking down an insanely difficult bug > in my R code that "disappeared" whenever slight changes were made to the > script (e.g. like adding cat() statements). In my case, it coincided with > my over-eager compilation of R and its

Winston, I had a similar experience to you tracking down an insanely difficult bug in my R code that "disappeared" whenever slight changes were made to the script (e.g. like adding cat() statements). In my case, it coincided with my over-eager compilation of R and its library stack, as I was also experimenting with a cutting edge version of the gcc compiler as well as what I thought were

Hello, I'm writing a script that automates the testing of reverse dependencies of a package. I found the function testInstalledPackage in the tools package, which seems to do what I want. However, when I use it for a source package that was installed with --install-tests, I've noticed that only the actual test files (e.g. located in inst/tests) are available and run. In other words the

Hello, Windows R-devel no longer lets me use testthat even though the CRAN checks are pretty much clean. I have copied my session output below. Will R Under development (unstable) (2017-09-16 r73293) -- "Unsuffered Consequences" Copyright (C) 2017 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) R is free software and comes with ABSOLUTELY NO

Hi! Im currently developing an R package to automatically give students feedback on programming assignments in R. I use the testthat package as an engine for the unit testing and do a wrapper to make the automatic marking easy for the students. One function (called mark_my_file() ) will mark the students lab file using testthat tests and a new (simple) reporter. The problem is that I need to do

I am the author of R package animint which uses testthat for unit tests. This means that there is a single test file (animint/tests/testthat.R) and during R CMD check we will see the following output * checking tests ... Running ?testthat.R? I run these tests on Travis, which has a policy that if no output is received after 10 minutes, it will kill the check. Because animint's testthat

On 10/01/2023 4:07 p.m., Sebastian Meyer wrote: > Am 10.01.23 um 21:28 schrieb Duncan Murdoch: >> On 10/01/2023 2:05 p.m., Ivan Krylov wrote: >>> On Tue, 10 Jan 2023 16:27:53 +0000 >>> RICHET Yann <yann.richet at irsn.fr> wrote: >>> >>>> In facts, 10 threads are asked by armadillo for some LinAlg, which >>>> backs to two threads as

Thank you all, for these advices. So I try to fix OMP_THREADS, cleanup tests, and display explicitly what test is running by moving in tests/ instead of tests/testthat/... Next step should be to investigate blocking test using a reporter (maybe "list"). For now, waiting for CRAN results... Yann -----Message d'origine----- De?: Duncan Murdoch <murdoch.duncan at gmail.com>

Am 10.01.23 um 21:28 schrieb Duncan Murdoch: > On 10/01/2023 2:05 p.m., Ivan Krylov wrote: >> On Tue, 10 Jan 2023 16:27:53 +0000 >> RICHET Yann <yann.richet at irsn.fr> wrote: >> >>> In facts, 10 threads are asked by armadillo for some LinAlg, which >>> backs to two threads as warned. >> >> I think you're right about your tests de-facto

Hi all, I'm trying to understand how the search path and namespaces interact. For example, take the devtools package which suggests the testthat package. Here's what the search path looks like after I load each of those packages: > library(devtools) > search() [1] ".GlobalEnv" "package:devtools" "package:stats" [4]

Hi! The problem is that the test environment inherits from the global environment. See https://github.com/hadley/testthat/blob/master/R/test-files.r The students labs are simply an R script file. Say that they have an assignment to calculate sqrt(2) and store it in variable a. In the same session they should be able to test the script file when they are done (using a function mark_my_file() in

I am trying to learn how to run the unit tests in the stringr package and have the following questions. 1) The r-cran-stringr package does not suggest/depend on the r-cran-testthat package . Would it make sense to add such a thing since after all the tests in /usr/lib/R/site-library/stringr/tests rely on testthat package? 2) I am getting the following error when trying to run the unit tests %

On 10/01/2023 2:05 p.m., Ivan Krylov wrote: > On Tue, 10 Jan 2023 16:27:53 +0000 > RICHET Yann <yann.richet at irsn.fr> wrote: > >> In facts, 10 threads are asked by armadillo for some LinAlg, which >> backs to two threads as warned. > > I think you're right about your tests de-facto using two threads, but > it might be a good idea to _default_ to up to

Dear all, as a follow-up to the question asked on R-package-devel (see link below): Someone sent a package to CRAN with a few problems. There's more things wrong with the submission, but one thing that really caught my eye was the following error: Warning message: running command '"C:/PROGRA~1/R/R-33~1.2/bin/x64/R" CMD BATCH --vanilla "testthat.R"

Thank you for your answer. In facts, 10 threads are asked by armadillo for some LinAlg, which backs to two threads as warned. But I cannot imagine this costs so much time just for that... A deeper analysis of time spent seems to point that a large time was mainly spent on testthat and Rcpp dependencies compilation... But other recent packages depending on these also are not spending so much time.

Hello, I am getting a fresh CentOS 6.7 machine set up with all of the goodies for R 3.2.3, including dplyr package. I am unable to successfully install it. Below I show the failed installation using utils::install.packages() and then again using devtools::install_github(). Each yields an error similar to the other but not quite exactly the same - the error messages sail right over my head. I

On Tue, 10 Jan 2023 16:27:53 +0000 RICHET Yann <yann.richet at irsn.fr> wrote: > In facts, 10 threads are asked by armadillo for some LinAlg, which > backs to two threads as warned. I think you're right about your tests de-facto using two threads, but it might be a good idea to _default_ to up to two threads in tests and examples. This is especially valuable for third-party