Hallo,
SourceForge.net hat gesagt: // SourceForge.net wrote:
Comment By: Matteo Sisti Sette (sistisette) Date: 2007-02-10 19:45
Message: Logged In: YES user_id=1709568 Originator: NO
Just another example that triggers the same bug (dunnow why I can't attach a file so I "transcribe" it here):
[bng] | [f 0] | [find f, cut( | [s pd-thisFile'sName.pd]
I don't agree with zmoelnig in that it is not a bug. Calling functions and stacks are implementation details the patch author shouldn't need to be aware of. What the patch is doing is deleting an object. The message causing the deletion was triggered by (a message that was triggered by[...]) that object, so what? There's nothing semantically incorrect in doing that.
There is. You may be missing some implications of Pd's "depth first message passing" as described in the manual, chapter "2.3.2. depth first message passing": [1]
"Each message sets off a tree of consequent messages." As a message is generated by an object this also means that each (message) object sets off a tree of messages. Every branch of messages has to finish at some point. If it doesn't, you have an error in your patch, that will result in an infinite message loop or "stack overflow". The manual has an example for this, but you can also just bang an [until] without stopping it to make such a stack overflow without any backwards connections.
Now how does this relate to "suicide" messages, that is, messages that will result in a deletion of the object that generated the message?
Lets look at the [pd x] subpatch which has a [; pd-x clear( suidice message: As soon as you click this message, it will start a "message tree of consequent messages." This message tree has to finish, and the end point here would be the clearing of the subpatch including the message box that initiated the suidice.
At first look this may seem okay, but a powerful and important feature of Pd is, that an object or message can be a node for several message branches. [trigger bang float] is one example for this: Pd will first execute the tree below the right float outlet completely, and when this is finished, it will come back to the [t b f] to work on the left bang outlet's tree. With messages this also is possible, e.g. by seperating messages with a comma or semicolon: [; pd-x clear; pd-x msg 100 100 hello world(: First this message will clear [pd x] then it will evaluate the second part of the message and put a "hello world" message into [pd x].
To be able to do this Pd has to save the current branching node somehow to come back there later, when the first branch has finished.
But now we have a problem, if a message tries to commit suicide and thus deletes the node that according to Pd's language rules and logic needs to be evaluated again, after the "depth first tree" has come to an end!
As the node was deleted, this is impossible, the correct data flow cannot be restored and that's why these messages indeed are semantically incorrect just like infinite message loops. Of course Pd should not die if someone attempts suidide, but still these kinds of messages are illegal constructs.
Ciao