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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
