Actually currently the paths are searched as follows (for [declare -path] paths):
patch's directory*
topmost patch's directory*
topmost patch's directory*
I've proposed a patch that would search:
abstraction's directory then* to the topmost patch's directory
**containing abstraction's directory then* to the topmost patch's directory
grandparent abstraction's directory then* to the topmost patch's directory
This would allow to harmlessly turn a top-level patch into an abstraction (e.g located in another directory than caller's one), even if it uses [declare]s.
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-01-05 16:14 GMT+01:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2017-01-05 12:50, rolfm@dds.nl wrote:
however, the libs which are declared in the main patch (when loaded) are not available in this new window.
the only way this makes sense to me is if with "libs" you mean "paths" (to abstractions). traditional libraries (binary files containing one or more objects) will be loaded into global namespace.
with the "libdir" loader, the distinction has (unfortunately) become blurry.
is there a design reason for this?
the paths are searched as follows:
- searchpaths declared locally in the abstraction
- searchpaths declared in the containing abstraction
- searchpaths declared in the grandparent abstraction
- ...
- global searchpaths (preferences/startup-flags)
in your example you have two top-level patches: "the big main window" and the newly created window. since they are unrelated, they don't share any paths declared in any of them.
this is of course by design, and is inspired by module loading in other languages. (e.g. "import" in python)
fgmsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list