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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
