Okay, here's a first pass to outline what's going on with Pd's library
loader(s):
http://www.jonathanwilkes.net/2014/10/loading-a-library-in-pure-data/
I don't cover the interaction between global and canvas-local searchpaths, nor
how exactly the libdir loader from Pd-extended does its thing. If anyone finds
errors let me know and I'll correct them.
-Jonathan
On Monday, October 20, 2014 5:43 PM, katja <[email protected]> wrote:
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
