On Mar 17, 2008, at 8:36 PM, marius schebella wrote:
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...
All of the objects in Pd-extended are fully accessible, but we need to:
a) better document how to access them b) add a search function c) fix the declare/import functionaility
If you don't think that name clashes are a common problem, please
read the archives about prepend, counter, etc. Günter tried to make
a system without duplicate names. In the end it was too much work,
and no one wants to do it anymore. If you want it, then do it. This
stuff has been talked to death.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne