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

[Hans-Christoph Steiner]

On Feb 18, 2009, at 7:03 PM, Roman Haefeli wrote:

> On Wed, 2009-02-18 at 20:19 +0100, IOhannes m zmoelnig wrote:
>> cyrille henry wrote:
>>>
>>> IOhannes m zmoelnig a écrit :
>>> ..
>>>> they could, but it was an effort to do so.
>>>> any "ordinary" external would not be able to do it.
>>>> the only library that i am aware of that did override internal  
>>>> classes
>>>> is cyclone,
>>> what about zexy [unpack]?
>>> it is still here,
>>
>> oops, nobody told me yet :-)
>> i have hopefully fixed it now...
>>
>>> and it is still breaking my patch.
>>
>> how's that?
>> i would be interested in a patch demonstrating this breakage.
>>
>
>
> IOhannes, thanks a lot for the explanation in previous mails about how
> fuddling was needed in previous version of pd and isn't anymore in  
> 0.42.
> this explainy why suddenly [pack] and [unpack] of zexy overwrite the
> versions of pd. i think, this makes all sense to me now.
>
> the switch from 0.41 to 0.42 did indeed also break at least one of the
> netpd patches. this patch is using [unpack] for an incoming message,
> that misses the list selector. while this still works with pd's  
> [unpack]
> (although it is an undocumented feature, i guess), it doesn't work  
> with
> the zexy [unpack]: it complains: no method for 'bla'.
>
> this again raises the question: should zexy's [unpack] mimick the the
> funny behaviours of pd's [unpack]? i am undecided here. personally i
> think, that it was a bad choice to call it [unpack] after all.


Zexy's unpack/pack is how the original should have worked, IMHO.  They  
have very useful functionality, but they should have different names  
so that they can be used more easily in Pd.  How about:

packlist/unpacklist
zexypack/zexyunpack
bundle/unbundle
group/ungroup
makelist/splitlist

.hc


----------------------------------------------------------------------------

There is no way to peace, peace is the way.       -A.J. Muste