Dear list,
I installed gem 0.87, and noticed that there are some objects that are repeated from other libraries, specifically average and scale (motex), change (default), abs~ (zexy 1.1).
Are the objects from gem identical to the other ones? (at least they seem) If so, is there any advantage in using one instead of the other?
To decide which library to use, pd works with the libraries first loaded, so I put gem as the last library on my list.
João Miguel Pais
João M Pais wrote:
Dear list,
hi !
I installed gem 0.87, and noticed that there are some objects that are repeated from other libraries, specifically average and scale (motex), change (default), abs~ (zexy 1.1).
Are the objects from gem identical to the other ones? (at least they
seem)
If so, is there any advantage in using one instead of the other?
Gem was merged with markEX some years ago. while Gem provided the graphics-engine, markEX was a useful collection of externals, like [change] and [abs~]
some of these (markEX) externals were so useful, they made it into the main-distribution, noteable [change]. others were not SO useful, but still needed by lot's of people, who didn't want to include the huge Gem-library all the time they needed (say: ) basic signal operations, like [abs~]. so they included it in their private libraries. [abs~] from zexy is an example for this.
[average] is a similar case. while i do not know, what is the behaviour in the motex-version, i do know, that there is the [mavg] (Moving AVeraGe) object in zexy, which does quite the same (although it is a bit more dynamic).
that's the good news (name clashes with objects that do the same) now the bad news:
[scale] is a basic Gem-object, that allows you to scale (sic!) a Gem-geo (like a model, cube, square, etc.) i am sure no other external/library (like motex) will be able to provide the same functionality. (i am sure other libraries could be able (like gemee) but i leave it like this)
however, we have a problem (which was discussed before) in terms of fairness we have to apply a "first comes, first served" rule on name-clashes. Since Gem (and the old markEX) were the very first (public available) libraries (as is see it, having played with pd since about 0.20), and Gem is really a world of it's own nobody should use object-names that have been introduced by Gem long ago for different functionality (which is *very* likely in the case of Gem), however unappropriate (or general) the name seems for the Gem-functionality and however fitting it would appear for the new function.
to avoid nameclashes with (at least) Gem (and a few other libraries) we could either restart the discussion on namespaces in pd or look at the pure-data-base @ http://pd.iem.at/pdb Since the number of libraries have been exploding in the last year, this data-base is kind of un-maintainable for a single person (like me - at least at my current working-conditions ;-), and therefore should be made writeable by the community (which i would have to do)
To decide which library to use, pd works with the libraries first loaded, so I put gem as the last library on my list.
which might render Gem unusable. however, it is your decision. but maybe it would be a better idea to load libraries on demand rather than all the time. to make this more useable, it might be a good idea (just brainstorming!) to introduce a "-nolib" flag, which would prevent a library priorly specified with the "-lib" flag to be loaded at start-up. So you could have a .pdrc that loads (say) motex but not Gem, and, if you wanted to use Gem you could start pd with "pd -nolib motex -lib Gem" to avoid the [scale] nameclash. of course very unsatisfactory
mfg.cd.asr IOhannes
João Miguel Pais
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi there,
I just realized you can create an object like "maxlib", "ext13" or whatever, and pd will load the library just as if I had used the -lib parameter (assuming the library is on my path, as they are).
So it seems I could kick the -lib flag goodbye (finally) and start marking my patches with library names.. it's still "first loaded, first served" though.
If a patch with "maxlib" on it would give preference to objects on maxlib, that would be the namespace thing done in minimal effort, in a way that would simplify things instead of making it more complex, and with the information of what libraries a patch depends on in the right place.
(arguably, am I overlooking this?)
cheers Juha
More:
If a patch uses gem and zexy, which both have abs~, and I'd wish to use abs~ from zexy, I would make an abstraction with [zexy] and [abs~] in it, and name it zexyabs~ or whatever.
This would shift the trouble of resolving namecollisions from developers to end-users, which I find very reasonable.
(since the problem is, in the first case, which object I want to USE.)
cheers Juha
If a patch with [maxlib] on it would give preference to objects on maxlib, that would be the namespace thing done in minimal effort, in a way that would simplify things instead of making it more complex, and with the information of what libraries a patch depends on in the right place.
(arguably, am I overlooking this?)
cheers Juha
Juha Vehviläinen schrieb:
More:
If a patch uses gem and zexy, which both have abs~, and I'd wish to use abs~ from zexy, I would make an abstraction with [zexy] and [abs~] in it, and name it zexyabs~ or whatever.
Hi Juha,
have you tried this? - My experience - at least on win - is, that once you loaded an external into Pd it is available to any patch you open (even ofter closing the patch you originally used it in)! This would mean that after having loaded a zexy* abstraction all other abstractions would know about the zexy objects as well. One needs to restart Pd to get rid of it....
Olaf
Yes, you would need to make a gemabs~ abstraction as well to use that version. With a lot of name collisions this wouldn't be too good, but that doesn't seem to be the case.. yet..
If a patch uses gem and zexy, which both have abs~, and I'd wish to use abs~ from zexy, I would make an abstraction with [zexy] and [abs~] in it, and name it zexyabs~ or whatever.
Hi Juha,
have you tried this? - My experience - at least on win - is, that once you loaded an external into Pd it is available to any patch you open (even ofter closing the patch you originally used it in)! This would mean that after having loaded a zexy* abstraction all other abstractions would know about the zexy objects as well. One needs to restart Pd to get rid of it....
Hi Juha, one other potential problem is that the [zexy] object must then be loaded before all the objects you want to reference from the zexy library. Otherwise they wont't be found. I'm not sure if one can always be in control of this.
greetings, Thomas
----- Original Message ----- From: "Juha Vehviläinen" jusu@acoustics.hut.fi To: pd-list@iem.kug.ac.at Sent: Wednesday, August 28, 2002 8:17 AM Subject: [PD] name collisions, namespaces ..
Hi there,
I just realized you can create an object like "maxlib", "ext13" or whatever, and pd will load the library just as if I had used the -lib parameter (assuming the library is on my path, as they are).
So it seems I could kick the -lib flag goodbye (finally) and start marking my patches with library names.. it's still "first loaded, first served" though.
If a patch with "maxlib" on it would give preference to objects on maxlib, that would be the namespace thing done in minimal effort, in a way that would simplify things instead of making it more complex, and with the information of what libraries a patch depends on in the right place.
(arguably, am I overlooking this?)
cheers Juha
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Ouch.
Hi Juha, one other potential problem is that the [zexy] object must then be loaded before all the objects you want to reference from the zexy library. Otherwise they wont't be found. I'm not sure if one can always be in control of this.
If a patch with [maxlib] on it would give preference to objects on maxlib, that would be the namespace thing done in minimal effort, in a way that would simplify things instead of making it more complex, and with the information of what libraries a patch depends on in the right place.
Juha Vehviläinen wrote:
Ouch.
hi !
Hi Juha, one other potential problem is that the [zexy] object must then be loaded before all the objects you want to reference from the zexy library. Otherwise they wont't be found. I'm not sure if one can always be in control of this.
If a patch with [maxlib] on it would give preference to objects on maxlib, that would be the namespace thing done in minimal
well, i always think it is good style to define dependencies (on libraries) in the patch itself. in fact, most of my patches look like this (maybe some (a lot?) do not) some years ago (??, really ?), i've proposed an additional "object"-like GUI-representation for loading libraries / showing dependencies (kind of "import"-thing). it was then rejected by most.
i would think, that placing a (say) [zexy] (or {import zexy}) in an abstraction, should set a priority to use zexy-externals, whenever nameclashes appear, in this very patch (subpatch?).
example: starting pd with "pd -lib Gem -lib zexy".
- a patch containing [abs~] would naturally use Gem's [abs~]
- a patch containing {import zexy} would use zexy's [abs~] instead.
- a patch containing {import abslib zexy} would load the abslib-library
(and offer its additional features like [absinth] from now on, just like ordinary library loading), use abslib's [abs~] and zexy's [reson~]
i would not dare/like to implement this feature and change pd's library loading mechanism. as a by-product, it is very likely that the (discussed) namespacing-mechanism ([zexy::abs~] vs. [Gem::abs~]) would have to be implemented anyway. i think that this would be simpler and be able to handle all problems apropriately.
mfg.cds.asdr IOhannes
hi all,
why on earth do we need two separate implementations of the abs~ class? They seem equivalent. And, after all, the abs~ is to be included in the Pd proper at some point...
Well, having namespaces in Pd would be a dream come true for some users (including myself), but from the pov of many more users it would have been much better, if the coders agreed to avoid name duplication at all costs, either merging their efforts, or using pre- or postfixes or whatever.
I think, even if there are namespaces, people mostly tend to ignore them, unless they are forced to comply.
Krzysztof
IOhannes zmoelnig wrote: ...
as a by-product, it is very likely that the (discussed) namespacing-mechanism ([zexy::abs~] vs. [Gem::abs~]) would have to be implemented anyway.
Krzysztof Czaja wrote:
hi all,
why on earth do we need two separate implementations of the abs~ class? They seem equivalent. And, after all, the abs~ is to be included in the Pd proper at some point...
Of course, we do not need to separate implementations of the [abs~] class ! In fact, in this special case, they are not 2 separate implementations, but 2 100%-compatible classes packed into 2 separate libraries (!). Why ? For pure convenience, because when distributing pd-work on small floppy-disks, the big Gem-project (even if we talk about the binary-only distribution) just will not fit on the media !
So what should we do then ? Of course, I could split Gem up again into Gem+markEx, but then there arises the problem that most of markEx is really useful for work with Gem. The not-so-useful-for-Gem-objects are maybe [abs~] and [reson~]. Should i split the package then ?
my personal opinion (and yours too, i see) is, that it would be best to include [abs~] in the main pd release.
All the talk i have made up till now used the [abs~] only as an example. Worse problems occur with not-so-obvious classes like [scale]
Well, having namespaces in Pd would be a dream come true for some users (including myself), but from the pov of many more users it would have been much better, if the coders agreed to avoid name duplication at all costs, either merging their efforts, or using pre- or postfixes or whatever.
I think, even if there are namespaces, people mostly tend to ignore them, unless they are forced to comply.
Well, my idea is to make namespaces handled by the library loader of pd. This is, the namespace is not handled by the programmer. She just writes a library (pe "zexy") and with classes like "matrix~". When the pd-library-loader loads "zexy", it inserts the new classes not as "matrix~" but as "zexy::matrix~" (please ignore the ascii-value of the delimiter) and furthermore tries to add a class_creator "matrix~", which is allowed to fail, because someone has ignorantly written a library "matrixlib" that provides the "matrix~"-class and has been loaded before.
so i would encourage programmers of libraries to not use (artificial) namespaces for their classes until...
mfg.fsd.sdr IOhannes
Krzysztof
hi again,
my point was mainly about lazy users putting plain [matrix~] in a patch, and then other users opening the same patch in a Pd session having different library loaded. So the whole namespace idea would fail, unless the library marking is saved in a patch, even if it is not visible in an object box. Thus, the needed changes to the Pd design and coding involve more than simply modifying the library loader.
But there is yet another point -- about users just being puzzled by various meanings of simple words such as 'matrix~' or 'counter'.
Btw, matrix~ is an msp class too (however not in the cyclone yet). From this probably follows (but it is not for me to judge), that this name could very well become 'reserved' for a 'compatibility' class.
Krzysztof
IOhannes zmoelnig wrote: ...
Well, my idea is to make namespaces handled by the library loader of pd. This is, the namespace is not handled by the programmer. She just writes a library (pe "zexy") and with classes like "matrix~". When the pd-library-loader loads "zexy", it inserts the new classes not as "matrix~" but as "zexy::matrix~" (please ignore the ascii-value of the delimiter) and furthermore tries to add a class_creator "matrix~", which is allowed to fail, because someone has ignorantly written a library "matrixlib" that provides the "matrix~"-class and has been loaded before.
so i would encourage programmers of libraries to not use (artificial) namespaces for their classes until...
IOhannes wrote:
my personal opinion (and yours too, i see) is, that it would be best to include [abs~] in the main pd release.
why not put many more of the libraries/externals in the pd main release? some of them are really "standard" like the zexy or iem. is the filesize the problem or releasing new versions? or just author/copyright reasons?
sme.
-
IOhannes zmoelnig -
João M Pais -
Juha Vehviläinen -
Krzysztof Czaja -
marius schebella -
Olaf Matthes -
Thomas Grill