hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
- namespaces: add the library name like library/object or library::object pros: - selectable at runtime - the patch will work exactly as you expect, since you see that object is from library cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
- startup flav: having another flag like -force library/object or -force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object - behaviour of the patch depends on startup flags (less portable)
- communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
- standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
hy
maybe, hm, clean up the codebase i.e. declare the most simple and robust the main one and throw out all other versions or at least rename the "thrown out" versions to something like "packagename_objectname".
i saw somebody already made the effort to convert . separators to _ ones.
this will also work with the single object <-> filesystem mapping.
a flag seems overcomplicated.
bst, opt
[Tim Blechmann]->[[PD-dev] nameclashes]->[04-11-04 23:19]
|hi all ... | |i'm currently thinking of a way to solve the nameclash problem (counter, |scale, prepend, gate...) | |here are some suggestions for a solution ... with some pros and cons: | |- namespaces: add the library name like library/object or | library::object | pros: - selectable at runtime | - the patch will work exactly as you expect, since you see that object | is from library | cons: - "/" is already used for the search path (shouldn't be a big | problem), "::" are two chars | - only works if an object is compiled as library ... if a | library is split to single externals (like the build system does) pd | is not aware of the library name | |- startup flav: having another flag like -force library/object or -force | library::object | pros: - easy to use | cons: - you can't use both library1::object and library2::object | - behaviour of the patch depends on startup flags (less portable) | |- communication: figure out, if the external name is already in use | pros: - no implementation effords | cons: - not really working (that's why we've got these problems *g*) | |- standard behaviour: if object1 is doing the same as object2, except | that it is missing one feature, add this feature to object1, if they | behave exactly the same, the nameclash isn't a problem any more ... | (escept for the waste of memory) | pros: - as above | cons: - as above | |personally i'd prefer the communication in combination with a startup |flag ... but i'm curious about other ideas or comments ... | |cheers ... tim | |
A namespace already exists if you are not using libraries. When objects are compiled into separate objects, then you can use directories to create namespaces. Abstractions work with this namespace as well. Check the attached set of patches to see it in action.
I was thinking of doing this with a couple of sets of objects for the distros. For example, having a folder called "cyclone" with all of the cyclone objects, which would only need to be used when porting a Max patch. The good objects from cyclone should be part of the main distro, like [prepend]. The other one I was thinking of making is "deprecated", for objects that aren't really useful anymore, but old patches might use them. For example, after I release the [hid] stuff, then the [linuxmouse], etc. stuff would be deprecated, since [hid] does everything they do, does it better, and does more.
.hc
(one included obj is compiled Darwin)
On Nov 4, 2004, at 3:39 PM, d.lj wrote:
hy
maybe, hm, clean up the codebase i.e. declare the most simple and robust the main one and throw out all other versions or at least rename the "thrown out" versions to something like "packagename_objectname".
i saw somebody already made the effort to convert . separators to _ ones.
this will also work with the single object <-> filesystem mapping.
a flag seems overcomplicated.
bst, opt
[Tim Blechmann]->[[PD-dev] nameclashes]->[04-11-04 23:19]
|hi all ... | |i'm currently thinking of a way to solve the nameclash problem (counter, |scale, prepend, gate...) | |here are some suggestions for a solution ... with some pros and cons: | |- namespaces: add the library name like library/object or | library::object | pros: - selectable at runtime | - the patch will work exactly as you expect, since you see that object | is from library | cons: - "/" is already used for the search path (shouldn't be a big | problem), "::" are two chars | - only works if an object is compiled as library ... if a | library is split to single externals (like the build system does) pd | is not aware of the library name | |- startup flav: having another flag like -force library/object or -force | library::object | pros: - easy to use | cons: - you can't use both library1::object and library2::object | - behaviour of the patch depends on startup flags (less portable) | |- communication: figure out, if the external name is already in use | pros: - no implementation effords | cons: - not really working (that's why we've got these problems *g*) | |- standard behaviour: if object1 is doing the same as object2, except | that it is missing one feature, add this feature to object1, if they | behave exactly the same, the nameclash isn't a problem any more ... | (escept for the waste of memory) | pros: - as above | cons: - as above | |personally i'd prefer the communication in combination with a startup |flag ... but i'm curious about other ideas or comments ... | |cheers ... tim | |
-- x Ð v . o 7 g GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
Well then, how about a combination of the "Geiger namespace" and a separator / for library/object resolution?
e.g. for an object that is explicitly called [cyclone/prepend] First try folder cyclone, external prepend Then try library cyclone, class prepend
grrrrT
----- Original Message ----- From: "Hans-Christoph Steiner" hans@eds.org To: "d.lj" jdl@xdv.org Cc: "pd-dev" pd-dev@iem.at; "Tim Blechmann" TimBlechmann@gmx.net Sent: Friday, November 05, 2004 6:11 PM Subject: Re: [PD-dev] nameclashes
A namespace already exists if you are not using libraries. When objects are compiled into separate objects, then you can use directories to create namespaces. Abstractions work with this namespace as well. Check the attached set of patches to see it in action.
I was thinking of doing this with a couple of sets of objects for the distros. For example, having a folder called "cyclone" with all of the cyclone objects, which would only need to be used when porting a Max patch. The good objects from cyclone should be part of the main distro, like [prepend]. The other one I was thinking of making is "deprecated", for objects that aren't really useful anymore, but old patches might use them. For example, after I release the [hid] stuff, then the [linuxmouse], etc. stuff would be deprecated, since [hid] does everything they do, does it better, and does more.
.hc
---------------------------------------------------------------------------- ----
(one included obj is compiled Darwin)
On Nov 4, 2004, at 3:39 PM, d.lj wrote:
hy
maybe, hm, clean up the codebase i.e. declare the most simple and robust the main one and throw out all other versions or at least rename the "thrown out" versions to something like "packagename_objectname".
i saw somebody already made the effort to convert . separators to _ ones.
this will also work with the single object <-> filesystem mapping.
a flag seems overcomplicated.
bst, opt
[Tim Blechmann]->[[PD-dev] nameclashes]->[04-11-04 23:19]
|hi all ... | |i'm currently thinking of a way to solve the nameclash problem (counter, |scale, prepend, gate...) | |here are some suggestions for a solution ... with some pros and cons: | |- namespaces: add the library name like library/object or | library::object | pros: - selectable at runtime | - the patch will work exactly as you expect, since you see that object | is from library | cons: - "/" is already used for the search path (shouldn't be a big | problem), "::" are two chars | - only works if an object is compiled as library ... if a | library is split to single externals (like the build system does) pd | is not aware of the library name | |- startup flav: having another flag like -force library/object or -force | library::object | pros: - easy to use | cons: - you can't use both library1::object and library2::object | - behaviour of the patch depends on startup flags (less portable) | |- communication: figure out, if the external name is already in use | pros: - no implementation effords | cons: - not really working (that's why we've got these problems *g*) | |- standard behaviour: if object1 is doing the same as object2, except | that it is missing one feature, add this feature to object1, if they | behave exactly the same, the nameclash isn't a problem any more ... | (escept for the waste of memory) | pros: - as above | cons: - as above | |personally i'd prefer the communication in combination with a startup |flag ... but i'm curious about other ideas or comments ... | |cheers ... tim | |
-- x Ð v . o 7 g GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
On Fri, 5 Nov 2004, Thomas Grill wrote:
Well then, how about a combination of the "Geiger namespace" and a separator / for library/object resolution?
I always thought that it is the most obvious thing to do. Second best after not doing anything. (and being fair to maxlib scale, which is called maxlib_scale too, as Olaf pointed out several times). Personally I go for the Barknecht solution (only implement things as externals if its not doable within Pd).
Guenter
e.g. for an object that is explicitly called [cyclone/prepend] First try folder cyclone, external prepend Then try library cyclone, class prepend
grrrrT
----- Original Message ----- From: "Hans-Christoph Steiner" hans@eds.org To: "d.lj" jdl@xdv.org Cc: "pd-dev" pd-dev@iem.at; "Tim Blechmann" TimBlechmann@gmx.net Sent: Friday, November 05, 2004 6:11 PM Subject: Re: [PD-dev] nameclashes
A namespace already exists if you are not using libraries. When objects are compiled into separate objects, then you can use directories to create namespaces. Abstractions work with this namespace as well. Check the attached set of patches to see it in action.
I was thinking of doing this with a couple of sets of objects for the distros. For example, having a folder called "cyclone" with all of the cyclone objects, which would only need to be used when porting a Max patch. The good objects from cyclone should be part of the main distro, like [prepend]. The other one I was thinking of making is "deprecated", for objects that aren't really useful anymore, but old patches might use them. For example, after I release the [hid] stuff, then the [linuxmouse], etc. stuff would be deprecated, since [hid] does everything they do, does it better, and does more.
.hc
(one included obj is compiled Darwin)
On Nov 4, 2004, at 3:39 PM, d.lj wrote:
hy
maybe, hm, clean up the codebase i.e. declare the most simple and robust the main one and throw out all other versions or at least rename the "thrown out" versions to something like "packagename_objectname".
i saw somebody already made the effort to convert . separators to _ ones.
this will also work with the single object <-> filesystem mapping.
a flag seems overcomplicated.
bst, opt
[Tim Blechmann]->[[PD-dev] nameclashes]->[04-11-04 23:19]
|hi all ... | |i'm currently thinking of a way to solve the nameclash problem (counter, |scale, prepend, gate...) | |here are some suggestions for a solution ... with some pros and cons: | |- namespaces: add the library name like library/object or | library::object | pros: - selectable at runtime | - the patch will work exactly as you expect, since you see that object | is from library | cons: - "/" is already used for the search path (shouldn't be a big | problem), "::" are two chars | - only works if an object is compiled as library ... if a | library is split to single externals (like the build system does) pd | is not aware of the library name | |- startup flav: having another flag like -force library/object or -force | library::object | pros: - easy to use | cons: - you can't use both library1::object and library2::object | - behaviour of the patch depends on startup flags (less portable) | |- communication: figure out, if the external name is already in use | pros: - no implementation effords | cons: - not really working (that's why we've got these problems *g*) | |- standard behaviour: if object1 is doing the same as object2, except | that it is missing one feature, add this feature to object1, if they | behave exactly the same, the nameclash isn't a problem any more ... | (escept for the waste of memory) | pros: - as above | cons: - as above | |personally i'd prefer the communication in combination with a startup |flag ... but i'm curious about other ideas or comments ... | |cheers ... tim | |
-- x � v . o 7 g GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
"The arc of history bends towards justice." Dr.Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
guenter geiger wrote:
I always thought that it is the most obvious thing to do. Second best after not doing anything. (and being fair to maxlib scale, which is called maxlib_scale too, as Olaf pointed out several times). Personally I go for the Barknecht solution (only implement things as externals if its not doable within Pd).
But the nameclash is still there if you implement 'scale' in Pd and call it 'scale' because that's what it does and what the Max object with the same name does.... Only that the user can rename it a bit more easily being an abstraction and not part of a library.
Pointing it out once again (after I said to myselfe not to jump in again this time...): in case every library would follow the 'libname_objectname' convention the nameclash problem would be solved. Maybe we'd also have to change two or three lines of code in Pd in order to issue a warning in case two libraries want to register (through class_addcreator())their 'maxlib_scale' and 'gem_scale' both as 'scale'.
Olaf
On Sat, 6 Nov 2004, Olaf Matthes wrote:
But the nameclash is still there if you implement 'scale' in Pd and call it 'scale' because that's what it does and what the Max object with the same name does.... Only that the user can rename it a bit more easily being an abstraction and not part of a library.
What you call "only" are actually the advantages that make it the better solution in case of name clashes. To change the name of an external you would need to know how to program, compile and have at least three (four with irix) compilers at hand, if you want to make your patches cross platform.
Although I am not coming from the Max world I see the reasoning behind Max compatibility, which is probably the best argument in favour of a real solution of the nameclashes problem. Unfortately it is not one that I can lead, because for me Max is as weird as Pd is to Max'ers, so I personally don't care.
Guenter
Hans-Christoph Steiner wrote:
A namespace already exists if you are not using libraries. When objects are compiled into separate objects, then you can use directories to create namespaces.
this is only half of the truth, as (in your example) [prepend] (without "namespace") will be used after using [cxc/prepend]. so you will have to use the namespace mechanism throughout your patches. (think compatibility)
maybe, hm, clean up the codebase i.e. declare the most simple and robust the main one and throw out all other versions or at least rename the "thrown out" versions to something like "packagename_objectname".
ahem, what are you talking about really ? the cvs is a collaborative code base where people can check in whatever they produce. as soon as anyone will start kicking out off/renaming objects within a library (e.g. zexy) i will consider this as censorship, being a hard violation of "free as in speech".
who will decide which "prepend" is the most simple and robust ? and who will pay for fixing up patches ?
i saw somebody already made the effort to convert . separators to _ ones.
this will also work with the single object <-> filesystem mapping.
a flag seems overcomplicated.
actually i think that flags would be great to acchieve compatibility between different solutions of the namespace-problems.
|- namespaces: add the library name like library/object or | library::object | pros: - selectable at runtime | - the patch will work exactly as you expect, since you see that object | is from library | cons: - "/" is already used for the search path (shouldn't be a big | problem), "::" are two chars | - only works if an object is compiled as library ... if a | library is split to single externals (like the build system does) pd | is not aware of the library name
actually i really think this would solve most of the problems: using both(!) directory structures and automatic library/object naming (from within pd - which i have suggested years ago).
no flames intended.
| |- startup flav: having another flag like -force library/object or -force | library::object | pros: - easy to use | cons: - you can't use both library1::object and library2::object | - behaviour of the patch depends on startup flags (less portable)
well, i guess the flag-syntax has to be carefully thought off to come over the cons.
|- standard behaviour: if object1 is doing the same as object2, except | that it is missing one feature, add this feature to object1, if they | behave exactly the same, the nameclash isn't a problem any more ... | (escept for the waste of memory) | pros: - as above | cons: - as above
i don't see how this should work. generic feature testing of objects ? i wonder, how you do that
mfg.a.sdr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
A namespace already exists if you are not using libraries. When objects are compiled into separate objects, then you can use directories to create namespaces.
this is only half of the truth, as (in your example) [prepend] (without "namespace") will be used after using [cxc/prepend].
with "used" i meant "reserved";
you cannot call the _setup() functions for 2 identically named objects, no matter where they are: e.g. cxc/prepend.pd_linux and iemlib/prepend.pd_linux still can not used in coexistance within one patch as both of them export "void prepend_setup(void)"; pd will only call one of these.
ahem, what are you talking about really ? the cvs is a collaborative code base where people can check in whatever they produce. as soon as anyone will start kicking out off/renaming objects within a library (e.g. zexy) i will consider this as censorship, being a hard violation of "free as in speech".
of course, the packager (or anyone) can use the code and modify it as they like. they are free to decide which packages go into the "official" (rather: semi-official) distribution of pd-externals, they can even modify the code of the externals that go in there (at the point when they go in there; e.g. at pre-compilation time) however, i am strongly against modifying the code-base of externals itself (this is: the code the external-collection is derived from)
who will decide which "prepend" is the most simple and robust ? and who will pay for fixing up patches ?
and since lots of people seem to prefer cxc.prepend over iemlib.prepend i would btw want to know why: to me it seems that iemlib.prepend has more features
mfg.a.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Mon, 8 Nov 2004, Johannes M Zmoelnig wrote:
you cannot call the _setup() functions for 2 identically named objects, no matter where they are: e.g. cxc/prepend.pd_linux and iemlib/prepend.pd_linux still can not used in coexistance within one patch as both of them export "void prepend_setup(void)"; pd will only call one of these.
Thats not true, because pd calls explicitely the setup function of the object it has just loaded. (See attached test)
The only quirks with the method is the help file loading (as fbar demonstrated at the pd-conv). I think this could be fixed.
Guenter
ahem, what are you talking about really ? the cvs is a collaborative code base where people can check in whatever they produce. as soon as anyone will start kicking out off/renaming objects within a library (e.g. zexy) i will consider this as censorship, being a hard violation of "free as in speech".
of course, the packager (or anyone) can use the code and modify it as they like. they are free to decide which packages go into the "official" (rather: semi-official) distribution of pd-externals, they can even modify the code of the externals that go in there (at the point when they go in there; e.g. at pre-compilation time) however, i am strongly against modifying the code-base of externals itself (this is: the code the external-collection is derived from)
who will decide which "prepend" is the most simple and robust ? and who will pay for fixing up patches ?
and since lots of people seem to prefer cxc.prepend over iemlib.prepend i would btw want to know why: to me it seems that iemlib.prepend has more features
mfg.a.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
guenter geiger wrote:
On Mon, 8 Nov 2004, Johannes M Zmoelnig wrote:
Thats not true, because pd calls explicitely the setup function of the object it has just loaded. (See attached test)
that's great.
The only quirks with the method is the help file loading (as fbar demonstrated at the pd-conv). I think this could be fixed.
i am always confused by people telling me that the help-system will not properly work. thomas keeps insisting that it does not work the way he expects it too. (i understand his points) unfortunately i cannot remember exactly what frank's problems were.
what i have just tested (0.37.2 and 0.38test4) was to create help-patches for both obj1's (help-obj1.pd) and put them beside the obj1.pd_linux's
works great and as expected. (of course there are problems with the helppath and standard search-paths: but things should not be in there anyhow, as there will be a file-collision)
mfg.asd.r IOhannes
On Mon, 8 Nov 2004, Johannes M Zmoelnig wrote:
The only quirks with the method is the help file loading (as fbar demonstrated at the pd-conv). I think this could be fixed.
...
unfortunately i cannot remember exactly what frank's problems were.
Me neither :), just remembered that there was something. Maybe Frank can elaborate on that.
what i have just tested (0.37.2 and 0.38test4) was to create help-patches for both obj1's (help-obj1.pd) and put them beside the obj1.pd_linux's
works great and as expected.
Yes, works here too. I tested the other case, calling the help files obj1-help.pd. this way the help sorts beside the object. I am not sure which way is clearer, it is important though that all help files are the same in one directory.
Guenter
(of course there are problems with the helppath and standard search-paths: but things should not be in there anyhow, as there will be a file-collision)
So are we in agreement that the directory-based namespace is the way to go, as long as the *-help.pd patch problems are fixed? I would love to put this matter to rest.
.hc
On Nov 8, 2004, at 10:22 AM, guenter geiger wrote:
On Mon, 8 Nov 2004, Johannes M Zmoelnig wrote:
you cannot call the _setup() functions for 2 identically named objects, no matter where they are: e.g. cxc/prepend.pd_linux and iemlib/prepend.pd_linux still can not used in coexistance within one patch as both of them export "void prepend_setup(void)"; pd will only call one of these.
Thats not true, because pd calls explicitely the setup function of the object it has just loaded. (See attached test)
The only quirks with the method is the help file loading (as fbar demonstrated at the pd-conv). I think this could be fixed.
Guenter
ahem, what are you talking about really ? the cvs is a collaborative code base where people can check in whatever they produce. as soon as anyone will start kicking out off/renaming objects within a library (e.g. zexy) i will consider this as censorship, being a hard violation of "free as in speech".
of course, the packager (or anyone) can use the code and modify it as they like. they are free to decide which packages go into the "official" (rather: semi-official) distribution of pd-externals, they can even modify the code of the externals that go in there (at the point when they go in there; e.g. at pre-compilation time) however, i am strongly against modifying the code-base of externals itself (this is: the code the external-collection is derived from)
who will decide which "prepend" is the most simple and robust ? and who will pay for fixing up patches ?
and since lots of people seem to prefer cxc.prepend over iemlib.prepend i would btw want to know why: to me it seems that iemlib.prepend has more features
mfg.a.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
<namespace.tgz>
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
So are we in agreement that the directory-based namespace is the way to go, as long as the *-help.pd patch problems are fixed?
right. and imitate that namespace for libraries.
but what about objects that include "/" (it is not the most uncommon character i can think of) (but of course the only one that stays compatible with directories)
I would love to put this matter to rest.
me too. but still i can't remember what the "*-help.pd patch problems" are. i like it, that there are both help-*.pd and *-help.pd for instance with Gem i bundle all the help-patches in another directory (there are really a lot of them) and i like it that they are just "help-Gem/gemwin.pd" instead of "Gem/gemwin-help.pd" (this made it very easy to port from the pre-0.37 aera: just renaming a single directory instead of all objects.)
mfg.a.sdr IOhannes
Hans-Christoph Steiner wrote:
So are we in agreement that the directory-based namespace is the way to go, as long as the *-help.pd patch problems are fixed?
right. and imitate that namespace for libraries.
Yes i am. Uh, sorry, i hope _we_ are.
but what about objects that include "/" (it is not the most uncommon character i can think of)
i think one must have really bad luck if that object is named like a folder/object combination.... then it's a case of need for user communication ;-)
best greetings, Thomas
On Nov 8, 2004, at 4:25 PM, Thomas Grill wrote:
Hans-Christoph Steiner wrote:
So are we in agreement that the directory-based namespace is the way to go, as long as the *-help.pd patch problems are fixed?
right. and imitate that namespace for libraries.
Yes i am. Uh, sorry, i hope _we_ are.
but what about objects that include "/" (it is not the most uncommon character i can think of)
i think one must have really bad luck if that object is named like a folder/object combination.... then it's a case of need for user communication ;-)
I would have to strongly agree with that. Also, does anyone know of any existing objects that have a "/" in the name?
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Nov 8, 2004, at 4:13 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So are we in agreement that the directory-based namespace is the way to go, as long as the *-help.pd patch problems are fixed?
right. and imitate that namespace for libraries.
but what about objects that include "/" (it is not the most uncommon character i can think of) (but of course the only one that stays compatible with directories)
I would love to put this matter to rest.
me too. but still i can't remember what the "*-help.pd patch problems" are. i like it, that there are both help-*.pd and *-help.pd for instance with Gem i bundle all the help-patches in another directory (there are really a lot of them) and i like it that they are just "help-Gem/gemwin.pd" instead of "Gem/gemwin-help.pd" (this made it very easy to port from the pre-0.37 aera: just renaming a single directory instead of all objects.)
Actually, I think that we should try to stick to the "*-help.pd" as the standard because it allows you to easily alphabetize the help files, and also scan the filenames. With the hierarchical Help menu that I made, this makes a huge difference. But it would be fine to use the "help-*" format with a directory, like you did with Gem, since the individual help files would start with the name, rather than "help-"
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
I think communication is necessary anyways, but a technical solution would allow pd to scale to a larger community. namespaces also allow names to be more easy to understand. A startup flag would be very nice to have now though, it would allow using all of the libraries
2€¢
. g
El 04/11/2004, a las 23:19, Tim Blechmann escribió:
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or
-force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi, i'd prefer the namespace approach with some separation character that has a clear meaning and isn't otherwise widely used. e.g. / | _would be ok. Communication is always good but shouldn't be a must. There may be people contributing things that aren't good at it. I don't like the flag approach very much since it's more a private "fix", not a general solution.
best greetings. Thomas
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: pd-dev@iem.at Cc: pd-list@iem.at Sent: Thursday, November 04, 2004 11:19 PM Subject: [PD-dev] nameclashes
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
the patch will work exactly as you expect, since you see that object is from library cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or -force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
i'd prefer the namespace approach with some separation character that has a clear meaning and isn't otherwise widely used. e.g. / | _would be ok. Communication is always good but shouldn't be a must. There may
a namespace would definitely be a clean approach ... but someone will have to rewrite the build system ... the fact that single externals from the build system will cause problems ... there is also the problem with cyclone, since you don't know if cyclone is one cyclone library, or split to hammer, sickle and dummy ...
cheers ... tim
I know that the pd fileformat does not allow comments or headers. But I was thinking of a declaration in a header like "from iemlib import gate" and all gates in the patch would be iem ones. I dont like the idea of typing iem::gate all the time and I think it may be easier to define the object at the beginning of the pd file than replacing the text of every object. And you could use different library objects in different abstractions. Apart from that, I think, communication is best. Is there a list of all problem objects until now? i think also the capital letter-cyclone objects are problematic, because of the help-patches, which are not displayed correctly under windows.
Append (pd native, cyclone) Clip (pd native, cyclone) Line~ (pd native, cyclone) Snapshot~ (pd native, cyclone) Scope~ (pd native, cyclone) gate (iemlib, cyclone) prepend (iemlib, cyclone) split (iemlib, cyclone) and I think there are some cyclone dummies, which will be objects in the future (?). like sfplay~.
btw. arent there also problems with abstraction nameclashes?
marius.
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: pd-dev@iem.at Cc: pd-list@iem.at Sent: Thursday, November 04, 2004 11:19 PM Subject: [PD] nameclashes
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
- namespaces: add the library name like library/object or
library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
- startup flav: having another flag like -force library/object or -force
library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use
pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
- standard behaviour: if object1 is doing the same as object2, except
that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
I have a hard time myself with the library thing...I usually use only one or two objects from a library. Would it not be preferable to have the individual objects from a library inside their own folder nested inside the externs folder? I would also feel a lot better if there was a mechanism to register every object with a unique name, so that a developer who wanted to publish their object would register it in the database the same way you choose an email address: if the name is already in use, try again with another name. The names database could reside within the cvs repository. So you would have counter, counter1, counter2, ...
.02CAD Martin
Tim Blechmann wrote:
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or -force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
- behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
Tim Blechmann wrote:
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
- namespaces: add the library name like library/object or
library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
couldnt you extend the object definition to include a namespace definition?
- startup flav: having another flag like -force library/object or -force
library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use
pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
- standard behaviour: if object1 is doing the same as object2, except
that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
couldnt you extend the object definition to include a namespace definition?
possible ... but with keeping backwards compatibility ... possibly not ... and if the people producing the nameclashes don't solve them by talking and removing their objects from their libraries, how to convince them to add a namespace definition ...
günter had an interesting approach at the coding sprint, that might be used for that ... but still, for a solution, we shouldn't try to extend the pd api...
cheers ... tim
-
0001 -
d.lj -
guenter geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
Josh Steiner -
Marius Schebella -
Martin Peach -
Olaf Matthes -
Thomas Grill -
Tim Blechmann