Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Tue, 18 Sep 2007, Hans-Christoph Steiner wrote: They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists. That's also called an interface, a protocol, a contract, or an abstract class. For example, if I have [comport], [tcpsocket] and [file] classes, all three of which implement the io protocol, then any of those three can be called an io object, or an object of the io class, and each of those three's helpfiles can refer to the io protocol help file instead of copy-pasting each other, and then you have help files about classes that are not implementations and which you can't instantiate because they only exist documentation-wise, and that's alright. That's a direction that I advocate for PDDP. This concept is independent from namespaces. It has to, to some extent, because often a class will implement multiple protocols. Even in the io department, you can split the io interface into readable, writable, seekable, etc.; then it's better to have the namespace go with a category of classes that are related by their protocol relationships, but don't necessarily all implement a same single protocol. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo! The first one found would be the right one. It's not pd's problem if there exist more than one file with the same name. Surely that's up to the creators of the files to sort out. Well, this is now discussed since years. The whole namespace+pd-extended thing would not be obsolete if we simply would load everything in the extra directory ... Also every external in there would be loaded into the memory when you start pd. LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: We would not have Gem, PDP, PiDiP, hid, ann, pdogg, streaming, theora/ speex/mp3 externals, etc. if we did not allow externals to use non- core libraries. Nowhere did I say that. All I'm suggesting is, that a std-library of externals and abstractions must be self-contained: It must include everything that is needed to run it (except Pd). Add to that that ideally this lib would also run on pure-Pd, abstractions must use only core objects or externals from the std-lib itself, nothing else. Note that I don't see the std-lib as a pd-distribution itself. It's not meant to be a duplicate of what pd-extended does. Pd-extended could include the stdlib, but not define what the stdlib is. Instead of arbitrary restrictions, we should make an environment where people can count on having the libraries they need in the same place on every machine. This is a key thing about Java, Debian, etc. and this is the core purpose of Pd-extended. I don't think a std-library can be restricted to one pd-distribution only. This would be the same as if Python's os-module would only run on Debian. Wouldn't be a problem to me, but it would be for many others. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: Well, the examples with more than one folder depth are not of concern. Just limit the search to one depth. Okay, one level could work for extra. It would break how pd-extended is built however. Also, asking the authors of the conflicting objects/abstractions is much less work than building a mega-meta-system. After, that, the cvs law could simply state that no now object/abstraction may have the same name at the first depth level (or second depth depending on your persepective). I'm not too confident about this ask the authors as that didn't work out in the past (10 years). I think, for Pd a mechanisms not policy guideline as the Lua people have works better. Without policy the risk of automatically searching one additional level is that nameclashes are easier again, even with only one level, because extra/a/x.pd and extra/b/x.pd both can exist on one harddisk without problems and we have two [x] again. So only objetcts/abstractions named extra/*/*.pd, extra/*/*.dll, extra/*/*.pd_linux or extra/*/*.pd_darwin Also, please quoting pdmtl abstractions. If you require more information about them, please visit the documentation website. The cvs version is outdated, and since there is talking of making a svn system, they will be integrated properly then. Ah, I'm very sorry. I was only looking at how it's in CVS and pd-extended and now I see that you've dropped the second-level directories. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: The first one found would be the right one. I hereby would like to register the namespace 000 to be the right one myself most of the time. ;) It's not pd's problem if there exist more than one file with the same name. Surely that's up to the creators of the files to sort out. The alternative of using paths for each and every object is a massive kludge that's going to fall on your head and crush you sooner or later, at least I can already feel it pushing me into the mud :( If you'd like to come out of the mud, why not just do a mv extra/*/* extra/? Seriously: This would be exactly the same as a one-level deep search, except that uninstalling single libs is a bit harder. Personally I still have it that way and my externals all are directly in extra, but I choose which ones/once are there myself. This doesn't work for a general purpose distribution like pd-extended, though, which on one hand wants to ship every version of counter and once, but otoh also has to give users a choice, which version to load. With an automatic deep-search this is impossible to achieve, as far as I see. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
[EMAIL PROTECTED] wrote: I think it would be more useful right now if pd would search in subdirectories. How about the adding the ability to write an asterix for recursive search so /home/atte/music/synth/pd/attes_pd_stuff/* would also look in /home/atte/music/synth/pd/attes_pd_stuff/externals /home/atte/music/synth/pd/attes_pd_stuff/abstractions /home/atte/music/synth/pd/attes_pd_stuff/midi_instruments This would keep backwards compatibility + make it possible to do it only for certain directories. I realize the user would still be able to run into name clashes, though... -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hey all, This is a nice idea, but the bottom line is that its too late for that. People already depend on many old (first) funny externals like Markex Counter, which is still in some of my older patches. Its the oldest counter, so should it be the default? too bad its inlets are arranged differently than its arguments. too late to fix that too. PixelTANGO also depends on private externals in a subdirectory that should not be available to the end user. (and not just because it depends on memento either) The libdirs are the solution to that problem, and it has already been solved. Maybe such a feature would be in PD devel or something for the power users to build there own PD, but I'm moving more and more to pd-extended even for installation stuff and especially now that there are nice debs for it. Throwing away the way extended works (and namespaces) to get some extra drop an external somewhere solution does not make much sense to me. As for MaxMSP, if you want to install an external in PD vanilla, just put it in the extra folder, not in a subfolder!!! How many files are in the Max extra (or whatever its called folder?) I think Marius counter over 1200 externals in PD... I don't see any goo reasons against the way the libdir design now (and should in the future) work. So why not improve that then find more awkward ways around the same problems? Just my opinion, .b. Atte André Jensen wrote: [EMAIL PROTECTED] wrote: I think it would be more useful right now if pd would search in subdirectories. How about the adding the ability to write an asterix for recursive search so /home/atte/music/synth/pd/attes_pd_stuff/* would also look in /home/atte/music/synth/pd/attes_pd_stuff/externals /home/atte/music/synth/pd/attes_pd_stuff/abstractions /home/atte/music/synth/pd/attes_pd_stuff/midi_instruments This would keep backwards compatibility + make it possible to do it only for certain directories. I realize the user would still be able to run into name clashes, though... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Frank Barknecht wrote: Hallo, Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the purepd or list-abs collections). as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) fma.dsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: This all sounds excellent, I think this is exactly what would work well. As for choosing standard namespace names, I think that we should follow the lazy consensus rule, with required discussion, i.e., standard lib names should not be automatically accepted unless there is discussion. I think there is need for discussion when it comes to the classes in standard lib names, as I think, that the std-namespace(s) require(s) a more elaborated style guide/specification. Two issues come to my mind immediatly. One is that the behaviour of every of these std-objects needs to be discussed before they are finally released into the wild to avoid future complications and possibly incompatible changes and conflicting interfaces like we have with [counter]. (Matju probably would wisely recommend to add tests as well.) Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the purepd or list-abs collections). That's not because I don't like externals or would want to convince everyone to never touch an external, it's just that a std-library for a programming language should be self-contained. For example if you install Python, a Python programmer can rely on the fact, that all the modules delivered with the core-Python will definitely work. It's still possible to use additional Python modules, but of course none of the core-python modules depends on third-party modules like pyode etc. Pd distributions like pd-extended or the packages included in the various Linux-distributions may still opt to ship optimized implementations of the std-library classes that use externals. I've already mentioned as an example two versions of [list-drip]: one using no externals as in list-abs and one just wrapping [zexy/drip]. Pd-extended could include the [list-drip] with [zexy/drip] as default, users of e.g. PDa would maybe use the list-abs version. However as a guideline I believe, that every std-class should have a purepd implementation, otherwise it should not be included in that namespace. As a side note I may add that finding solutions to some tricky problems under the additional restriction to only use builtin objects is a very satisfying experience. It makes you feel like a Master Of The Universe(tm) ;-) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo! as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Georg Holzmann wrote: Hallo! as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. that is obviously the idea of the stdlib maintainers. nevertheless, it assumes that the auther of a certain object would happily give up their object and either maintain a stdlibized version or withdraw from maintaining the object alltogether (and someone else maintains the stdlibized version) i guess, the 1st option is the one we would want to see happen. nevertheless i have some doubts: often, objects can not simply be moved into the stdlib, but they should follow some standard (hence the name!) design principles (of the interface). but changing the interface of an object is a heavy modification, which needs a lot of social competence) (i am pretty sure that there are lots of ideas how to make objects in zexy more consistent with other objects, however i have spend a lot of time in designing the API (at least for some of them :-)) Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is not necessarily a social permission. mfgad.sr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Frank Barknecht wrote: Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend]. It looks like the function do_open_via_path in s_path.c is the one to fix... This might break some stuff. For example I often use private subdirectories whose objects should *not* be available globally. What if pd searched deeply only in the extra directory, then you could put private files elsewhere and they would not be found? The do_open_via_path function already treats 'extra' as a special case, only searching it after all else fails. Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Frank Barknecht wrote: Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend]. It looks like the function do_open_via_path in s_path.c is the one to fix... Martin Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), the rights to Max/Msp would not have to be bought (as this is clearly the feature that most Max/Msp features adore: to install an external, simply put it in the external folder, and voilà, done). Tom On 9/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Frank Barknecht wrote: Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend]. It looks like the function do_open_via_path in s_path.c is the one to fix... Martin Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: What if pd searched deeply only in the extra directory, then you could put private files elsewhere and they would not be found? The do_open_via_path function already treats 'extra' as a special case, only searching it after all else fails. It would be the same: For example I use a private subdir in sssad which already is install in extra. AFAIR this topic was discussed some times on pd-dev. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 18, 2007, at 11:04 AM, Frank Barknecht wrote: Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). It's all a matter of perspective. I use [comport] all the time and really want a [io/serial] that is based on comport, but has a clean, standardized interface in common with all IO objects (i.e. same basic messages, inlets, outlets, etc.). I have never used [drip], so it doesn't matter to me whether that was included now or in 10 years. Whether iem/comport is maintained is also a non-issue. If someone wants to do the work to maintain both, why stop them? .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list kill your television ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), If it was implemented, which one would become [once]: extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd or maybe: extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd ? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Well, the examples with more than one folder depth are not of concern. Just limit the search to one depth. Also, asking the authors of the conflicting objects/abstractions is much less work than building a mega-meta-system. After, that, the cvs law could simply state that no now object/abstraction may have the same name at the first depth level (or second depth depending on your persepective). So only objetcts/abstractions named extra/*/*.pd, extra/*/*.dll, extra/*/*.pd_linux or extra/*/*.pd_darwin Also, please quoting pdmtl abstractions. If you require more information about them, please visit the documentation website. The cvs version is outdated, and since there is talking of making a svn system, they will be integrated properly then. Tom On 9/18/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), If it was implemented, which one would become [once]: extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd or maybe: extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd ? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 18, 2007, at 8:23 AM, IOhannes m zmoelnig wrote: Frank Barknecht wrote: Hallo, Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the purepd or list-abs collections). as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists. So no, I don't think we should just copy over existing code without change. Instead, we should use existing code when it's useful, but focus on having a clean and consistent interface for each library. Then the old author's name libraries, like iem, zexy, ggee, etc. would remain in place for backwards compatibility. .hc fma.dsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 18, 2007, at 9:43 AM, IOhannes m zmoelnig wrote: Georg Holzmann wrote: Hallo! as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. that is obviously the idea of the stdlib maintainers. nevertheless, it assumes that the auther of a certain object would happily give up their object and either maintain a stdlibized version or withdraw from maintaining the object alltogether (and someone else maintains the stdlibized version) i guess, the 1st option is the one we would want to see happen. nevertheless i have some doubts: often, objects can not simply be moved into the stdlib, but they should follow some standard (hence the name!) design principles (of the interface). but changing the interface of an object is a heavy modification, which needs a lot of social competence) (i am pretty sure that there are lots of ideas how to make objects in zexy more consistent with other objects, however i have spend a lot of time in designing the API (at least for some of them :-)) They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists. So no, I don't think we should just copy over existing code without change. Instead, we should use existing code when it's useful, but focus on having a clean and consistent interface for each library. Then the old author's name libraries, like iem, zexy, ggee, etc. would remain in place for backwards compatibility. Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is not necessarily a social permission. Why use a free license then? That just needlessly complicates things. If someone doesn't want people freely using their code, then they should say so overtly. Not, my license says you can use my code, but if you do, then I'll get mad and work against you. .hc mfgad.sr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Frank Barknecht wrote: Date: 2007/09/18 Tue PM 04:51:57 EDT To: pd-list@iem.at Subject: Re: [PD] inconsistencies with lib names (was: representning classes Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), If it was implemented, which one would become [once]: extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd or maybe: extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd The first one found would be the right one. It's not pd's problem if there exist more than one file with the same name. Surely that's up to the creators of the files to sort out. The alternative of using paths for each and every object is a massive kludge that's going to fall on your head and crush you sooner or later, at least I can already feel it pushing me into the mud :( [possibly/the/worst/idea/ever/invented/once] Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 16, 2007, at 5:59 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea. Yes. And no, too. Oops, forgot to explain why yes and no. Namespaces based on author/vendor solve nameclashes: cxc_counter, maxlib_counter, cyclone_counter. Namespaces based on functionality don't: Which one of the three above should become math/counter? I think, a STD-library of Pd objects should of course be based on functional namespaces, while vendor-namespaces could be used to let various independent vendors do their own thing without creating conflicts with each other. All an editor in chief would need to do is keep a list of which vendor names are already taken. The editor in chief could then be a simple Wiki page on puredata.info. Or not even that, if vendor namespaces are based on things like DNS-names as plists in OS-X. Call me an anarchist, but I believe that we can do it without an editor-in-chief. It just takes some communication and mutual respect. We've gotten this far with the whole Pd-extended collection without an editor-in-chief. .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list kill your television ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Call me an anarchist, but I believe that we can do it without an editor-in-chief. It just takes some communication and mutual respect. We've gotten this far with the whole Pd-extended collection without an editor-in-chief. Unless one considers you to be the pd-extended editor-in-chief. ;) An editor-in-chief wouldn't need to be a real person. A wiki page or a textfile in cvs/svn would be enough plus some simple rules. Registering a namespace name would be as simple as writing the name one wants to use plus a contact in there. Possible simple rules could be: * announcements should go to pd-dev before registering. * otherwise first come, first serve. * everthing that starts with NAME/ is reserved to the registered project. * every class that is registered should always be used with NAME/. Additionaly rules could be: * NAMES must start with letter or digit and be all lowercase. * NAMES starting with an _underscore are for private use (and cannot be registered) Only remaning issue would be that generic/functional names like math or std or pd are tricky, because they might be needed for a real std-namespace later. Vendor-based names like footils are easier in this regard, but mnemonics are worse. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 17, 2007, at 12:21 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Call me an anarchist, but I believe that we can do it without an editor-in-chief. It just takes some communication and mutual respect. We've gotten this far with the whole Pd-extended collection without an editor-in-chief. Unless one considers you to be the pd-extended editor-in-chief. ;) Yeah... I think that's part of the problem with Pd-extended, that I have been the de facto editor-in-chief. I think it'll work much better as more people get involved. I can't keep up on the details of everyone's libs... :D An editor-in-chief wouldn't need to be a real person. A wiki page or a textfile in cvs/svn would be enough plus some simple rules. Registering a namespace name would be as simple as writing the name one wants to use plus a contact in there. Possible simple rules could be: * announcements should go to pd-dev before registering. * otherwise first come, first serve. * everthing that starts with NAME/ is reserved to the registered project. * every class that is registered should always be used with NAME/. Additionaly rules could be: * NAMES must start with letter or digit and be all lowercase. * NAMES starting with an _underscore are for private use (and cannot be registered) Only remaning issue would be that generic/functional names like math or std or pd are tricky, because they might be needed for a real std-namespace later. Vendor-based names like footils are easier in this regard, but mnemonics are worse. This all sounds excellent, I think this is exactly what would work well. As for choosing standard namespace names, I think that we should follow the lazy consensus rule, with required discussion, i.e., standard lib names should not be automatically accepted unless there is discussion. In order for things to get done, I think we need project leads, which have similar duties to an editor-in-chief, but I think it should be more like a community organizer who focuses on organizing things like the rules for a given library. A key difference would be that a project lead would not have the complete authority of a editor- in-chief. The mob that is the Pd community would always have some say if we want. :) .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea. Yes. And no, too. Oops, forgot to explain why yes and no. Namespaces based on author/vendor solve nameclashes: cxc_counter, maxlib_counter, cyclone_counter. Namespaces based on functionality don't: Which one of the three above should become math/counter? I think, a STD-library of Pd objects should of course be based on functional namespaces, while vendor-namespaces could be used to let various independent vendors do their own thing without creating conflicts with each other. All an editor in chief would need to do is keep a list of which vendor names are already taken. The editor in chief could then be a simple Wiki page on puredata.info. Or not even that, if vendor namespaces are based on things like DNS-names as plists in OS-X. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote: Again, this is up to the person building them. why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not. I am totally with you in spirit, but the issues are social, not technical. I think that we should purge all old build systems (they'd still be archived in CVS) and replace them all with a standard build system. But unfortunately, it has been a very political issue in the past, so the cruft remained. It seems that things have changed on the social front somewhat, so maybe now this could be done. Are you volunteering to lead the charge? :-D actually i would like to do so, but i have some concerns. first, as i mentioned a few times before, i've never written a line of c code or a makefile or a config-file. my knowledge about this is very limited. and i am not a pd-cvs dev myself and thus do not feel like making my hands dirty on files which have been written and developped carefully by others. and still if i would feel to be able to do it, i would request an admission first from the original author for each library before doing it. if it's only about deleting makefiles/configures and probably editing the readmes and all pd-cvs people agree, i would do it. As I see it, it's not about that at all. Basically it's a social and not a technical issue. Namespaces aren't something, that can be enforced technically ATM. They are a convention: Nothing can stop a user to add the directory of some classes to the Pd search path or alternatively put them into a directory and use that dir as a namespace. Let me explain this taking pdmtl as an (extreme) example: pdmtl can be used with a double namespace: [pdmtl/list/op] but that's not the way the pdmtl people suggest to use it: IIRC you're supposed to use [list/op] instead, as that is, what the help files use. But then, if you do this, pdmtl grabs a whole bunch of possible prefixes, namely these: 2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems, generate, gui, init, input, list, midi, mix, musical, number, random, sample, scale, seq, sf, synth, table, timing, transform So more than 30 possible prefix names are taken by pdmtl. The important thing to note here is: This doesn't have anything to do with the way, pdmtl is installed, it's only a matter of how the Pd search path is configured! How to configure the search path is a matter of conventions, and I'm convinced, that as long as the Pd community doesn't agree on conventions, it is not possible to solve. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
You will be happy to know that the pdmtl abstractions have given up (for a couple of months now) the [pdmtl/list/op] style of naming it's abstractions. By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea. The ideal solution would be to add alternate names to many externals (like zexy's length could have one additional line of code that would instantiate it with list.length, by registering list.length as: class_addcreator((t_newmethod)length_new, gensym(list.length)... But then you would need an editor in chief that would decide what objects get what alternate names. I think the best would be to hold an election for the editor in chief that would make all the needed changes. But honestly I do not think this is going to happen as there are many issues that this thread has already enumerated. In my own opinion, I would say give up and find another solution. That's what we did :) Tom On 9/15/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote: Again, this is up to the person building them. why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not. I am totally with you in spirit, but the issues are social, not technical. I think that we should purge all old build systems (they'd still be archived in CVS) and replace them all with a standard build system. But unfortunately, it has been a very political issue in the past, so the cruft remained. It seems that things have changed on the social front somewhat, so maybe now this could be done. Are you volunteering to lead the charge? :-D actually i would like to do so, but i have some concerns. first, as i mentioned a few times before, i've never written a line of c code or a makefile or a config-file. my knowledge about this is very limited. and i am not a pd-cvs dev myself and thus do not feel like making my hands dirty on files which have been written and developped carefully by others. and still if i would feel to be able to do it, i would request an admission first from the original author for each library before doing it. if it's only about deleting makefiles/configures and probably editing the readmes and all pd-cvs people agree, i would do it. As I see it, it's not about that at all. Basically it's a social and not a technical issue. Namespaces aren't something, that can be enforced technically ATM. They are a convention: Nothing can stop a user to add the directory of some classes to the Pd search path or alternatively put them into a directory and use that dir as a namespace. Let me explain this taking pdmtl as an (extreme) example: pdmtl can be used with a double namespace: [pdmtl/list/op] but that's not the way the pdmtl people suggest to use it: IIRC you're supposed to use [list/op] instead, as that is, what the help files use. But then, if you do this, pdmtl grabs a whole bunch of possible prefixes, namely these: 2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems, generate, gui, init, input, list, midi, mix, musical, number, random, sample, scale, seq, sf, synth, table, timing, transform So more than 30 possible prefix names are taken by pdmtl. The important thing to note here is: This doesn't have anything to do with the way, pdmtl is installed, it's only a matter of how the Pd search path is configured! How to configure the search path is a matter of conventions, and I'm convinced, that as long as the Pd community doesn't agree on conventions, it is not possible to solve. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sat, 2007-09-15 at 11:01 -0400, Thomas O Fredericks wrote: I would say give up hm it seems the only thing i can do here is to become religious and a follower of the church of consistency and wait until all have become members of this church. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: You will be happy to know that the pdmtl abstractions have given up (for a couple of months now) the [pdmtl/list/op] style of naming it's abstractions. In favour of [list/op]? That's what I wrote. Or did I miss something? By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea. Yes. And no, too. I believe, there should be several standard, function-based namespaces. Kind of like pdmtl internally is, but in my opinion, classes in these STD-library should have implementations without any dependencies besides Pd core objects. At least that's the guideline I tried with the [list]-abs: Abstractions in that library must not use externals *at all*. (See the end of this mail for my reasoning.) Then, as an additional layer, versions of these classes could be provided, that do use externals. So there would be two [list/drip] implementations: One using only [list ...], another using [drip] from Zexy for speed reasons. This could then shadow the purepd-version, when Zexy is available, for example in pd-extended. In fact, I'm already using many of these external-enhanced variations of [list]-abs locally. This way, patches using [list/drip] would run everywhere, even without Zexy. Being dependency-free they could be used by everyone regardless of how this everyone has his/her system and search path configured. The ideal solution would be to add alternate names to many externals (like zexy's length could have one additional line of code that would instantiate it with list.length, by registering list.length as: class_addcreator((t_newmethod)length_new, gensym(list.length)... I don't really understand which problem alternate names would solve? But then you would need an editor in chief that would decide what objects get what alternate names. I think the best would be to hold an election for the editor in chief that would make all the needed changes. But honestly I do not think this is going to happen as there are many issues that this thread has already enumerated. In my own opinion, I would say give up and find another solution. That's what we did :) I honestly believe that without an editor in chief (which would be a group of editors or a voting process or a document with guidelines or ...) the nameclash and path setup problem for external classes isn't possible to solve. I learned that lesson from looking at how Python, Java, C/C++ and everyone else is giving away standard class namespaces and keywords. So far we have one editor in chief and that is Miller Puckette who decides, what's in Pd-vanilla. Miller is the only constant, that's why Pd-vanilla IMO is the only working base assumption for a STD-library as I suggested above. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote: Again, this is up to the person building them. why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not. I am totally with you in spirit, but the issues are social, not technical. I think that we should purge all old build systems (they'd still be archived in CVS) and replace them all with a standard build system. But unfortunately, it has been a very political issue in the past, so the cruft remained. It seems that things have changed on the social front somewhat, so maybe now this could be done. Are you volunteering to lead the charge? :-D actually i would like to do so, but i have some concerns. first, as i mentioned a few times before, i've never written a line of c code or a makefile or a config-file. my knowledge about this is very limited. and i am not a pd-cvs dev myself and thus do not feel like making my hands dirty on files which have been written and developped carefully by others. and still if i would feel to be able to do it, i would request an admission first from the original author for each library before doing it. if it's only about deleting makefiles/configures and probably editing the readmes and all pd-cvs people agree, i would do it. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Thu, 2007-09-13 at 07:30 +0200, Roman Haefeli wrote: i tried to always call it 'pd-vanilla/externals', not just 'pd-vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work. iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere. since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward. yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency. some people could probably find it a bit nasty, that a guy like me, who haven't contributed not a single line of code to the cvs yet, does make such proposals. please excuse me for that (i'm already a bit tired and have had some beers). however, the church of consistency will be founded. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 13, 2007, at 1:30 AM, Roman Haefeli wrote: On Thu, 2007-09-13 at 00:49 -0400, Hans-Christoph Steiner wrote: On Sep 12, 2007, at 12:47 PM, Roman Haefeli wrote: hi marius, hi iohannes sorry to chime whitout having participated yet to this discussion at all, On Wed, 2007-09-12 at 17:17 +0200, IOhannes m zmoelnig wrote: marius schebella wrote: how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to flatspace. wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today) iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package iemlib1 to the meta-package iemlib. i thought this would be impossible, given the structure of the iemlib. let us not be troubled by repackaging of objects. but i am. it's not only, that objects (or 'classes') used to move from one to the other, but they exist at two different places at the same time, dependent on whether you are using pd-extended (with libdir format) or pd-vanilla with the original externals. iemlib is a good example, lets stick with this one. [hp1~] is part of 'iemabs' in pd-vanilla and part of 'iemlib' in pd-extended. if you want to use namespaces for instantiating the objects, it doesn't work crosscompatible on both distros. however, this is actually a different story, but probably affects the way we want to implement the wiki. since there _are_ incompatibilites between pd-vanilla/original libs and pd-extended, i vehemently propose to decide which route to follow for the database: the 'pd-vanilla/externals' way or the 'pd-extended' way. let's also face who is actually addressed with this database. one of its goals is to have all information about objects available at one place, which is, i think, fairly essential for people, who are new to pd and want to explore all facets of pd. i also believe, that most of these people will use pd-extended, since it is by far the easiest way to get 'just everything'. taking into account all these points, i strongly believe, that it would be the best way to reflect the pd-extended topology in the database, none the less just because people, who compile pd and externals themselves could live more easily with incostistencies between their pd installation and the database than less experienced pd users. to sum it up, i'd vote for: [url]/[libname]:description of a library [url]/[libname]/[objectname]: description of the object (i am not an wiki expert at all and also don't know, if these proposal can be represented in mediawiki [or i a wiki in generel]) why making it flat und having to deal with nameconflicts, when the libdir was introduced in order to just avoid that? yo, i hope i didn't bring something up, that has been discussed and defined before already, since i missed the major part of the pd-doc meeting. roman I agree with this email, but I just want to clarify something. Namespace support is _exactly_ the same on pd-vanilla and pd- extended. Whether you can use the namespace in the object name depends purely on how you compile the libraries, not on whether you are using pd-extended or pd-vanilla. If you are talking pd-vanilla, then you are talking no externals at all. i tried to always call it 'pd-vanilla/externals', not just 'pd- vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work. Again, this is up to the person building them. For example, the externals that come with Pd in the extra folder are built in both ways. bonk~, fiddle~ are built as single files. The exprs are all built into one file. Some libraries (ggee, unauthorized) have been built as single-class-single-file single well before Pd-extended. iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere. since [declare] doesn't output an error,
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Thu, 2007-09-13 at 11:14 -0400, Hans-Christoph Steiner wrote: Again, this is up to the person building them. For example, the externals that come with Pd in the extra folder are built in both ways. bonk~, fiddle~ are built as single files. The exprs are all built into one file. Some libraries (ggee, unauthorized) have been built as single-class-single-file single well before Pd-extended. iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere. since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward. yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency. Sounds like the iemlibs should be should be split up in Pd-extended, then it would be consistent. Any volunteers? this not what i was proposing. i was rather referring to this: Again, this is up to the person building them. why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 13, 2007, at 1:40 PM, Roman Haefeli wrote: On Thu, 2007-09-13 at 11:14 -0400, Hans-Christoph Steiner wrote: Again, this is up to the person building them. For example, the externals that come with Pd in the extra folder are built in both ways. bonk~, fiddle~ are built as single files. The exprs are all built into one file. Some libraries (ggee, unauthorized) have been built as single-class-single-file single well before Pd-extended. iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere. since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward. yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency. Sounds like the iemlibs should be should be split up in Pd-extended, then it would be consistent. Any volunteers? this not what i was proposing. i was rather referring to this: Again, this is up to the person building them. why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not. I am totally with you in spirit, but the issues are social, not technical. I think that we should purge all old build systems (they'd still be archived in CVS) and replace them all with a standard build system. But unfortunately, it has been a very political issue in the past, so the cruft remained. It seems that things have changed on the social front somewhat, so maybe now this could be done. Are you volunteering to lead the charge? :-D .hc roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 13, 2007, at 2:02 AM, Roman Haefeli wrote: On Thu, 2007-09-13 at 07:30 +0200, Roman Haefeli wrote: i tried to always call it 'pd-vanilla/externals', not just 'pd- vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work. iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere. since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward. yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency. some people could probably find it a bit nasty, that a guy like me, who haven't contributed not a single line of code to the cvs yet, does make such proposals. please excuse me for that (i'm already a bit tired and have had some beers). however, the church of consistency will be founded. I'll only forgive you if you fix it! ;) .hc roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
