[PD] [PD-announce] Pd-extended 0.43.4 released!)

Fri Feb 1 16:48:03 CET 2013

On 02/01/2013 08:55 AM, Ed Kelly wrote:
> OK, so Pd-extended doesn't load any libs by default (except Gem of course).

There is some confusion there since all of the version/loading messages no
longer show by default.  The same libraries are all still being loaded by
default, and the messages are still being posted to the Pd window, but at the
'debug' level.

> I'd like to suggest a fix for a problem I've encountered, especially when moving patches. 
> 
> Would there be a reverse way of finding out what libs are missing from a patch? Even just to generate a file, it would be a good idea to be able to search the libs and find out what you need to [import] to get a patch made on pre 0.43 Pd-extended to work.
> 
> Perhaps it could be an adaptation of the search plugin (nice work Jonathan ;-)

That probably could be done with a GUI plugin, but it wouldn't be 100%
accurate since you can't get the canvas-local [import] and [path] info in a
GUI plugin.  It would be something like this:

* find all tk 'text' widgets with the tag 'obj'
* read the contents of the text widget to get the object name.  It would be
the first word, except for [list prepend], etc.  Those are the first two words.
* search the standard path for that object

.hc

> 
> Ta,
> Ed 
> 
> Gemnotes-0.2: Live music notation for Pure Data, now with dynamics!
> http://sharktracks.co.uk/
> 
> 
> 
>> ________________________________
>> 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, 31 January 2013, 17:42
>> 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!
>>>>
>>>
>>> [...]
>>>
>>>> * 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
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>