On Fri, Dec 18, 2009 at 01:11:16PM -0500, Hans-Christoph Steiner wrote:
I will test it, but that faces the same old can of worms with [until], which is to say, what if the user just passed a very very large number to until? (e.g. if they are processing a very long list).
Yup, no easy answer. This is where the timeout comes in. I can't think of another way.
Yes, I see that in the case of unit tests, which are pretty much always meant to run for a finite time and then exit, the upper bound of the run time is a known quantity on a reasonably fast CPU. A timeout in this case is a fine solution.
The goal of PyPd is two things: 1) provide an easy way to launch, communicate with, and shut down an instance of Pd. 2) provide an easy and general way to parse Pd files in order to extract useful information from them.
Those both sound good. For the unittests, #1 seems more important. I guess the question is whether you want to deal with the until/timeout problem in PyPd. I.e. tracking whether a Pd process stops responding and providing a way to kill/restart it.
This doesn't belong in the library, but providing your own watchdog/timeout would be easy, and killing/restarting Pd is the whole point of the library so that should be easy too. Basically you should sub-class the Pd class to build something with that functionality. Email me off list if you get stuck or need tips on doing that. This could be as simple as spawning a separate thread which sleeps for 10 seconds and then kills Pd if the unit test is still running, or exits if it receives a special Event() from the main loop before then.
Yesterday I improved the exiting routine for RjDj, so hopefully it's quite robust now. I can see that you will already need two things added to PyPd:
- Ability to specify which Pd to execute.
- Make sure Pd can be restarted once it's been killed.
The first one is quite minor, and the second one is just a matter of testing, so I'll try and make them soon.
Chris.