Hey all
I see some commits in git trying to 'fix' [declare]. While I definitely appreciate it taking immediate effect, the -stdlib flag doesn't work for me anymore (the way I expect it). Probably there is still some confusion about the meaning of the flags, or they are intentionally changed without updating the documentation.
So, what's the deal with, for instance, [declare -stlib zexy]? With current git master only [declare -lib zexy] works (which did only work if zexy was installed near the patch in previous version of Pd). Is that switch intentional?
Roman
On 01/12/2016 10:39 PM, Roman Haefeli wrote:
Hey all
I see some commits in git trying to 'fix' [declare]. While I definitely appreciate it taking immediate effect, the -stdlib flag doesn't work for me anymore (the way I expect it). Probably there is still some confusion about the meaning of the flags, or they are intentionally changed without updating the documentation.
So, what's the deal with, for instance, [declare -stlib zexy]? With current git master only [declare -lib zexy] works (which did only work if zexy was installed near the patch in previous version of Pd). Is that switch intentional?
ouch no. i will check this immediately.
gmadr IOhannes
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.
gfrdsa IOhannes
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
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.
The immediate effect of [declare] is a great advancement. Thanks for working on that!
great that you like it.
[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.
yes.
Now that [declare] has immediate effect, is that line still necessary?
yes.
when you do interactive patching, you don't expect a [declare -lib zexy] that you haven't created yet to take an effect.
but when loading an abstraction containing [declare -lib zexy] you want it to be able to use the zexy objects, regardless of when the [declare] object gets instantiated. (imagine: you have added "-lib zexy" to your startup flags, so *you* don't really need [declare -lib zexy]; now you create an abstraction that uses [list2sybmol]; then you remember that you should declare a dependency (for other users) and add the [declare] object)
the "line at the beginning of the patch" takes care of this.
It seems it is (when removing it, the loading doesn't happen anymore), but why?
because you don't want to load the library multiple times.
I'm asking because when using [declare] in abstractions, those lines "pollute" the parent patch.
do they? afaict d76b2e (or my original 2nd part of the patch, which was somehow forgotten) has fixed this.
gfmsdr IOhannes
On Fri, 2016-01-15 at 16:25 +0100, IOhannes m zmölnig wrote:
On 01/15/2016 11:12 AM, Roman Haefeli wrote:
I'm asking because when using [declare] in abstractions, those lines "pollute" the parent patch.
do they? afaict d76b2e (or my original 2nd part of the patch, which was somehow forgotten) has fixed this.
No, not anymore! Sorry for not having checked this, I noticed it puts still a line at the beginning and thought that also means it pollutes parents, but it doesn't.
Good! Thanks!
Roman
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...
cheers Miller
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
On 2016-01-18 09:27, Roman Haefeli wrote:
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.
so if i create a patch that depends on a library (e.g. "zexy"), and i want people to be able to use it straight away i would: - compile zexy for my platform (w32) - put it into a zexy/ directory besides my patch. - use [declare -lib zexy]
now zmoelnig would like to use my patch, but they are linux freaks. so they install the "pd-zexy" package, which installs zexy into /usr/lib/pd/extra. but they still cannot use the patch, since the library is not found.
so i really would need to add a - [declare -lib zexy -stdlib zexy]
but this is wrong again, since now woelnig, who is a dickheaded w32 user who has installed zexy systemwide in %AppData%\Pd\zexy will have the wrong zexy loaded: - "-lib zexy" will be called first, loading the embedded copy of zexy - "-stdlib zexy" will be called second, loading the system installed copy of zexy, which will overwrite all the zexy-provided classes from the embedded copy (and output a lot of warnings along the lines of
warning: class 'z~' overwritten; old one renamed 'z~_aliased'
so i *really* need to add a - [declare -stdlib zexy -lib zexy]
to be sure to use the local copy of zexy and fall back to a system installed copy.
i'm pretty sure i cannot see the obvious though. so if you have some use-cases (where it would make sense to not search stdpath; how to make use of that additional "control",...) i would be thankful...
Quite possibly I'm misunderstanding something though. The whole path/lib thing has become too complicated for me...
ouch. i guess i shall do some documentation then.
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.
are you sure?
i just tested with Pd-0.46-7 (as shipped with Debian; please note that Debian does some slight modification to the stdpath).
$ cat foo.pd #N canvas 416 252 450 300 10; #X declare -lib zexy; #X obj 151 152 declare -lib zexy;
$ pd -noprefs -verbose
then i create a new patch, and instantiate the [foo] object. according to the verbose-printout, zexy is loaded from /usr/lib/pd/extra/zexy, which afaik is the std-search path.
tried /tmp/zmoelnig/zexy.l_ia64 and failed tried ./zexy.l_ia64 and failed tried /Net/iem/Benutzer/zmoelnig/pd-externals/zexy.l_ia64 and failed tried /usr/local/lib/pd-externals/zexy.l_ia64 and failed tried /usr/lib/puredata/extra/zexy.l_ia64 and failed tried /usr/lib/pd/extra/zexy.l_ia64 and failed tried /tmp/zmoelnig/zexy.pd_linux and failed tried ./zexy.pd_linux and failed tried /Net/iem/Benutzer/zmoelnig/pd-externals/zexy.pd_linux and failed tried /usr/local/lib/pd-externals/zexy.pd_linux and failed tried /usr/lib/puredata/extra/zexy.pd_linux and failed tried /usr/lib/pd/extra/zexy.pd_linux and failed tried /tmp/zmoelnig/zexy/zexy.l_ia64 and failed tried ./zexy/zexy.l_ia64 and failed tried /Net/iem/Benutzer/zmoelnig/pd-externals/zexy/zexy.l_ia64 and failed tried /usr/local/lib/pd-externals/zexy/zexy.l_ia64 and failed tried /usr/lib/puredata/extra/zexy/zexy.l_ia64 and failed tried /usr/lib/pd/extra/zexy/zexy.l_ia64 and failed tried /tmp/zmoelnig/zexy/zexy.pd_linux and failed tried ./zexy/zexy.pd_linux and failed tried /Net/iem/Benutzer/zmoelnig/pd-externals/zexy/zexy.pd_linux and
failed
tried /usr/local/lib/pd-externals/zexy/zexy.pd_linux and failed tried /usr/lib/puredata/extra/zexy/zexy.pd_linux and failed tried /usr/lib/pd/extra/zexy/zexy.pd_linux and succeeded
one thing that comes to my mind though: could it be that the stdpaths are actually searched but without prepending "extra", and thus failing to find libraries?
I'm undecided whether the new behavior is advantage, but it is different from before.
afaict, the mainly difference is that it now searches each path for all the different extensions (rather than searching for each extension in all the paths). this *is* different behaviour (and i do think that it is an advantage).
mfgasdr IOhannes
On Mon, Jan 18, 2016 at 10:06:10AM +0100, IOhannes m zmoelnig wrote:
[snip]
so i *really* need to add a
- [declare -stdlib zexy -lib zexy]
to be sure to use the local copy of zexy and fall back to a system installed copy.
i'm pretty sure i cannot see the obvious though. so if you have some use-cases (where it would make sense to not search stdpath; how to make use of that additional "control",...) i would be thankful...
well, my usage case is this: I want to be able to distribute self-contained patches and be as certain as possible they'll do the same thing on some machine I've never seen as they do on mine here. For example, I just developed a patch for a premiere in Istanbul (Hi Pieter!) working from here in San Diego. This can be a _great_ way to work :)
So I want my patch to use only externs that I'm including with it in a "lib" subdirectory. If the extern can't be loaded, I'd rather have the patch fail to load than pick up someone else's object with the same name. So I really want "-path" and "-lib" only to search locally, and never in "installed" places. I don't know where the performance machine has been, or even if it's the same machine as was used in rehearsal.
So my preference would be to have "-lib x" search locally, and "-stdlib [x] -lib [x]" effectively fall back to "installed" libs if my local one isn't available.
OTOH is this indeed is a change from 0.46 behavior there's also compatibility to consider...
cheers Miller
On Mon, 2016-01-18 at 10:39 -0800, Miller Puckette wrote:
On Mon, Jan 18, 2016 at 10:06:10AM +0100, IOhannes m zmoelnig wrote:
[snip]
so i *really* need to add a
- [declare -stdlib zexy -lib zexy]
to be sure to use the local copy of zexy and fall back to a system installed copy.
i'm pretty sure i cannot see the obvious though. so if you have some use-cases (where it would make sense to not search stdpath; how to make use of that additional "control",...) i would be thankful...
well, my usage case is this: I want to be able to distribute self-contained patches and be as certain as possible they'll do the same thing on some machine I've never seen as they do on mine here. For example, I just developed a patch for a premiere in Istanbul (Hi Pieter!) working from here in San Diego. This can be a _great_ way to work :)
So I want my patch to use only externs that I'm including with it in a "lib" subdirectory. If the extern can't be loaded, I'd rather have the patch fail to load than pick up someone else's object with the same name. So I really want "-path" and "-lib" only to search locally, and never in "installed" places. I don't know where the performance machine has been, or even if it's the same machine as was used in rehearsal.
So my preference would be to have "-lib x" search locally, and "-stdlib [x] -lib [x]" effectively fall back to "installed" libs if my local one isn't available.
OTOH is this indeed is a change from 0.46 behavior there's also compatibility to consider...
IOhannes is correct in that "-lib" behavior hasn't changed (I just tested with 0.45). Considering this, it's probably wise not to change it now, although I feel more sympathy with the use case you described. I don't see anything wrong with having to use [declare -stdlib zexy -lib zexy] in case I want to cover both, relative to calling patch and all standard paths.
Roman
On 01/19/2016 11:45 AM, Roman Haefeli wrote:
IOhannes is correct in that "-lib" behavior hasn't changed (I just tested with 0.45). Considering this, it's probably wise not to change it now, although I feel more sympathy with the use case you described. I don't see anything wrong with having to use [declare -stdlib zexy -lib zexy] in case I want to cover both, relative to calling patch and all standard paths.
so what to do now? there are a few ways to implement the dont-search-stdpath behaviour (starting from a trivial two-liner), and i'm willing to provide one in order to keep everybody happy.
nevertheless here's some things to consider: - backward compatibility (since it seems that no known version of Pd had the dont-search-stdpath behaviour) - consistency with startup flags ("pd -lib foo" will search both the "-path" paths and the standard paths) - iictc it's fairly trivial to make it very likely that a library is loaded only from a patch-local directory, even if "-lib" does search the stdpath:
[declare -lib byzantium2016/zexy]
while this will try to load "/usr/lib/pd/extra/byzantium2016/zexy/zexy.pd_linux", chances are rather low that this actually exists and so it will happily only load the türkçe zexy besides the patch. but of course this is rather a hack...
mgfdsr IOhannes
On Mit, 2016-01-20 at 00:49 +0100, IOhannes m zmölnig wrote:
On 01/19/2016 11:45 AM, Roman Haefeli wrote:
IOhannes is correct in that "-lib" behavior hasn't changed (I just tested with 0.45). Considering this, it's probably wise not to change it now, although I feel more sympathy with the use case you described. I don't see anything wrong with having to use [declare -stdlib zexy -lib zexy] in case I want to cover both, relative to calling patch and all standard paths.
so what to do now?
Considering your points[*], it should probably stay as it is.
Roman
[*]
nevertheless here's some things to consider:
- backward compatibility (since it seems that no known version of Pd had
the dont-search-stdpath behaviour)
- consistency with startup flags ("pd -lib foo" will search both the
"-path" paths and the standard paths)
- iictc it's fairly trivial to make it very likely that a library is
loaded only from a patch-local directory, even if "-lib" does search the stdpath:
[declare -lib byzantium2016/zexy]
while this will try to load "/usr/lib/pd/extra/byzantium2016/zexy/zexy.pd_linux", chances are rather low that this actually exists and so it will happily only load the türkçe zexy besides the patch. but of course this is rather a hack...
mgfdsr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Mit, 2016-01-20 at 00:49 +0100, IOhannes m zmölnig wrote:
On 01/19/2016 11:45 AM, Roman Haefeli wrote:
IOhannes is correct in that "-lib" behavior hasn't changed (I just tested with 0.45). Considering this, it's probably wise not to change it now, although I feel more sympathy with the use case you described. I don't see anything wrong with having to use [declare -stdlib zexy -lib zexy] in case I want to cover both, relative to calling patch and all standard paths.
so what to do now? there are a few ways to implement the dont-search-stdpath behaviour (starting from a trivial two-liner), and i'm willing to provide one in order to keep everybody happy.
nevertheless here's some things to consider:
- backward compatibility (since it seems that no known version of Pd had
the dont-search-stdpath behaviour)
- consistency with startup flags ("pd -lib foo" will search both the
"-path" paths and the standard paths)
- iictc it's fairly trivial to make it very likely that a library is
loaded only from a patch-local directory, even if "-lib" does search the stdpath:
[declare -lib byzantium2016/zexy]
while this will try to load "/usr/lib/pd/extra/byzantium2016/zexy/zexy.pd_linux", chances are rather low that this actually exists and so it will happily only load the türkçe zexy besides the patch. but of course this is rather a hack...
Zexy is actually a good real-world test case, once because it comes as two different flavors (extended one-object-per-file style, and as multi-object lib), second because the multi-object library is mixed with some abstractions. In order to load the full library, you need to specify a path and a lib. Not that this example makes any sense in the real-world, anyhow one could load zexy like this: [declare -stdpath zexy -lib zexy]. If zexy is installed in a standard path, the patch loads the full library and [dirac~ ] and [cart2sph] can be instantiated. If, however, zexy is installed near the patch, [dirac~ ] instantiates and [cart2sph] does not.
Hm.. I don't know actually, what I'm trying to illustrate here other than that things are complicated.
Isn't it a flawed design that the patch author has to know the packaging style of the library their patch uses? Shouldn't it be sufficient just to _name_ the dependency without having to know whether is a path, a lib, a combination? Something like [declare -std zexy -local my_included_lib] ? Just thinking loud here...
Roman
On Mon, 2016-01-18 at 10:06 +0100, IOhannes m zmoelnig wrote:
afaict, the mainly difference is that it now searches each path for all the different extensions (rather than searching for each extension in all the paths). this *is* different behaviour (and i do think that it is an advantage).
Oh, great! This *is* an improvement. Thanks!
Roman
OK... from what I hear there's no immediate need to change anything... maybe just wait and see what bugs appear.
OTOH, following a suggestions from Hannes, I bumbed the version number to 0.47-test so that externs can figure out what loadbang messages to expect.
cheers M
On Wed, Jan 20, 2016 at 08:46:29AM +0100, Roman Haefeli wrote:
On Mon, 2016-01-18 at 10:06 +0100, IOhannes m zmoelnig wrote:
afaict, the mainly difference is that it now searches each path for all the different extensions (rather than searching for each extension in all the paths). this *is* different behaviour (and i do think that it is an advantage).
Oh, great! This *is* an improvement. Thanks!
Roman
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Miller Puckette -
Roman Haefeli