[PD-dev] 0.43 omission: 'set-startup' and 'set-path'

[Claude Heiland-Allen]

On 22/07/10 05:09, Miller Puckette wrote:
> Oh yes, and -lib itself needs somehow to be made to work locally to the
> patch, but this is a huge issue I don't know how to deal with.

At first glance it should be possible to have canvas-local objectmakers 
and have the "put on load list" put the absolute pathname of the dll 
instead of just the name, but maybe there are some libraries that simply 
cannot be dlopen()d more than once by the same executable due to 
clashing exported symbols or so?  I don't know enough about dlopen() to say!

I'm sorta working on this, but there are a whole nest of things all 
interconnected with each other:

1. paths and search order, currently it's roughly this afaict:
    a. search relative to patch
    b. search this patch's declared paths
    c. search relative to parents (a and b)
    d. search global paths

2. loader plugins
    currently plugins have to do their own searching
    which means it's not consistent with "local first" priorities
    (ie, foo.pd next to the patch is overriden by some random library)

3. libraries and import scopes/namespaces
    a. libraries can register multiple objects, which might nameclash
    b. import/declare should have a way to bring only certain names
       from a library into "unqualified" scope
       eg: [import Gem maxlib maxlib/scale]
       then [scale] would be from maxlib
       and [Gem/scale] and [maxlib/scale] would work too
    c. http://lists.puredata.info/pipermail/pd-dev/2010-07/015606.html
       section "Clearer Error Messages" explains more

4. abstractions
    kinda second class citizens because they can't register classes
    how about if an abstraction is found, it is registered magically?
    enabling caching, but what if the file is modified outside of pd?

5. efficiency
    checking 100 or more files for a failed object is excessive
    especially if this is repeated many times


Claude
-- 
http://claudiusmaximus.goto10.org