hi
a new window opened in an existing patch becomes completely part of the overall name-space. but the declares are NOT applied.
why, is it by design?
it seems illogical, especially now the declares rule from the top-level patch.
rolf
On 01/03/2017 08:37 PM, rolfm@dds.nl wrote:
hi
a new window opened in an existing patch becomes completely part of the overall name-space.
i'm either unable to parse this sentence or to grok its meaning.
but the declares are NOT applied.
which declares?
why, is it by design?
which version of Pd are you using? Pd-0.47 has seen signifcant changes to how [declare] works.
gfamsrd IOhannes
i try again: working on a big patch, i open a new, empty window.
in this window it's possible to refer to names in the whole patch, do send and receive etc.
however, the libs which are declared in the main patch (when loaded) are not available in this new window.
is there a design reason for this?
On 01/03/2017 08:37 PM, rolfm@dds.nl wrote:
hi
a new window opened in an existing patch becomes completely part of the overall name-space.
i'm either unable to parse this sentence or to grok its meaning.
but the declares are NOT applied.
which declares?
why, is it by design?
which version of Pd are you using? Pd-0.47 has seen signifcant changes to how [declare] works.
gfamsrd IOhannes
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
Actually currently the paths are searched as follows (for [declare -path] paths):
- searchpaths declared locally in the abstraction* applied to the topmost
patch's directory*
- searchpaths declared in the containing abstraction* applied to the
topmost patch's directory*
- searchpaths declared in the grandparent abstraction* applied to the
topmost patch's directory*
- ...
I've proposed a patch that would search:
- searchpaths declared locally in the abstraction *applied to the
abstraction's directory then* to the topmost patch's directory
- searchpaths declared in the containing abstraction *applied to the
**containing abstraction's directory then* to the topmost patch's directory
- searchpaths declared in the grandparent abstraction *applied to the
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
-
Antoine Rousseau -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
rolfm＠dds.nl