@whale-av Pd has a strict order of operations. It tries to compute each tree until the end. If it recognizes a loop, it starts an internal counter. If that counter hits a certain threshold, Pd stops the computation and displays "Stack overflow" in the console.

[delay] schedules an operation for the next cycle of operations. So the first set of operations will be finished, then the delayed operations start. The stack overflow counter will be reset for this new cycle of operations.

This is the reason why the left example above will stop with a stack overflow message and the right one will go on forever without any error.

@ingox Sorry, we are both trying to type at the same time. A similar problem to the one we are discussing.
[random] should pump out random numbers...... which would stop the loop in at most 3 or 4 iterations.
But it does not, because the looped bangs all arrive at exactly the same time...... and push the same value repeatedly....... hence the overflow.

@whale-av Haha, well yes. Actually, i am not trying to solve a problem, rather than explaining the principles of Pd.

All i am saying is that if you create a loop, there might be a chance to run into a stack overflow. One method to avoid this is to use [del 0], another is to rethink the given task and to build code without loop, as shown above.

@ingox If you go back up the thread, a [pipe] ...... no delay..... after random, forces order of the floats from random, so that in the OP patch the [t f f] completes its operation before allowing the looped operation to continue.
I have to go to bed now, but it will be interesting to know tomorrow if a pipe after random works with your loop, instead of a delay.
Always have to remember that Pd of course uses the objects we see on the screen, but rebuilds the whole set of sub-routines into one new routine...... so there is room for unforeseen bugs.
David.

@whale-av Yes, [pipe] breaks the loop the same way [delay] does.

Edit: Ah, i just saw that you mentioned this before, as you said. Sorry, i didn't see this before.

So no disagreement here, i was just arguing your point.

@ingox Closure?...... pun intended...... ..... not timing?
https://dzone.com/articles/why-does-javascript-loop-only-use-last-value
I looks like [pipe] introduces a catch /throw maybe (of the looked up random variable) in the Pd runtime (solution 3 in the link), that should really be incorporated in the [random] object, and probably in many other Pd objects too....

If any coders think this is a likely scenario then it should go as a bug report, and should be only an hour or two for someone knowledgeable (like Miller e.g.) to fix every likely culprit.
Unless, of course it will slow Pd enough to break all of our heavy patches.
David.

@whale-av There is a counter defined in m_obj.c. If this counter hits 1000, the code execution will stop and "stack overflow" will be displayed:

static int stackcount = 0; /* iteration counter */
#define STACKITER 1000 /* maximum iterations allowed */

[pipe] and [delay] reset this counter, so the stack overflow doesn't occur. I think this is the expected behavior and not a bug.

@ingox Yes, but random should produce a different float most times, and [sel 0] should close the loop....... operation completed.
I would expect it with f fed back from +1 as Miller says, but not with [random] and [sel].
David.

@whale-av Yes, but [delay] and [pipe] are the objects that break the order of operations and that is the reason they break the loop, even with zero delay time. For me it is consistent that every other object stays within the chain as long as they have an outgoing connection. Anyhow, i believe it will stay this way and am fine with it