Mathieu Bouchard wrote:
On Sun, 23 Dec 2007, Hans-Christoph Steiner wrote:
e.g. "fail_blabla" will only success if it returns the state "FAIL" immediately or after a "WAIT".
In a binary system, anything that doesn't success would be a failure. I don't quite get the WAIT state. Do you have an example of where to use that?
In most tristate electronics, the third state is WAIT, but in Pd, you normally do that by not sending a message: if as binary you'd send a 0 or 1 while running a certain method, and want to introduce a WAIT state, you'd make it not output anything at first, introduce proper [delay], and only later send a 0 or 1 when it's ready. It's as simple as that. If the answer is not going to come, an explicit "wait" message isn't going to disambiguate nor solve that, so it might be a good idea to put some timeout protection *outside* of the tests themselves.
In digital electronics the third state is high-impedance, that is, it is not driven high or low. However, a device reading a Hi-Z output will itself always output either 0 or 1 and has no way of telling that it is connected to a Hi-Z output, so if you want Hi-Z to mean WAIT, you'll need another line that is driven to 1 or 0 to indicate that the result isn't in yet. It's an early result in computational theory that in general it is not possible to know if a process will terminate or not. Probably using a watchdog timer is the best way out: if the result isn't in after a reasonable delay, assume it's not going to happen, something like:
[test_suite( | | [b] | | | [delay] [object_under_test] | | | [fail( [pass( [stop(------->to [delay]
Martin