On Sat, 2016-01-16 at 20:44 -0800, Miller Puckette wrote:
OK.. applied these. Will vomment on one question below.... On Fri, Jan 15, 2016 at 04:25:47PM +0100, IOhannes m zmölnig wrote:
On 01/15/2016 11:12 AM, Roman Haefeli wrote:
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?
i think so. i cannot think of a reason why it should be different.
Well, "-path" works differently (only relative to the calling patch). If indeed "-lib" additionally searches "standard" paths it would seem more sensible to make it act like "-path" - that gives the user the most control.
Quite possibly I'm misunderstanding something though. The whole path/lib thing has become too complicated for me...
At least, we seem to have a similar understanding. Also, I believe to know that "-lib" used to _not_ search standard paths, but _only_ relative to the calling patch. I'm undecided whether the new behavior is advantage, but it is different from before.
Roman