[PD-dev] even more confusion?
mpuckett at man104-1.ucsd.edu
Mon Sep 9 18:31:41 CEST 2002
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...
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,
> 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 at iem.kug.ac.at
More information about the Pd-dev