Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Hi Frank,
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch. However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's. These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
cheers Miller
On Sat, Jan 05, 2008 at 06:28:20PM +0100, Frank Barknecht wrote:
Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch.
This sounds similar to the problem my [polypoly] abstraction generates. [polypoly] is called with the name of an abstraction and dynamically creates several instances of that abstraction to simplify building polyphonic patches. Assuming polypoly.pd is in /poly/path which is part of the search path, then if a patch X.pd somewhere else is using [polypoly instrument] with instrument.pd next to X.pd, [polypoly] will not find instrument.pd, because polypoly.pd is in /poly/path and doesn't know about any instrument.pd. The fix is to either add the path to instrument.pd or copy polypoly.pd over to the directory of X.pd and instrument.pd.
The path to instrument.pd however cannot be added with [declare], as [declare] is and should be local to a canvas, which in this case is the parent's canvas, not the canvas of polypoly.pd.
However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's.
Yes, I agree.
These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
[declare] in abstractions was broken or inconsistent anyways (that's what my bug report was about) so I don't think anybody is depending on [declare] to work in a specific way for abstractions currently.
OTOH as every patch file could be used as an abstraction as well, making the use of a patch file as an abstraction a special case could be a recipe for trouble. ;)
So in the long run (e.g. for 0.42) some kind of specification how [declare -path X] should work in abstractions would be necessary.
I always thought of [declare] as an object that modifies settings for the local canvas only. I think, Hans' [import] does that and I believe it's sensible. But I may be missing possible side effects.
Anyway I would expect [declare -path DIR] to add "DIR" to the local canvas' searchpath with "DIR" relative to the current patch's path. Basically it would make an object in [DIR/file] be available as [file] as well. For absolute paths like [declare -path /DIR] it would add the absolute path. A declare in a parent patch then should not modify the path of an abstraction used.
However, as the polypoly-example and maybe some soundfiler use cases show, sometimes it can be useful or even necessary to access a parent's path settings. I don't know how to allow that in a useful way. Maybe with some additional option to declare like [declare -addparentpath]? Tricky ...
Ciao
On Jan 5, 2008, at 10:13 PM, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch.
This sounds similar to the problem my [polypoly] abstraction generates. [polypoly] is called with the name of an abstraction and dynamically creates several instances of that abstraction to simplify building polyphonic patches. Assuming polypoly.pd is in /poly/path which is part of the search path, then if a patch X.pd somewhere else is using [polypoly instrument] with instrument.pd next to X.pd, [polypoly] will not find instrument.pd, because polypoly.pd is in /poly/path and doesn't know about any instrument.pd. The fix is to either add the path to instrument.pd or copy polypoly.pd over to the directory of X.pd and instrument.pd.
The path to instrument.pd however cannot be added with [declare], as [declare] is and should be local to a canvas, which in this case is the parent's canvas, not the canvas of polypoly.pd.
However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's.
Yes, I agree.
These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
[declare] in abstractions was broken or inconsistent anyways (that's what my bug report was about) so I don't think anybody is depending on [declare] to work in a specific way for abstractions currently.
OTOH as every patch file could be used as an abstraction as well, making the use of a patch file as an abstraction a special case could be a recipe for trouble. ;)
So in the long run (e.g. for 0.42) some kind of specification how [declare -path X] should work in abstractions would be necessary.
I always thought of [declare] as an object that modifies settings for the local canvas only. I think, Hans' [import] does that and I believe it's sensible. But I may be missing possible side effects.
As it stands, [import] is a sketch of how I think the interface should work, and it currently uses the same code as [declare] to do its work. I am planning on working on this stuff more in the near future, hopefully we can come up with a simple, clean solution for all this. It would save us a lot of trouble, IMHO.
.hc
Anyway I would expect [declare -path DIR] to add "DIR" to the local canvas' searchpath with "DIR" relative to the current patch's path. Basically it would make an object in [DIR/file] be available as [file] as well. For absolute paths like [declare -path /DIR] it would add the absolute path. A declare in a parent patch then should not modify the path of an abstraction used.
However, as the polypoly-example and maybe some soundfiler use cases show, sometimes it can be useful or even necessary to access a parent's path settings. I don't know how to allow that in a useful way. Maybe with some additional option to declare like [declare -addparentpath]? Tricky ...
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television
On Sat, 2008-01-05 at 10:32 -0800, Miller Puckette wrote:
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
yes, i am using [declare]s in abstractions (using the flag -stdlib).
are [declare]s in abstractions ignored completely or just the flags '-path' and '-stdpath'? i would expect [declare -[std]lib xxx] to be common practice within abstractions, since it's an odd thing to be forced in the parent patch to keep track of the externals used in its abstractions.
besides that, i agree with frank, that it makes using [declare <whatever flag>] very troublesome, if it makes the patch behave differently when loaded as patch from when loaded as an abstraction. although i couldn't find something in the docu saying explicitly that abstractions always behave the same as if they were opened as a patch, i know of some projects (including netpd) that implicitly rely on this rule. personally i think that breaking this rule introduces willingly an inconsistency.
i strongly hope that [declare] is going to be fixed sooner or later and by saying that, i hope that it would work in abstractions as well, namely in a manner, that frank described in his very last mail.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
are [declare]s in abstractions ignored completely or just the flags '-path' and '-stdpath'? i would expect [declare -[std]lib xxx] to be common practice within abstractions, since it's an odd thing to be forced in the parent patch to keep track of the externals used in its abstractions.
Only path settings seem to be ignored.
Ciao
On Sun, 2008-01-06 at 12:41 +0100, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
are [declare]s in abstractions ignored completely or just the flags '-path' and '-stdpath'? i would expect [declare -[std]lib xxx] to be common practice within abstractions, since it's an odd thing to be forced in the parent patch to keep track of the externals used in its abstractions.
Only path settings seem to be ignored.
excuse me, if that is a dumb question, but are there ambiguities with -stdpath? since this one is always relative to pd, whether it is called from a patch or an abstraction, i don't see what troubles it could cause, if it would just work.
why should [declare -stdlib extra/zexy] work, but not [declare -stdpath extra/list-abs] ?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hi miller
will [declare -stdpath] work inside abstractions?
thanks roman
On Sat, 2008-01-05 at 10:32 -0800, Miller Puckette wrote:
Hi Frank,
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch. However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's. These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
cheers Miller
On Sat, Jan 05, 2008 at 06:28:20PM +0100, Frank Barknecht wrote:
Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Frank Barknecht _ ______footils.org__
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
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
At teh moment, "-stdpath" and "-nostdpath" work inside abstractions, and if you have a calling patch that declares the opposite, it's not clear which overrides which. (There's only one global path in effect that affects both the main patch and all abstractions called up by it). So there's no situation that I can think of in which it's a good idea to use "-stdpath" or "-nostdpath" in an abstraction. However, I'm scared to take it away so late in the release cycle so will leave it standing for now.
cheers Miller
On Wed, Jan 16, 2008 at 02:03:44PM +0100, Roman Haefeli wrote:
hi miller
will [declare -stdpath] work inside abstractions?
thanks roman
On Sat, 2008-01-05 at 10:32 -0800, Miller Puckette wrote:
Hi Frank,
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch. However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's. These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
cheers Miller
On Sat, Jan 05, 2008 at 06:28:20PM +0100, Frank Barknecht wrote:
Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Frank Barknecht _ ______footils.org__
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
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hi
hm, there seems to be confusion, but i am not quite sure, if it is me or you.
according to the helpfile of [declare] the flag '-stdpath' adds the specified path to the searchpath and afaik (this is not written in the help-file, but actual behaviour in 0.40) it does add it only to the searchpath of the calling patch and all its abstractions. the 'std' part stands for 'relative to pd'. there is no flag '-nostdpath' mentioned in the helpfile. your response sounds to me, as if you are mixing up '-stdpath' for [declare] with the flags '-stdpath'/'-nostdpath' for the commandline, which do something different (enable/disable searching the extra directory).
excuse me, if i am totally missing your point here. if so, please help me clarify the confusion.
roman
On Wed, 2008-01-16 at 07:54 -0800, Miller Puckette wrote:
At teh moment, "-stdpath" and "-nostdpath" work inside abstractions, and if you have a calling patch that declares the opposite, it's not clear which overrides which. (There's only one global path in effect that affects both the main patch and all abstractions called up by it). So there's no situation that I can think of in which it's a good idea to use "-stdpath" or "-nostdpath" in an abstraction. However, I'm scared to take it away so late in the release cycle so will leave it standing for now.
cheers Miller
On Wed, Jan 16, 2008 at 02:03:44PM +0100, Roman Haefeli wrote:
hi miller
will [declare -stdpath] work inside abstractions?
thanks roman
On Sat, 2008-01-05 at 10:32 -0800, Miller Puckette wrote:
Hi Frank,
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch. However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's. These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
cheers Miller
On Sat, Jan 05, 2008 at 06:28:20PM +0100, Frank Barknecht wrote:
Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Frank Barknecht _ ______footils.org__
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
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Oops, no, you're right, it's a mistake on my part to have used the same name as a Pd flag to mean something different... now I have to go back and figure out what the hell I could have been thinking :)
I should have made "declare" reject "-stdpath" in abstractions in the same way as I made it reject "-path". Furthermore I should probably deprecate the name (but keep it forever for compatibility) and start suggesting a better one.
cheers Miller
On Wed, Jan 16, 2008 at 05:48:21PM +0100, Roman Haefeli wrote:
hi
hm, there seems to be confusion, but i am not quite sure, if it is me or you.
according to the helpfile of [declare] the flag '-stdpath' adds the specified path to the searchpath and afaik (this is not written in the help-file, but actual behaviour in 0.40) it does add it only to the searchpath of the calling patch and all its abstractions. the 'std' part stands for 'relative to pd'. there is no flag '-nostdpath' mentioned in the helpfile. your response sounds to me, as if you are mixing up '-stdpath' for [declare] with the flags '-stdpath'/'-nostdpath' for the commandline, which do something different (enable/disable searching the extra directory).
excuse me, if i am totally missing your point here. if so, please help me clarify the confusion.
roman
On Wed, 2008-01-16 at 07:54 -0800, Miller Puckette wrote:
At teh moment, "-stdpath" and "-nostdpath" work inside abstractions, and if you have a calling patch that declares the opposite, it's not clear which overrides which. (There's only one global path in effect that affects both the main patch and all abstractions called up by it). So there's no situation that I can think of in which it's a good idea to use "-stdpath" or "-nostdpath" in an abstraction. However, I'm scared to take it away so late in the release cycle so will leave it standing for now.
cheers Miller
On Wed, Jan 16, 2008 at 02:03:44PM +0100, Roman Haefeli wrote:
hi miller
will [declare -stdpath] work inside abstractions?
thanks roman
On Sat, 2008-01-05 at 10:32 -0800, Miller Puckette wrote:
Hi Frank,
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch. However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's. These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
cheers Miller
On Sat, Jan 05, 2008 at 06:28:20PM +0100, Frank Barknecht wrote:
Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Frank Barknecht _ ______footils.org__
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
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2008-01-16 at 08:54 -0800, Miller Puckette wrote:
Oops, no, you're right,
ah ok :-)
I should have made "declare" reject "-stdpath" in abstractions in the same way as I made it reject "-path".
hm.. why?
the '-stdpath' flag is perfectly working as expected in 0.40.3, in patches as well as in abstractions. i don't see a need to change it/disabling it inside abstractions. if [declare -stdpath extra/blah] is called inside [myabs], 'extra/blah' is only added to the searchpath of [myabs], but not to the searchpath of the parent patch, which is exactly what one would expect.
since the introduction of [declare] i (and maybe others as well?) changed my strategy to deal with pathes. instead of loading all possible pathes beforehand with the pd-settings file or .pdrc, i specify explicitly in each patch (whether used as patch or as abstraction), which pathes to add to the search path. this practice has the advantage of avoiding nameclashes (since pathes are added only locally) while at the same time not being forced to use namespaces (which for many externals work only in extended). because using [declare -stdpath] seemed to be so straightforward to me, i started using it all over the place, also in abstractions. (just for the record: it would definitely break some of my patches, if it would be disabled inside abstractions).
i hope i could make my point clear, that [declare -stdpath] is working in a useful, meaningful and particularly obvious way in 0.40.3, so i hope there is no need to change it for 0.41.
'-path' is another story, though.
Furthermore I should probably deprecate the name (but keep it forever for compatibility) and start suggesting a better one.
personally i come along easily with the name '-stdpath', but i wouldn't mind if it would be changed.
roman
cheers Miller
On Wed, Jan 16, 2008 at 05:48:21PM +0100, Roman Haefeli wrote:
hi
hm, there seems to be confusion, but i am not quite sure, if it is me or you.
according to the helpfile of [declare] the flag '-stdpath' adds the specified path to the searchpath and afaik (this is not written in the help-file, but actual behaviour in 0.40) it does add it only to the searchpath of the calling patch and all its abstractions. the 'std' part stands for 'relative to pd'. there is no flag '-nostdpath' mentioned in the helpfile. your response sounds to me, as if you are mixing up '-stdpath' for [declare] with the flags '-stdpath'/'-nostdpath' for the commandline, which do something different (enable/disable searching the extra directory).
excuse me, if i am totally missing your point here. if so, please help me clarify the confusion.
roman
On Wed, 2008-01-16 at 07:54 -0800, Miller Puckette wrote:
At teh moment, "-stdpath" and "-nostdpath" work inside abstractions, and if you have a calling patch that declares the opposite, it's not clear which overrides which. (There's only one global path in effect that affects both the main patch and all abstractions called up by it). So there's no situation that I can think of in which it's a good idea to use "-stdpath" or "-nostdpath" in an abstraction. However, I'm scared to take it away so late in the release cycle so will leave it standing for now.
cheers Miller
On Wed, Jan 16, 2008 at 02:03:44PM +0100, Roman Haefeli wrote:
hi miller
will [declare -stdpath] work inside abstractions?
thanks roman
On Sat, 2008-01-05 at 10:32 -0800, Miller Puckette wrote:
Hi Frank,
Well, I can't remember now if I was looking at that bug report or if I was having my own problems with declare (I've had many). I had bad confusion making abstractions use "soundfiler", for instance, and having relative paths get expanded relative to the abstraction instead of the calling patch. However, when an abstraction opens a sub-abstraction as in "x/y", I think it's best to have x/y be relative to the abstraction's location and not the calling patch's. These two needs seem in direct conflict. I hope to figure out a better way to handle this but have given up trying to resolve it for 0.41.
I hope nobody is yet throwing "declare" objects in abstractions, as that currently does something so wrong (altering the global path for the calling patch!?) that I thought it better to get rid of the whole thing for now.
cheers Miller
On Sat, Jan 05, 2008 at 06:28:20PM +0100, Frank Barknecht wrote:
Hi,
I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes:
Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored.
Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why?
The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd
I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path.
Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing.
Ciao
Frank Barknecht _ ______footils.org__
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
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Frank Barknecht -
Hans-Christoph Steiner -
Miller Puckette -
Roman Haefeli