Sorry, I feel sorry for the noobness of this question, but I can't figure out why this model of very simple loop doesn't work.

Behind the idea of solving this particular problem (I should find an another way to produce it), I'd really like to understand what I am missing here.

Thank you,

Nau

http://www.pdpatchrepo.info/hurleur/stackoverflow_loop.pd

nau, it would be interesting to post your patch to the pd-list. It may be a bug.
Apart from the fact that this patch is overcomplicated for the task, all i can say is that you should avoid this "freewheeling" patching style as much as possible. There is nothing to control the execution of this code. There are far better practices, like using [until] as TLP7 said.

Yop,

I'm used to [until], but when the loop trigs long processing chains, I don't always have a predictive behaviour (how does [until] understand that he "is allowed to iterate" when the process he has to finish has a big extension, like a whole subpatch ?). Of course my example here was oversimplified to demonstrate that the problem is "iteration content independant"

It's easier to me to make a more "open" looping scheme, that I can trig every iteration from another part of the patch to ensure the computation has reached its very end.

It's crazy, I can't beleive yet this could be a bug... I'll post on pd-list if nobody finds something concrete here (don't want to troll )

Thank you.

Nau

Speaking of until iterating at the right rate, here is an [nbuntil] abstraction which might be of interest:
http://lists.puredata.info/pipermail/pd-list/2012-12/099455.html

Thank you for remainding me of this, Kyro.

Would the key of my problem be nested in the "depth first" rule ?

Hey, now that's a good question..
Usually there will be stack-overflows if per loop there is something not finished in that loop. So that part would wait for beeing computed after that loop. But if the loop starts again before, it'll wait until the stack is full, and then you get some stack-overflow..
...Or, to explain it in a different way, you produce chains of infinite (=bigger than the stack) length (= the loop).

Well I always use [until]. That's how you do loops in pd! (At least I do...)
Anyways you've roughly got 2 ways to avoid stack-overflows:
-use [until], so you'll rather do an iteration instead of a recursion..
-use [del 0] instead of the [bang] that starts every loop over again.. (you don't have to use a [del 1], that's really too slow...) The [del 0] will just 'cut' the too deep chain into parts.

Yop,

Thank you for your efforts, Flipp.
I already knew everything that you stated, but this doesn't give any explanation yet, imho. Troubleshooting is not an issue, I said it from the beginning.

I remember that someone I do respect here wrote some day that he didn't rely on [counter] and did it with vanilla objects. From this day I decided to apply the same rule to avoid [until] (I never felt sure to fully understand how it works with deep subpatches to be "driven" by the iteration)

My concern is that I'm shocked by what looks like a unpredictable behaviour of Pd.
This loop works from 0 to 100, but not from 0 to 200...

Thanxs anyway,

Nau

[until] is vanilla !
The behaviour you get IS predictable (in a way), because it's a bad way to patch. See what while(1) does ? That's kind of similar. There is a long thread about stack overflow on the list : http://lists.puredata.info/pipermail/pd-list/2007-12/057872.html

see also : http://lists.puredata.info/pipermail/pd-list/2005-09/031246.html

Thank you Dwan, interresting.

Decided to patch it with [until], as I'm convinced now that it is the best way to do it. Thank you for this info that helped me understand that [until] simply can't be replaced by a combination of objects.

Nau

http://www.pdpatchrepo.info/hurleur/stackoverflow_loop_fix.pd

You're welcome