On Feb 17, 2009, at 11:14 AM, dmotd wrote:
On Tuesday 17 February 2009 22:29:10 Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
depends on what you mean by "storing the preferences in patches". one part of the preferences is the libraries to be loaded. personally, i think it is a good thing to explicitely require libraries in patches that need them.
Yeah, but IMO one has nothing to do with the other. Just because a pd-extended user would be forced to manage preferences manually doesn't make [import] a builtin or makes everyone layout their patches and externals as Pd-extended does it neither lets it [declare] work in abstractions. So I don't see how a minimized set of libraries affects anything.
Personally I don't care what pd-extended loads and what not, but *if* minimizing libraries should be done, then I think no library should be loaded at all besides [import].
Ciao
without having any real grasp of pd-extended (sorry, never used it), my understanding is that [declare] and [import] may load libraries/ objects relative to the patch, but they are still loaded in memory and *will* override the functionality expected in any patch loaded consecutively. without an unload routine for external libs, or a method to restrict dynamic loading of libs to the parent patch, then pd will still suffer nameclashes and aliasing of default behaviour for any patch loaded thereafter.
i think this behaviour becomes even more confusing as the lib in question was never explicitly loaded by the user.
please correct me if I am wrong or misguided!
ciao,
dmotd
First off, I just want to say, this doesn't only affect Pd-extended. [declare] is in vanilla, and these namespace prefixes existed before Pd-extended did. Pd-extended does use them as the main organizing structure of libraries, while Pd-vanilla is a free-for-all, you can use them, but you don't have to.
That said, you bring up a good point. For binaries, once they are loaded, they are in the global namespace. So yes, I think it will be confusing. But for abstractions, they are in effect only loaded into the canvas-local namespace because the path is consulted everytime you load an abstraction, AFAIK.
So perhaps for this release, only the libs made up of abstractions should be removed from the default load list (mapping, jmmmp, pixeltango, etc.)
The end goal is to have no libraries loaded by default, but it would be good if we can soften the transition. Maybe my idea doesn't soften the transition, in which case things should stay as they are. This thread has been very useful is bringing the issues to the surface. :)
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams