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, ydego...@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.
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
