[PD] pd-ext paths, libs and help

[marius schebella]

hi,

Hans-Christoph Steiner wrote:
> 
> On Mar 5, 2008, at 9:57 PM, marius schebella wrote:
> 
>> Roman Haefeli wrote:
>>> On Tue, 2008-03-04 at 12:09 -0500, marius schebella wrote:
>>>
>>>> declare -path oscx is also doing nothing. oh, wait!
>>>
>>> as written in the declare-help.pd, -path is relative to pd, so you have
>>> to use:
>>>
>>> [declare -path oscx] (assuming the folder is <pd-path>/extra/oscx)
>>>
>>> roman
>>
>> but that is exaclty what I used! (see 2 lines above...) something is
>> broken with declare. (see mails before).
>> hans, would it be a problem to add all the missing paths to the
>> configuration file of pdxt? adding all these external libraries but not
>> supporting them seems weird.
>> marius.
> 
> I had a discussion about this with Roman on #dataflow.  Basically, 
> having all of the libraries loaded by default isn't a workable long-term 
> solution.  Let's say we have two libraries, firstlib and secondlib.  
> firstlib is loaded first, secondlib is loaded second.  secondlib has an 
> object called [foo].  It's great and a lot of people use it all the 
> time.  It's in lots of patches just as [foo].
> 
> The author of firstlib never use secondlib or [foo], then creates an 
> object that does something different, but is called [foo].  Since 
> firstlib is already being loaded first, then firstlib's new [foo] will 
> override secondlib's well-established [foo], and everyone's patches break.

I think this is a lot of theory, and part of why all this is possible, 
is because there is no good documentation of existing libraries and 
objectclasses.
I rather would like to fix a problem with one out of 2500 than fixing 
*every* patches, because 1000 objects are not accessible...
I already suggested several times that we should agree on a standard set 
of objectclasses additionally to vanilla.
why can't we have an official list of names that are already in use by 
some library?

> So we need to come up with something better.  One thing that will always 
> work is having the library load order embedded in each patch.  That 
> means a bit more work when writing a patch, but this is how many, many 
> languages handle this problem (python, ruby, Tcl namespaces, C++, etc.).

one thing that would help here would be something like
"from iem load gate".
think of how it works in practice: someone wants to share a patch with a 
list of abstractions and posts it on the mailing list: 10 people test 
it, 1 has a naming conflict, reports it back, the original author 
changes the name of the abstraction and done.
or you want to open an old patch, that used an abstraction name that now 
someone has written an external with the same name. you see that your 
patch is not working anymore, you declare which of your object classes 
to use, done.
again, I am talking about a broad mass of objects that are not 
accessible to the broad mass of pd-extended users. I am not sure if many 
pd-extended users would have problems with conflicting namespaces.

one more thing that would be useful is if you got a warning if you have 
a nameclash. "you have two versions of gate on your system. Pd is now 
using the gate version from cyclone."

I think pd-extended should be shipped as a clean distribution without 
nameclashes, objects with nameclashes should be renamed. and help-files 
should be automatically provided for all objects and all objects should 
be accessible without directory prefixes...

marius.