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 > > > > > > [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 ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
