CRAN 1.0.1

[mattansb]

Closes #670

[mattansb]

Running revdepcheck locally

---

## revdepcheck results

We checked 28 reverse dependencies, comparing R CMD check results across CRAN and dev versions of this package.

 * We saw 0 new problems related to effectsize.

[mattansb]

Sent to winbuilder

• R-release
• R-devel
• R-oldrelease

[mattansb]

Is anyone able to reproduce these issues? I have R 4.5.0 on windows and everything is working fine...

https://win-builder.r-project.org/95JM4QBwX887/00check.log

@rempsyc most of these (warning: restarting interrupted promise evaluation) are coming from effectsize(..., data = ) - please advise.

@strengejacke the rest are related to include_intercept= but seem to ignore the fix to {parameters}? Is this again the issue were updates to make their way to winbuilder...?

[strengejacke]

I had this restarting warning, too, it was due to a call to tryCatch() inside tryCatch().

[strengejacke]

@strengejacke the rest are related to include_intercept= but seem to ignore the fix to {parameters}? Is this again the issue were updates to make their way to winbuilder...?

Strange, I have no issues locally, too. And on GitHub, tests also pass.

[mattansb]

I had this restarting warning, too, it was due to a call to tryCatch() inside tryCatch().

There are no tryCatch()s in the relevant code :/ I blame @rempsyc !

Strange, I have no issues locally, too. And on GitHub, tests also pass.

Should we wait a few days, see if winbuilder gets the updated parameters?

[strengejacke]

I'm on vacation until Friday, so I won't be able to investigate further. You can also just try to submit?

[rempsyc]

Is anyone able to reproduce these issues? I have R 4.5.0 on windows and everything is working fine...

I cannot replicate this on R version 4.5.0 on Windows 11 with devtools::check(remote = TRUE) :(

Do you get these errors reliably Mattan? I also don't see these errors on the CRAN failings... so maybe fine? 😬 sorry for these troubles

[strengejacke]

The warning message "restarting interrupted promise evaluation" in R package testing typically arises when an error occurs during the evaluation of a promise (a delayed computation), and R attempts to re-evaluate that promise later.

Here's a breakdown of what's happening and why it's a warning:

Understanding Promises:

• In R, promises are objects that represent a value that might not exist yet. They are often associated with function arguments that are not immediately evaluated. The evaluation is delayed until the value is actually needed within the function. This is a key aspect of R's lazy evaluation.

What Causes the Warning:

The warning usually appears in scenarios like this:

• An Error Occurs Within a Promise: When a function tries to evaluate a promise, and the code within that promise leads to an error.
• The Promise is Evaluated Again: Despite the error, some part of the code might try to access the value of that same promise again. This triggers R to attempt to re-evaluate it.
• The Warning is Issued: Since the promise previously resulted in an error, R warns you that it's trying to restart the evaluation of something that already failed.

Why is it a Warning?

• Potential for Infinite Loops or Repeated Failures: If the underlying condition that caused the error in the promise evaluation persists, re-evaluating the promise will likely lead to the same error again. This could potentially lead to infinite loops or repeated failures in your code.
• Unexpected Behavior: The fact that a promise evaluation was interrupted and is being restarted might indicate unexpected control flow or error handling in your code.
• Underlying Issues: It can be a symptom of a deeper problem in how your functions are handling errors or managing delayed computations.

Common Scenarios Where You Might See This Warning in Package Testing:

• Error Handling in Functions: If a test involves a function that is expected to throw an error, and the test tries to access a value that depended on the part of the function that errored out.
• Lazy Evaluation and Side Effects: If a promise involves side effects (like writing to a file or modifying a global variable) and the evaluation is interrupted, restarting it might lead to unintended consequences.
• tryCatch or on.exit Behavior: Sometimes, the way error handling mechanisms like tryCatch or on.exit are used can lead to promises being re-evaluated after an error.
• Asynchronous Operations (less common in basic package tests): In more complex scenarios involving asynchronous operations, an interrupted promise might be restarted.

What to Do When You See This Warning During Package Testing:

• Examine the Test Code: Carefully review the test that produced the warning. Understand the sequence of operations and where the error might be occurring.
• Look at the Function Under Test: Investigate the function being tested, especially how it handles potential errors and how it uses lazy evaluation.
• Identify Why the Promise is Being Re-evaluated: Determine which part of the code is trying to access the value of the promise after it has already failed.
• Ensure Proper Error Handling: Make sure your functions and tests have robust error handling mechanisms in place to prevent the re-evaluation of promises that have already errored. This might involve using tryCatch more effectively or restructuring your code to avoid relying on the value of a failed promise.
• Consider the Side Effects: If the promise involves side effects, think about the implications of restarting the evaluation. You might need to ensure that side effects are handled appropriately in case of errors.
• Muffle the Warning (with caution): In some specific cases, if you understand why the warning is occurring and are confident that it doesn't indicate a serious problem, you might consider muffling the warning within your test using suppressWarnings(). However, this should be done with caution and only when you are sure it's safe to ignore the warning. It's generally better to address the underlying cause.

In summary, the "restarting interrupted promise evaluation" warning in R package testing signals that an error occurred during the evaluation of a delayed computation, and R is attempting to evaluate it again. It's a sign that you should investigate your code and tests to ensure proper error handling and prevent potential issues arising from the re-evaluation of failed promises.

[mattansb]

Is anyone able to even locate where the warning is happening?

[rempsyc]

Sadly no

[mattansb]

thanks, package effectsize_1.0.1.tar.gz is on its way to CRAN.

lol, I guess Daniel knows what he's talking about ("You can also just try to submit?")