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

Alexandre Torres Porres porres at gmail.com
Wed Sep 9 15:26:03 CEST 2015


I just wanna know how it works... I'm not really making a case that I'd
like to do it, I just want to understand the behaviour of Pd.

but it's funny how everyone emphatically insists to advice it shouldn't be
done and stuff. Well, to calm everyone down, I'll come out and say I'll
never do such a thing :)

thanks folks

2015-09-09 9:17 GMT-03:00 IOhannes m zmoelnig <zmoelnig at iem.at>:

> 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.
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150909/56a4cfe3/attachment-0001.html>


More information about the Pd-list mailing list