ola,
precisely, there are _too_ many discussions on this topic, and i don't know the actual state of it...
subsidiary question :
do i neeed pd-extended ( from which version on ? ) to use namespaces and inspect the mapping library ?
will pd-extended crush my dev version living in /usr/local/pd ?
saludos, sevy
Hans-Christoph Steiner wrote:
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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@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.