hi. i put this back to the pd-list. i guess (and hope) it was only by accident to you answered me in private.
Andy Farnell wrote:
On Mon, 17 Dec 2007 21:08:05 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
Andy Farnell wrote:
On Mon, 17 Dec 2007 20:08:20 +0100 Derek Holzer derek@umatic.nl wrote:
Sending a "bang" message to the [until] object, created without an argument saying how many times the bang should be done, will give roughly the same effect--
If only!
Objects that overflow the stack cause an exception, most of which trap nicely and you get a gentle report not to do that again.
Sending an unqualified bang to [until] will have you reaching for power switch because it enters a very tight loop with no exit condition and no hope of even seeing a SIGINT.
I know we like to pretend this is "feature", but isn't it time to treat it as a bug?
so what is the behaviour you would like to see? only allow fixed sized loops? stop iterating after a maximum 10 bangs? use [del 0] inbetween to make the loop interruptible?
None of the above. Behaviour should be normal but if it's instantiated without arguments then bangs are ignored and only positive (I just saw the bug report for negatives) numbers are processed. Any finite number of iterations is the users concern, having bang mean loop infinitely seems wrong.
but a [bang(--[until] is not meant to loop infinitely. it loops until a certain condition is reached.
what you are asking for is a [for] object ("for" is _usually_ used for looping through a fixed number of iterations) [until] corresponds to "while" and (tada!) "until" loops, which _usually_ are used to iterate a to-be-determined-number times.
so, probably you should just write an abstraction "for.pd":
[inlet] | [int $1] | [max 0] | [until] | [outlet]
and use that instead of [until]. you should be saved from any trouble you are experiencing so far.
(luckily it is like that: with [until] you can easily write [for]; it would be more difficult to do it the other way round; that is why i prefer it like it is)
btw, Pd does not freeze for me. while i am typing this email, an infinite [until] is eating most of my CPU power (but not all).
now i did send it a SIGINT and this freed my CPU.
Now that's news to me. I've never been able to free a machine from a locked up [until], but I guess it must be possible in theory with a powerful enough CPU.
i don't think it is related to the power of CPU (btw, i am using a AMD-XP2000+) [bnag(--[until] should take all the resources the OS will grant it. (just like "while(1);" will take all the resources it can get) if the OS gives is _all_ the resources of the CPU you have a freeze. if the OS reserves some cycles for itself, then you will be able to stop the process.
btw, SIGINT killed my Pd.
fgmadsr. IOhannes
On Mon, 17 Dec 2007 22:23:11 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
hi. i put this back to the pd-list. i guess (and hope) it was only by accident to you answered me in private.
Andy Farnell wrote:
On Mon, 17 Dec 2007 21:08:05 +0100
None of the above. Behaviour should be normal but if it's instantiated without arguments then bangs are ignored and only positive (I just saw the bug report for negatives) numbers are processed. Any finite number of iterations is the users concern, having bang mean loop infinitely seems wrong.
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.
An object can tell if it has a connection made to any of its inlets, so perhaps the safety catch for [until] is not to work unless the condition inlet is connected? If the condition is never satisfied due to user programming error that's another thing but a first line of defence would be helpful.
sorry, i drank rice wine tonight, so excuse the personal opinion:
but isn't this yet another pd list discussion that is meaningless in 99.9% of cases?
you get a stack overflow = you connected some objects incorrectly and made a loop you don't want.
if you see the 'stack overflow' message in the pd console, you should debug your patch so that there are no unwanted loops.
isn't that what happens in 99.9% of cases? i know there are exceptions...roman posted one a while back related to netpd parsing long streams of messages...but for the average pd user, none of this actually matters, does it?
but yeah. i agree.
[bang( | [until]
is a great name for a death metal band!
On Thu, 20 Dec 2007 01:17:33 +0900 "hard off" hard.off@gmail.com wrote:
but yeah. i agree.
[bang( | [until]
is a great name for a death metal band!
LOL! Yeah.
Anyway, in accordance with what you said bang-until is the one that is in the 0.1% of "worth thinking about safety" issues, precisely because it does not cause a stack overflow.
I'm sold on the "it's a feature logic", sorry for being so dumb as to suggest turning Until into For, but we need to consider a safety catch. An overflow is like shooting yourself in the foot, you have to make the careless and embarrasing mistake of pointing it at your foot and pulling the trigger. Bang-until is more like the chamber exploding in your face.
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Thu, 20 Dec 2007 01:17:33 +0900 "hard off" hard.off@gmail.com wrote:
but yeah. i agree.
[bang( | [until]
is a great name for a death metal band!
LOL! Yeah.
Yeah, really cool. Lets make that the t-shirt for pd~conv 2009!
Anyway, in accordance with what you said bang-until is the one that is in the 0.1% of "worth thinking about safety" issues, precisely because it does not cause a stack overflow.
I think, that now, that the "negative numbers" bug of [until] where negative numbers acted like a bang, is fixed in the next Pd, maybe we should tell beginners that they can send a number into Pd when they are unsure if their patch is stopping [until] correctly. Maybe we should even *preach* to send numbers instead of a bang into [until] in general? If you use a large enough number, it's "almost the same" as a bang except that it will stop by itself at some point.
Ciao
Frank Barknecht _ ______footils.org__
On 12/19/07, Frank Barknecht fbar@footils.org wrote:
I think, that now, that the "negative numbers" bug of [until] where negative numbers acted like a bang, is fixed in the next Pd, maybe we should tell beginners that they can send a number into Pd when they are unsure if their patch is stopping [until] correctly. Maybe we should even *preach* to send numbers instead of a bang into [until] in general? If you use a large enough number, it's "almost the same" as a bang except that it will stop by itself at some point.
I seem to be tuning in a little late, in this discussion, but if it's a bad problem, couldn't you change the method of until to use only floats?
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/19/07, Charles Henry czhenry@gmail.com wrote:
I seem to be tuning in a little late, in this discussion, but if it's a bad problem, couldn't you change the method of until to use only floats?
oh, wait, now I get it. You should send a message back to until to stop the loop at some point--that's why it loops until some condition is met.
On Wed, 19 Dec 2007 14:57:12 -0600 "Charles Henry" czhenry@gmail.com wrote:
On 12/19/07, Frank Barknecht fbar@footils.org wrote:
I think, that now, that the "negative numbers" bug of [until] where negative numbers acted like a bang, is fixed in the next Pd, maybe we should tell beginners that they can send a number into Pd when they are unsure if their patch is stopping [until] correctly. Maybe we should even *preach* to send numbers instead of a bang into [until] in general? If you use a large enough number, it's "almost the same" as a bang except that it will stop by itself at some point.
I seem to be tuning in a little late, in this discussion, but if it's a bad problem, couldn't you change the method of until to use only floats?
No, that's the point. I said the same (similar) thing and IOhannes put me right.
Until is the only conditional in Pd we have (unless you construct your own messages with feedback arrangement) that gives a deferred conditional after executing at least once, just like DO-WHILE or REPEAT-UNTIL. If you constrain it with numbers then it's logically a FOR(range) construct. I know there's no situation where you actually want an infinite number of bangs, but where are you going to draw the line?
The thing is not the logical behaviour of [until] but how to make it safer, because it is potentially very nasty. I've lost work to it more than once.
Ciao
Frank Barknecht _ ______footils.org__
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
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Until is the only conditional in Pd we have (unless you construct your own messages with feedback arrangement) that gives a deferred conditional after executing at least once, just like DO-WHILE or REPEAT-UNTIL. If you constrain it with numbers then it's logically a FOR(range) construct.
If people want to make sure to not be bitten by the endless loop, they could just use
[inlet] | [b] | [f 1000000000000] | [inlet] | | [until] | [outlet]
as an abstraction called: [funtil] It will bang 1000000000000 times unless stopped, which is more bangs for the bang than most people would want.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
If people want to make sure to not be bitten by the endless loop, they could just use
[inlet] | [b] | [f 1000000000000] | [inlet] | | [until] | [outlet]
as an abstraction called: [funtil] It will bang 1000000000000 times unless stopped, which is more bangs for the bang than most people would want.
It doesn't look like that would work. The number of times to run is stored as an int, which on most systems is 4-bytes. The maximum is a bit over 2 billion for a float input. :)
Also, from looking at the implementation of [until], a simple bang until will stop after a complete overflow over the storage space in an integer, which is usually 4 billion and change.
(x_count is an int.)
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) x->x_count--, outlet_bang(x->x_obj.ob_outlet); }
-- Russell Bryant
Russell Bryant wrote:
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) x->x_count--, outlet_bang(x->x_obj.ob_outlet); }
Furthermore, if this loop is eating up CPU and making the system unresponsive, you can make the situation much better by adding a simple sleep that makes the process yield to to other waiting processes on each iteration of the loop. The new version would look like:
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) { x->x_count--; outlet_bang(x->x_obj.ob_outlet); usleep(1); } }
On Wed, 2007-12-19 at 18:10 -0600, Russell Bryant wrote:
Furthermore, if this loop is eating up CPU and making the system unresponsive, you can make the situation much better by adding a simple sleep that makes the process yield to to other waiting processes on each iteration of the loop. The new version would look like:
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) { x->x_count--; outlet_bang(x->x_obj.ob_outlet); usleep(1); } }
I think this is the best idea. But after writing my last post to the list, I started to wonder if Miller had a good reason for not doing this when he wrote the original code?
Jamie
Jamie Bullock wrote:
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) { x->x_count--; outlet_bang(x->x_obj.ob_outlet); usleep(1); } }
I think this is the best idea. But after writing my last post to the list, I started to wonder if Miller had a good reason for not doing this when he wrote the original code?
Well, now that i think of it, I think this change is a bit unreasonable. So, I take it back. :) It introduces a small performance hit that shouldn't be there. This construct can be used to do something a bunch of times, and as fast as possible. Also, as I have pointed out before, even if you screw up, it _will_ stop eventually, after some 4 billion something iterations. How long it takes is completely dependent on what you have after the [until].
Just to drive home a point, I measured how long it would take to take an int starting and -1, and decrement it until it gets to 0.
(This system has a dual core Pentium D 2.8 GHz, 2 gigs of ram ...)
test.c:
#include <stdlib.h> #include <stdio.h>
int main() { int i = -1; while (i) i--; exit(0); }
$ gcc -o test test.c $ time ./test
real 0m10.677s user 0m9.437s sys 0m0.048s
So, going back to the original code, the amount of time it takes this construct to finish depends on what you do with outlet_bang(). And really, it's a nice construct to be able to something a bunch of times, as fast as the program can handle.
After all, this is a programming environment. You can write bad code. I have been down this road multiple times before. With an environment like this, you can't try to infer what the user actually meant. I know it would be nice if computers "did you want, not what you say", but implementing that is non-trivial. Personally, I'd rather have deterministic software that does exactly what I say.
So, after going through my own mental exercise to analyze the situation, I now don't think any changes should be made at all.
If anything, it probably just hints at a potential Pd architecture improvement, where patch processing should be premptable, so that the GUI can continue to be responsive, regardless of how the patch is written ...
-- Russell
-- Russell Bryant
On Dec 20, 2007 10:41 AM, Russell Bryant russell@russellbryant.net wrote:
So, after going through my own mental exercise to analyze the situation, I now don't think any changes should be made at all.
I agree with this. This is just one of the few (or more) things you need to know about when dealing with PD. It even says it on the help page for [until]...
I don't think I want the software to try and second guess what I want, and if I construct an [until] that is an infinite loop, then so be it...
Mike
On 12/20/07, Mike McGonagle mjmogo@gmail.com wrote:
On Dec 20, 2007 10:41 AM, Russell Bryant russell@russellbryant.net wrote:
So, after going through my own mental exercise to analyze the situation, I
now
don't think any changes should be made at all.
I agree with this. This is just one of the few (or more) things you need to know about when dealing with PD. It even says it on the help page for [until]...
I don't think I want the software to try and second guess what I want, and if I construct an [until] that is an infinite loop, then so be it...
The only problem I see with it is a contrast with other programming & development environments. If you create a problem in your code, you shouldn't be able to crash the development environment. You halt the process, make changes, and re-compile. And Pd patching is different from this. I'd say it warrants some consideration whether there is a means to allow Pd to make errors without crashing or becoming unresponsive.
Mike
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 20, 2007 1:32 PM, Charles Henry czhenry@gmail.com wrote:
On 12/20/07, Mike McGonagle mjmogo@gmail.com wrote:
I agree with this. This is just one of the few (or more) things you need
to
know about when dealing with PD. It even says it on the help page for [until]...
I don't think I want the software to try and second guess what I want,
and
if I construct an [until] that is an infinite loop, then so be it...
The only problem I see with it is a contrast with other programming & development environments. If you create a problem in your code, you shouldn't be able to crash the development environment. You halt the process, make changes, and re-compile.
Well, that is all fine and dandy, but how many other development environments are REALTIME processors? I would love to see Eclipse present the same sort of REALTIME environment, and NOT have it crash when a user wants to do something like this.
The real power in this sort of thing is that YOU CAN do anything you want with it, and in order to keep it general enough AND REALTIME, things like this will happen.
And Pd patching is different from this. I'd say it warrants some consideration whether there is a means to allow Pd to make errors without crashing or becoming unresponsive.
And to do this, how much of the realtime stuff would get impaired? There are going to be trade offs in any configuration, and I think the current implementation of [until] is correct in allowing the user to cut off their own legs...
Besides, we all need a coffee break now and then, and a reboot makes those things possible...
Mike
Charles Henry wrote:
The only problem I see with it is a contrast with other programming & development environments. If you create a problem in your code, you shouldn't be able to crash the development environment. You halt the process, make changes, and re-compile. And Pd patching is different from this. I'd say it warrants some consideration whether there is a means to allow Pd to make errors without crashing or becoming unresponsive.
Yeah, this is something that Miller has proposed doing something for in another section of this thread, and which I mentioned at the very end of my last message.
"If anything, it probably just hints at a potential Pd architecture improvement, where patch processing should be premptable, so that the GUI can continue to be responsive, regardless of how the patch is written ..."
That's really the core issue, in my opinion. If you can still interact with the GUI, then you can say "oops", and stop the until at any time.
-- Russell Bryant
On Thu, 20 Dec 2007, Charles Henry wrote:
The only problem I see with it is a contrast with other programming & development environments. If you create a problem in your code, you shouldn't be able to crash the development environment. You halt the process, make changes, and re-compile. And Pd patching is different from this. I'd say it warrants some consideration whether there is a means to allow Pd to make errors without crashing or becoming unresponsive.
The other programming languages you allude to all have exception handling and require some amount of handling to be done in any of their externals. Nevertheless, it's still easy to write externals that ignore interruptions, as long as the signal-handler only communicates the signal to the opcode executer: thus a C function can only be interrupted if it calls the interpreter directly or indirectly.
They do it like this because it's still too complicated and unportable to handle interruptibility. I'm not sure whether I'd even ever try the best tricks that I have in mind, because they still can't be 100% crash proof. That said, it's only important to get just a high percentage of success, as without such tactics the process would just be dead anyway. It's just important for the user to know that there's a chance that a crash-recovery trick like that can cause serious malfunction once in a while, and so that any bug reports are done only about situations in which the crash-recovery was not used.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 2007-12-20 at 13:12 -0600, Mike McGonagle wrote:
On Dec 20, 2007 10:41 AM, Russell Bryant russell@russellbryant.net wrote: So, after going through my own mental exercise to analyze the situation, I now
don't think any changes should be made at all.I agree with this. This is just one of the few (or more) things you need to know about when dealing with PD. It even says it on the help page for [until]...
I don't think I want the software to try and second guess what I want, and if I construct an [until] that is an infinite loop, then so be it...
I agree, but it would be nice if there was a distinction between hanging a patch and hanging Pd. The user should at least have the opportunity to close the window that contains the infinitely looping [until], and keep Pd running. However, I don't think this would be possible without some architectural changes to Pd (like more extensive use of threading).
Jamie
On Thu, 20 Dec 2007, Russell Bryant wrote:
Well, now that i think of it, I think this change is a bit unreasonable. So, I take it back. :) It introduces a small performance hit
No, this one is most likely a *big* performance hit.
even if you screw up, it _will_ stop eventually, after some 4 billion something iterations. How long it takes is completely dependent on what you have after the [until].
This is still way too much, but it's too complicated to get pd to support interrupting its own calculations unless all externals are compiled with C++ exception support, and even then, it's tricky because you can't directly add exception support to libc itself or whatever else.
If one can't wait, it's possible to restart pd without losing any changes. In DesireData, all changes made to patches are backed up in the Tcl/Tk process, so unless both processes crash at once, you can still recover the patch. It wouldn't take much effort to implement this: there's already a force-quit menu-item that kills the server while keeping the client.
This still wouldn't get you exactly where you were before the crash, in the same way that closing and reopening any patch will lose object state.
int main() {int i = -1; while (i) i--; exit(0);} $ gcc -o test test.c $ time ./test real 0m10.677s user 0m9.437s sys 0m0.048s
This is probably right. To be sure that nothing is optimised out, you should use the "volatile" keyword on the i variable, but because the default is "no optimisation" it doesn't make a difference. It would if you wanted to measure something both optimised and not too much optimised so that it is representative of the minimum time it would take if something else would be done inside of the loop.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 2007-12-20 at 16:14 -0500, Mathieu Bouchard wrote:
This is still way too much, but it's too complicated to get pd to support interrupting its own calculations unless all externals are compiled with C++ exception support, and even then, it's tricky because you can't directly add exception support to libc itself or whatever else.
How do the ruby (irb) and python interactive interpreters handle this? Both python's "while 1:" and ruby's "while(1)" can be safely interrupted with ctrl-c with the interpreter still running. Would it be necessary to implement the measures you suggest above in order to implement something like this for Pd or dd - ctrl-c stops message processing?
Jamie
On Thu, 20 Dec 2007, Jamie Bullock wrote:
How do the ruby (irb) and python interactive interpreters handle this? Both python's "while 1:" and ruby's "while(1)" can be safely interrupted with ctrl-c with the interpreter still running.
I wrote about that in another mail today. It's gonna be hard to add this to Pd. The alternative is even harder.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
By that reckoning bang-until would run itself out after a few seconds. One of us is wrong. (I apologise in advance :)
What's going on?
Perhaps we can reach a reasonable compromise in source. If you knew that an accidentally banged until would give up after a couple of minutes it wouldn't be so bad.
On Wed, 19 Dec 2007 17:49:44 -0600 Russell Bryant russell@russellbryant.net wrote:
Frank Barknecht wrote:
If people want to make sure to not be bitten by the endless loop, they could just use
[inlet] | [b] | [f 1000000000000] | [inlet] | | [until] | [outlet]
as an abstraction called: [funtil] It will bang 1000000000000 times unless stopped, which is more bangs for the bang than most people would want.
It doesn't look like that would work. The number of times to run is stored as an int, which on most systems is 4-bytes. The maximum is a bit over 2 billion for a float input. :)
Also, from looking at the implementation of [until], a simple bang until will stop after a complete overflow over the storage space in an integer, which is usually 4 billion and change.
(x_count is an int.)
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) x->x_count--, outlet_bang(x->x_obj.ob_outlet); }
-- Russell Bryant
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2007-12-20 at 00:15 +0000, Andy Farnell wrote:
Perhaps we can reach a reasonable compromise in source. If you knew that an accidentally banged until would give up after a couple of minutes it wouldn't be so bad.
IMO [until] should just not hang Pd that's all. I don't think that a warning should be thrown when you do |bang( -> [until], or that it should have a built in limit.
This is in the same sense that you don't get a warning when you do 'while 1:' in Python or while(1){ } or whatever in other languages. 'while 1:' doesn't hang the interpreter (at least not in the Python implementation I use), and |bang( -> [until] shouldn't hang Pd.
Actually on my machine |bang( -> [until] runs at ~99% CPU and hangs Pd, 'while 1:' in Python runs at more like 69% and is interruptible with ctrl-c leaving you back in the interactive interpreter unscathed.
Perhaps a usleep() is in order on each iteration?
Jamie
That's still 5 mins to burn through on an "average machine" or quarter of an hour on a low spec.
Knock a couple of zeros off.
On Thu, 20 Dec 2007 00:17:46 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Until is the only conditional in Pd we have (unless you construct your own messages with feedback arrangement) that gives a deferred conditional after executing at least once, just like DO-WHILE or REPEAT-UNTIL. If you constrain it with numbers then it's logically a FOR(range) construct.
If people want to make sure to not be bitten by the endless loop, they could just use
[inlet] | [b] | [f 1000000000000] | [inlet] | | [until] | [outlet]
as an abstraction called: [funtil] It will bang 1000000000000 times unless stopped, which is more bangs for the bang than most people would want.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 20 Dec 2007, Frank Barknecht wrote:
as an abstraction called: [funtil] It will bang 1000000000000 times unless stopped, which is more bangs for the bang than most people would want.
no, 1000000000000 as a float is non-representable and will be rounded to the closest number within float32, which is 999999995904. Then it will cause an overflow, which will transform the value to -727384064, which will cause 3567583232 iterations.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
[f 1000000000000]
To all those who complain about this number: It was meant to be a meaningless example. I just bang'd my "0"-key a couple of times to fill it. In a real abstraction one could use a smaller number or $1. Isn't that the Max object uzi then?
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 19 Dec 2007, Frank Barknecht wrote:
Maybe we should even *preach* to send numbers instead of a bang into [until] in general? If you use a large enough number, it's "almost the same" as a bang except that it will stop by itself at some point.
If you send a bang it also stops by itself. It will make 4294967295 iterations. This is because bang is equivalent to -1 which is equivalent to that number. Read the source at x_connective.c, until_bang().
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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 zmoelnig@iem.at 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.
An object can tell if it has a connection made to any of its inlets, so perhaps the safety catch for [until] is not to work unless the condition inlet is connected? If the condition is never satisfied due to user programming error that's another thing but a first line of defence would be helpful.
This sounds to me like a really clean solution. Can anyone think of a case where you would want to send a bang (or negative number) to [until] without having the right inlet connected?
Of course, the connected right inlet might not have anything useful actually happening, but at least it offers some initial protection so the hairs on yr neck don't have to rise each time you type "until" in an object box.
The other somewhat dirty solution I thought of but I don't think I posted here yet is to make [until] artificially use stack space up so that it does eventually explode when stack is all used, in the same way as other Pd infinite loops. That's kind of gross but it would work.
Best,
Chris.
On Dec 19, 2007 7:58 PM, Chris McCormick chris@mccormick.cx 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 zmoelnig@iem.at 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. but it would still run into those problems of finding an arbitrary condition to trigger the 'halt'
Chuck
On Thu, 20 Dec 2007 10:43:57 -0600 "Charles Henry" czhenry@gmail.com wrote:
On Dec 19, 2007 7:58 PM, Chris McCormick chris@mccormick.cx 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 zmoelnig@iem.at 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
On 12/20/07, Andy Farnell padawan12@obiwannabe.co.uk wrote:
On Thu, 20 Dec 2007 10:43:57 -0600 "Charles Henry" czhenry@gmail.com wrote:
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?"
It would be best to have a user-controlled method to eliminate the need for an arbitrary condition. It might not be possible... hence, the watchdog could send signals from outside the pd process or an enable/disable "safe" mode that allows the use of arbitrary conditions to halt/continue all messages.
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
... 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.
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" czhenry@gmail.com wrote:
On Dec 19, 2007 7:58 PM, Chris McCormick chris@mccormick.cx 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 zmoelnig@iem.at 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
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.
Are there any other objects that run a loop like this that could potentially block GUI processing for a long period of time?
My first thought with this approach is that you would end up having to sprinkle this handling into the code for every object that could potentially have a problem like this. If this is the only one, then this certainly sounds like a simple approach.
Another idea: have a GUI item that interrupts Pd, causing the stack frame to be rudely dropped and all clocks to be unset.
Yikes. I personally would rather see an approach that simply ensures that the GUI input buffer gets serviced, such as your first proposal. I think that should be able to handle any situation that this proposal would help, but in a much less destructive manner. :)
-- Russell Bryant
On Thu, 20 Dec 2007, Russell Bryant wrote:
Are there any other objects that run a loop like this that could potentially block GUI processing for a long period of time?
very long [list] operations for example, as well as some externals like [repeat], [for], [foreach], most of GridFlow with huge inputs or huge outputs, operations on very large arrays, including built-in array methods and vasp, and GEM/PDP on very large images or large convolution kernels (when supported), etc.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I don't think it's so bad to have a means of dropping the stack and unsetting clocks. As a debugging technique, it could allow you to stop everything and probe some of your variables--not just an escape from infinite loops but a more general tool.
The performance and generality of until is pretty important to preserve. I wouldn't suggest to put a "child proof cap" on it, if you can't disable it somehow. damn child proof caps... Daddy needs his medicine!
Chuck
On 12/20/07, Miller Puckette mpuckett@imusic1.ucsd.edu 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.
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" czhenry@gmail.com wrote:
On Dec 19, 2007 7:58 PM, Chris McCormick chris@mccormick.cx 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 zmoelnig@iem.at 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
On Thu, 20 Dec 2007, 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,
No, it's better to make it wait for the user to start worrying and press the equivalent of Ctrl+C from the GUI, unless the patch is supposed to run unattended.
Another idea: have a GUI item that interrupts Pd, causing the stack frame to be rudely dropped and all clocks to be unset.
Rudely dropping the stack has lots of potential to cause crashes, in addition to be very unportable (you need one version of it per OS/CPU pair). If you are interested in that, I have just wrote several mails on that topic.
aren'y they both ugly? but maybe something like this is needed ...
As long as the user using them knows the problems that they are getting into by using that feature, everything is fine.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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" czhenry@gmail.com wrote:
On Dec 19, 2007 7:58 PM, Chris McCormick chris@mccormick.cx 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
zmoelnig@iem.at 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/
On Sat, 22 Dec 2007, Hans-Christoph Steiner wrote:
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.
Pd keeps only record of the connections in the outlets, not in the inlets, so you'd really have to do an elaborate special case for [until]. Perhaps it could be called class_setconnectnotify(t_class *x, t_connectnotifyfn f) which would register a callback so that objects can know that they've been connected.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, Dec 20, 2007 at 05:39:14PM +0000, Andy Farnell wrote:
but it would still run into those problems of finding an arbitrary condition to trigger the 'halt'
Hmmmm, there's beard stroker. :)
http://en.wikipedia.org/wiki/Halting_problem
"Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist."
Best,
Chris.
On Wed, 19 Dec 2007, Chris McCormick wrote:
The other somewhat dirty solution I thought of but I don't think I posted here yet is to make [until] artificially use stack space up so that it does eventually explode when stack is all used, in the same way as other Pd infinite loops. That's kind of gross but it would work.
It won't do this unless you make it recurse using messages, because pd only counts how many stack messages are currently not finished, not how much stack space is used (since 0.38 or so).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Charles Henry -
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Jamie Bullock -
Mathieu Bouchard -
Mike McGonagle -
Miller Puckette -
Russell Bryant