On Wed, 2016-01-13 at 00:54 +0100, IOhannes m zmölnig wrote:
On 01/12/2016 11:56 PM, IOhannes m zmölnig wrote:
On 01/12/2016 11:34 PM, IOhannes m zmölnig wrote:
i will check this immediately.
actually it turns out that loading anything via it's absolute path is broken (and [declare -stdlib] uses this):
e.g. [/usr/lib/pd/extra/zexy/zexy] fails now.
which means that the culprit is really in the new loader code (unrelated to [declare]).
anyhow, attached you find two patches that supposedly fix this problem.
0001: does special handling for absolute paths (which was stripped out in my loader rewrite - on purpose, but accidentally no replacement was provided), by trying to load them first (if applicable).
0002: fixes the extra/ stripping/appending when generating the absolute pathnames for stdlib/stdpath.
Thanks for the fix(es). [declare -stdlib] works again for me.
Unlike specified in the help, -lib now searches both, relative to the patch _and_ standard paths, while -stdlib only searches standard paths and is in accordance to the documentation. Is that intended?
The immediate effect of [declare] is a great advancement. Thanks for working on that!
[declare] used to add a line to the beginning of the patch file, like:
#X declare -stdlib zexy;
I assumed this was added so that on next load of the patch it takes effect before the rest of the patch was loaded. Now that [declare] has immediate effect, is that line still necessary? It seems it is (when removing it, the loading doesn't happen anymore), but why? I'm asking because when using [declare] in abstractions, those lines "pollute" the parent patch. Even without a [declare] object in the patch, such lines have an effect on loading, so you end up with a parent patch that secretly loads stuff without the user noticing.
Roman