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

Hans-Christoph Steiner hans at at.or.at
Thu Jan 31 18:42:01 CET 2013


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!
>>
> 
> [...]
> 
>> * new standard library that is larger and more consistent than what's in
>> vanilla, things like all math and logic objects both message and signal
>> included, rather than needed to load a library (i.e. zexy) for some of them.
>> It would prioritize correctness and consistency over backwards compatibility.
> 
> That's a royal waste of your time.  I'm certain you wouldn't advocate _moving_
> objects from various libs to one standard lib-- as that would break backwards
> compatability-- so you must be advocating copying them.  Both would have the
> direct affect of confusing users-- the former by _breaking_ all kinds of help docs,
> tutorials, and lots else that's more or less part of the "standard" Pd world at
> this point; and the latter by returning two results in a search for an object that
> happens to be in the standard library.  Either is also a royal waste of the users' time.
> 
> If there are specific objects inside zexy or hans that need to be superceded by
> an object with a better design in order to get more consistency, or if there are
> objects that haven't been created yet that would add needed functionality, let's
> talk about those cases.  But [import hans zexy lib_to_be_coded] is a perfectly
> reasonable interface for loading 90% of what the user needs, so let's not go
> breaking stuff for the sake of theoretical consistency.  For the other 10% it's
> just fine for the user to search for that functionality and use the prefix
> that is shown in the search results, or click the "info" icon to read about the
> relevant library, or use [import], or do all three.

Yes, it'll be a chunk of work, but I strongly believe it'll be worthwhile.
Python3 is a good example of this kind of thing.  All the existing libraries
would remain as they are, so backwards compatibility would be fully available.

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, 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'.

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.

>> * no libraries but the standard library loaded by default.
>>
>> * the possibility to load "distro profiles" for compatibilityYes, it'll be a chunk of work, but I strongly believe it'll be worthwhile.  Python3 is a good example of this kind of thing.  All the existing libraries would remain as they are, so backwards compatibility would be fully available. with 
>> Pd-vanilla
>> and Pd-extended
>>
>> * all of Pd-vanilla's objects as a separate 'vanilla' library.
> 
> In the search plugin I'm judging vanilla objects based on
> whether the help patch is inside 5.reference, and returning
> them first in the results.  I asked you awhile back if the
> subdirs in "doc" are subject to change and you said they
> were a standard part of Pd that wasn't likely to change.
> If want the "vanilla" lib for the sake of consistency,
> you won't get it because the vanilla help patches must
> remain in 5.reference.  If you copy them to vanilla/ again
> you would create UX problems as a search will return
> two results for every vanilla object.
> 
> -Jonathan

I think it'll be worthwhile to fix that quirk, and only have a single method
that applies for all bjects and libraries, including 'vanilla'.  This points
to exactly what I'm talking about: this is a random, unneeded exception that's
there because of historical reasons, but is not useful in its own right.

Most of the objects in this new standard library would likely change only
slightly so the help can be taken from PDDP and tweaked.

As for changing the tutorial sections in doc, I did not want to take on the
maintenance of modified version, but I always thought it would be nice to have
improved versions of them.  You've started that project, so I plan on using
your work there.  You've already created massive improvements in the general
help system, I expect no less with your effort on the included tutorials. :-D
no pressure... ;)

.hc



More information about the Pd-list mailing list