hi all, hi miller
recently i tried out the Pd 0.42-0test1 (as found in svn) and discovered that now libraries can (and will) overwrite already existing classes. this will eventually lead to some unexpected behaviour.
example: imagine an object (e.g. [prepend]) that can be found in 2 different libraries (iemlib, maxlib, cxc, cyclone) - in prior versions (<0.42) one could make sure that the "correct" version was used by specifying the library including the object as the first one to be loaded ("-lib cxc:iemlib2" would give you cxc's [prepend]) - in future versions (>=0.42) one would specify the library with the "correct" behaviour to be loaded at last ("-lib cxc:iemlib2" will give you iemlib's [prepend].
this eventually breaks existing startup patches.
is this by design?
fmgasdr IOhannes
I'm still trying to figure out how to do this "right"... for years I've been unable to put some key objects into Pd 'vanilla' because they would then shadow objects of the same name in libraries, sometimes with somewhat different designes (e.g., the infamous "pow~"). The only solution I can see is to allow libraries to shadow built-in objects.
This has a side effect that you noticed: you now have to load libraries in the opposite order than you did before in order to get some desired version of "counter" or "prepend".
Also, "declare" and the search path mechanism themselves are in flux -- it might prove necessary to allow relative paths to be interpreted relative to abstractions and/or the calling patch. (example: an abstraction in "lib/" has a table that you ask to open "foo.wav" in "snd/" -- should that mean "snd/" relative to the calling patch (the normal thing to expect) or relative to the abstraction?) I think there's a lot of thinking needed here before we can settle on a long-term solution.
cheers Miller
On Thu, Jun 12, 2008 at 08:42:09PM +0200, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
this eventually breaks existing startup patches.
this of course should say "existing startup scripts" or the like
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The libdir library format with namespace prefixes is a simpler approach. You wouldn't need to change any of the code, just build the internal objects as a libdir and it would work. People could change the loading order, access multiple objectclasses with the same base name, etc.
The only thing that needs to change, AFAIK, for this to fully work is to have the namespace prefixes kept in the loaded classnames, i.e. using [cyclone/prepend] shouldn't then claim the name [prepend], as it does now.
.hc
On Jun 13, 2008, at 7:32 PM, Miller Puckette wrote:
I'm still trying to figure out how to do this "right"... for years I've been unable to put some key objects into Pd 'vanilla' because they would then shadow objects of the same name in libraries, sometimes with somewhat different designes (e.g., the infamous "pow~"). The only solution I can see is to allow libraries to shadow built-in objects.
This has a side effect that you noticed: you now have to load libraries in the opposite order than you did before in order to get some desired version of "counter" or "prepend".
Also, "declare" and the search path mechanism themselves are in flux -- it might prove necessary to allow relative paths to be interpreted relative to abstractions and/or the calling patch. (example: an abstraction in "lib/" has a table that you ask to open "foo.wav" in "snd/" -- should that mean "snd/" relative to the calling patch (the normal thing to expect) or relative to the abstraction?) I think there's a lot of thinking needed here before we can settle on a long-term solution.
cheers Miller
On Thu, Jun 12, 2008 at 08:42:09PM +0200, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
this eventually breaks existing startup patches.
this of course should say "existing startup scripts" or the like
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
(example: an abstraction in "lib/" has a table that you ask to open "foo.wav" in "snd/" -- should that mean "snd/" relative to the calling patch (the normal thing to expect) or relative to the abstraction?)
That's indeed a very tricky issue, as it also may mean that we'd need to track where a message originated. Said table in lib/abstraction.pd may actually *want* to open a file relative to itself in lib/snd/default.wav instead of relative to the calling patch, for example to preload a certain soundfile shipped with the abstraction.
Ciao
Hi Miller,
With respect to this and other compatability breakages which you are very careful to avoid, I wonder if you have any plan to release a version (0.50 maybe?) which specifically says that it will break backwards compatability and fixes some of the little annoying bits in Pd?
Best,
Chris.
On Fri, Jun 13, 2008 at 10:32:21AM -0700, Miller Puckette wrote:
I'm still trying to figure out how to do this "right"... for years I've been unable to put some key objects into Pd 'vanilla' because they would then shadow objects of the same name in libraries, sometimes with somewhat different designes (e.g., the infamous "pow~"). The only solution I can see is to allow libraries to shadow built-in objects.
This has a side effect that you noticed: you now have to load libraries in the opposite order than you did before in order to get some desired version of "counter" or "prepend".
Also, "declare" and the search path mechanism themselves are in flux -- it might prove necessary to allow relative paths to be interpreted relative to abstractions and/or the calling patch. (example: an abstraction in "lib/" has a table that you ask to open "foo.wav" in "snd/" -- should that mean "snd/" relative to the calling patch (the normal thing to expect) or relative to the abstraction?) I think there's a lot of thinking needed here before we can settle on a long-term solution.
cheers Miller
On Thu, Jun 12, 2008 at 08:42:09PM +0200, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
this eventually breaks existing startup patches.
this of course should say "existing startup scripts" or the like
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------- http://mccormick.cx
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette