[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

[Frank Barknecht]

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:

> On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote:
> > >>
> > >> Again, this is up to the person building them.
> > >
> > > why? what is the benefit of it, when your decision creates
> > > inconistencies? since everything seems to be hostet in cvs, why  
> > > does cvs
> > > still support two ways of compiling them? i'd like to know from the
> > > devs, if there is any good reason to keep the old makefiles/readmes  
> > > and
> > > stuff in cvs.
> > > if people finally would find only one makefile/readme: byebye
> > > inconistencies. it automatically wouldn't make a difference anymore,
> > > whether you are an pd-extended user or not.
> > 
> > I am totally with you in spirit, but the issues are social, not  
> > technical.  I think that we should purge all old build systems  
> > (they'd still be archived in CVS) and replace them all with a  
> > standard build system.  But unfortunately, it has been a very  
> > political issue in the past, so the cruft remained.  It seems that  
> > things have changed on the social front somewhat, so maybe now this  
> > could be done.
> > 
> > Are you volunteering to lead the charge? :-D
> 
> actually i would like to do so, but i have some concerns. first, as i
> mentioned a few times before, i've never written a line of c code or a
> makefile or a config-file. my knowledge about this is very limited. and
> i am not a pd-cvs dev myself and thus do not feel like making my hands
> dirty on files which have been written and developped carefully by
> others. and still if i would feel to be able to do it, i would request
> an admission first from the original author for each library before
> doing it. 
> 
> if it's only about deleting makefiles/configures and probably editing
> the readmes and all pd-cvs people agree, i would do it.

As I see it, it's not about that at all. Basically it's a social and
not a technical issue. Namespaces aren't something, that can be
enforced technically ATM. They are a convention: Nothing can stop a
user to add the directory of some classes to the Pd search path or
alternatively put them into a directory and use that dir as a
namespace.

Let me explain this taking pdmtl as an (extreme) example: pdmtl can be
used with a double namespace: [pdmtl/list/op] but that's not the way
the pdmtl people suggest to use it: IIRC you're supposed to use
[list/op] instead, as that is, what the help files use. But then, if
you do this, pdmtl grabs a whole bunch of possible prefixes, namely
these:

2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems,
generate, gui, init, input, list, midi, mix, musical, number, random,
sample, scale, seq, sf, synth, table, timing, transform

So more than 30 possible prefix names are taken by pdmtl. 

The important thing to note here is: This doesn't have anything to do
with the way, pdmtl is installed, it's only a matter of how the Pd
search path is configured! How to configure the search path is a
matter of conventions, and I'm convinced, that as long as the Pd
community doesn't agree on conventions, it is not possible to solve.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__