hi all,
it is so hot here, thinking is so hard and painful... are there cooler places on earth, where pd-dev people live?
...say, we have 150 classes using some amount of a common code. The size of this common code is rather small -- close to the average size of one class' code, or possibly 2 or 3 classes. Some of the options are:
1. All classes, and the common code, are statically linked in a one monolithic library.
2. Each class is kept as a separate external, linked with the common code (which means: there are as many common code copies, as the number of externals containing it, and loaded during a Pd session).
3. The common code is linked dynamically, and it has to be loaded prior to any of the classes (using an explicit -lib option).
4. Class names are prefixed with a library name, causing Pd to load the library with both the common code, and the classes (a feature not yet available, but already discussed on pd-list).
5. Like 4., but the library contains only the common code -- its setup routine has to know what particular class is demanded, and how to load it.
6. Each class uses a tiny ``stub code'', possibly a part of a future Pd api, which somehow checks if the common code is already loaded (currently it might be done by checking if something 'familiar' is bound to a particular symbol). If not, it loads the library, and obtains a set of pointers to the functions in the common code.
Are there other options? Which option is best?
Btw, perhaps due to my mind melting in the heat, I somehow tend to like the method 6 (if only it was a part of Pd api...)
Btw, options 4/5 cannot be applied in case of the cyclone library. They might be in case of xeq or vexing (currently both are using a modified version of the first method, while a cyclone user has to choose between options 1 and 2).
Btw, there are not as many classes in cyclone (yet:-?) just a bit over 40, but it keeps growing...
Krzysztof
On Fri, 21 Jun 2002, Krzysztof Czaja wrote:
hi all,
it is so hot here, thinking is so hard and painful... are there cooler places on earth, where pd-dev people live?
Barcelona, but with air conditioning :)
<snipped the 6 possibilities)
Btw, perhaps due to my mind melting in the heat, I somehow tend to like the method 6 (if only it was a part of Pd api...)
Depending on the shared code, I prefer version 2 and version 6, whereas version 6, the automatic loading of common code seems to be more generic, and therefore preferable. The only problem I see is, when distributing a patch with the used externals people might tend to forget to copy the common code part (external)
They ugly thing about version 6 is that you have to supply a stub for every external symbol, otherwise you probably would not be able to load the externals, ...
Guenter
Btw, options 4/5 cannot be applied in case of the cyclone library. They might be in case of xeq or vexing (currently both are using a modified version of the first method, while a cyclone user has to choose between options 1 and 2).
I dont really like the libraryname_externalname approach ..
Btw, there are not as many classes in cyclone (yet:-?) just a bit over 40, but it keeps growing...
Krzysztof
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
I dont really like the libraryname_externalname approach ..
yep, agree with that, because accepting there might be several externals with the same name is not a good principle : it would obfuscate a little bit more the art of making patches.
what we'd really need is a central naming system.
my 2 ç.
cheers,
sevy/yves
hi,
even if in a very vague way, I would like to defend the idea of introducing qualified class names into Pd, in some form or the other. First, I think people are generally used to this idea -- it is a natural way of thinking not only among c++ programmers and other freaks, but also among internet surfers (domain names).
Second, any central naming system would require establishing the central authority (or a voting system), and enforcement powers.
Third, if there are two externals providing the same feature, but differently, I would like both to have the same proper name, and either explicitly qualify in an object box, or globally declare that I am going to use one or the other (such declaration should be part of a patch, instead of a command line, though).
Krzysztof
ydegoyon@free.fr wrote: ...
I dont really like the libraryname_externalname approach ..
...
yep, agree with that, because accepting there might be several externals with the same name is not a good principle : it would obfuscate a little bit more the art of making patches.
what we'd really need is a central naming system.
-
g�nter geiger -
Krzysztof Czaja -
ydegoyon＠free.fr