Frank a écrit:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[...] prefix is required. Then I might call it patate/patate_poil.pd, but that's redundant, so I remove the folder so that it's just called [patate_poil], and then we're back to prefixes. However if pd wasn't doing that and if there wasn't [import] then the slash wouldn't be anything more than a tilted underscore. So what are those guidelines good for?
Actually that is why I didn't yet use directory prefixes
Actually see my mail to Patrice Colet (patco) about the mistake in what I wrote. But you seem to have figured out the mistake and figure out what I meant instead:
objects like [list-abs] or [list-moses] are impossible to use in Pd {without the prefix} anyways, as [abs] and [moses] are builtins.
If someone else does an abstraction collection for lists, I'd say, "list_" or "list." are two other good choices.
So far, Max seems to be using ".", for example "jit."; because of this, I've used the "." prefix but for "lti." classes; actually I also used it for some PureUnity classes, initially like "f." "~." "#." to mean float's, signal's, grid's, in a way that is meant to be used as [$1.hello]. I have changed this to around to [hello.$1] because of pd 0.40 and of personal preference.
Where directory prefixes shine however is for making packages of externals and abstractions. Pd-extended is the prime example: It can ship all five [counter] objects, which would be impossible without subdirectories for each collection.
Edit the five source files, changing the name in it for something else. Is that so impossible? It might not be pretty, but I wouldn't call it "impossible".
start to use objects called [list-abs/list-abs] just because for packaging reasons, list-abs.pd in pd-extended lives in a directory called "list-abs". Now that's what I call redundancy: Instead of one, we get two prefixes. At least my help-files still work.
I'd call this three prefixes: "list" occurs twice, then "abs" occurs twice, one of which is a prefix for the other one. I usually call this the "Java disease", but I wouldn't want people to think that this is specific to Java or that I call it that way just because of my general dislike of Java.
pdmtl may face a similar or worse problem when people start using objects with names like [pdmtl/list/op]. Here not only help-files will be broken, as the help file "list/op-help.pd" uses an object called [list/op] which is unavailable unless "pdmtl" is in the path. Actually all objects using [list/x]-objects are broken then!
Therefore, whether a folder is intended to be a package (prefix) or a plain folder (that'd go in -path), is something that has to be decided in advance for every folder and has to be stated in some way. I mean, one can get around it, but it causes trouble eventually, because of unability to figure out whether the "real name" of an abstraction is [list/op] or [pdmtl/list/op].
All this to me seems to kind of pervert what Guenther Geiger actually intended when suggesting directory prefixes and initiating the CVS-repository.
Actually, it never occurred to me that those two things were related. I think that I joined pd-list shortly after the CVS created, but I don't recall that anyone said (in the last five years of pd-list) that the whole externals/ thingie had to do with Geiger namespaces. So, if anything got perverted, it's quite natural, because the original goals have not been re-stated often enough.
The reality now is, that [flatspace] announces that it is deprecated,
I admit that I don't really remember what [flatspace] is, if I ever knew. I think that I largely skipped over it.
and the "Path" window is filled with more entries than it can handle.
Apart from what the intention might have been about paths or libs (libdirs), this is not a problem with Hans's work per se, it's a problem in u_main.tk, and it's very possible to fix it: e.g. http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user interface also exists for -path and -helppath separately.
I think that category names have to be figured out pretty quick if people are expected to start using the names in backwards-compatible ways. Else you get into what is called "bit rot" - a program is not just the contents of source files, it's also a set of relationships with its environment, and especially, its direct dependencies.
[list-abs/list-abs] is bit-rot.
Well, i've only seen the word "bit-rot" to mean things that result from not updating software to changing interfaces (I'm not counting the meaning of it that has to do with physical media). Thus I don't really know what you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] has gone unmaintained for years such that the definition of pd (or what pd is in practice) has changed such that is has become contextually broken or outdated or irrelevant...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
If someone else does an abstraction collection for lists, I'd say, "list_" or "list." are two other good choices.
So far, Max seems to be using ".", for example "jit."; because of this, I've used the "." prefix but for "lti." classes; actually I also used it for some PureUnity classes, initially like "f." "~." "#." to mean float's, signal's, grid's, in a way that is meant to be used as [$1.hello]. I have changed this to around to [hello.$1] because of pd 0.40 and of personal preference.
There is a minor annoaynce with the dot for abstractions ATM because of an unfixed bug: If you save a new abstraction that already has a dot in its name like "list.abs", you need to add the ".pd" extension manually, otherwise Pd will save it as "list.abs" instead of "list.abs.pd". This is not a problem with "list-abs" which gets the suffix added automatically by Pd.
Where directory prefixes shine however is for making packages of externals and abstractions. Pd-extended is the prime example: It can ship all five [counter] objects, which would be impossible without subdirectories for each collection.
Edit the five source files, changing the name in it for something else. Is that so impossible? It might not be pretty, but I wouldn't call it "impossible".
Well, but then you wouldn't have five objects named [counter] anymore. And of course there is the social problem: How is it decided, which counter should keep its name? And that is actually what I meant with this:
All this to me seems to kind of pervert what Guenther Geiger actually intended when suggesting directory prefixes and initiating the CVS-repository.
IIRC one motive to start the CVS was to get rid of objects that do slightly different things but have the same name (like the [counter]s) by first collecting them all in one place (Sourceforge), see what's duplicated and/or conflicting, and then decide on the one "real" counter - possibly keeping the four others with different names.
Unfortunatly we didn't get further with developing an infrastructure to decide things like that.
Actually, it never occurred to me that those two things were related. I think that I joined pd-list shortly after the CVS created, but I don't recall that anyone said (in the last five years of pd-list) that the whole externals/ thingie had to do with Geiger namespaces.
The namespace and the CVS are not related directly, I didn't want to imply that. Geiger namespaces are just way to keep the four other [counter]s from above available, in case someone needs them. However I fear, that they also became a kind of excuse to not think about developing a way to decide things like "which [counter] to keep".
and the "Path" window is filled with more entries than it can handle.
Apart from what the intention might have been about paths or libs (libdirs), this is not a problem with Hans's work per se, it's a problem in u_main.tk, and it's very possible to fix it: e.g. http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user interface also exists for -path and -helppath separately.
Of course one could easily overhaul the path windows (and one has to do it for plain Pd as well) to be able to handle more paths, but the actual problem is: Why are there so many paths and are they all really necessary?
[list-abs/list-abs] is bit-rot.
Well, i've only seen the word "bit-rot" to mean things that result from not updating software to changing interfaces (I'm not counting the meaning of it that has to do with physical media). Thus I don't really know what you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] has gone unmaintained for years such that the definition of pd (or what pd is in practice) has changed such that is has become contextually broken or outdated or irrelevant...
I meant: Using [list-abs/list-abs] instead of just [list-abs] is a kind of bit rot, because the more people use the double or triple prefix, the more it gets carved into (some) stones and at some point, users will expect the [list]-abs objects with long names to be available. Maybe that's not something to call bit rot, but it would be rotten. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Mathieu Bouchard