Problem: Unique objects exist in more than one library with the same name, but different function, with no ombudsman or czar to arbitrate who gets the name. This forces library loading order to be an issue: IEM's gate vs cyclone's gate.
So I offer two thoughts: (if this has been discussed before, I couldn't find it.)
- If, at load time, external objects maintained their library name
persistently, then objects could be absolutely selected from a particular library at creation time in the patch. This would eliminate the effect of library loading order and increase reliability. So instead of [prob 2 4 5] someone publishing a patch could specify [mJlib/prob 2 4 5] to guarantee correct operation, and alert the user immediately to the required library, with no further documentation needed..
- If Pd had a option to enable/disable "object path display" in the GUI,
ALL object names could be displayed with their library path or not, in edit mode.
Advantages:
- No need to make up ridiculous non-mnemonic names for objects which have
nothing to do with their function, simply to avoid a dreaded name collision. 2. No more torture for users trying to figure out why patches don't work, especially for objects without documentation which shall remain unnamed here.
Disadvantage(s): Not backwards compatible. However, the patch or abstraction can be easily edited as text to remove the offending path, and it STILL alerts the user to the need for the correct library..
It's just a thought.
L
Lex Ein wrote:
So instead of [prob 2 4 5] someone publishing a patch could specify [mJlib/prob 2 4 5] to guarantee correct operation, and alert the user immediately to the required library, with no further documentation needed..
maxlib sort of does this since ages. In fact it uses 'maxlib_' as a prefix, so to make sure you get the maxlib scale and not GEM's scale use 'maxlib_scale'. This is not really the feature you suggest but has the same effect and can be implemented without having to modify any single line of Pd code.
Olaf
maxlib sort of does this since ages. In fact it uses 'maxlib_' as a prefix, so to make sure you get the maxlib scale and not GEM's scale use 'maxlib_scale'. This is not really the feature you suggest but has the same effect and can be implemented without having to modify any single line of Pd code.
imo, it's not very useful to have these nameclashes ... but for some important externals it would be worth to consider taking one of them to the pd core objects ... right now, i'm not using any counter, because of the differences between the different counter ... and since both maxlib and cyclone have objects, that do nearly the same and have similar names (e.g. borax vs. Borax) it would probably make sense to figure out, what the external _should_ to and cobine the objects of both libraries ...
implementing a (selectable) namespace for externals was one of the things that was discussed at the lad2conf in may ... well, but combining the efforts to improve pd is another topic ...
good night ... t
Part of putting all of the code into a central repository and also
compiling all of the contributed objects as individual files allows us
to eliminate such conflicts. So if you use the packages (Debian,
Windows, MacOS X), then there won't be conflicts if you don't use any
libs.
.hc
On Jul 18, 2004, at 4:56 PM, Lex Ein wrote:
Problem: Unique objects exist in more than one library with the same
name, but different function, with no ombudsman or czar to arbitrate who gets
the name. This forces library loading order to be an issue: IEM's gate
vs cyclone's gate.So I offer two thoughts: (if this has been discussed before, I
couldn't find it.)
- If, at load time, external objects maintained their library name
persistently, then objects could be absolutely selected from a particular library at
creation time in the patch. This would eliminate the effect of library loading order and increase
reliability. So instead of [prob 2 4 5] someone publishing a patch could specify [mJlib/prob 2 4 5] to guarantee correct operation, and alert the user immediately to the
required library, with no further documentation needed..
- If Pd had a option to enable/disable "object path display" in the
GUI, ALL object names could be displayed with their library path or not, in
edit mode.Advantages:
- No need to make up ridiculous non-mnemonic names for objects which
have nothing to do with their function, simply to avoid a dreaded name
collision. 2. No more torture for users trying to figure out why patches don't
work, especially for objects without documentation which shall remain
unnamed here.Disadvantage(s): Not backwards compatible. However, the patch or abstraction can be
easily edited as text to remove the offending path, and it STILL alerts the user to
the need for the correct library..It's just a thought.
L
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
On Sun, Jul 18, 2004 at 07:11:51PM -0400, Hans-Christoph Steiner wrote:
Part of putting all of the code into a central repository and also compiling all of the contributed objects as individual files allows us to eliminate such conflicts.
how so? if below is implemented:
implementing a (selectable) namespace for externals was one of the things that was discussed at the lad2conf in may
it seems it would be much easier if libraries were monolithic, containing all the objects in one file, so you could for example:
pd -lib maxlib:ml
and then use [ml:prepend] in your patch, if you send it to smoeone else and a "ml:" namespace is not found it will look in the global namespace. having as seperate files would much more difficult, unless you propose to change to the code of every external to hardcode a namespace identifier in?
guess the key would be adding optional namespace-mapping while having it not confuse earlier versions of pd, perhaps throwing the name of the preferred library somewhere after the ; ...
Hans-Christoph Steiner wrote:
Part of putting all of the code into a central repository
....like herding the sweetest, but most unwilling cats: not all developers will plant their code in the CVS.
and also compiling all of the contributed objects as individual files
Unless I misunderstand you, this requires breaking up existing libs into separate objects. Lots of work, and the original developers won't want to do it, and won't want to touch it after someone's dismantled it.
allows us to eliminate such conflicts.
No, that means you'll still have two different, say, "counter" single-entity libs and hence [counter], and users will still never be able to reach both of them.
Do you mean allowing the user to rename the lib? Doesn't that break load-time linking? And then break the patch on everyone else's machine?
Load-time namespace management will allow ALL objects to be reachable, even into the infinite future, whether or not they are in simple (1 entity) or aggregate libraries, no matter if a developer names ALL his objects the same [thing], as long as the library names are different.
So if you use the packages (Debian, Windows, MacOS X), then there won't be conflicts if you don't use any libs.
Who will make the choice of which objects 'live' without renaming, and who 'dies' (gets renamed)? Even dictionaries allow different definitions of words, and multiple entries, and they're all accessible to those who wish to access them.
To expand on my core arguments: 0. Not all users are C developers, nor do they wish to be..
- Not all developers will plant their code in the CVS.
I imagine the most important one never will do so.
- All users want arbitrary access to all objects, with
a) no unresolvable conflicts, and b) an easy workaround for any conflicts, and c) easy to find, install, and successfully reference objects.
Example, unresolvable as of July 18, 2004: lib1 contains [counter](2 inlets) and [slope](2 inlets) lib2 contains [counter](4 inlets) and [slope](4 inlets) All four objects are useful and interesting, and do what they say in different ways. All should be reachable, without forcing literal renaming, or forcing tortuous workarounds.
Note: lib_obj naming is not 'renaming', but 'name extension'
- Not all developers will choose to check the name of their new objects
against the
WWW to guarantee uniqueness, because that would force them to choose YAASIN
(Yet Another Arbitrary Silly Irrelevant Name) for their objects.
Perhaps better to force
them to use a thesaurus (see attached pic, courtesy Visual Thesaurus).
- Objects evolve. There are early versions of objects which are fast
but featureless. Later versions (same name) have great features, but are slow. The user should be able to choose.
Conclusion: some sort of easy user-end name choices are needed.
I personally like pseudo-heirarchical built-in name mangling as expressed in maxlib, followed by path-heirarchical with a lib-name 'namespace' separation, or (perhaps) a true namespace implementation.
If the argument is that it's a lot of work for a few conflicts, please note that there are nearly a hundred actual conflicts in the Pd universe of objects right now. This is because every weirdly synonymical-yet-irrelevantly-named object represents a conflict resolved by the developer at coding time. That resolution was achieved in an extraordinary, non-mnemonic and ultimately user-alienating way. Each of those conflicts continually re-affects every user to tries to use Pd.
I disliked irrelevantly-named objects in Max, and I dislike them even more in Pd, because in this new, developing language, they're unnecessary. We'll never know what those irrelevantly-named objects (INOs) would have been named if there had been another way.
Historical interpretive note:
In Max and Pd and others, names are short ONLY to take up minimal space
on the screen, because
they are perforce textual languages, and texts, not diagrams. There is
no functional meaning assigned
to the square boxes without the name present. These are English-centric
and are likely to remain so,
even though this does not serve users(too-short names), or international
users(must know English), all
that well.
Why make this point?
In some other gui-based languages, such as eyesweb, object names are
long, and are descriptive,
but objects in patches are represented primarily as icons, perhaps
accented and differentiated from its
functional family members with an additional symbol or letter. These
are inherently more
internationalizable. There is a certain greater compactness and visual
understandability which _can_
be achieved graphically, although eyesweb does not achieve this.
Worse, the ease of mutating an object
is missing in eyesweb - an object cannot be changed "on the fly", but
must be newly created, and the old
one deleted, along with all its prior connections, which must then be
rebuilt.
"Freedom of choice, it's what you've got. Freedom from choice, it's what you want." --- Devo
L
.hc
On Jul 18, 2004, at 4:56 PM, Lex Ein wrote:
Problem: Unique objects exist in more than one library with the same name, but different function, with no ombudsman or czar to arbitrate who gets the name. This forces library loading order to be an issue: IEM's gate vs cyclone's gate.
So I offer two thoughts: (if this has been discussed before, I couldn't find it.) 1. If, at load time, external objects maintained their library name persistently, then objects could be absolutely selected from a particular library at creation time in the patch. This would eliminate the effect of library loading order and increase reliability. So instead of [prob 2 4 5] someone publishing a patch could specify [mJlib/prob 2 4 5] to guarantee correct operation, and alert the user immediately to the required library, with no further documentation needed..
- If Pd had a option to enable/disable "object path display" in the
GUI, ALL object names could be displayed with their library path or not, in edit mode.
Advantages: 1. No need to make up ridiculous non-mnemonic names for objects which have nothing to do with their function, simply to avoid a dreaded name collision. 2. No more torture for users trying to figure out why patches don't work, especially for objects without documentation which shall remain unnamed here.
Disadvantage(s): Not backwards compatible. However, the patch or abstraction can be easily edited as text to remove the offending path, and it STILL alerts the user to the need for the correct library..
It's just a thought.
L
Hallo, Lex Ein hat gesagt: // Lex Ein wrote:
Hans-Christoph Steiner wrote:
Part of putting all of the code into a central repository
....like herding the sweetest, but most unwilling cats: not all developers will plant their code in the CVS.
For externals, the CVS already almost is a standard.
and also compiling all of the contributed objects as individual files
Unless I misunderstand you, this requires breaking up existing libs into separate objects. Lots of work, and the original developers won't want to do it, and won't want to touch it after someone's dismantled it.
Yes, this is a problem, and breaking up libraries only should be done as a last resort. But as shown by IEMLib technically it can be done and then it magically solves all nameclashes present in that library before.
Single externals are a solution, which works often (IEMLib) but not everytime (Gem, also I don't understand at all why Gem still has a "counter" object)
allows us to eliminate such conflicts.
No, that means you'll still have two different, say, "counter" single-entity libs and hence [counter], and users will still never be able to reach both of them.
The problem with libraries is, that you cannot disable an object inside a library, and you aren't aware, what objects are in which library. With single externals, everything is visible in the filesystem.
So if you use the packages (Debian, Windows, MacOS X), then there won't be conflicts if you don't use any libs.
Who will make the choice of which objects 'live' without renaming, and who 'dies' (gets renamed)?
We. The people on this list and on pd-dev and the CVS maintainers. It's just that we need to find a way to communicate or vote, which objects should be the standard "counter" or "prepend" objects.
I agree with you than some kind of namespace would be very useful, but it alone won't solve the nameclash problem, we also need socal enineering here.
On Mon, 19 Jul 2004, Frank Barknecht wrote:
I agree with you than some kind of namespace would be very useful, but it alone won't solve the nameclash problem, we also need socal enineering here.
I can only second this thought. The rest of the topic has been discussed in and out.
The name clash problem does not only exist with externals but with abstractions too. There is a solution implemented in pd, which uses the filesystem and "/" as a delimiter between directory and external name.
Example:
/library/abc/foo.pd (on windows with "") /library/xyz/bar.pd
If /library is in your path, then you can load these abstractions with [abc/foo] and [xyz/bar]. The same applies if the two files are not abstractions but externals.
And here comes the big drawback. It will not easily be possible to load two externals of the same name, whatever namespace mechanism you implement, wether single externals or libraries. This would theoretically only work if the developers decide to name all of their ("exported") functions differently.
e.g the two "counter" examples:
both counters have "counter_bang" as their main function. You can not have two functions with the same name in a C program, so one of the counters will misbehave by using the wrong (first) counter_bang function.
The solution would be that the developers have to agree on function names, which brings us back to the initial problem.
What we really need is communication between developers.
If we do have the communication overhead, why shouldn't we decide on a single counter in the first place ? For the good of the user and the community ?
Guenter
PS: Or, even better, forget about having a counter external and implement the counter as an abstraction - but thats another story.
hi all...
both counters have "counter_bang" as their main function. You can not have two functions with the same name in a C program, so one of the counters will misbehave by using the wrong (first) counter_bang function.
The solution would be that the developers have to agree on function names, which brings us back to the initial problem.
the externals that have been written several times have been written, because different people needed the same, more or less basic, that's not implemented as pd internal... (on cvs, there are 3 counters, including the flext tutorial, excluding the gem counter and 4 prepends)
i would deeply suggest that all the developers (iohannes, d.ly, krzysztof, thomas, guenter for counter or prepend) who are involved in these nameclashes, discuss about their opinion on these externals, and implement one of them in the appropiate place ... e.g. since cyclone seems to be the place for max/msp port, put the externals into cyclone... or send some diffs to miller and ask him about implementing it to his next release...
What we really need is communication between developers.
to me it seems that if there is communication between the developers, it is more or less about the communication itself, but very few communication is about external development, an nearly none about internal/kernel development ...
about the namespaces: since some externals have the same name, either try to find one external that it fits to and add all features to this specific external. or write one internal and add some kind of feature that forbids to include such an external (with a fancy error message)
about some nameclashes like scale (maxlib vs. gem) these externals have a different behaviour ... maybe it would be possible to add some characters like ~ for audio externals to the gem externals. this way, gem externals would have a naming convention on their own. since they have a message path of their own, it would probably be useful to mark an external as gem external...
cheers ... tim
On Mon, 19 Jul 2004, Tim Blechmann wrote:
the externals that have been written several times have been written, because different people needed the same, more or less basic, that's not implemented as pd internal... (on cvs, there are 3 counters, including the flext tutorial, excluding the gem counter and 4 prepends)
They have been implemented several times because there was no central CVS and people did not know that they already exist. Another case that demonstrates why the CVS is a good thing.
i would deeply suggest that all the developers (iohannes, d.ly, krzysztof, thomas, guenter for counter or prepend) who are involved in these nameclashes, discuss about their opinion on these externals, and implement one of them in the appropiate place ...
yep, we have discussed the prepend case, the solution is in CVS. Miller has the decision if he want to include it in pd.
Would be good if the counter case would be discussed too by those involved.
Guenter
On Jul 20, 2004, at 10:47 AM, guenter geiger wrote:
On Mon, 19 Jul 2004, Tim Blechmann wrote:
the externals that have been written several times have been written, because different people needed the same, more or less basic, that's
not implemented as pd internal... (on cvs, there are 3 counters, including the flext tutorial, excluding the gem counter and 4 prepends)They have been implemented several times because there was no central
CVS and people did not know that they already exist. Another case that demonstrates why the CVS is a good thing.
I strongly second that opinion.
i would deeply suggest that all the developers (iohannes, d.ly, krzysztof, thomas, guenter for counter or prepend) who are involved in these nameclashes, discuss about their opinion on these externals, and implement one of them in the appropiate place ...
yep, we have discussed the prepend case, the solution is in CVS. Miller has the decision if he want to include it in pd.
Would be good if the counter case would be discussed too by those involved.
I think that we should also use the cyclone [counter]. We should use
the Max-compatible objects first, unless there is a very good reason to
do otherwise. Other counter-type objects can just as easily have
different names. Plus with many of the help files linking to all
related objects, it makes it much easier to figure out which specific
object serves your purpose.
.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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think that we should also use the cyclone [counter]. We should use the Max-compatible objects first, unless there is a very good reason to do otherwise. Other counter-type objects can just as easily have different names. Plus with many of the help files linking to all related objects, it makes it much easier to figure out which specific object serves your purpose.
I agree here. Max compatibility shouldn't be broken where not necessary.
Ciao
Frank Barknecht _ ______footils.org__
I agree too... Whenever something is available in Max and also in clashing libraries, I'm thinking of figuring out the Max compatible one (probably this will always be the one in cyclone) and putting that in the Pd core.
Also, objects such as abs~, etc., which are in cyclone but seem canonical should go into Pd. I haven't decided wheether Pd should try to include the whole of cyclone or not.
also, I want to add a flag to Pd to supperss loading specific classes so that, when classes are added to Pd , they don't break existing libraries quite so badly.
cheers Miller
On Tue, Jul 20, 2004 at 06:26:58PM +0200, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think that we should also use the cyclone [counter]. We should use the Max-compatible objects first, unless there is a very good reason to do otherwise. Other counter-type objects can just as easily have different names. Plus with many of the help files linking to all related objects, it makes it much easier to figure out which specific object serves your purpose.
I agree here. Max compatibility shouldn't be broken where not necessary.
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Miller Puckette wrote:
I agree too... Whenever something is available in Max and also in clashing libraries, I'm thinking of figuring out the Max compatible one (probably this will always be the one in cyclone) and putting that in the Pd core.
Also, objects such as abs~, etc., which are in cyclone but seem canonical should go into Pd. I haven't decided wheether Pd should try to include the whole of cyclone or not.
also, I want to add a flag to Pd to supperss loading specific classes so that, when classes are added to Pd , they don't break existing libraries quite so badly.
cheers Miller
Fine, so I give up. No namespaces. Fine. So everybody's mind is made up. So much for that debate.
But it sure seems like encouraging "libraryname_objectname" aliases as in maxlib would go a long way to avoiding and providing a user-side method to resolve nameclashes, and allowing simultaneous (within the same patch or abstraction) usage of objects with identical root objectnames. Without "changing a line of code", by the way.
"one word - one object" - feh. Try that in a dictionary and see how far you get. As in real estate, context, context, context.
Hallo, Lex Ein hat gesagt: // Lex Ein wrote:
Fine, so I give up. No namespaces. Fine. So everybody's mind is made up. So much for that debate.
Ah, come on, nobody said something *against* namespaces. In fact several posters here, including me, expicitly welcomed them.
It was just pointed out that they won't solve all our current name clash problems, and they might not work well for clashes with abstractions.
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 21 Jul 2004, Frank Barknecht wrote:
Hallo, Lex Ein hat gesagt: // Lex Ein wrote:
Fine, so I give up. No namespaces. Fine. So everybody's mind is made up. So much for that debate.
Ah, come on, nobody said something *against* namespaces. In fact several posters here, including me, expicitly welcomed them.
It was just pointed out that they won't solve all our current name clash problems, and they might not work well for clashes with abstractions.
Hi,
Well, actually the other way round. Namespaces are already implemented, they work perfectly for abstractions but not so well for externals.
<repeat> Use "/" as a namespace delimiter and sort your abstractions/externals into subdirectories in order to assign them their namespace. </repeat>
The solution of Lex doesn't work because of the same reason externals won't fully work. Adding an alias is not enough, you have to change the name of every method that could be in conflict with other methods of different externals. Otherwise you will have some surprises while using two objects with the same name. (and this could be very tricky to debug)
Guenter
guenter geiger wrote:
[...] The solution of Lex doesn't work because of the same reason externals won't fully work. Adding an alias is not enough, you have to change the name of every method that could be in conflict with other methods of different externals. Otherwise you will have some surprises while using two objects with the same name. (and this could be very tricky to debug)
and Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Declaring a function static gives it file scope, so it is only known to functions in the same file. That might solve the 'shadowed declarations' error that occurs because two entities named 'exp' are found in the source.
Might indeed help, too, although renaming was easier. The static thing won't help with the clashes of *_setup functions, though, as these need to be visible to the Pd main app, so I think, they must not be "static". Am I right?
So the above mentioned method (that already _is_ used in maxlib) should work, right? - The setup functions also have the prefix ',axlib_' and thus are different from for example 'scale_setup()' and all functions are declared static...
Olaf
On Sat, 24 Jul 2004, Olaf Matthes wrote:
So the above mentioned method (that already _is_ used in maxlib) should work, right? - The setup functions also have the prefix ',axlib_' and thus are different from for example 'scale_setup()' and all functions are declared static...
Yes, if the setup function has a prefix it works.
Guenter
Lex Ein wrote:
But it sure seems like encouraging "libraryname_objectname" aliases as in maxlib would go a long way to avoiding and providing a user-side method to resolve nameclashes, and allowing simultaneous (within the same patch or abstraction) usage of objects with identical root objectnames. Without "changing a line of code", by the way.
I agree. By changing the code, possibly extend the thing by having libraryname:objectname being an optional way of referring to objectname. At the moment I am impeded from using a lot of objects in pd by not knowing where they are, as some seem to be integrated into pd, others are in the externs, others in extras, others invisible inside libs... In the patcher file itself, libraryname:objectname should be used for every object that is actually part of a library. The internal objects would be pd:objectname, then the loose ones would be extra:objectname, externs:objectname or somesuch. ...?
Martin
Martin Peach wrote:
Lex Ein wrote:
every object that is actually part of a library. The internal objects
would be pd:objectname, then the loose ones would be extra:objectname, externs:objectname or somesuch. ...?
basically this is what i proposed 2 years ago (although is used "." instead of ":"). it worked with 3 lines of code-change in pd's main source and no code-change at all in the externals.
but again, it doesn't help us with nameclashes at all (or at least with the C-function-clashes), but only helps/disturbs the pd-users to understand which objects they are using.
another strong objection is, that this will be more of a curse than a cure when libraries get renamed (and it doesn't help at all with single-external-libraries)
however, while i use the CVS, i do not think that it is a good idea, to make it *the* standard. there are people who refuse to work with the CVS (however irrational their reasons might be), other people see the CVS as a distribution platform (and not as a community-based development platform).
so i would favour some other mechanism (but have no idea which one ;-))
mfg.a.sdr IOhannes
PS: as for Gem's [counter]: it is there because it is there; i have no problem to remove it entirely - which brings us back to the old discussion to remove markEX from GEM (and probably check it into the "main" CVS); -- furthermore i really think that [counter] should be an abstraction instead of an external (as C-objects make things appear more complicated than they are)
PPS: i remember having heard something about "static" functions in C; anybody can shed a light on this ....
IOhannes m zmoelnig wrote:
Martin Peach wrote:
Lex Ein wrote:
every object that is actually part of a library. The internal objects
would be pd:objectname, then the loose ones would be extra:objectname, externs:objectname or somesuch. ...?
basically this is what i proposed 2 years ago (although is used "." instead of ":"). it worked with 3 lines of code-change in pd's main source and no code-change at all in the externals.
but again, it doesn't help us with nameclashes at all (or at least with the C-function-clashes), but only helps/disturbs the pd-users to understand which objects they are using.
another strong objection is, that this will be more of a curse than a cure when libraries get renamed (and it doesn't help at all with single-external-libraries)
however, while i use the CVS, i do not think that it is a good idea, to make it *the* standard. there are people who refuse to work with the CVS (however irrational their reasons might be), other people see the CVS as a distribution platform (and not as a community-based development platform).
so i would favour some other mechanism (but have no idea which one ;-))
mfg.a.sdr IOhannes
PS: as for Gem's [counter]: it is there because it is there; i have no problem to remove it entirely - which brings us back to the old discussion to remove markEX from GEM (and probably check it into the "main" CVS); -- furthermore i really think that [counter] should be an abstraction instead of an external (as C-objects make things appear more complicated than they are)
Why not call it pix_counter like most of the other Gem stuff? I _have_ discovered that the 'pix' prefix means it's in GEM :) But having some way of referring to it as counter or pix_counter or Gem.counter would seem better. That way the GEM counter would be loaded if it was the first one found, while pix_counter would be a synonym for the counter in GEM, and Gem.counter would tell pd to use the counter in GEM and no other.
PPS: i remember having heard something about "static" functions in C; anybody can shed a light on this ....
Declaring a function static gives it file scope, so it is only known to functions in the same file. That might solve the 'shadowed declarations' error that occurs because two entities named 'exp' are found in the source.
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Declaring a function static gives it file scope, so it is only known to functions in the same file. That might solve the 'shadowed declarations' error that occurs because two entities named 'exp' are found in the source.
Might indeed help, too, although renaming was easier. The static thing won't help with the clashes of *_setup functions, though, as these need to be visible to the Pd main app, so I think, they must not be "static". Am I right?
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 21 Jul 2004, Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Declaring a function static gives it file scope, so it is only known to functions in the same file. That might solve the 'shadowed declarations' error that occurs because two entities named 'exp' are found in the source.
Might indeed help, too, although renaming was easier. The static thing won't help with the clashes of *_setup functions, though, as these need to be visible to the Pd main app, so I think, they must not be "static". Am I right?
Arghh, right, I have to stand corrected. If the externals implement the functions as static this problem is solved indeed.
Seems that the problem with the externals I tested was that these functions were not static.
The setup functions is not a problem, because pd assures that the right setup function is called by fetching it directly from the external.
This actually means that we have a namespace system implemented, we just have to use it.
We have to adjust the loading of libraries though, because there it doesn't work this way. .. well.
Guenter
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi Guenter,
I doubt publishing unambiguous patches would be any easier with filesystem-based extern hierarchies, unless:
- the loader is changed (currently, having a default prepend in
extra, and another version of prepend in extra/evenbetter, the clash between [prepend], and [evenbetter/prepend] remains, because if the latter is created first, it will register the plain "prepend" name as well);
the -path option is either banned, or stored with the patch;
using libraries is banned.
While (1) is probably doable, (2) and (3) seem not.
Anyway, I think, its easier to ask developers for renaming all but one of each of the equivocal classes (e.g. by adding an explicit, obligatory prefix), instead of 1. asking developers for never including potentially clashing classes in a library, and 2. asking maintainers for placing all potentially clashing externs in separate subdirectories, and 3. asking users to always prepend subdir name to any potentially ambiguous object name in any published patch.
Never using extern hierarchies, we get an extra bonus of always being able to safely resolve abstraction names against potentially shadowing class names, by placing all abstractions a level down relative to the main patch's directory, and releasing the whole bundle as a tarball.
Krzysztof
guenter geiger wrote: ...
This actually means that we have a namespace system implemented, we just have to use it.
On Thu, 22 Jul 2004, Krzysztof Czaja wrote:
hi Guenter,
I doubt publishing unambiguous patches would be any easier with filesystem-based extern hierarchies, unless:
- the loader is changed (currently, having a default prepend in
extra, and another version of prepend in extra/evenbetter, the clash between [prepend], and [evenbetter/prepend] remains, because if the latter is created first, it will register the plain "prepend" name as well);
the -path option is either banned, or stored with the patch;
using libraries is banned.
While (1) is probably doable, (2) and (3) seem not.
Anyway, I think, its easier to ask developers for renaming all but one of each of the equivocal classes (e.g. by adding an explicit, obligatory prefix), instead of 1. asking developers for never including potentially clashing classes in a library, and 2. asking maintainers for placing all potentially clashing externs in separate subdirectories, and 3. asking users to always prepend subdir name to any potentially ambiguous object name in any published patch.
Yes, for sure. It doesn't make sense to discuss about the problems of the namespace system, when we agree that it might be better to not to have to use it.
Never using extern hierarchies, we get an extra bonus of always being able to safely resolve abstraction names against potentially shadowing class names, by placing all abstractions a level down relative to the main patch's directory, and releasing the whole bundle as a tarball.
Hmm, I think I do not fully understand how this helps. You mean instead of using extern hierarchies you use abstraction hierarchies ? What is the difference ?
Guenter
Krzysztof
guenter geiger wrote: ...
This actually means that we have a namespace system implemented, we just have to use it.
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Thu, 22 Jul 2004, Krzysztof Czaja wrote:
Never using extern hierarchies, we get an extra bonus of always being able to safely resolve abstraction names against potentially shadowing class names, by placing all abstractions a level down relative to the main patch's directory, and releasing the whole bundle as a tarball.
Hmm, I think I do not fully understand how this helps. You mean instead of using extern hierarchies you use abstraction hierarchies ? What is the difference ?
I think Krzysztof is referring to abstraction collections or application patches like my RRADical collection and he is mentioning something I have on my todo list anyway: move "private" abstractions to subdirs.
RRADical patches use some utility abstractions, which are *not* meant to be part of the actual collection for the user, they are implementation details. Those could be hidden savely from the users if I would reference them inside a "Geiger-namespace" (tm), that is, put them into subdirectories. Currently i use an underscore to "hide" these, but that could still clash.
Ciao
Frank Barknecht _ ______footils.org__
On Jul 21, 2004, at 1:31 PM, Martin Peach wrote:
IOhannes m zmoelnig wrote:
Martin Peach wrote:
Lex Ein wrote:
every object that is actually part of a library. The internal objects
would be pd:objectname, then the loose ones would be
extra:objectname, externs:objectname or somesuch. ...?basically this is what i proposed 2 years ago (although is used "."
instead of ":"). it worked with 3 lines of code-change in pd's main
source and no code-change at all in the externals.but again, it doesn't help us with nameclashes at all (or at least
with the C-function-clashes), but only helps/disturbs the pd-users to
understand which objects they are using.another strong objection is, that this will be more of a curse than a
cure when libraries get renamed (and it doesn't help at all with
single-external-libraries)however, while i use the CVS, i do not think that it is a good idea,
to make it *the* standard. there are people who refuse to work with the CVS (however irrational
their reasons might be), other people see the CVS as a distribution
platform (and not as a community-based development platform).so i would favour some other mechanism (but have no idea which one
;-))mfg.a.sdr IOhannes
PS: as for Gem's [counter]: it is there because it is there; i have
no problem to remove it entirely - which brings us back to the old
discussion to remove markEX from GEM (and probably check it into the
"main" CVS); -- furthermore i really think that [counter] should be an abstraction
instead of an external (as C-objects make things appear more
complicated than they are)Why not call it pix_counter like most of the other Gem stuff? I _have_
discovered that the 'pix' prefix means it's in GEM :) But having some way of referring to it as counter or pix_counter or
Gem.counter would seem better. That way the GEM counter would be
loaded if it was the first one found, while pix_counter would be a
synonym for the counter in GEM, and Gem.counter would tell pd to use
the counter in GEM and no other.
MarkEx should definitely be removed from Gem since its objects are not
specifically about graphics, and they are in the CVS anyway and all
distros related to the CVS, except for the vector objects, which could
be added without too much difficulty.
.hc
PPS: i remember having heard something about "static" functions in C;
anybody can shed a light on this ....Declaring a function static gives it file scope, so it is only known
to functions in the same file. That might solve the 'shadowed
declarations' error that occurs because two entities named 'exp' are
found in the source.Martin
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
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
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
ix -
Krzysztof Czaja -
Lex Ein -
Martin Peach -
Miller Puckette -
Olaf Matthes -
Tim Blechmann