hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part? Do I understand you correctly that you want to restructure the whole library mess? maybe you should just go for one big lib called extended then, that includes everything that is not really related to special libraries like gem or pdp. I would support a public decision making process that votes nameclashing objects in or out to extended. but the most important thing is to document what's inside. then people can reference to that set of object classes and deal with exceptions.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
btw, does the number of loaded libraries/object classes influence the startup time of patches?
marius.
2009/2/16 Hans-Christoph Steiner hans@eds.org:
Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
Gem cyclone zexy creb cxc iemlib list-abs mapping markex maxlib memento mjlib motex oscx pddp pdogg pixeltango pmpd rradical sigpack smlib toxy unauthorized vbap pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Or does it even make sense to do it in stages?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev