On 02/02/2013 02:46 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@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.or.at To: pd-list@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