[PD-dev] subpatch clearing itself crashes Pd

IOhannes m zmoelnig zmoelnig at iem.at
Tue Feb 13 10:39:25 CET 2007


Frank Barknecht wrote:
> Hallo,
> IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

>> obviously this is just the simplest example i was able to think of.
>> what i was trying to illustrate is:
>> i expect [clear, obj 0 0 foo( to clear the entire canvas and then to
>> create an instance of [foo].
>> using your "delay" message for the "clear", would first create the [foo]
>> object and then delete the entire canvas (including [foo]).
> 
> Risking to appear as an advocate for it: As I understand Tim's

no problem with that.
seems like i am risking to be an advocate against it, which is not true:
a warning message is better than a crash; but an intelligent handling of
the problem is far better than a warning message; however, i believe
that a semi-intelligent solution is worse than a warning; if this
discussion helps us to make tim's proposal a fully-intelligent
(sidenote: i shouldn't have started to use the word "intelligent"; now i
can't find my way out...) solution, implementation schould start asap.

> approach now, it could work a bit differently. The "clear" would set
> the "deletable" flag in every object inside the canvas, but it would
> not do the deletion immediatly. Then the "obj" messages could create
> objects, which would not have the "deletable" flag set. After the full
> message is executed, the flagged objects would be deleted, but the
> unflagged objects could remain. Which in the end would be the same as
> [clear, obj 0 0 foo(---[delay]---[s pd-sub]


yes this makes sense for simple assumptions.
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)

mfg.adr
IOhannes




More information about the Pd-dev mailing list