[PD] canvas path

[katja]

Thanks for demonstrating [declare -path .], Frank. Food for thought.



On Mon, Oct 20, 2014 at 8:54 PM, Frank Barknecht <fbar at 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:
> > > 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
> >
> > > _______________________________________________
> > > Pd-list at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> --
>  Frank Barknecht                                     _ ______footils.org__
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141020/fbffb20a/attachment.html>