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.