hi all,
this is in a way a follow-up to both my mails from this morning:)
While browsing pd/src at sourceforge I found this:
x_connective.c 1.1.1.1.8.1 9 days ggeiger \ added set message to send/receive, patches from cxc and ext13
...surprise!
Looking at the patch, I wonder, why nobody has ever reported crashes caused by a receive settable in a cxc/ext13 way? Lets try
'; x set y', [r x], [r x]
or anything similar.
Forgive me please, but I think the core of Pd, like send/receive behaviour, should not be changed behind Miller's back...
Btw, 'receive74' is settable, but
1) only via its inlet, never remotely,
2) only if it has no argument (apparently for compatibility reasons?).
The 'send74' is not settable (it is the 'forward74', which is...)
Krzysztof
On Thu, 5 Sep 2002, Krzysztof Czaja wrote:
Forgive me please, but I think the core of Pd, like send/receive behaviour, should not be changed behind Miller's back...
Probably I made a mistake when merging the "set" messages, thats why nobody reported the bug against the external packages.
I got sick after that day and spend half of my holidays in bed, thats why I couldn't continue working/testing the changes I made.
About changing the core of pd behind Millers back:
This was definitely not my intention, I rather tried to setup a repository for those who like to send patches to Miller, in order to have the possibility to test them, select those that fit and throw away those who are useless.
Finally Miller will have the say what he accepts for pd and what not. I think it is very important to make development for pd as open as possible, same for GEM. I am just trying to propose a "procedure" how to contribute to pd, because I think that several contributions may get lost because there is not an official way to do so.
We had several discussions about how to do that, and in order not to increase the load upon Miller I did it this way, maybe there are better ways ..., or maybe its a bad idea in general.
What do you think ?
Greetings
Guenter
Btw, 'receive74' is settable, but
only via its inlet, never remotely,
only if it has no argument (apparently for compatibility
reasons?).
The 'send74' is not settable (it is the 'forward74', which is...)
hi! i personally would not know what to change/add to the pd-core sources, but i thinks it's a very good idea to have this cvs-repository as a platform for tests and experiments. there needs to be a way to deal with the incresing number of people, who want to participate in this project. i always understood the the cvs that way, and never thought it would/could replace millers distribution.
[X] pro cvs
regards d13b
About changing the core of pd behind Millers back:
This was definitely not my intention, I rather tried to setup a repository for those who like to send patches to Miller, in order to have the possibility to test them, select those that fit and throw away those who are useless.
Finally Miller will have the say what he accepts for pd and what not. I think it is very important to make development for pd as open as possible, same for GEM. I am just trying to propose a "procedure" how to contribute to pd, because I think that several contributions may get lost because there is not an official way to do so.
We had several discussions about how to do that, and in order not to increase the load upon Miller I did it this way, maybe there are better ways ..., or maybe its a bad idea in general.
What do you think ?
Greetings
Guenter
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
hi Guenter,
thank you for a clarification... and sorry: it was probably me to cause all the confusion...
The best way of showing that I mean so, would be attempting to improve receive's handling of the 'set' message -- but I do not know how to do it right.
The main trouble is how to sense which 'set' is remote, and which has come via an inlet. It might be done by not binding a [receive] itself to a symbol, but binding a proxy object instead. However, it would involve a complete rewrite of the class, and this is something which should involve much better understanding of the 'core' than mine!
Hoping you are well now, and there is still some time left for your holidays,
Krzysztof
guenter geiger wrote:
Probably I made a mistake when merging the "set" messages, thats why nobody reported the bug against the external packages.
I got sick after that day and spend half of my holidays in bed, thats why I couldn't continue working/testing the changes I made.
About changing the core of pd behind Millers back:
This was definitely not my intention, I rather tried to setup a repository for those who like to send patches to Miller, in order to have the possibility to test them, select those that fit and throw away those who are useless.
Finally Miller will have the say what he accepts for pd and what not. I think it is very important to make development for pd as open as possible, same for GEM. I am just trying to propose a "procedure" how to contribute to pd, because I think that several contributions may get lost because there is not an official way to do so.
Hi all,
I don't think it's enough simply to insist that "set" messages come through the inlet; there could still be people traversing either the new or the old symbol somewhere up the stack.
I think the only solution would be somehow to detect reentrancy and refuse to bind or unbind something to a symbol reentrantly. I just can't think of a really efficient way to do this...
cheers Miller
On Mon, Sep 09, 2002 at 03:25:24PM +0200, Krzysztof Czaja wrote:
hi Guenter,
thank you for a clarification... and sorry: it was probably me to cause all the confusion...
The best way of showing that I mean so, would be attempting to improve receive's handling of the 'set' message -- but I do not know how to do it right.
The main trouble is how to sense which 'set' is remote, and which has come via an inlet. It might be done by not binding a [receive] itself to a symbol, but binding a proxy object instead. However, it would involve a complete rewrite of the class, and this is something which should involve much better understanding of the 'core' than mine!
Hoping you are well now, and there is still some time left for your holidays,
Krzysztof
guenter geiger wrote:
Probably I made a mistake when merging the "set" messages, thats why nobody reported the bug against the external packages.
I got sick after that day and spend half of my holidays in bed, thats why I couldn't continue working/testing the changes I made.
About changing the core of pd behind Millers back:
This was definitely not my intention, I rather tried to setup a repository for those who like to send patches to Miller, in order to have the possibility to test them, select those that fit and throw away those who are useless.
Finally Miller will have the say what he accepts for pd and what not. I think it is very important to make development for pd as open as possible, same for GEM. I am just trying to propose a "procedure" how to contribute to pd, because I think that several contributions may get lost because there is not an official way to do so.
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Mon, 9 Sep 2002, Krzysztof Czaja wrote:
The best way of showing that I mean so, would be attempting to improve receive's handling of the 'set' message -- but I do not know how to do it right.
The main trouble is how to sense which 'set' is remote, and which has come via an inlet. It might be done by not binding a [receive] itself to a symbol, but binding a proxy object instead. However, it would involve a complete rewrite of the class, and this is something which should involve much better understanding of the 'core' than mine!
I'd say we can postpone this problem, therefore I removed receive's set message.
Maybe someone will implement your suggestion in an external, or we can find a general solution ala Miller.
And thanks for tracking this down, I probably would never have given it a second thought.
Hoping you are well now, and there is still some time left for your holidays,
Yes there was, batteries recharged
Guenter
-
d13 -
guenter geiger -
Krzysztof Czaja -
Miller Puckette