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 > > > > > [email protected] > > > > > http://lists.puredata.info/listinfo/pd-dev > > > > > > > > _______________________________________________ > > > > PD-dev mailing list > > > > [email protected] > > > > 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 _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
