I get this all the time. It's a real problem, because in a longer score it usually means the first half of the score has had all its notes changed to a new reference pitch and the second half hasn't, and there's no way back from that but to reload the piece.
I have a "JInext" abstraction I made, which takes a bang or a next message, and finds the next $1 scalar in pd-score. Because I have a vertical line on each beat, and octave marking lines, and tempo markers, plus notes, it has to skip past a lot of other templates. I put an internal delay in it, so that every 10 times it goes, it waits 10 ms. I've adjusted this to be slower and slower as I've written longer scores, but I still get stack overflow from the "next" message that retriggers it.
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
Thanks. -Chuckk
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
On Thu, 2006-03-23 at 06:59 -0500, Chuckk Hubbard wrote:
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
you've written a recursive patch, so each recursion increases the interpreter stack ... if your recursions are happening too often ... booooooom ... :-/
it's probably better to solve something like this with an iteration, which doesn't use the stack ... in pd it can be done with the |until| object ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
I don't understand. I've understood recursive to mean a function that calls itself within itself. The output from my patch retriggers the patch, but to my understanding it should all be determinate; if Pd uses depth-first message passing, it should finish with one thread before calling the next. The abstraction is only retriggered from its left outlet, so nothing should happen during the 10 ms delay.
I'm also not sure how [until] will help. Pd doesn't know how many scalars the score has, or how many are of any one structure.
I'm still not clear on what "the stack" is or what makes it overflow. Thanks.
-Chuckk
On 3/23/06, Tim Blechmann TimBlechmann@gmx.net wrote:
On Thu, 2006-03-23 at 06:59 -0500, Chuckk Hubbard wrote:
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
you've written a recursive patch, so each recursion increases the interpreter stack ... if your recursions are happening too often ... booooooom ... :-/
it's probably better to solve something like this with an iteration, which doesn't use the stack ... in pd it can be done with the |until| object ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQBEIpg6NDZZF/Yk3sURAq/tAKCxvMTiWrwTIrRsp1M/84jA4qPDEgCfavpK HlIXg2tHiybWlXLrgVPqMS8= =yuY2 -----END PGP SIGNATURE-----
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
If you're using linux, you might try "ulimit" in the terminal type ulimit -a to see all the things you can configure ulimit -s 20480 sets the stack size to 20 Mb, it is by default 10 Mb I don't know if this will work... I don't profess to understand threads or stacks, and pd might have its own system for setting max stack size. I have had a recursive problem once that was solved using ulimit. Chuck Henry
On 3/23/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
I don't understand. I've understood recursive to mean a function that calls itself within itself. The output from my patch retriggers the patch, but to my understanding it should all be determinate; if Pd uses depth-first message passing, it should finish with one thread before calling the next. The abstraction is only retriggered from its left outlet, so nothing should happen during the 10 ms delay.
I'm also not sure how [until] will help. Pd doesn't know how many scalars the score has, or how many are of any one structure.
I'm still not clear on what "the stack" is or what makes it overflow. Thanks.
-Chuckk
On 3/23/06, Tim Blechmann TimBlechmann@gmx.net wrote:
On Thu, 2006-03-23 at 06:59 -0500, Chuckk Hubbard wrote:
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
you've written a recursive patch, so each recursion increases the interpreter stack ... if your recursions are happening too often ... booooooom ... :-/
it's probably better to solve something like this with an iteration, which doesn't use the stack ... in pd it can be done with the |until| object ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQBEIpg6NDZZF/Yk3sURAq/tAKCxvMTiWrwTIrRsp1M/84jA4qPDEgCfavpK HlIXg2tHiybWlXLrgVPqMS8= =yuY2 -----END PGP SIGNATURE-----
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Charles Henry wrote:
If you're using linux, you might try "ulimit" in the terminal type ulimit -a to see all the things you can configure ulimit -s 20480 sets the stack size to 20 Mb, it is by default 10 Mb I don't know if this will work... I don't profess to understand threads or stacks, and pd might have its own system for setting max stack size.
pd does have its own stack overflow detection mechanism which you cannot control via ulimit: whenever the stack depth reaches a certain number (which is hardcoded in the pd-source and not adjustable at runtime) pd will break the loop and print "Stack overflow".
if you had a "real" stack overflow, things are likely to be worse.
mfg.asdr. IOhannes
I have had a recursive problem once that was solved using ulimit. Chuck Henry
I don't understand. I've understood recursive to mean a function that calls itself within itself. The output from my patch retriggers the patch, but to my understanding it should all be determinate; if Pd uses depth-first message passing, it should finish with one thread before calling the next. The abstraction is only retriggered from its left outlet, so nothing should happen during the 10 ms delay.
I'm also not sure how [until] will help. Pd doesn't know how many scalars the score has, or how many are of any one structure.
I'm still not clear on what "the stack" is or what makes it overflow. Thanks.
in pd every outlet call is a recursive function call ... if an message goes back to the message signal flow, you have an iteration ...
i've attached a simple patch with a counter counting to 100 ... this might show you the difference ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
The Magic of Google:
http://www.devx.com/tips/Tip/14276
Understanding Stack Overflow The stack is a region of memory on which local automatic variables are created and function arguments are passed. The implementation allocates a default stack size per process. On modern operating systems, a typical stack has at least 1 megabyte, which is sufficient for most purposes. Under anomalous conditions, the program exceeds its stack limit. This causes a stack overflow. The two most common causes for a stack overflow is an infinite recursion, as in:
int f(){ g(); } int g() { f(); }
f() calls g(), which in turn calls f() and so on. If your program crashes due to a stack overflow, check for infinite recursion or too large local objects.
Hope that helps!
David
On 3/23/06, Tim Blechmann TimBlechmann@gmx.net wrote:
I don't understand. I've understood recursive to mean a function that calls itself within itself. The output from my patch retriggers the patch, but to my understanding it should all be determinate; if Pd uses depth-first message passing, it should finish with one thread before calling the next. The abstraction is only retriggered from its left outlet, so nothing should happen during the 10 ms delay.
I'm also not sure how [until] will help. Pd doesn't know how many scalars the score has, or how many are of any one structure.
I'm still not clear on what "the stack" is or what makes it overflow. Thanks.
in pd every outlet call is a recursive function call ... if an message goes back to the message signal flow, you have an iteration ...
i've attached a simple patch with a counter counting to 100 ... this might show you the difference ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQBEIulDNDZZF/Yk3sURAqUWAKCU5ykxTxdSyouzICj4zqobpNoP+wCfUVPu pj3x4x6zYloo+8TcpPRsa7w= =vknI -----END PGP SIGNATURE-----
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OH. Basically you are saying my patch has to finish the last calculation before it's finished with the first one- so it's one really deep string of messages instead of a lot of short ones?
It all makes perfect sense now. I've just become a slightly better programmer. Thanks!
I guess my next question would be whether that will slow down the sequencer, having each scalar accessed at a different logical time, but I suppose in real time there won't be any difference. I'm going to revamp this and see how it works. Thanks again.
-Chuckk
On 3/23/06, Tim Blechmann TimBlechmann@gmx.net wrote:
I don't understand. I've understood recursive to mean a function that calls itself within itself. The output from my patch retriggers the patch, but to my understanding it should all be determinate; if Pd uses depth-first message passing, it should finish with one thread before calling the next. The abstraction is only retriggered from its left outlet, so nothing should happen during the 10 ms delay.
I'm also not sure how [until] will help. Pd doesn't know how many scalars the score has, or how many are of any one structure.
I'm still not clear on what "the stack" is or what makes it overflow. Thanks.
in pd every outlet call is a recursive function call ... if an message goes back to the message signal flow, you have an iteration ...
i've attached a simple patch with a counter counting to 100 ... this might show you the difference ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQBEIulDNDZZF/Yk3sURAqUWAKCU5ykxTxdSyouzICj4zqobpNoP+wCfUVPu pj3x4x6zYloo+8TcpPRsa7w= =vknI -----END PGP SIGNATURE-----
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I guess my next question would be whether that will slow down the sequencer, having each scalar accessed at a different logical time, but I suppose in real time there won't be any difference. I'm going to revamp this and see how it works.
The sequencer example in the Pd documentation shows how to do traversal in smaller chunks by sending delayed [next( messages using delta times. In the attached patches I factored out the general mechanism into "sequence-data.pd", and example use is in seq-example.pd
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I guess my next question would be whether that will slow down the sequencer, having each scalar accessed at a different logical time, but I suppose in real time there won't be any difference. I'm going to revamp this and see how it works.
The sequencer example in the Pd documentation shows how to do traversal in smaller chunks by sending delayed [next( messages using delta times. In the attached patches I factored out the general mechanism into "sequence-data.pd", and example use is in seq-example.pd
Just ignore this, I now figured out that you have a completely different problem. See my reply to the first mail for a suggestion on how to solve that.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 23 Mar 2006, Tim Blechmann wrote:
if an message goes back to the message signal flow, you have an iteration ...
I'm puzzled. Which of the words "message" "signal" and "iteration" are you trying to redefine here?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
How does this look?
On 3/23/06, Tim Blechmann TimBlechmann@gmx.net wrote:
On Thu, 2006-03-23 at 06:59 -0500, Chuckk Hubbard wrote:
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
you've written a recursive patch, so each recursion increases the interpreter stack ... if your recursions are happening too often ... booooooom ... :-/
it's probably better to solve something like this with an iteration, which doesn't use the stack ... in pd it can be done with the |until| object ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Oh yeah. That was why I was afraid to use until.
On 3/24/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
How does this look?
On 3/23/06, Tim Blechmann TimBlechmann@gmx.net wrote:
On Thu, 2006-03-23 at 06:59 -0500, Chuckk Hubbard wrote:
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
you've written a recursive patch, so each recursion increases the interpreter stack ... if your recursions are happening too often ... booooooom ... :-/
it's probably better to solve something like this with an iteration, which doesn't use the stack ... in pd it can be done with the |until| object ...
hth ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
I still can't come up with a good way to do this, because I want a "next" message to the abstraction to move the pointer along the path it's already on, and yet there is the possibility that a "next" message will be sent inadvertently when the pointer is empty at some point; I know good coding would prevent that, but a system crash is a heavy price to pay for one slipup, considering I have over a dozen copies of this abstraction in use.
I tried starting the "until" with a float message just in case it is an empty pointer, but then I get overflow errors again. It seems like something that would be simple to do in Pd, but since the only response from an empty pointer is printed to the Pd window, I can't make it react to that. :/
-Chuckk
On 3/23/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
I get this all the time. It's a real problem, because in a longer score it usually means the first half of the score has had all its notes changed to a new reference pitch and the second half hasn't, and there's no way back from that but to reload the piece.
I have a "JInext" abstraction I made, which takes a bang or a next message, and finds the next $1 scalar in pd-score. Because I have a vertical line on each beat, and octave marking lines, and tempo markers, plus notes, it has to skip past a lot of other templates. I put an internal delay in it, so that every 10 times it goes, it waits 10 ms. I've adjusted this to be slower and slower as I've written longer scores, but I still get stack overflow from the "next" message that retriggers it.
Can anyone explain more about what exactly "stack overflow" is? Might it help if I just put a 1 ms delay for each scalar?
Thanks. -Chuckk
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I get this all the time. It's a real problem, because in a longer score it usually means the first half of the score has had all its notes changed to a new reference pitch and the second half hasn't, and there's no way back from that but to reload the piece.
I have a "JInext" abstraction I made, which takes a bang or a next message, and finds the next $1 scalar in pd-score. Because I have a vertical line on each beat, and octave marking lines, and tempo markers, plus notes, it has to skip past a lot of other templates.
You could implement the beat, octave etc. lines as arrays instead of as single structs.
Then even a long score with 1000 beat lines will just contain one single "beatgrid" struct. And it's even much easier to patch.
An example is attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Charles Henry -
Chuckk Hubbard -
david golightly -
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard -
Tim Blechmann