Thanks for demonstrating [declare -path .], Frank. Food for thought.
On Mon, Oct 20, 2014 at 8:54 PM, Frank Barknecht <[email protected]> wrote: > Hi, > > here's some more food for thought: How to deal with library abstractions > that > load other objects whose name is set at runtime? This is actually pretty > common, for example in abstractions that decorate other abstraction with > e.g. > polyphony, or when writing soundfile/score loading objects. > > I attached a test case that illustrates various combinations one may meet > in > this case. > > Please start Pd in the directory "metaprog" and open: > > 01_loadhere.pd > 02_loadhere-declare-mylib.pd > 03_loadhere-declare-dot.pd > > Ciao > -- > Frank > > > On Mon, Oct 20, 2014 at 08:34:13AM -0700, Miller Puckette wrote: > > Hi all, > > > > I think it might work simply to maintain a per-patch list of "externs" > > currently loaded. New patches would start out with an empty list, which > would > > then get filled in by that patch's own search procedures. > > > > There might be some complicated problems to resove about such searche > within > > abstractions (indeed, there are already severe problems the way that is > set > > up that I want to try to fix.) > > > > cheers > > Miller > > > > Oe Sun, Oct 19, 2014 at 11:21:15AM -0700, Jonathan Wilkes via Pd-list > wrote: > > > Hi list, > > > Let me describe a typical way to use Pd: > > > 1) patch author makes a patch > > > 2) > > > patch author abstracts out certain functions into Pd abstractions > > > 3) patch author makes a self-contained collection of these > abstractions (and maybe some helper abstractions) > > > 4) patch author takes every _reasonable_ step to make their collection > portable-- that is, to ensure that their abstractions and nested > abstractions create correctly on any version of Pd and don't collide with > anything in the standard library path. > > > > > > Currently a patch author cannot achieve this. Pure data forces them > to care about what names pre-existing externals might have (which is > probably why many externals make a common name prefix part of the name of > each object). The reason is that an abstraction's directory is not the > first place to be searched for externals or abstractions to be loaded. It > is superceded by the searchpath set by [declare] for all of that > abstraction's parent canvases. > > > > > > If any of those parent canvases declare a path which > > > has an external or abstraction by the same name as one of the helper > abstractions, the object in that path will get created instead of the > helper abstraction. Furthermore, if any of those parent canvases declare a > path that happens to have the same name as the subdirectory containing the > helper abstraction, then "path/objectname" will override > "subdirectory/helper". This is even true if you use > "./subdirectory/helper". > > > > > > This means that if the patch author wants to grope toward portability > they have to do this, too: > > > 5) read/search all the libnames and object names in pd-extended, and > all the other widely used libs and objects scattered about the internet. > Then come up with a name that is human readable, but also unique enough to > prevent collisions with anything else out there. > > > > > > I think #5 is unreasonable, especially because creating a little > zipped directory with abstractions (or even externals) is such a common way > of > > > making ostensibly portable libraries in Pd. Essentially we're asking > users to do their own name-mangling. > > > > > > So why isn't an abstraction's directory the _first_ one to be searched > by default in Pd? I understand katja and Matt Barber's reasons for using > [declare] to infect an entire running instance with different path > priorities, but I think that's the exception rather than the rule. Can we > give abstraction directories precedence in the loading scheme, and maybe > use a startup flag to trigger Pd's current behavior? > > > > > > -Jonathan > > > > > _______________________________________________ > > > [email protected] mailing list > > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- > Frank Barknecht _ ______footils.org__ > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
