On 22/07/10 05:09, Miller Puckette wrote:

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