On Sat, May 26, 2012 at 01:12:07PM +0100, Scott Hewitt wrote:
hi,
No I dont think you missed anything just saying that it would be useful if zero time loops could be intercepted before they are run so as to protect the VM
Got it. I think there are some issues with this though. "Zero time" loops can be useful. For example; I might be playing back a wave-file and at some point desire to know when the next zero crossing in it is. For that I'd use a loop and this loop wouldn't advance time and would run until either the next such point or at worst the end of the wave-file. In this case you and I know that the loop will terminate but ChucK doesn't. Those two types of loops are non-trivial to sort; it would need to happen in the parser yet also take the state of the VM into account; anything that uses me.yield() may be safe, but only if there is at least one other shred running, for example. We do have the popup in the Mini and I think that "watchdog" functionality is also there in the CLI version but it could be made more accessible there, for example by printing a message when a halted VM is suspected. That's quite close to what you propose in practice, I think, and workable. Imho parser/compilation errors leading to segfaults are a bigger danger to the VM but my perception might be slanted by my own use patterns. As a final point; the worst loss of the VM is in the Mini where a loss of the VM typically also means a loss of the contents of unsaved buffers. There auto-saving buffers to a special directory would decrease the risks by decreasing the consequences. To me those two solutions seem like a decent remedy for some of the risks that powertools like detailed control over execution create. ChucK is probably not the right tool for high-security or high-risk applications and a bit of risk does add some excitement ;-). IMHO, IMHO and IMHO, respectively. Trying to solve the halting problem is primarily like designing a perpetuum mobile; great fun. Kas.