[PD] problem with pd-extended 0.41.4

[Hans-Christoph Steiner]

There is lots of discussion in the archives on these topics.  Here's a  
summary:

- building as one-class-per-file gives us some namespace functionality  
to deal with nameclashes

- pd-extended aims to use a single format for all libraries

- the nightly build of Pd-vanilla + externals uses vanilla as the 'pd'  
instead of 'pd-extended.

.hc

On Sep 13, 2009, at 9:53 AM, ydegoyon at gmail.com wrote:

>
> very good subject .
>
> in fact, i would add : and what are the differences between
> a pd vanilla + externals and pd-extended ?
> it's not listed ni trced anywhere?
>
> and which libs became objects,
> or objects became libs?
>
> Ivica Ico Bukvic wrote:
>>>> Yup, we are aware.  Originally that stuff was handled by the  
>>>> hexloader
>>>>
>>> for
>>>
>>>> special characters, which had serious bugs.
>>>>
>>> I probably missed something important. What happened to the
>>> hexloader?
>>>
>>
>> Second that. I would love to hear more about the hexloader. Is this  
>> a part
>> of the regular distribution or only pd-extended? Also, why is zexy  
>> not built
>> as a lib rather than being a collection of files? Does it have  
>> lower memory
>> footprint this way? It seems a simple solution would be to have  
>> zexy as a
>> lib (at least on Linux). Finally, are there any other libs that  
>> have similar
>> issues?
>>
>> Ico
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



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

If you are not part of the solution, you are part of the problem.