On TimeConstrained[]

[aravindh-krishnamoorthy]

Nested TimeConstrained[] and RemainingTime[] are crucial for Rubi and other applications. In this thread, I propose to collect: (a) the requirements for these functions, (b) some initial design ideas, and (c) why the old implementation had to be removed. The impact of future multi-threading will also need to be considered. This will help me or others implement the feature better.

[rocky]

@aravindh-krishnamoorthy To be able to correct the problems with TimeConstrained[] it would be very helpful to have simple reproducible examples or test cases that can be run. This way, it is easy not only to demonstrate the problem but also to assess the goodness of solutions or that we've completely fixed the problem.

But even informally, what steps does one have to do to see the problem? My understanding is that you were going to add a mathics-core issue or feature, right?

[aravindh-krishnamoorthy]

Hello @rocky ! Based on a comment from @mmatera, I think there was a previous version of TimeConstrained[]. What were the deficiencies of this? What I'd like to do right now is to collect what "features" must be supported by that and related functions. Then, I want to think about what would be the best way to implement and test them.

[mmatera]

Indeed, it was a previous version with a homebrew implementation of TimeConstrained. That implementation failed to interrupt computations running in Sympy. The new version is based on the stopit package, but it seems to have some issues.

[rocky]

I am a bit lost at where things stand now. Independent of what happened in the past and how we go forward, would you summarize where things stand right now.

I'd like to get the tests in place that demonstrate what we are trying to fix put in before we start thinking about the fixes.

How does someone test what you have? Can we start doing CI testing of Mathics3-Rubi? How can a person see in quick, easy, and reliable way what the current issues are right now. Thanks.