You will be happy to know that the pdmtl abstractions have given up (for a couple of months now) the [pdmtl/list/op] style of naming it's abstractions.<br><br>By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea. The ideal solution would be to add alternate names to many externals (like zexy's length could have one additional line of code that would instantiate it with
list.length, by registering "list.length" as: class_addcreator((t_newmethod)length_new, gensym("list.length")...<br>But then you would need an editor in chief that would decide what objects get what alternate names. I think the best would be to hold an election for the "editor in chief" that would make all the needed changes.
<br><br>But honestly I do not think this is going to happen as there are many issues that this thread has already enumerated. In my own opinion, I would say "give up" and find another solution. That's what we did :)
<br><br>Tom<br><br><div><span class="gmail_quote">On 9/15/07, <b class="gmail_sendername">Frank Barknecht</b> <<a href="mailto:fbar@footils.org">fbar@footils.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hallo,<br>Roman Haefeli hat gesagt: // Roman Haefeli wrote:<br><br>> On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote:<br>> > >><br>> > >> Again, this is up to the person building them.
<br>> > ><br>> > > why? what is the benefit of it, when your decision creates<br>> > > inconistencies? since everything seems to be hostet in cvs, why<br>> > > does cvs<br>> > > still support two ways of compiling them? i'd like to know from the
<br>> > > devs, if there is any good reason to keep the old makefiles/readmes<br>> > > and<br>> > > stuff in cvs.<br>> > > if people finally would find only one makefile/readme: byebye<br>
> > > inconistencies. it automatically wouldn't make a difference anymore,<br>> > > whether you are an pd-extended user or not.<br>> ><br>> > I am totally with you in spirit, but the issues are social, not
<br>> > technical. I think that we should purge all old build systems<br>> > (they'd still be archived in CVS) and replace them all with a<br>> > standard build system. But unfortunately, it has been a very
<br>> > political issue in the past, so the cruft remained. It seems that<br>> > things have changed on the social front somewhat, so maybe now this<br>> > could be done.<br>> ><br>> > Are you volunteering to lead the charge? :-D
<br>><br>> actually i would like to do so, but i have some concerns. first, as i<br>> mentioned a few times before, i've never written a line of c code or a<br>> makefile or a config-file. my knowledge about this is very limited. and
<br>> i am not a pd-cvs dev myself and thus do not feel like making my hands<br>> dirty on files which have been written and developped carefully by<br>> others. and still if i would feel to be able to do it, i would request
<br>> an admission first from the original author for each library before<br>> doing it.<br>><br>> if it's only about deleting makefiles/configures and probably editing<br>> the readmes and all pd-cvs people agree, i would do it.
<br><br>As I see it, it's not about that at all. Basically it's a social and<br>not a technical issue. Namespaces aren't something, that can be<br>enforced technically ATM. They are a convention: Nothing can stop a
<br>user to add the directory of some classes to the Pd search path or<br>alternatively put them into a directory and use that dir as a<br>namespace.<br><br>Let me explain this taking pdmtl as an (extreme) example: pdmtl can be
<br>used with a double namespace: [pdmtl/list/op] but that's not the way<br>the pdmtl people suggest to use it: IIRC you're supposed to use<br>[list/op] instead, as that is, what the help files use. But then, if<br>
you do this, pdmtl grabs a whole bunch of possible prefixes, namely<br>these:<br><br>2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems,<br>generate, gui, init, input, list, midi, mix, musical, number, random,
<br>sample, scale, seq, sf, synth, table, timing, transform<br><br>So more than 30 possible prefix names are taken by pdmtl.<br><br>The important thing to note here is: This doesn't have anything to do<br>with the way, pdmtl is installed, it's only a matter of how the Pd
<br>search path is configured! How to configure the search path is a<br>matter of conventions, and I'm convinced, that as long as the Pd<br>community doesn't agree on conventions, it is not possible to solve.<br><br>
Ciao<br>--<br> Frank Barknecht _ ______footils.org_ __goto10.org__<br><br>_______________________________________________<br><a href="mailto:PD-list@iem.at">PD-list@iem.at</a> mailing list<br>UNSUBSCRIBE and account-management ->
<a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br></blockquote></div><br>