Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Sunday, February 3, 2013 1:41 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!) [...] If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed. I suspect it'd be about two or three months of full-time work. If people are willing to pay me to make these changes I'm happy to do them. As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes. (As well as testing that the results worked across platforms.) -Jonathan These things are all true, I think its worth it. I think you might be thinking that there will be more changed than there need to be. Most of the objects would not need documentation changes, or just small changes. Here's the doc work: 1) search plugin - for classes that are copied into the new libs, don't show duplicate results from the legacy library (which is only there for backwards compatability). Probably the best way to do this is add a legacy tag to the old lib stuff. 2) Change the relative pddp links for all 200+ PDDP help patches that points to stuff outside of 5.reference/ (probably can automate much of this process) 3) Find and change all the pddplinks and comments in docs of externals that refer to 5.reference (absolute and relative). (Somewhat automated) 4) Make a good faith effort to amend FLOSS references and other common PD learning materials to document new libs. (Otherwise new users read about legacy stuff while using new stuff, get confused, and write to the list to ask about why the same exact objects get different prefixes in different docs.) 5) Lots of iterative changes to places in the documentation that make a distinction between internal and external objects, including the search plugin, all about Pd patches, tutorials, the Pd manual, and probably a lot else that I'm not thinking of at the moment. 6) Create new documentation to explain _exactly_ how to use standard libs, explaining how to a) get the old behavior of just loading all libs in Pd-extended, b) how to use [import], c) how to use the lib prefix, and d) any other ways of loading libs and the benefits/drawbacks of those approaches. 7) Making a user-friendly doc or patch about legacy libs that explains the legacy author-oriented approach for new (and old) users, focusing esp. on the most popular legacy libs. Without this a lot of documentation on puredata.info-- and esp. on the user and dev list-- becomes difficult to understand and follow. 8) Find entry points into the common Pd learning materials and inject a note about the move from the legacy approach to the new approach, with a link to the doc from #7. 9) Keep a list of all easily translatable sources of documentation on this change, so that translations of the new approach can happen as soon as possible. 10) Check for cross-platform compatibility, to make sure none of the core doc changes or search-plugin changes introduce weirdness somewhere. However, after doing some initial research I see there's a bigger issue before any of this could even happen. Let's say I put up a Kickstarter for a month's worth of doc work on this. I'd have to schedule it for a date after the work is done deciding what names the standard libs should get and what code goes in those libs. That process will probably turn into bikeshedding where none of the real work actually gets done-- I can say this because _substantial_ preliminary discussions for this work already took place 4 years ago on the dev list and we don't have standard libs today. So here's my proposition: I'll work on compiling a list of classes that should have been included in vanilla but aren't yet. I'll exclude objects which are currently in a maintained, aptly-named library build around classes that share some core functionality in common, as those libraries are already standard libraries. I should end up with a list of classes which, in conjunction with the vanilla classes, make it possible to get substantially more work done without relying on hacks or workarounds. We can worry about libname and relationship with vanilla later-- the main point will be that these core objects can all be typed into an object box in Pd extended, without any namespace prefixes, and as long as nothing has been [import]ed or [declare]d it should all just work. If it goes the way I think it will, there won't be any need to have a bunch of new libs, just one that adds long-desired functionality to vanilla that's been missing for so long. None of this initial work requires any discussion whatsoever, since it all exists already on the user and dev lists. So
Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Saturday, February 2, 2013 8:35 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!) [...] 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). But you're evidently keeping zexy for compatibility reasons, so how would this create less maintenance for you? 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+. You are wrong-- there are libraries currently under GPLv2, some under GPLv3, some GPLv2+, some 3-clause BSD, some Tcl/Tk license, and maybe a few others. You cannot automagically change the GPLv2 and GPLv3 to GPLv3+, and if you change the 3-clause BSD to GPLv3+ it needs to be explicit-- i.e., changing it in the pd META patch. For the other versions of the GPL someone would need to contact all the original authors and get them to release it under GPLv3+. (Btw-- please don't start a thread on licenses here. If you don't understand the problems then email the fsf and they can explain it, and you can paste their response here.) These changes will turn into a lot of documentation work, not to mention changing existing docs to point to the standard libs instead of the legacy ones where possible, and changing FLOSS manual stuff and Pd manual stuff as well as any other extant tutorials widely used by the Pd community to clearly explain the new libs so that new users don't get stuck learning half legacy stuff and half new lib stuff (thus making it even more difficult to get around in the language). Not to mention documenting the legacy stuff and its relationship to the new stuff, while making the new stuff more easily discoverable in the docs and the search plugin. (Oh, and contacting legacy lib devs and seeing who is willing to relicense under GPLv3+.) If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed. I suspect it'd be about two or three months of full-time work. If people are willing to pay me to make these changes I'm happy to do them. As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes. (As well as testing that the results worked across platforms.) -Jonathan There will need to be other copyirght notices from BSD licensed code, but that's manageable. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
On 02/03/2013 01:19 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Saturday, February 2, 2013 8:35 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!) [...] 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). But you're evidently keeping zexy for compatibility reasons, so how would this create less maintenance for you? 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+. You are wrong-- there are libraries currently under GPLv2, some under GPLv3, some GPLv2+, some 3-clause BSD, some Tcl/Tk license, and maybe a few others. You cannot automagically change the GPLv2 and GPLv3 to GPLv3+, and if you change the 3-clause BSD to GPLv3+ it needs to be explicit-- i.e., changing it in the pd META patch. For the other versions of the GPL someone would need to contact all the original authors and get them to release it under GPLv3+. (Btw-- please don't start a thread on licenses here. If you don't understand the problems then email the fsf and they can explain it, and you can paste their response here.) Only the copyright holder can change the license, I'm not proposing any license changes. I am saying that if the overall library is licensed under the GPLv3+, then code licensed under the GPLv2+, BSD, Tcl license will be compatible and can be freely incorporated into the GPLv3+ library. This library would have to keep the copyright licenses intact, according to the terms of the other licenses. Code licensed GPLv2-only like the Linux kernel would not be compatible, for example, but I haven't found any Pd code that's licensed GPLv2-only. These changes will turn into a lot of documentation work, not to mention changing existing docs to point to the standard libs instead of the legacy ones where possible, and changing FLOSS manual stuff and Pd manual stuff as well as any other extant tutorials widely used by the Pd community to clearly explain the new libs so that new users don't get stuck learning half legacy stuff and half new lib stuff (thus making it even more difficult to get around in the language). Not to mention documenting the legacy stuff and its relationship to the new stuff, while making the new stuff more easily discoverable in the docs and the search plugin. (Oh, and contacting legacy lib devs and seeing who is willing to relicense under GPLv3+.) If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed. I suspect it'd be about two or three months of full-time work. If people are willing to pay me to make these changes I'm happy to do them. As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes. (As well as testing that the results worked across platforms.) -Jonathan These things are all true, I think its worth it. I think you might be thinking that there will be more changed than there need to be. Most of the objects would not need documentation changes, or just small changes. There are a number of libraries that I continue to maintain only because of a couple objects (like [ENV] in cxc, or [getenv] and [system] in Motex). My plan is to stop my maintenance work on those libs once the standard lib makes them unneeded. Of course anyone else is welcome to maintain them. Another thing is that there will be less to document. For example, newbies won't need to learn about loading libraries until much later. And the current system of separate libraries loaded by default in a specific order is fragile and causes many weird, hard to understand bugs for no good reason. .hc There will need to be other copyirght notices from BSD licensed code, but that's manageable. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
On 02/02/2013 02:46 AM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@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 h...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@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 h...@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? 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? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-30 22:40, Hans-Christoph Steiner wrote: A quick internet translations makes me think that I agree with what cyrille is saying. The preferences shouldn't be used for loading libraries, as they have been in pd and especially Pd-extended for a long time. Pd-extended no longer lets you set libraries to load from the preferences, this is one step to get us on the right direction. I've been thinking about other things as well, i'm still very skeptic about the possibility that there is one right direction. here's how I'm thinking: * 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. i'm not sure i really understand the sentence. but i guess it is mainly suggesting to move objects of general value to a so called standard library that provides the basic needs. one question os of course, what a basic need is. e.g. personally i would vote for a minimum set of math-like operators, rather than high-level user-friendly objects. e.g. [~] but not [moog~]. others might think very differently about this. It would prioritize correctness and consistency over backwards compatibility. i agree, that a so called standard library is a *must*. * no libraries but the standard library loaded by default. note that many languages (including C and python) don't automatically load their standard libraries. however, they do have a standard library. and they provide primitives that allows you to use the language even without any standard library. from the users's perspective it's probably a good default to load a stdlib, but one could easily introduce a -nostdlib flag to override that. * all of Pd-vanilla's objects as a separate 'vanilla' library. how would that be different from the standard library? i guess the stdlib most likely will contain more objects than vanilla, and some objectclasses would not be part of stdlib or under another name ([makefilename] springs to my mind). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEKLX0ACgkQkX2Xpv6ydvR4IgCeLjnGVP95jO7SwTL9v/PKBdwQ c9wAnjWlQs+ethcLueD7EmNE3umt3u4d =AgIj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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 h...@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! [...] * 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@iem.at mailing list UNSUBSCRIBE
Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
On 01/31/2013 03:38 AM, IOhannes m zmoelnig wrote: On 2013-01-30 22:40, Hans-Christoph Steiner wrote: A quick internet translations makes me think that I agree with what cyrille is saying. The preferences shouldn't be used for loading libraries, as they have been in pd and especially Pd-extended for a long time. Pd-extended no longer lets you set libraries to load from the preferences, this is one step to get us on the right direction. I've been thinking about other things as well, i'm still very skeptic about the possibility that there is one right direction. here's how I'm thinking: * 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. i'm not sure i really understand the sentence. but i guess it is mainly suggesting to move objects of general value to a so called standard library that provides the basic needs. move, not copy. I wouldn't change any existing libraries. one question os of course, what a basic need is. e.g. personally i would vote for a minimum set of math-like operators, rather than high-level user-friendly objects. e.g. [~] but not [moog~]. others might think very differently about this. I totally agree. We'll have to work out what is required in the basic library. I think all math and logic are the obvious starting point, and moog~ is obviously still an external. I think that the standard library will be broader than other programming languages because Pd aims to be simpler, smaller, and easier to learn. So I would definitely include all symbol and list manipulations (symbol2list, makesymbol, list-append, list-prepend, split, etc.). I also think that all of the objects should flexibly work with both floats and symbols wherever appropriate. zexy/pack is a great example of this. [select] should be like that too. It would prioritize correctness and consistency over backwards compatibility. i agree, that a so called standard library is a *must*. The hard part is agreeing on what's correct ;) * no libraries but the standard library loaded by default. note that many languages (including C and python) don't automatically load their standard libraries. however, they do have a standard library. and they provide primitives that allows you to use the language even without any standard library. To clarify here, by standard library I mean the commands that are available without specifically loading anything. So this is different than what python calls its standard library which included things loaded by default and many things that have to be loaded. from the users's perspective it's probably a good default to load a stdlib, but one could easily introduce a -nostdlib flag to override that. Yes the transition will be a long slow process. I'm thinking it could be a separate build, and leave Pd-extended as the name of the old way. This would be like python2 vs python3. So I guess built-in might be a better name for it: http://docs.python.org/2/library/functions.html And 'builtin' is actually a loadable module too: http://docs.python.org/2/library/__builtin__.html I want to include functionality like this in Pd-extended, or the new python3-style thing if we go that route, so that it would be possible to load a vanilla or extended compatibility mode. * all of Pd-vanilla's objects as a separate 'vanilla' library. how would that be different from the standard library? i guess the stdlib most likely will contain more objects than vanilla, and some objectclasses would not be part of stdlib or under another name ([makefilename] springs to my mind). yes, exactly. Then things like [hip~], [log], etc. that have changed over the years in incompatible ways, they would only include the correct method. I would also replace [list append], etc. since it is the only set of objects that violate the first word is the object name rule. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
