[PD] Why does this cause stack overflow?

[Claude Heiland-Allen]

Hi Phil,

On 2019-05-27 18:23, Philip Stone wrote:
> Hello, I’ve run into a situation that strains my understanding of
> Pd’s strict determinacy – please see the attached patch of the
> simplest case. On my system, the stack over-flows at count 331.
> 
> I don’t understand why this happens, as the bang that re-fires the
> loop is not triggered until after the print. What is filling the
> stack, exactly?

Control flow in Pd's message system is depth-first, usually 
right-to-left.  This means that control passes from first object to 
deepest object, then back up again:

in this small example

[bng]
[t b b]
  |   [print r]
[print l]

the control flow stack over time is like:

[bng]
[bng] [t b b]
[bng] [t b b] [print r]
[bng] [t b b]
[bng] [t b b] [print l]
[bng] [t b b]
[bng]

But in your example control is not yielded back to the caller before 400 
iterations, at which point the stack is filled with

... [f] [t] [spigot] [f] [t] [spigot] ....

The default stack size limit I think is 1000 objects, recent Pd let you 
change it - search list archives or github issues for details.

But the simplest(*) way to get recursive calls to work is often to break 
the recursion with a [delay 0] to start a new depth first execution 
chain after the current one is finished, or to refactor it to use 
[until](+) to iterate instead of recurse.

(*) but it can become unmaintainable in larger patches...
(+) but [bang(--[until] can take a while to finish, be careful...


Claude
-- 
https://mathr.co.uk