hi all
i have [tcpserver] from mrpeach installed in:
/usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux
and i have a patch with:
[declare -stdpath extra/mrpeach]
[tcpserver]
however, [tcpserver] doesn't instantiate. as verbose output i get:
tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create
it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file)
i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it.
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
hi all
i have [tcpserver] from mrpeach installed in:
/usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux
and i have a patch with:
[declare -stdpath extra/mrpeach]
[tcpserver]
however, [tcpserver] doesn't instantiate. as verbose output i get:
tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create
it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file)
i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it.
Yes it never works for me either on pd-extended; you have to do [mrpeach/tcpserver], or take tcpserver.pd_linux out of mrpeach and put it into /usr/local/lib/pd/extra.
Martin
Hi Roman,
Not sure if this is the problem, but I had similar troubles like this, and to solve the issue, I saved the patch that contains the [declare] in it, and then reopened it. I guess the issue here is that declare really only operates when a patch is first opened from a file. (I could be wrong on this...)
Mike
On Tue, Aug 12, 2008 at 2:58 PM, Roman Haefeli reduzierer@yahoo.de wrote:
hi all
i have [tcpserver] from mrpeach installed in:
/usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux
and i have a patch with:
[declare -stdpath extra/mrpeach]
[tcpserver]
however, [tcpserver] doesn't instantiate. as verbose output i get:
tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create
it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file)
i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it.
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2008-08-12 at 17:42 -0500, Mike McGonagle wrote:
Hi Roman,
Not sure if this is the problem, but I had similar troubles like this, and to solve the issue, I saved the patch that contains the [declare] in it, and then reopened it. I guess the issue here is that declare really only operates when a patch is first opened from a file. (I could be wrong on this...)
no, you are fully right and i also was aware of this. when testing with binary files (as opposed to abstractions) it gets even trickier: it seems that pd holds a list for the namespace of binary classes, whereas it seems, that abstractions are always searched in the filesystem. which means, that when you once have successfully instantiated an object from a binary class (for example [mrpeach/tcpserver]), then [tcpserver] will instantiate as well (during the whole pd session). this means, that in certain cases it is not even sufficient to reload the patch in order to realiably test [declare], but you would have to restart pd to get rid of the registered classes.
personally i dislike the fact, that binary single object classes behave so differently from abstractions. this means, that patches using [abs~] from extra/zexy might have worked well with the binary 'extra/zexy/abs~.pd_linux', but when it is replaced by 'extra/zexy/abs~.pd' the same patch probably doesn't work as it did before.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Aug 13, 2008, at 5:22 AM, Roman Haefeli wrote:
On Tue, 2008-08-12 at 17:42 -0500, Mike McGonagle wrote:
Hi Roman,
Not sure if this is the problem, but I had similar troubles like this, and to solve the issue, I saved the patch that contains the [declare] in it, and then reopened it. I guess the issue here is that declare really only operates when a patch is first opened from a file. (I could be wrong on this...)
no, you are fully right and i also was aware of this. when testing with binary files (as opposed to abstractions) it gets even trickier: it seems that pd holds a list for the namespace of binary classes, whereas it seems, that abstractions are always searched in the filesystem. which means, that when you once have successfully instantiated an object from a binary class (for example [mrpeach/tcpserver]), then [tcpserver] will instantiate as well (during the whole pd session). this means, that in certain cases it is not even sufficient to reload the patch in order to realiably test [declare], but you would have to restart pd to get rid of the registered classes.
personally i dislike the fact, that binary single object classes behave so differently from abstractions. this means, that patches using [abs~] from extra/zexy might have worked well with the binary 'extra/zexy/abs~.pd_linux', but when it is replaced by 'extra/zexy/abs~.pd' the same patch probably doesn't work as it did before.
Yes, I agree. This is the biggest thing that needs to be solved for complete namespace support. I hope to work on this in a couple monthes...
.hc
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
hi roman,
thanks for bringing this one up :). just tested it on OSX and here is what I got: it has some effect, but not as supposed. It extends the path relative to the directory of the pdpatch (and not as stated in the help "relative to Pd"). in your case: it seems your testpatch resides in /home/roman/testpatch97.pd. therefor [declare -stdpath extra/mrpeach] extends the searchpath to /home/roman/extra/mrpeach. so all the lines that contain "tried /home/roman/extra/mrpeach/..." are a result of the declare object.
The behaviour is definitely not as written in the docs, but it kind of makes sense to make relative declarations always relative to the file location as opposed to the pd binary.
so you can decide what exactly the bug is, the wrong behaviour or the wrong documentation.
regarding the "relative to what?" question, I think both behaviours could be useful (rel to patch and rel to Pd). Maybe "declare -stdpath" should actually be "declare -relpath" (relative to the patch) and "declare -rel2pdpath" (relative to the pd binary), but then is the directory of "pd binary" really the directory that all paths should be relative to? or as some other people already suggested, make it relative to the directory that holds the "bin" and the "extra" (and the "src") folder.
marius.
Roman Haefeli wrote:
hi all
i have [tcpserver] from mrpeach installed in:
/usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux
and i have a patch with:
[declare -stdpath extra/mrpeach]
[tcpserver]
however, [tcpserver] doesn't instantiate. as verbose output i get:
tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create
it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file)
i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it.
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
ouch, this is a bug in that case. On my dolist to check it out...
cheers M
On Tue, Aug 12, 2008 at 06:47:50PM -0400, marius schebella wrote:
hi roman,
thanks for bringing this one up :). just tested it on OSX and here is what I got: it has some effect, but not as supposed. It extends the path relative to the directory of the pdpatch (and not as stated in the help "relative to Pd"). in your case: it seems your testpatch resides in /home/roman/testpatch97.pd. therefor [declare -stdpath extra/mrpeach] extends the searchpath to /home/roman/extra/mrpeach. so all the lines that contain "tried /home/roman/extra/mrpeach/..." are a result of the declare object.
The behaviour is definitely not as written in the docs, but it kind of makes sense to make relative declarations always relative to the file location as opposed to the pd binary.
so you can decide what exactly the bug is, the wrong behaviour or the wrong documentation.
regarding the "relative to what?" question, I think both behaviours could be useful (rel to patch and rel to Pd). Maybe "declare -stdpath" should actually be "declare -relpath" (relative to the patch) and "declare -rel2pdpath" (relative to the pd binary), but then is the directory of "pd binary" really the directory that all paths should be relative to? or as some other people already suggested, make it relative to the directory that holds the "bin" and the "extra" (and the "src") folder.
marius.
Roman Haefeli wrote:
hi all
i have [tcpserver] from mrpeach installed in:
/usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux
and i have a patch with:
[declare -stdpath extra/mrpeach]
[tcpserver]
however, [tcpserver] doesn't instantiate. as verbose output i get:
tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create
it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file)
i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it.
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
hi (miller),
for the project I am currently working on, I would need exactly this behaviour: a path declaration relative to the directory of a pd-file.
I put all abstractions in a subfolder 'abs'. It would be extremely useful if [declare -stdpath abs] (or some other command) would add this subfolder to the searchpath for abstractions/libs. and more than that, it would be perfect, if it would add that path at the beginning of the directories to be searched. so that I could guarantee that the objects from the 'abs' folder are the ones that get loaded, even if there are other object classes that have the same name.
afaict that is how it is working now, but you said 'this is a bug'. it is a really useful bug, and maybe we can keep it somehow. or implement exactly this feature under a different name.
marius.
Miller Puckette wrote:
ouch, this is a bug in that case. On my dolist to check it out...
cheers M
On Tue, Aug 12, 2008 at 06:47:50PM -0400, marius schebella wrote:
hi roman,
thanks for bringing this one up :). just tested it on OSX and here is what I got: it has some effect, but not as supposed. It extends the path relative to the directory of the pdpatch (and not as stated in the help "relative to Pd"). in your case: it seems your testpatch resides in /home/roman/testpatch97.pd. therefor [declare -stdpath extra/mrpeach] extends the searchpath to /home/roman/extra/mrpeach. so all the lines that contain "tried /home/roman/extra/mrpeach/..." are a result of the declare object.
The behaviour is definitely not as written in the docs, but it kind of makes sense to make relative declarations always relative to the file location as opposed to the pd binary.
so you can decide what exactly the bug is, the wrong behaviour or the wrong documentation.
regarding the "relative to what?" question, I think both behaviours could be useful (rel to patch and rel to Pd). Maybe "declare -stdpath" should actually be "declare -relpath" (relative to the patch) and "declare -rel2pdpath" (relative to the pd binary), but then is the directory of "pd binary" really the directory that all paths should be relative to? or as some other people already suggested, make it relative to the directory that holds the "bin" and the "extra" (and the "src") folder.
marius.
Roman Haefeli wrote:
hi all
i have [tcpserver] from mrpeach installed in:
/usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux
and i have a patch with:
[declare -stdpath extra/mrpeach]
[tcpserver]
however, [tcpserver] doesn't instantiate. as verbose output i get:
tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver .... couldn't create
it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file)
i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it.
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2008-08-12 at 18:47 -0400, marius schebella wrote:
hi roman,
thanks for bringing this one up :). just tested it on OSX and here is what I got: it has some effect, but not as supposed. It extends the path relative to the directory of the pdpatch (and not as stated in the help "relative to Pd"). in your case: it seems your testpatch resides in /home/roman/testpatch97.pd. therefor [declare -stdpath extra/mrpeach] extends the searchpath to /home/roman/extra/mrpeach. so all the lines that contain "tried /home/roman/extra/mrpeach/..." are a result of the declare object.
yeah, you're right: declare is not completely ignored in this case, but extends the pathes relative to patch instead of pd.
however, miller already confirmed the bug.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Hans-Christoph Steiner -
marius schebella -
Martin Peach -
Mike McGonagle -
Miller Puckette -
Roman Haefeli