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
uuuuuhhhhhh... 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
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
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__
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
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
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
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.
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.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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.
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.
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.
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.
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
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
On Apr 8, 2008, at 9:12 AM, Roman Haefeli wrote:
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.........
Constructive words are good, but without action, they are no more
than a way to idle away time. It is time spent with no time gained
due to a better implementation. There is only so much I can do, the
more contributions we have, the better we will all be.
.hc
"[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
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
marius schebella -
niko -
Roman Haefeli