[PD] "G05.execution.order" issue (bug? just wrong?)

[IOhannes m zmoelnig]

On 2015-09-08 16:29, Alexandre Torres Porres wrote:
> cause if so, as I understant it, it is "defined", but not to get into the
> technical discussion about programming languages. It's just a synonym to
> "reliable", and I think it is important to note that, because otherwise you
> can give the idea to people that it'll be chaotic and all, when it isn't
> (that happened to me).

it won't be chaotic.
it also won't change - at least it won't change if you are using the
same Pd-runtime.

i would put it that way: Pd currently has a way to explicitely enforce
the order of execution of a DSP graph. this behaviour is documented
*explicitely*, eg. in G05.execution.order.pd
if your patch needs to rely on a certain execution order, you should use
the documented way to enforce this execution order.

Pd has a long history of not breaking patches. this is one of its
biggest strengths (and one of it's weaknesses, as it prevents fast
addition of new features).
so if you are using an undocumented way¹ of ensuring that objects are
scheduled in order (e.g. by connecting A before B in order to have Pd
schedule C before D), chances are high that your patch will still work
next year. and the year after.

however, if a major bug was discovered and the only (sane) way to fix
this bug would involve invalidating your assumption (that connecting A
before B will schedule C before D), then i would argue that breking the
current behaviour is *not* a regression (as long as the explicit way to
enforce order still works).
and then your patch will stop working (when used with Pd-0.63.
and when you come complaining i will tell you that you should not have
relied on undefined behaviour in the first place.


gfmasdr
IOhannes


¹ and no: the fact that G05.execution.order exploits the undocumented
behaviour to guarantee that the "wrong" flanger is indeed "wrong", does
not count as documentation.