[PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

Roman Haefeli reduzierer at yahoo.de
Tue Feb 17 20:08:59 CET 2009


On Tue, 2009-02-17 at 10:47 +0100, IOhannes m zmoelnig wrote:
> Frank Barknecht wrote:
> > Hallo,
> > Roman Haefeli hat gesagt: // Roman Haefeli wrote:
> > 
> >> On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote:
> >> how can someone assume so? > no, that is so not true. i didn't even know,
> >> that zexy comes with their own version of [pack] and [unpack] until some
> >> weeks ago. and why the hell to they use the same names as internals?
> >> no, by no means i don't want to be forced to use the zexy version, just
> >> because some patches i use need zexy. 
> > 
> > You have been forced to do so for many years, you just haven't been told
> > about it until 0.42. I just now discovered that something is overwriting
> > my [wrap]. I don't know yet which library does that. It would be nice if
> > Pd could report the source library file together with the warning.
> > 
> >>> It's a difference between Pd >= 0.42 and Pd < 0.42.  I don't think,
> >>> overriding builtins ever worked with single-file externals, 
> >> that is what i am saying: this is introducing a _new_ incompatibility
> >> between pd-extended and pd vanilla.
> 
> this i don't understand; it is an incompatibility between prior and post 
> 0.42, no matter whether you are using pd-vanilla or pd-ext.
> just because pd-ext is still far from 0.42, doesn't mean that it will 
> take counter-measures when the time is ripe.

correct me, if this is wrong, but i understand, that overriding internal
classes doesn't work with single-file externals. so the feature of
overriding internal classes doesn't and won't work with pd-extended.
this is what i call the incompatibility. a patch, that loads cyclone,
assumes to be using the [pow~] of cyclone, while on pd-extended it does
actually use the pd [pow~]. this is _not_ related to the version of
pd-extended, this will virtually always be true, wouldn't it? so in my
terminology, introducing the ability for external classes to override
internal classes is what i call deliberately introducing a _new_
incompatibility between pd vanilla and pd-extended.

please someone correct me, if this is wrong or based on wrong
assumptions.

roman
 


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de





More information about the Pd-dev mailing list