Skip to content

Conversation

shikokuchuo
Copy link
Member

@shikokuchuo shikokuchuo commented Oct 17, 2025

Closes #142, closes #48.

As discussed in today's Shiny meeting. This PR takes an approach that works universally for any type of promise.

I need time to ponder (i) the function name, (ii) whether it should throw on rejection, and (iii) whether it is correct/optimal to set all = FALSE for later::run_now().

To add:

  • Tests
  • News item

In the meantime, feel free to comment @schloerke @gadenbuie @cpsievert.

@shikokuchuo
Copy link
Member Author

shikokuchuo commented Oct 19, 2025

After putting together this PR, I came across the version of wait_for() @lionel- uses internally for tests in coro. This gives me confidence in (i) the naming of the function and (ii) its behaviour on error.

@gadenbuie
Copy link
Member

This looks like a great start @shikokuchuo! Have you reviewed the chromote implementation?

Currently this PR resembles various implementations we've used in package testing, which is a much more controlled environment. For a public, robust and final solution in promises we should be very convinced about the features we do or do not need from the chromote implementation.

@shikokuchuo
Copy link
Member Author

Thanks @gadenbuie I hadn't actually reviewed chromote as I was under the impression that it wasn't an R-level implementation, let alone one based on promises! Luckily it seems we all converge on the same approach.

Chromote additionally has a lot of code to handle interrupts and my gut reaction is that this isn't necessary in the general case, but this should become apparent when I actually write the tests!

@gadenbuie
Copy link
Member

Chromote additionally has a lot of code to handle interrupts and my gut reaction is that this isn't necessary in the general case, but this should become apparent when I actually write the tests!

I think this gets at what I meant by the difference between the implementations we've used in testing and a user-facing API. My inclination is that in user-facing code we'd want, or might even need, to support interrupts and other features that users would need and expect in an interactive session.

@schloerke
Copy link
Contributor

Yes. Both @gadenbuie and I would like to have the chromote version with interrupt support.

Thank you, @shikokuchuo !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Provide a method to make a promise synchronous Provide a way to block and wait for a promise (for testing)

3 participants