Re: [PD] pd extended development
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: hm...does that mean, when there is: extra/zexy/zexy.pd_linux [zexy/abs~] could be instantiated? i tried and it didn't work. i must be misunderstanding you. for bundles, even if there is a directory prefix, [mylib/myabs] doesn't work. Yes, you're right, I wasn't thinking of this actually. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. This problem is not related to multiclass externals (i.e. bundles) at all: All patches that use a directory prefix to specify object names break as soon as that directory name isn't available because it doesn't exist. As pd-vanilla doesn't have most of the subdirectories in extra, that pd-extended does, and as there is no common installer just for externals yet, people who install their own externals may have them in whatever directory. It all depends on their paths settings. Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote: In the end we may be back at square one: a flatspace with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again. Or what am I missing? ;) The flatspace model breaks down when you start adding libraries to Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues. I should have written best of the (un)pack objectclasses in a single *namespace*, not a directory. But that's how pd-extended is setup and used in practice ATM. If we look at other programming languages, we can see that namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as well. Me neither. I just see a discrepancy between theory and real life and am searching for the reason. ;) Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Roman Haefeli wrote: On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. at the beginning of this discussion (probably 2002 or so; i have no idea) i posted a diff for Pd that would allow this: using [mylib/myclass] after loading the multiclass-library mylib containing the class myclass. the patch never got accepted (iirc, the arguing was that nameclashes have to be solved on a social level rather than on a technical one) i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported. i think generally better would be to drop external support entirely from Pd; this would reduce nameclashes a lot; i don't know how to solve nameclashes of abstractions (without dropping abstraction support), but one idea would be to just not distribute any collections (like Pd-extended) anymore, and make the problem a _private_ one. but i think we all agree that this is not going to happen. anyhow, feel free to make Gem a single object per file library :-) fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
IOhannes m zmoelnig wrote: Roman Haefeli wrote: On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. at the beginning of this discussion (probably 2002 or so; i have no idea) i posted a diff for Pd that would allow this: using [mylib/myclass] after loading the multiclass-library mylib containing the class myclass. the patch never got accepted (iirc, the arguing was that nameclashes have to be solved on a social level rather than on a technical one) and obviously it has the same problems as frank has already mentioned: if the library get's renamed, you cannot access the object anymore. iirc, there have been more library renames than object-renames in the past. fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
On Thu, 2008-04-17 at 09:48 +0200, IOhannes m zmoelnig wrote: Roman Haefeli wrote: On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. at the beginning of this discussion (probably 2002 or so; i have no idea) i posted a diff for Pd that would allow this: using [mylib/myclass] after loading the multiclass-library mylib containing the class myclass. the patch never got accepted (iirc, the arguing was that nameclashes have to be solved on a social level rather than on a technical one) if i would have known, that this would be possible and that a patch is _already_ written, i probably wouldn't have suggested to drop the multiclass external format. right now i think, your (obviously old) idea seems to be a very good solution. too bad, that it didn't make it into miller's pd. anyhow, feel free to make Gem a single object per file library :-) gotcha. i haven't thought about that. 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] pd extended development
On Wed, 2008-04-16 at 22:54 -0400, marius schebella wrote: Roman Haefeli wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. seriously??? I did not know that. that actually changes a lot. it basically means back to start... pd-extended: extra/zexy/abs~.pd_linux: 'abs~' can be called by [zexy/abs~] pd-vanilla: extra/zexy.pd_linux: [zexy/abs~] doesn't work not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason. i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported. what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries [mux] is an alias od [multiplex]. currently [mux] can only be instantiated when a [multiplex] has been instantiated before. which means that aliases are not fully supported by the libdir format. sorry for causing confusion with new terms. when saying 'multiple-class-per-external format' i was referring to the bundled libraries. let's stick with the latter. from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches? it should be 100% compatible and should add no or only the very minimum necessary overhead. I am willing to put a lot of effort into this being realized. cool to hear. here a list of a few issues regarding portability between extended and vanilla, that i encountered while using netpd: - objects, that use the alias name ([mux], [l2s], [s2l] etc.) cannot often not be created, when a patch is loaded on pd-extended. possible work-arounds: - avoid alias-names when making a netpd-patch(my recommended solution) - loading a patch which calls all objects with aliases by their original name, so that the aliasses work afterwards - certain classes cause troubles because they contain characters, that aren't supported by the filesystem (is the filesystem the real reason?) however, certain classes, such as [~] and [~] cannot be used at all in pd-extended. my recommended workaround: - avoid such classes in netpd-patches - since it cannot be expected, that every pd-user uses the same configuration (i.e. pd-settings file/registry), it seemed reasonable to me, that netpd loads dependencies by itself. the introduction of [declare] looked very promising at first glance, because it should make it possible, that each patch can load its own dependencies independently from a specific configuration file. currently there are still some culprits with that approach: - [declare] is partially broken (undecided behaviour inside abstractions) - i have to use a different [declare] for pd-extended than for pd- vanilla: [declare -stdlib zexy] vs. [declare -stdpath zexy] - some libraries are called differently on both: iemlib vs. iemlib1, iemlib2, iem_t3_lib, iemabs workarounds: none if a netpd-patch developer wants to make her patch work on all pd distros, she needs to be aware of the different layouts, which is an unnecessary overhead, i believe. replace 'netpd' by any project, that focusses on portability. 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] pd extended development
On Thu, 2008-04-17 at 08:26 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. This problem is not related to multiclass externals (i.e. bundles) at all: All patches that use a directory prefix to specify object names break as soon as that directory name isn't available because it doesn't exist. hm...does that mean, when there is: extra/zexy/zexy.pd_linux [zexy/abs~] could be instantiated? i tried and it didn't work. i must be misunderstanding you. for bundles, even if there is a directory prefix, [mylib/myabs] doesn't work. As pd-vanilla doesn't have most of the subdirectories in extra, that pd-extended does, and as there is no common installer just for externals yet, people who install their own externals may have them in whatever directory. It all depends on their paths settings. i don't see an advantage in the user being responsible where to put dependencies. why cannot we come up with a standard? how will it be possible to create portable patches independently from some user-edited configuration file? as others already pointed out, other programming languages use standards and a script/programm will run on every system, that has the dependencies installed. there is no need for the user to tweak the configuration or adapt the script. don't we want to get at this point as well? 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] pd extended development
On Apr 17, 2008, at 2:31 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote: In the end we may be back at square one: a flatspace with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again. Or what am I missing? ;) The flatspace model breaks down when you start adding libraries to Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues. I should have written best of the (un)pack objectclasses in a single *namespace*, not a directory. But that's how pd-extended is setup and used in practice ATM. If we look at other programming languages, we can see that namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as well. Me neither. I just see a discrepancy between theory and real life and am searching for the reason. ;) This is the reason AFAIK: The namespace stuff isn't fully implemented, plus people are used to working in a single namespace, so first things need to be fixed, then we need to work out a transistion plan. .hc Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hallo, marius schebella hat gesagt: // marius schebella wrote: Hans-Christoph Steiner wrote: Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine. is there a page where this idea is documented? how is it supposed to work in the future? I still don't know. will I have to include declare in every patch that I write??? [declare] currently is rather useless. You can load a binary library with [declare], but AFAIK Pd-extended doesn't have any libraries except Gem. [declare -path] acts funny, or rather, it's unclear whether it should act differently when used in an abstraction instance compared to being used standalone. Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries. OTOH the names of the directories in CVS have been chosen to be the names of the prefixes, which is something, several developers didn't like, but some way to name the subdires had to be chosen of course. Example: Martin doesn't like [mrpeach/packOSC], I don't like the redundant [list-abs/list-abs] etc. But the real problem is this: Advertising the libdir directories as namespaces has created hundreds of possible new object names. Of course people use these new names, and now backwards compatibility has to take these new names into account. Any pd-condensed which I recently invented as a joke would still need to support these new names (or just ignore them). And if some future, cleaned up version of pd-extended includes [abs~] globally, it also will need to offer support for [zexy/abs~], [creb/abs~], [markex/abs~] and [flatspace/abs~] to not break patches written in the advertised style. Not very beautiful. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: Hans-Christoph Steiner wrote: Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine. is there a page where this idea is documented? how is it supposed to work in the future? I still don't know. will I have to include declare in every patch that I write??? [declare] currently is rather useless. You can load a binary library with [declare], but AFAIK Pd-extended doesn't have any libraries except Gem. [declare -path] acts funny, or rather, it's unclear whether it should act differently when used in an abstraction instance compared to being used standalone. there are some other libraries that are still bundled binaries, pdp for example. I think declare -lib works relative to the abstraction. but you also have to possibility to use -stdlib which will be relative to pd or use absolute paths. Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries. I totally agree with you that preloading unnecessary libraries is a waste of memory. there are only two cases where you really have to do that: bundled libraries and objects that have abbreviated names. if you don't preload them, they will not work. with the rest of the objectclasses I think it should be enough to load the path, which would only load the classes into memory, after you created an object (and then only load this single object. correct? still don't know what to do about abbreviated objectnames. maybe the meta file can handle this? marius. OTOH the names of the directories in CVS have been chosen to be the names of the prefixes, which is something, several developers didn't like, but some way to name the subdires had to be chosen of course. Example: Martin doesn't like [mrpeach/packOSC], I don't like the redundant [list-abs/list-abs] etc. But the real problem is this: Advertising the libdir directories as namespaces has created hundreds of possible new object names. Of course people use these new names, and now backwards compatibility has to take these new names into account. Any pd-condensed which I recently invented as a joke would still need to support these new names (or just ignore them). And if some future, cleaned up version of pd-extended includes [abs~] globally, it also will need to offer support for [zexy/abs~], [creb/abs~], [markex/abs~] and [flatspace/abs~] to not break patches written in the advertised style. Not very beautiful. Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hallo, marius schebella hat gesagt: // marius schebella wrote: Frank Barknecht wrote: Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries. I totally agree with you that preloading unnecessary libraries is a waste of memory. Actually I wasn't referring to preloading and I don't care about the memory waste (which is minor), but to the virtual library loading that pd-extended does with its libdir loading or path settings. IIRC that was, what you and many others were complaing about when it was broken on their systemsa. Most of the libraries in pd-extended are built as single externals, and for abstraction libraries like list-abs bundles aren't possible anyway. Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. (and pd does not look into the sub-directories of extra). and there is no way to add the paths except writing them into the plist manually. marius. Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: Frank Barknecht wrote: Directory prefixes like [zexy/abs~] kind of solve the problem. The problem is, that nobody likes them. (Though probably Hans does;) E.g. I remember that you were complaining quite loudly when the new pd-extended version didn't preload many libraries and libdirs. But of course preloading libraries makes the [zexy/abs~] approach pointless, except for objects in private or rarely used libraries. I totally agree with you that preloading unnecessary libraries is a waste of memory. Actually I wasn't referring to preloading and I don't care about the memory waste (which is minor), but to the virtual library loading that pd-extended does with its libdir loading or path settings. IIRC that was, what you and many others were complaing about when it was broken on their systemsa. Most of the libraries in pd-extended are built as single externals, and for abstraction libraries like list-abs bundles aren't possible anyway. Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hallo, marius schebella hat gesagt: // marius schebella wrote: sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk). the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. OTOH many also want every object in CVS to be available in pd-extended. The net result then is a lot of nameclashes: You just cannot get zexy's urn and maxlib's urn loaded into the global namespace at the same time without a clash. (Actually you cannot even load them at the same time at all, IIR.) Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk). the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. am I wrong? marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hallo, marius schebella hat gesagt: // marius schebella wrote: Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk). the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do. In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable. In the end we may be back at square one: a flatspace with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again. Or what am I missing? ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Frank Barknecht wrote: the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? all people interested in pd-extended would have influence on the order, like hans, you, me... we would provide a list with all nameclashes inherent in pd-extended and how to access the non default classes. (at least that is my intention.) As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. additionaly we could have a printout everytime you try to load a class that is in a nameclash with another one the sonsole, but that would be annoying too, no? Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. yes, but I think it *should* be set out of the box. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do. noone knows which objectclasses are loaded by default, and nobody ever decided this, everything is arbitrary, but I have not given up the hope that this will change soon. if you have this published list of objects that pd-extended uses and want to write your own abstractions, then you would have a good reference of taken names, and this will prevent further nameclashes in the future. more people would focus on *one* list of available pd objects and name their abstractions in reference to the already existing ones. In the long run, this process should become a bit more organized my words... it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable. how many nameclashes do we have? 20, 30? how many libraries are affected 5? yea, that's what has to be done. the situation right now is worse than any solution with a default class. because an object like urn is already problematic. a mentored quasi-official pd-objectclass list would at least guarantee future compatibility for the one class that would be considered the default. and the other urns would have to be explicitely called with notdefault/urn. but that is exactly what needs to be done to prevent nameclashes. if you don't do it, then you never will have compatibility... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk). the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do. In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable. In the end we may be back at square one: a flatspace with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again. Or what am I missing? ;) The flatspace model breaks down when you start adding libraries to Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues. If we look at other programming languages, we can see that namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as well. .hc 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] pd extended development
On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote: how many nameclashes do we have? 20, 30? how many libraries are affected 5? yea, that's what has to be done. the situation right now is worse than any solution with a default class. because an object like urn is already problematic. a mentored quasi-official pd-objectclass list would at least guarantee future compatibility for the one class that would be considered the default. and the other urns would have to be explicitely called with notdefault/urn. but that is exactly what needs to be done to prevent nameclashes. if you don't do it, then you never will have compatibility... how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason. i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported. from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches? 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] pd extended development
Python's namespacing has these features that I haven't seen discussed yet: There are three common ways to import: import list-abs, which just makes list-abs available for use, but you still need to type list-abs.list-map (the Python equivalent of [list-abs/list-map]). [1] from list-abs import list-map, makes it possible to just type list-map. And finally from list-abs import *, makes it possible to type any of the functions in list-abs without a prefix. The 3rd option is widely discouraged, because it makes it very unclear where a function comes from, or which one is in use. I greatly appreciate this arrangement, and I think it would be wise to follow. A 4th feature that reduces verbosity is the ability to write import list-abs as l. And of course once things actually work, [list-map] could be renamed to just map to give [l/map], which I think is great. Cheers Luke On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk). the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do. In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about single objects. Maybe zexy's [abs~] is better, while [urn] in Cyclone is preferable. In the end we may be back at square one: a flatspace with the selected best of the (un)pack objectclasses in a single directory. No problems with path settings, all is fine again. Or what am I missing? ;) The flatspace model breaks down when you start adding libraries to Pd- extended. Then you can have nameclashes again. Say someone writes their own library with an [urn], then what happens? At best, confusion ensues. If we look at other programming languages, we can see that namespaces are a very common solution to this problem (C++, Tcl, python, Java, Smalltalk, etc). I see no reason why it wouldn't work for Pd as well. .hc
Re: [PD] pd extended development
On Apr 16, 2008, at 6:27 PM, Luke Iannini (pd) wrote: Python's namespacing has these features that I haven't seen discussed yet: There are three common ways to import: import list-abs, which just makes list-abs available for use, but you still need to type list-abs.list-map (the Python equivalent of [list-abs/list-map]). [1] from list-abs import list-map, makes it possible to just type list-map. And finally from list-abs import *, makes it possible to type any of the functions in list-abs without a prefix. The 3rd option is widely discouraged, because it makes it very unclear where a function comes from, or which one is in use. I greatly appreciate this arrangement, and I think it would be wise to follow. Those sound reasonable, but a lot more work to implement. For the next release, there should be - [list-abs/list-split] (like python without needed the import list- abs statement). I am not sure I see the reason to have to import a lib in order to use it with the lib prefix. - [import list-abs] which is the same as from list-abs import *, for better or worse. It's what Pd people are used to, so... - I think it should be possible to do [import list-abs/list-split] but I haven't looked at it too much yet. A 4th feature that reduces verbosity is the ability to write import list-abs as l. And of course once things actually work, [list-map] could be renamed to just map to give [l/map], which I think is great. This sounds like a write-only feature, it makes the code much harder for others to read. If you don't recognize a library name, then you have to check both whether it is an alias, and if it is a library. From what I have seen, aliases cause more harm than good in programming languages. .hc Cheers Luke On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: sorry, I still don't know exactly what you mean. I think it is the only solution to keep libraries in subfolders if we want to solve nameclashes. but even if in subfolders, they should be accessible as list-abs and not list-abs/list-abs. Huh? Nameclashes have nothing to do with subfolders per se. A nameclash is, when two objects have the same name registered in Pd but act differently. Folders are a way to organize files in a filesystem (harddisk). the thing that I was complaining so loudly is that pd-extended ships all these libraries but does not add the paths. Yes, that's exactly what I mean: Many people would like every objectclass to be global. but that is not a problem for pd-extended users (and I want to solve the pd-extended problems here), as long as you can overrule the global namespace with a local namespace. Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? As pd-extended by popular demand (and for practical reasons) is configured to allow access to one of the [urn]s out of the box, I believe not many people are actually using the names [zexy/urn] or [maxlib/urn] or [cyclone/urn]. But all of these behave differently. So we have a hidden nameclash if you try to use a patch that assumes [urn] to be the one from the library, pd-extended loads as the second one. Now IIRC Hans' goal is to not load any library or set any path out of the box, so that all names would have to be qualified with directory prefixes or [declare]d. But when this behavious accidentally came into effect because of the change in plist-location on OS-X, people complained about missing objects and that their patches were broken with the new pd-extended. Note that I don't want to rate if they complained for a good reason, I just want to point to a problem. pd-extended would provide a default object for every nameclash. If you have old patches that were using objects, that are not the default in pd-extended you would have to add a declare to your patch. or explicitely call them as mynondefaultlib/abs~. So you see: pd-extended selected a certain set of externals to be the default set of available objectclasses in pd-extended. I don't know how it was decided which libs should be these defaults, I don't even know which ones are the defaults. Probably Hans just chose some popular ones, which is a sensible thing to do. In the long run, this process should become a bit more organized and it especially should not be handled along library/author borders. For example, I think, zexy (rightfully) has a high loading priority, because it's one of the oldest and most widely used library. But Cyclone also deserves a high priority because it's generally Max-compatible. OTOH zexy is older. What to do? If we only priorize complete libraries, we're not able to make finely grained decisions about
Re: [PD] pd extended development
Roman Haefeli wrote: how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals. seriously??? I did not know that. that actually changes a lot. it basically means back to start... not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason. i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported. what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches? it should be 100% compatible and should add no or only the very minimum necessary overhead. I am willing to put a lot of effort into this being realized. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hans-Christoph Steiner wrote: - I think it should be possible to do [import list-abs/list-split] but I haven't looked at it too much yet. this feature is afaik broken, because if you do [import list-abs/list-split] then pd does not find [list-abs/list-split anymore (only [list=split]. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine. Basically up until recently, I was pursing Pd-extended as a proof of concept for building libraries as standalone binaries in directories instead of all compiled into one binary. I think that clearly works, so now it is time to clean things up into a coherent package. I document what I can here: http://puredata.info/docs/developer/ I don't really know what else needs to be documented. One way to find out is when people start to contribute, then they find shortcomings that we can fill in. .hc On Apr 15, 2008, at 2:15 PM, marius schebella wrote: Hi, is it true, that only hans is working on the pd-extended releases? are there other maintainers? I got the impression in the past that pd-extended is very useful (and I personally use it a lot), but development for it is also very cryptical and almost hidden like a secret. and often things are implemented that seem to be good ideas, but do not really work (like the whole path/import stuff). maybe hans, if you could provide more information and documentation about pd-extended and how the whole integration of libraries works then more people would be able to help you and development would be more consistent. what is the direction that you want to go? for me pd-extended is the attempt to create a pd distribution that includes as many as possible external libraries in addition to pd vanilla. I love most of the things in pd-ext, although there is still a lot of work that needs to be done... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended development
Hans-Christoph Steiner wrote: Lots of people contribute, but I am the person who manages the releases. Any help is welcome. The path/import/declare stuff is currently a half-complete effort of Miller's and mine. is there a page where this idea is documented? how is it supposed to work in the future? I still don't know. will I have to include declare in every patch that I write??? Basically up until recently, I was pursing Pd-extended as a proof of concept for building libraries as standalone binaries in directories instead of all compiled into one binary. I think that clearly works, so now it is time to clean things up into a coherent package. It doesn't work for abbreviations. I document what I can here: http://puredata.info/docs/developer/ thanks. I don't really know what else needs to be documented. One way to find out is when people start to contribute, then they find shortcomings that we can fill in. well, it would be nice if there was some documentation of which libraries and objects are included, how to handle all the path problems, which paths and libs are loaded by default how to load the other libs/externals. filessystem layout, platform compatibility, which libraries do *not* work on which os. what additional features you added to pd-extended (advanced helpmenu, advanced tcltk interface (colorscheme...), differences in shortcuts, closing, . all that. marius. .hc On Apr 15, 2008, at 2:15 PM, marius schebella wrote: Hi, is it true, that only hans is working on the pd-extended releases? are there other maintainers? I got the impression in the past that pd-extended is very useful (and I personally use it a lot), but development for it is also very cryptical and almost hidden like a secret. and often things are implemented that seem to be good ideas, but do not really work (like the whole path/import stuff). maybe hans, if you could provide more information and documentation about pd-extended and how the whole integration of libraries works then more people would be able to help you and development would be more consistent. what is the direction that you want to go? for me pd-extended is the attempt to create a pd distribution that includes as many as possible external libraries in addition to pd vanilla. I love most of the things in pd-ext, although there is still a lot of work that needs to be done... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
