On Dec 20, 2007, at 10:37 AM, Miller Puckette wrote: > ... and to wade in, here's an idea I'm toying with: every 1000 or > so bangs that until sends out, check the CPU clock. Each time more > than a second elapses, go check the input buffer from the GUI, and > execute it (so that mouse clicks would appear within the context of > the until loop!) This would allow you to delete the offending until, > assuming you know where it is. > > Another idea: have a GUI item that interrupts Pd, causing the stack > frame to be rudely dropped and all clocks to be unset.
I think this second option would be quite useful, a high priority reset item for escaping in an emergency. There are a number of things that can totally take over your machine, beyond just the endless [until]. For example, trying to play a complex Gem scene at a high frame rate on a slower machine. That will totally freeze up the OS sometimes. So this may not be pretty, but it's certainly prettier than killing Pd or hard resetting your machine. In addition, I like the idea of ignoring bangs on [until]'s hot inlet unless something is connected on the cold inlet. That would help the situation without detriment that I can see. When it ignores the bang, it should issue a warning. I am not sure how feasible it is though. .hc > > aren'y they both ugly? but maybe something like this is needed ... > > M > > > On Thu, Dec 20, 2007 at 05:39:14PM +0000, Andy Farnell wrote: >> On Thu, 20 Dec 2007 10:43:57 -0600 >> "Charles Henry" <[EMAIL PROTECTED]> wrote: >> >>> On Dec 19, 2007 7:58 PM, Chris McCormick <[EMAIL PROTECTED]> wrote: >>>> On Wed, Dec 19, 2007 at 02:22:44PM +0000, Andy Farnell wrote: >>>>> On Mon, 17 Dec 2007 22:23:11 +0100 IOhannes m zmoelnig >>>>> <[EMAIL PROTECTED]> wrote: >>>>>> but a [bang(--[until] is not meant to loop infinitely. >>>>>> it loops until a certain condition is reached. >>>>> >>>>> As it stands the behaviour of [until] is correct, but it's a >>>>> very dangerous >>>>> object unlike almost every other Pd object it's the only one >>>>> beginners can >>>>> really screw up with. >>> >>> I think a useful feature that would perhaps be able to handle this >>> type of problem is a 'halt'/'continue' routine for message >>> processing. >>> Say, for example, it could be automatically handled during a stack >>> overflow-clear the stack and send an error message. Or triggered by >>> the watchdog to catch bang/until problems. Something like that >>> would >>> give you the opportunity to save/re-load or add additional >>> objects to >>> stop the infinite loop, when not intended. >> >> >> The subject of the watchdog is really interesting and I'd love to >> hear a deeper discussion on it. But how do you propose to identify >> an infinite loop? At what point does the watchdog say "Hi I'm Clippy >> your Pd Watchdog... did you mean to create an infinite loop?" >> >> >>> but it would still run into those problems of finding an arbitrary >>> condition to trigger the 'halt' >> >> Hmmmm, there's beard stroker. :) >> >> a. >> >> >>> >>> Chuck >>> >>> _______________________________________________ >>> PD-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >>> listinfo/pd-list >> >> >> -- >> Use the source >> >> _______________________________________________ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >> listinfo/pd-list > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ------------------------------------------------------------------------ ---- http://at.or.at/hans/ _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
