[PD-dev] stripping down Pd-extended's default libs

[Hans-Christoph Steiner]

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