I've had many hard reboots after doing the same thing in the glsl editor ;)
One possible improvement: have the execution + UI on separate threads somehow. This way at least if it's looping you have some chance of the stop button actually doing what it should. It won't work in all cases, but might possibly work in some? Otherwise, how do you detect the loop? Like Chris Wright said, that's not an easy challenge. I mean, I've written shaders before that go into a loop for a *long* time, like 30 seconds plus. This locks the whole machine up until it's finished. But it's designed to loop for this long. How do you tell that apart from a crash or infinite loop? Chris On 9 Feb 2011, at 23:40, Keith Lang wrote: > When I started to use the Javascript Editor for the first time in QC, I lost > work because I accidentally created an infinite loop. > > I admit I'm not a developer, and only have the lightest grasp of the > underlying architecture. > > However, as an HI guy I can only look at such an experience and see an > opportunity for improvement. :) > > Keith. > > > > > ######## > On Thursday, 10 February 2011 at 10:14 AM, Christopher Wright wrote: > >>> I stick with what I said in my last email though- if this kind of problem >>> is inevitably going to happen with certain setups, and the Quartz Composer >>> Editor allows you to setup a system where it does, and there isn't any kind >>> of warning that it might, that's a problem. >> >> The QC Editor cannot protect you from yourself (even when unfortunate CI >> details leak through the abstractions, like in this case). You could enqueue >> hundreds of millions of large images in a Queue, and that'd almost certainly >> take down even the most powerful machines -- should that warn you? If so, at >> what point should it emit the warning? At 1,000,000 images? 1,000,000,001? >> There's unfortunately no good way to determine where that point is, or even >> where such situations might arise. >> >> JavaScript in QC allows for potentially infinite loops (I'm sure everyone's >> been bitten by that one before). Should that warn? That's not even possible >> (see: Halting Problem). It could also take a structure input, and append a >> single element to it. Feed that into itself, and you've got an unboundedly >> growing structure, with no possible way to predict it, much less prevent it. >> >> It's actually possible to do iterative effects in CI in QC, provided the >> number of iterations is bounded. For people doing such a thing (as goofy and >> unlikely as that might be), this warning will make them believe they're >> doing something wrong when they aren't (necessarily). >> >> -- >> Christopher Wright >> [email protected] >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/quartzcomposer-dev/songcarver%40gmail.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/psonice%40gmail.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
