hallo georg, the problem is, that you have to remember in which library an object is, no help patch uses import or declare, and at least for me they are not working. I would like to use every object without having to add the prefix. let's say I want to use OSCroute... I put an object [import oscx]. but OSCroute ... couldn't create only oscx/OSCroute works, and then I can also use OSCroute. I can import OSCroute, but only after I imported oscx. almost all the help patches that rely on one of these libraries are broken. for me it looks like I have to import every single object in pdxt before I can use it, that's really not a solution. what I want is, that when I type OSCroute, the library is loaded. and there should be a default loaded that gets loaded if there are nameclashes between different libs. for nameclashes it makes sense to use the declare or prefix, but for the rest it is rather annoying. marius.
Georg Holzmann wrote:
Hallo!
there are a lot of objects in pdxt that will not load by default, because the libraries are not loaded in the beginning and there is no path. I thought the idea of pdxt is that all objects are loadable. I
Again: why should all obects load at the beginning ? I can't remember that this was the idea of pdxt. In my opinion this makes no sense at all - instead we should focus on or document how its possible to load libs (declare/import), then also patches are much more clear ...
LG Georg
Hallo!
let's say I want to use OSCroute... I put an object [import oscx]. but OSCroute ... couldn't create only oscx/OSCroute works, and then I can also use OSCroute. I can import OSCroute, but only after I imported oscx.
Okay, which pd-extended version do you use ? I use the autobuild Pd version 0.40.3-extended-20080224 and I can do a [import oscx] and [OSCroute].
(of course you have to load the library "libdir" first, because thats the library loader - so yes, libdir should be loaded automatically)
Alternatively I can do [declare -lib oscx] and then [OSCroute] which should work with any pd version which supports [declare].
almost all the help patches that rely on one of these libraries are broken.
I changed the makefile at some time that all the helpfiles are also installed into the extra/library path. So everything worked basically. But I think these changes are not yet in the official released pd-extended ...
LG Georg
I am using 20080222. libdir is loading by default, so to me it looks as import is broken. otoh, there is no library oscx.pd_darwin, since in pdxt all objectclasses are separate binaries. (OSCroute.pd_darwin). maybe that is the reason why import oscx does not work? otoh (again), when I create [import oscx] I get [import] $Revision: 1.2 $ written by Hans-Christoph Steiner hans@at.or.at compiled on Feb 22 2008 at 14:19:06 compiled against Pd version 0.40.3 libdir_loader: added oscx to the canvas-local path [import] loaded library: oscx but then, still, OSCroute ... couldn't create. I also read that import only gets executed on startup, so I saved the patch and reopened/restarted pd, but still OSC couldn't create. only oscx/OSCroute works. declare -path oscx is also doing nothing. oh, wait! import -path oscx did the trick!!!
ok, here is what I get when I *only* use import -path oscx
[import] $Revision: 1.2 $ written by Hans-Christoph Steiner hans@at.or.at compiled on Feb 22 2008 at 14:19:06 compiled against Pd version 0.40.3 [import]: ERROR: can't load library in -path libdir_loader: added oscx to the canvas-local path [import] loaded library: oscx and then OSCroute ... couldn't create.
hmm, [import oscx -path oscx] gives some errors, but then it works
[import] $Revision: 1.2 $ written by Hans-Christoph Steiner hans@at.or.at compiled on Feb 22 2008 at 14:19:06 compiled against Pd version 0.40.3 libdir_loader: added oscx to the canvas-local path [import] loaded library: oscx [import]: ERROR: can't load library in -path libdir_loader: added oscx to the canvas-local path [import] loaded library: oscx
don't know, is that the way it is supposed to work??? marius.
Georg Holzmann wrote:
Hallo!
let's say I want to use OSCroute... I put an object [import oscx]. but OSCroute ... couldn't create only oscx/OSCroute works, and then I can also use OSCroute. I can import OSCroute, but only after I imported oscx.
Okay, which pd-extended version do you use ? I use the autobuild Pd version 0.40.3-extended-20080224 and I can do a [import oscx] and [OSCroute].
(of course you have to load the library "libdir" first, because thats the library loader - so yes, libdir should be loaded automatically)
Alternatively I can do [declare -lib oscx] and then [OSCroute] which should work with any pd version which supports [declare].
almost all the help patches that rely on one of these libraries are broken.
I changed the makefile at some time that all the helpfiles are also installed into the extra/library path. So everything worked basically. But I think these changes are not yet in the official released pd-extended ...
LG Georg
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
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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.
On Wed, 2008-03-05 at 21:57 -0500, 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.
argh.. sorry for the confusion.. i wanted to type:
[declare -path extra/oscx]
that is what actually is written in the helpfile. anyway, have a look at it.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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.
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.).
So for this upcoming Pd-extended release, I plan on focusing on this
problem and getting import/declare working well.
As for missing help files, please write them and submit them to the
bug tracker! Or submit a bug report!
.hc
Mistrust authority - promote decentralization. - the hacker ethic
On Mon, 2008-03-17 at 20:09 -0400, 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).
oh.. i really shouldn't have had done this mistake... actually there are even two.. blame myself!
test again with:
[declare -stdpath extra/oscx]
if THIS is not working, then write a bug report. this is at least working with pd-vanilla 0.40.3
three times sorry for the unnecessary confusion.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
sorry to say, but this is not working either... the object I am trying to create is [OSCroute]. I can create [oscx/OSCroute], but what I want to accomplish is to avoid the oscx prefix, so I tried [declare -stdpath extra/oscx] [declare -stdpath oscx] [declare -path extra/oscx] [declare -path oscx] [declare -stdlib extra/oscx] [declare -stdlib oscx] [declare -lib extra/oscx] [declare -lib oscx]
I even tried [declare -stdpath extra/oscx] in combination with import oscx. and I get a console printout saying [import] loaded library: oscx, but OSCroute ... couldn't create you know what is working? import oscx/OSCroute. but then, I have to add every single object? that method would be good for nameclashes if it would overwrite preexisting classes with that name... will file a but report. oh, and by the way sorry, couldn't find help patch for "declare.pd" (...no offence, just a bad day) marius.
Roman Haefeli wrote:
On Mon, 2008-03-17 at 20:09 -0400, 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).
oh.. i really shouldn't have had done this mistake... actually there are even two.. blame myself!
test again with:
[declare -stdpath extra/oscx]
if THIS is not working, then write a bug report. this is at least working with pd-vanilla 0.40.3
three times sorry for the unnecessary confusion.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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.
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
-
Georg Holzmann -
Hans-Christoph Steiner -
marius schebella -
Roman Haefeli