[PD-dev] subpatch clearing itself crashes Pd

Frank Barknecht fbar at footils.org
Tue Feb 13 11:39:45 CET 2007


Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

> yes this makes sense for simple assumptions.

Yep, the goal of this discussion should be to really try to find as
many pitfalls as possible and to see if they are really pitfalls.

> however, what about "consistent data"?
> 
> problem1: what happens if you delete a [table foo] object? what happens
> if you create another [table foo] instance just after deletion? this
> might be handled explicitely for pd's internal tables, but how about
> similar (external!) "tables"?
> problem2: how to deal with singletons? (but thinking about this reveals,
>  that the deletion of singletons' isn't handled "correctly" anyway
> (actually it is not handled at all - until we have someting like the
> [closebang]; and once we have this, the problem will be solved anyhow);
> so this might not be such a big problem)

Funny: I was also thinking about how this may affect to singletons
recently.

Anyway one thing we should probably keep in mind: The problems we talk
about only occur for objects, that are trying to delete themselves,
that want to commit suicide. So we don't need to think too much about
"passive" objects that cannot do anything anyway, about objects that
don't have outlets and aren't senders. [table] currently seems to be
such an object, that can only be killed from the outside. 

However it is not clear, that [table] will be such an object for all
times. For example data structures already are "active" objects, that
can produce messages when manipulated with the mouse or so. Attached
is an example for this. Data structures may introduce new
complications, as it's also possible to delete the [struct] definition
through an action initiated by an instance of this structure. This
currently crashes, too (also attached) but deleting a [struct] while
instances are still alive can crash Pd anyways, so I'm not sure, if
this is a suicide-related problem.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__
-------------- next part --------------
#N canvas 321 256 766 495 10;
#N canvas 0 0 468 419 ds 0;
#X obj 100 88 struct ds float x float y;
#X obj 300 137 drawnumber x;
#X obj 100 149 outlet;
#X obj 100 112 route change;
#X connect 0 0 3 0;
#X connect 3 0 2 0;
#X restore 102 69 pd ds;
#N canvas 739 471 450 300 x 0;
#X restore 149 69 pd x;
#X obj 218 183 b;
#X msg 218 209 \; pd-x clear;
#X obj 394 243 append ds x y;
#X obj 480 215 pointer;
#X msg 480 191 traverse pd-x \, bang;
#X msg 394 210 100 100;
#X obj 394 135 t b b b;
#X msg 394 111 create new ds in pd-x;
#X obj 127 182 b;
#X msg 127 208 \; pd-ds clear;
#X msg 480 157 \; pd-x clear;
#X obj 153 110 hradio 15 1 0 3 empty empty choose_your_poison 0 -8
1 10 -262144 -1 -1 0;
#N canvas 0 0 450 300 demux 0;
#X obj 64 47 inlet;
#X obj 157 46 inlet;
#X obj 64 77 list prepend 0;
#X obj 64 111 route 0 1 2;
#X obj 64 179 outlet;
#X obj 88 152 outlet;
#X obj 112 132 outlet;
#X connect 0 0 2 0;
#X connect 1 0 2 1;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 3 1 5 0;
#X connect 3 2 6 0;
#X restore 102 137 pd demux;
#X obj 102 261 print changed;
#X text 335 70 changing the number-DS in pd-x can kill Pd.;
#X text 82 32 Two ways to kill Pd.;
#X connect 0 0 14 0;
#X connect 2 0 3 0;
#X connect 5 0 4 2;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 7 0;
#X connect 8 1 6 0;
#X connect 8 2 12 0;
#X connect 9 0 8 0;
#X connect 10 0 11 0;
#X connect 13 0 14 1;
#X connect 14 0 15 0;
#X connect 14 1 10 0;
#X connect 14 2 2 0;


More information about the Pd-dev mailing list