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

[IOhannes m zmoelnig]

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.

> 
> Huh? The only "incompatibility" is the new *feature* of alias names for
> overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature*
> implemented by popular demand. Loading libraries and the overwriting
> itself hasn't changed at all AFAIK. If you don't use the alias names,
> you don't have any problems. 

imo, the entire "alias" thing does not deserve it's name.
who will ever want to have [pow~_alias] in their patches?

now what happens if we have 2 (multi-object) libraries loaded, both of 
them containing [pow~].
do we get [pow~_alias_alias] or will the internal just vanish from the 
users scope? if so, why is there an arbitrary boundary at 2?

this all brings back the original idea of implicetely adding the 
libraries name somehow for aliases.
e.g. [pow~] in pd, lib1, and lib2 (in this order)
1. Pd's [pow~]
2. lib1 gets loaded; the original [pow~] becomes [pd/pow~]; the lib1's 
one is now known as [pow~]
3. lib1 get's loaded; Pd's [pd/pow~] stays untouched; lib1's one becomes 
[lib1/pow~]; the new one is know as [pow~]

darn, this is all the thing i have written 6 (or so) years ago.
i remember there have been good reasons not to do it like this.

nevertheless, the idea is kind of re-occurant to me; and i firmly 
believe it is a better solution than to add an "_alias" suffix.


> 
>>> but maybe
>>> I'm wrong. IOhannes? 

overriding with single object externals never worked, because Pd does 
not see a reason to even try and open a library file which could then 
overwrite the internal.

> The overriding with lib-libraries works as before,

no it does not.
Pd never (that is: prior to 0.42) provided a way to overwrite existing 
classes. this holds true for multi-object libraries.
cyclone did some very special tricks to override existing objects.

btw, it tried to do so in a quite sensible way: if the new 
cyclone-object failed to create (e.g. because of wron arguments to the 
object), it would fall-back to the original object.

> 
> I agree with you that external libraries generally shouldn't overwrite
> builtins. When using Cyclone for Max-importing it makes sense, though.

actually i don't see a big problem.
it would be the external's responsibility to maintain full 
compatibility. if it is not compatible (like zexy's [pack] right now), 
then this is just a bug in the external.
the problem with zexy's [pack] overriding the internal was just because 
i was caught on the back foot, believing that i was save for now until 
the incompatibililties were fixed...

> 
> But IMO the aliasing is less insane than not being able to use the
> builtins at all, as is the case if you load object-overwriting-libraries
> like zexy or cyclone in any Pd version before 0.42, including
> pd-extended. 

aliasing is not bad.
what is bad is the way the aliases are generated

> 
> Note that here I use libraries in the "-lib"-loading
> many-externals-in-one-file sense here, not in the sense where everything
> (libs, singles, abstractions, "libdirs") is called a library and setting
> a path is called "loading a library". 

yes, i agree we should not call adding a path "loading a library".
"expanding the namespace" might be better.



mhadft
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090217/818013cd/attachment.bin>