Thanks for demonstrating [declare -path .], Frank. Food for thought.
On Mon, Oct 20, 2014 at 8:54 PM, Frank Barknecht fbar@footils.org 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:
- patch author makes a patch
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)
- 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:
- 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Frank Barknecht _ ______footils.org__
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list