[PD-dev] "declare" strangeness in abstractions (0.41 test10)

[Miller Puckette]

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 at iem.at
> > > > > http://lists.puredata.info/listinfo/pd-dev
> > > > 
> > > > _______________________________________________
> > > > PD-dev mailing list
> > > > PD-dev at 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