Re: [PD] externals with same names
On Apr 12, 2008, at 12:51 AM, Chris McCormick wrote: On Mon, Apr 07, 2008 at 07:02:15PM -0400, Hans-Christoph Steiner wrote: On Apr 6, 2008, at 10:20 PM, Chris McCormick wrote: On Sun, Apr 06, 2008 at 10:53:14PM +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd- extended which includes only externals and abstractions without nameclashes. ;) Same here! It would be good to have a distribution with a maintainer who is slightly less conservative than Miller about what goes in, but still keep it really tight. Maybe it would also be cool to see a democratized version of Pd where externals and libraries must be first nominated and then voted in by some requisite number of positive votes. For this to work I think we'd need to have people for each major GNU/Linux distribution who would do the work of the actual packaging and submission, separate to the building (My aims are totally selfish - I'd love to be able to apt-get install this). Even more talking with no action (sorry Roman), Check out my posts about a new ./configure based system for building externals and custom distros, it would allow us to all work together. http://lists.puredata.info/pipermail/pd-list/2008-03/060833.html This is all fine as long as it doesn't introduce incompatibilities and organizes the libraries so that it is compatible with pd-extended and pd-vanilla with libdirs. Otherwise, this project would just make the situation worse, there would then be three distros with different library layouts. We really don't need to return to the bad old days. I agree it would be a huge waste and duplication of effort to not use all the work you have done in pd-extended. Maybe it would be cool to use the work you have done as a sort of meta distribution from which a custom Pd could be built. That's the idea. As long as there is a common library format, then there won't be major compability issues between them. .hc I've been thinking more along these lines with Pd-extended anyway. What needs to happen is to establish a standard library format, then people can distribute the librs themselves, and they'll work with any Pd. libdir is almost there, there I am going to try to finish it this month, adding support for embedded help files and examples. Sounds interesting! Unfortunately I won't be contributing anything significant to Pd until at least August, when my degree and contracts are finished. Thanks again for all your hard work! Best, Chris. --- http://mccormick.cx 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
Re: [PD] externals with same names
On Sun, 2008-04-06 at 22:20 -0400, Chris McCormick wrote: On Sun, Apr 06, 2008 at 10:53:14PM +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Same here! It would be good to have a distribution with a maintainer who is slightly less conservative than Miller about what goes in, but still keep it really tight. Maybe it would also be cool to see a democratized version of Pd where externals and libraries must be first nominated and then voted in by some requisite number of positive votes. For this to work I think we'd need to have people for each major GNU/Linux distribution who would do the work of the actual packaging and submission, separate to the building (My aims are totally selfish - I'd love to be able to apt-get install this). Even more talking with no action (sorry Roman), no need to be sorry, because your talk is at least constructive, where mine was just a bit rude, and of course i could start working on it myself instead of asking others to do so. after all, i am happy that there is pd-extended, so that all objects are easily available for everyone. i think the next step should indeed be a cleaned-up version, that - doesn't have nameclashes - only contains classes, that work (the same) on every platform - doesn't conflict with libraries compiled as libraries. i mean conflicts such as no/bad support for aliases and certain class names. even more words. 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] externals with same names
I am totally in for that, too. but how would you do it in practice? would you just rely on a fixed order of path variables which would ensure that a certain object is preferably loaded when you create an object, or would you just not ship some of the externals or rename them? I always thought the biggest problem to solve the nameclashes was that nobody ever got an overview of which objects are really existing in the different libraries. now more and more people get involved and sift through the libraries, so it should be possible to find all nameclashes and vote one as the default for pd-extended. what about an irc meeting maybe next tuesday 6pm(EU)/12pm(east)/9am(west). and then the usual proceedings: wikipage, finding volunteers to implement it, lazy consensus and done. (sorry for my militant course, I know it will never work like that...) marius. Chris McCormick wrote: On Sun, Apr 06, 2008 at 10:53:14PM +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Same here! It would be good to have a distribution with a maintainer who is slightly less conservative than Miller about what goes in, but still keep it really tight. Maybe it would also be cool to see a democratized version of Pd where externals and libraries must be first nominated and then voted in by some requisite number of positive votes. For this to work I think we'd need to have people for each major GNU/Linux distribution who would do the work of the actual packaging and submission, separate to the building (My aims are totally selfish - I'd love to be able to apt-get install this). Even more talking with no action (sorry Roman), Chris. --- http://mccormick.cx ___ 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] externals with same names
On Apr 6, 2008, at 10:20 PM, Chris McCormick wrote: On Sun, Apr 06, 2008 at 10:53:14PM +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd- extended which includes only externals and abstractions without nameclashes. ;) Same here! It would be good to have a distribution with a maintainer who is slightly less conservative than Miller about what goes in, but still keep it really tight. Maybe it would also be cool to see a democratized version of Pd where externals and libraries must be first nominated and then voted in by some requisite number of positive votes. For this to work I think we'd need to have people for each major GNU/Linux distribution who would do the work of the actual packaging and submission, separate to the building (My aims are totally selfish - I'd love to be able to apt-get install this). Even more talking with no action (sorry Roman), Check out my posts about a new ./configure based system for building externals and custom distros, it would allow us to all work together. http://lists.puredata.info/pipermail/pd-list/2008-03/060833.html This is all fine as long as it doesn't introduce incompatibilities and organizes the libraries so that it is compatible with pd-extended and pd-vanilla with libdirs. Otherwise, this project would just make the situation worse, there would then be three distros with different library layouts. We really don't need to return to the bad old days. I've been thinking more along these lines with Pd-extended anyway. What needs to happen is to establish a standard library format, then people can distribute the librs themselves, and they'll work with any Pd. libdir is almost there, there I am going to try to finish it this month, adding support for embedded help files and examples. .hc Chris. --- http://mccormick.cx ___ 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] externals with same names
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] externals with same names
thanx in understand the problematic :), and will take the IOhannes advice my point was that meny of externals with name clashes are actually NOT the same, and that would maybe be easyer to define how to give a nemes to externals. pdp and iem are great examples. My oppinion is that it will be easyer for beginners to understand when they are using core objects and when externals. thanx 4 your time nikola Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] externals with same names
On Sun, 2008-04-06 at 22:53 +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) don't think. do! 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] externals with same names
On Apr 6, 2008, at 4:53 PM, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Since the pd-externals Debian package is now defunct (last released in Sarge), I think we can safely clean up the 'flatspace' section. We could remove all objects from 'flatspace' that are currently in any of the libraries that are loaded by default in Pd-extended. I think that will not break any backwards compatibility, except for people who have explicitly used [flatspace/myobject]. I am guessing that is very rare. Anyone want to take this on? .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] externals with same names
On Sun, Apr 06, 2008 at 10:53:14PM +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Same here! It would be good to have a distribution with a maintainer who is slightly less conservative than Miller about what goes in, but still keep it really tight. Maybe it would also be cool to see a democratized version of Pd where externals and libraries must be first nominated and then voted in by some requisite number of positive votes. For this to work I think we'd need to have people for each major GNU/Linux distribution who would do the work of the actual packaging and submission, separate to the building (My aims are totally selfish - I'd love to be able to apt-get install this). Even more talking with no action (sorry Roman), Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] externals with same names
niko wrote: hi list is this a feature or it should be like this? search the archives of both the pd-list and the pd-dev list for name clashes. as for the duplications in flatspace, they are just copies of other one other implementation (so if there only is one single other implementation, this should be the very same object; if the object is implemented in several libraries, this any suggestions/ideas how to deal with this? search the archives for name clashes :-) there are several solutions: 1: use namespace prefixes (e.g. [zexy/warp] instead of just [warp]) to make explicit which object you mean, at the potential cost, that the patch will break if a library is renamed 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) 3: other solutions including [import] and [declare] which i leave for others to go into detail. fgmadsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] externals with same names
hi list some days ago i downloaded and installed Pd version 0.41.4-extended-20080326 from nightly builds (linux). here is a list of externals with the same names in different libraries (pd_linux files) abs~ 4 times - /zexy, /cyclone, /creb, /markex aenv~ 2 times - /bsaylor, /flatspace alternate 2 times - /markex, /flatspace any2string 2 times - /moocow, /flatspace atan2~ 2 times - /cyclone, /ggee average 2 times - /maxlib, /markex avg~ 2 time - /zexy, /cyclone bfilt2 2 times - /cxc, /flatspace bfilt 2 times - /cxc, /flatspace counter 3 times - /cxc, /cyclone, /markex cxavgdev 2 time - /cxc, /flatspace delta~ 3 times - /cxc, /flatspace, /cyclone fexpr~ and expr~ and expr 2 times - /extra (root), /expr~ (they seem to be same) FIR~ 2 times - /iemlib, /flatspace folder_list 2 times - /hcs, /flatspace (same?) gate 2 times - /iemlib, /cyclone ifeel 2 times - /hcs, /flatspace (same?) image 2 times - /moonlib, /ggee import 2 times - /hcs, /extra(root) - (same?) init 2 times - /iemlib, /flatspace (same?) invert 2 times - /markex, /flatspace LFO_noise~ 2 times - /iemlib, /flatspace - (same?) linuxmouse 2 times - /depricated, /flatspace (same?) matrix_mul_line 2 times - /iemmatrix, /iem_matrix matrix~ 3 times - /iemmatrix, /creb, /cyclone mean~ 2 times - /cxc, /flatspace (same?) messages 2 times - /ext13, /ggee multiselect 2 times - /markex, /flatspace prepend 2 times - /cyclone, /flatspace prob 2 times - /cyclone, /mjlib range 2 times - /depricated, /flatspace (same?) reson~ 4 times - /cxc, /markex, /flatspace (same?) + /cyclone sinh 2 times - /cyclone, /ggee speedlim 3 times - /iemlib, /maxlib, /cyclone split_path 2 times - /hcs, /flatspace split 4 times - /iemlib, /cxc, /cyclone, /maxlib sprinkler 2 times - /moocow, /flatspace string2any 2 times - /moocow, /flatspace susloop~ 2 times - /bsaylor, /flatspace~(same?) svf~ 3 times - /bsaylor, /flatspace (same?) + /cyclone tripleLine and tripleRand 2 times - /markex, /flatspace (same?) urn 3 times - /zexy, /cyclone, /maxlib utime 2 times - /hcs, /flatspace vbap 2 times - /vbap, /ggee warp 3 times - /zexy, /iemlib, /maxlib zhzxh~ 2 times - /bsaylor, /flatspace uhh... i think that was it, hope i did not miss any. a lot of them look to be same (same file size at least) but some of them are different. is this a feature or it should be like this? how do i know witch one PD is loading/using? does this mean that PD can load a wrong help file for a 2 different externals? maybe it would be time to fix this, or just make new names (i know that this can break some patches, but if PD load a wrong external it will also break a patch, or?) any suggestions/ideas how to deal with this? thanx and keep a good work nikola ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
