[PD] problem with pd-extended 0.41.4
Hans-Christoph Steiner
hans at eds.org
Sun Sep 13 21:59:37 CEST 2009
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.
More information about the Pd-list
mailing list