Well, the examples with more than one folder depth are not of concern. Just limit the search to one depth. Also, asking the authors of the conflicting objects/abstractions is much less work than building a mega-meta-system. After, that, the cvs "law" could simply state that no now object/abstraction may have the same name at the first depth level (or second depth depending on your persepective).
So only objetcts/abstractions named extra/*/*.pd, extra/*/*.dll, extra/*/*.pd_linux or extra/*/*.pd_darwin Also, please quoting pdmtl abstractions. If you require more information about them, please visit the documentation website. The cvs version is outdated, and since there is talking of making a svn system, they will be integrated properly then. Tom On 9/18/07, Frank Barknecht <[EMAIL PROTECTED]> wrote: > > Hallo, > Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: > > > "It looks like the function do_open_via_path in s_path.c is the one to > > fix..." > > > > Wow, talk about solving a big problem with the most simple solution! > > If this were implemented (and that could be done in one day instead of > > years), > > If it was implemented, which one would become [once]: > > extra/purepd/once.pd > extra/iemabs/once.pd > extra/pdmtl/flow/once.pd > > or maybe: > > extra/iem/spatialization/VARESE/app/iemabs/once.pd > extra/CUBEmixer/lib/libs/iemabs/once.pd > > ? > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
