[PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

[Hans-Christoph Steiner]

On 02/02/2013 02:46 AM, Jonathan Wilkes wrote:
> ----- Original Message -----
> 
>> From: Hans-Christoph Steiner <hans at at.or.at>
>> To: Jonathan Wilkes <jancsika at yahoo.com>
>> Cc: "pd-list at iem.at" <pd-list at iem.at>
>> Sent: Thursday, January 31, 2013 12:42 PM
>> Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
>>
>> On 01/31/2013 11:45 AM, Jonathan Wilkes wrote:
>>>
>>>
>>>   ----- Original Message -----
>>>>   From: Hans-Christoph Steiner <hans at at.or.at>
>>>>   To: pd-list at iem.at
>>>>   Cc: 
>>>>   Sent: Wednesday, January 30, 2013 4:40 PM
>>>>   Subject: Re: [PD] [PD-announce] Pd-extended 0.43.4 released!
> 
> [...]
> 
>> I agree theoretical consistency is not a worthy goal, that's not the point
>> here at all. [import zexy] is a good example.  Let's say a user is looking 
>> for
>> objects to make and manipulate symbols,
> 
> That user can click the search-plugin category link "symbol_op".
> The result will be a user-friendly list of everything that would be in
> a symbol-oriented library, prefixed with the lib name, followed by an icon
> that links to lib info.  If those results don't include everything, someone
> can go in and add the keyword "symbol_op" to the help patch for the object
> that needs to be included.  Also, if "symbol_op" is too obscure, someone
> can change the text of that link on the search plugin home page to be
> something more descriptive.  All of those tasks are extremely cheap to
> carry out in Pd's current form, and there won't be long threads of
> discussion since categories aren't mutually exclusive.
> 
> 
>> how about calling tat library
>> "symboltricks" or something descriptive, rather than an arbitrary name 
>> 'zexy'.
>> In python, if I want to work with URLs, I load a 'urllib' or maybe 
>> 'urllib2'.
> 
> I agree that aptly-named libraries built around a specific domain or
> a logical grouping will improve the user experience, but not
> nearly to the degree that implementing cross-platform doc search
> functionality has.  It will mostly facilitate memorizing the prefixes (libs)
> of commonly used externals and reinforcing their shared attributes that
> relate directly to that specific library name.  But libraries don't overlap,
> and _standard_ libraries are (hopefully) static and are difficult to
> amend once set in place.  Tags are the opposite of all that, and are
> already implemented.
> 
>>
>> The point is that the old way of organizing libraries was around the author,
>> not what the library does, like zexy.  Newer libs like iemguts, pmpd, log,
>> etc. are organized around a topic, and that makes much more sense.  That's a
>> very widely established paradigm for libraries across basically all languages.
>>
>> Honestly, in the long run I think this will be less work than maintaining the
>> system as it is now.  There are so many exceptions and quirks that is really
>> is hard to make progress because some forgotten quirk comes back and bites you.
> 
> What are the maintenance problems solved by copying binaries into new
> directories?

The point is to reduce complexity and exceptions to consistency.  Once example
where just copying an external would reduce complexity is taking an object out
of zexy.  Zexy has a very complicated build system because it has a huge array
of objects, many of which will not build on every system, things like [lpt].
Therefore the build system needs to configure itself based on what is available.

A standard library would only have things that build on every system, so a
much simpler build system can be used (like the library template).


> Also-- you will end up with objects that have different licenses in the same lib.
> Is there a precedent for that in any programming language?

You will be able to consider the whole GPLv3+.  There will need to be other
copyirght notices from BSD licensed code, but that's manageable.

.hc