hi all
i made some tests with the new [declare] in 0.42.0test5. here the results:
-lib and -stdlib: those expand the global namespace. when having [declare -stdlib extra/zexy] somewhere, all zexy classes are available for any patches.
-path and -stdpath: they expand the namespace of the parent patch and all its (the parents) children patches, children's children inclusive. to be more clear: a [declare] in abstraction [foo] expands the namespace of abstraction [bar], when both are instantiated in the same patch. also the parent patch's namespace is expanded, but not the parent's of the parent. other patches with no relationship are not affected at all by -path and -stdpath.
this behaviour differs quite significantly from the implementations of declare in previous pd versions. also, unlike announced, it is _not_ disabled within abstractions. personally, i think, that is the best [declare] implementation that we ever had. i think, it covers many of the use cases one can think of, also because it affects the parent patch. because all of that, i really hope, that the declare's 'philosophy' won't change too much in the future. out of curiosity and out of the need of a reliable behaviour: what are the future plans for [declare]? will it basically stay as it is (which i personally hope)?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hi Roman,
I think the -path and -stdpath aren't doing what I intended... I think that if you've got a [foo] and [bar] with the same parent, then a declare in [foo] shouldn't affect either the parent or [bar]. So if I can figure out what's going wrong I'll try fixing that :)
thanks for checking this! Miller
On Wed, Nov 05, 2008 at 12:06:00AM +0100, Roman Haefeli wrote:
hi all
i made some tests with the new [declare] in 0.42.0test5. here the results:
-lib and -stdlib: those expand the global namespace. when having [declare -stdlib extra/zexy] somewhere, all zexy classes are available for any patches.
-path and -stdpath: they expand the namespace of the parent patch and all its (the parents) children patches, children's children inclusive. to be more clear: a [declare] in abstraction [foo] expands the namespace of abstraction [bar], when both are instantiated in the same patch. also the parent patch's namespace is expanded, but not the parent's of the parent. other patches with no relationship are not affected at all by -path and -stdpath.
this behaviour differs quite significantly from the implementations of declare in previous pd versions. also, unlike announced, it is _not_ disabled within abstractions. personally, i think, that is the best [declare] implementation that we ever had. i think, it covers many of the use cases one can think of, also because it affects the parent patch. because all of that, i really hope, that the declare's 'philosophy' won't change too much in the future. out of curiosity and out of the need of a reliable behaviour: what are the future plans for [declare]? will it basically stay as it is (which i personally hope)?
roman
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Followup: it looks like currently, "declaring" a path inside an abstraction adds the declaration, buggily, to the whole line of parent patches. one result of this is that, if you have a bunch of copies of an abstraction "declaring" a path, it actually gets searched over and over again every time a file is opened. So I really need to fix this... meantime, if you're putting "declares" in an abstraction, you might be making load times grow very high.
I still suggest never putting declares insige abstractions, since nobody has yet proposed a situation in which it's a good idea, and now it appears to be very bad for performance.
cheers Miller
On Wed, Nov 05, 2008 at 12:06:00AM +0100, Roman Haefeli wrote:
hi all
i made some tests with the new [declare] in 0.42.0test5. here the results:
-lib and -stdlib: those expand the global namespace. when having [declare -stdlib extra/zexy] somewhere, all zexy classes are available for any patches.
-path and -stdpath: they expand the namespace of the parent patch and all its (the parents) children patches, children's children inclusive. to be more clear: a [declare] in abstraction [foo] expands the namespace of abstraction [bar], when both are instantiated in the same patch. also the parent patch's namespace is expanded, but not the parent's of the parent. other patches with no relationship are not affected at all by -path and -stdpath.
this behaviour differs quite significantly from the implementations of declare in previous pd versions. also, unlike announced, it is _not_ disabled within abstractions. personally, i think, that is the best [declare] implementation that we ever had. i think, it covers many of the use cases one can think of, also because it affects the parent patch. because all of that, i really hope, that the declare's 'philosophy' won't change too much in the future. out of curiosity and out of the need of a reliable behaviour: what are the future plans for [declare]? will it basically stay as it is (which i personally hope)?
roman
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
What's wrong with having a declare with a local scope? To have functional namespaces that encourage encapsulation, there needs to be at minimum two options: a global space and a completely local space. Then other levels could be added as desired. Currently, there is a global and a middle level, but no completely local.
That means that an abstraction could break depending on which parent patch it is used in.
.hc
On Nov 5, 2008, at 3:22 PM, Miller Puckette wrote:
Followup: it looks like currently, "declaring" a path inside an abstraction adds the declaration, buggily, to the whole line of parent patches. one result of this is that, if you have a bunch of copies of an abstraction "declaring" a path, it actually gets searched over and over again every time a file is opened. So I really need to fix this... meantime, if you're putting "declares" in an abstraction, you might be making load times grow very high.
I still suggest never putting declares insige abstractions, since nobody has yet proposed a situation in which it's a good idea, and now it appears to be very bad for performance.
cheers Miller
On Wed, Nov 05, 2008 at 12:06:00AM +0100, Roman Haefeli wrote:
hi all
i made some tests with the new [declare] in 0.42.0test5. here the results:
-lib and -stdlib: those expand the global namespace. when having [declare -stdlib extra/zexy] somewhere, all zexy classes are available for any patches.
-path and -stdpath: they expand the namespace of the parent patch and all its (the parents) children patches, children's children inclusive. to be more clear: a [declare] in abstraction [foo] expands the namespace of abstraction [bar], when both are instantiated in the same patch. also the parent patch's namespace is expanded, but not the parent's of the parent. other patches with no relationship are not affected at all by - path and -stdpath.
this behaviour differs quite significantly from the implementations of declare in previous pd versions. also, unlike announced, it is _not_ disabled within abstractions. personally, i think, that is the best [declare] implementation that we ever had. i think, it covers many of the use cases one can think of, also because it affects the parent patch. because all of that, i really hope, that the declare's 'philosophy' won't change too much in the future. out of curiosity and out of the need of a reliable behaviour: what are the future plans for [declare]? will it basically stay as it is (which i personally hope)?
roman
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
On Wed, Nov 5, 2008 at 1:22 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Followup: it looks like currently, "declaring" a path inside an abstraction adds the declaration, buggily, to the whole line of parent patches. one result of this is that, if you have a bunch of copies of an abstraction "declaring" a path, it actually gets searched over and over again every time a file is opened. So I really need to fix this... meantime, if you're putting "declares" in an abstraction, you might be making load times grow very high.
I still suggest never putting declares insige abstractions, since nobody has yet proposed a situation in which it's a good idea, and now it appears to be very bad for performance.
Hi Miller, Isn't the benefit of declares in abstractions that you can modify the search path of just that parent abstraction and its children? If abstractionA is known to be the only one that needs the path "special-oscs/", there's no reason for abstractionB to be looking in there.
(or, perhaps you mean no one has proposed a situation in which it is a good idea, as declare is implemented currently)
Best Luke
cheers Miller
On Wed, Nov 05, 2008 at 12:06:00AM +0100, Roman Haefeli wrote:
hi all
i made some tests with the new [declare] in 0.42.0test5. here the results:
-lib and -stdlib: those expand the global namespace. when having [declare -stdlib extra/zexy] somewhere, all zexy classes are available for any patches.
-path and -stdpath: they expand the namespace of the parent patch and all its (the parents) children patches, children's children inclusive. to be more clear: a [declare] in abstraction [foo] expands the namespace of abstraction [bar], when both are instantiated in the same patch. also the parent patch's namespace is expanded, but not the parent's of the parent. other patches with no relationship are not affected at all by -path and -stdpath.
this behaviour differs quite significantly from the implementations of declare in previous pd versions. also, unlike announced, it is _not_ disabled within abstractions. personally, i think, that is the best [declare] implementation that we ever had. i think, it covers many of the use cases one can think of, also because it affects the parent patch. because all of that, i really hope, that the declare's 'philosophy' won't change too much in the future. out of curiosity and out of the need of a reliable behaviour: what are the future plans for [declare]? will it basically stay as it is (which i personally hope)?
roman
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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
Actually, I think it would be a bad idea to have an abstraction affect the search path of the containing patch. There would be no way for the patch to know about the stuff getting added to the path until the abstraction gets loaded... but you need the path in place to figure out where the abstraction should be searched for.
I think (probably as you're saying below) that an abstraction's declarations should affect only itself and things called from within it.
cheers Miller
Hi Miller, Isn't the benefit of declares in abstractions that you can modify the search path of just that parent abstraction and its children? If abstractionA is known to be the only one that needs the path "special-oscs/", there's no reason for abstractionB to be looking in there.
(or, perhaps you mean no one has proposed a situation in which it is a good idea, as declare is implemented currently)
Best Luke
With a little difficulty one could have it both ways by adding something like a -exportpath flag -- an advantage for having abstractions export paths to parents would be to have a master abstraction with all the [declare]'s -- but more importantly it would useful for looking for other resources like textfiles for qlists and soundfiles for soundfiler but specifying the path relative to the parent rather than the abstraction (makes the abstraction behave like a builtin object) -- I haven't checked the behavior recently, though, so I don't remember the default action for resources.
Matt
On Fri, Nov 7, 2008 at 8:55 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Actually, I think it would be a bad idea to have an abstraction affect the search path of the containing patch. There would be no way for the patch to know about the stuff getting added to the path until the abstraction gets loaded... but you need the path in place to figure out where the abstraction should be searched for.
I think (probably as you're saying below) that an abstraction's declarations should affect only itself and things called from within it.
cheers Miller
Hi Miller, Isn't the benefit of declares in abstractions that you can modify the search path of just that parent abstraction and its children? If abstractionA is known to be the only one that needs the path "special-oscs/", there's no reason for abstractionB to be looking in there.
(or, perhaps you mean no one has proposed a situation in which it is a good idea, as declare is implemented currently)
Best Luke
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I think (probably as you're saying below) that an abstraction's declarations should affect only itself and things called from within it.
I think, that's what Luke meant, and I would agree here. Generally it's not necessary and even against common sense for an abstraction's declare to modify the paths of its parents. (If we want to have this functionality for some exotic meta-programming techniques we should implement this in a different object.)
Ciao
On Fri, 2008-11-07 at 17:55 -0800, Miller Puckette wrote:
Actually, I think it would be a bad idea to have an abstraction affect the search path of the containing patch. There would be no way for the patch to know about the stuff getting added to the path until the abstraction gets loaded... but you need the path in place to figure out where the abstraction should be searched for.
I think (probably as you're saying below) that an abstraction's declarations should affect only itself and things called from within it.
hi again
my report was bogus due to some other bug i just discovered. the problem is _not_ that a [declare] directly expands the pathes of any 'ancestral' patch. in fact, if a patch containing an abstraction or a child of an abstraction containing a [declare] object is saved, the patch is saved with a hidden declare line:
#X declare -stdlib extra/list-abs;
but there is no line:
#X obj 8 8 declare -stdlib extra/list-abs;
and therefore no object [declare] appears in the patch, when opening it afterwards.
otoh, if the patch is saved before adding a [declare] to the abstraction, then the [declare] of the [abstraction] does _not_ expand the pathes of the parent patch.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Wed, 2008-11-05 at 12:22 -0800, Miller Puckette wrote:
Followup: it looks like currently, "declaring" a path inside an abstraction adds the declaration, buggily, to the whole line of parent patches. one result of this is that, if you have a bunch of copies of an abstraction "declaring" a path, it actually gets searched over and over again every time a file is opened. So I really need to fix this... meantime, if you're putting "declares" in an abstraction, you might be making load times grow very high.
stupid me.. after having posted exactly that to the tracker, i just discovered, that you already discovered the problem ;-) sorry for the noise (i misunderstood your lines, when i read them the last time).
I still suggest never putting declares insige abstractions, since nobody has yet proposed a situation in which it's a good idea, and now it appears to be very bad for performance.
i think, we should come up with use cases here. in my idea of [declare], i would like to use it to let a patch OR an abstractions loads its dependencies. if i create pd-file that is intended to be used as an abstraction and it uses [abs~] from zexy, then i would like to have it load zexy on its own by using a [declare -stdlib zexy]. as a result, the user of this abstraction doesn't have to think about the dependencies of the abstractions he/she is using. i guess, that would be a reason to have [declare]'s evaluated also inside abstractions.
what are the use cases speaking against the use of [declare]s inside abstractions? the fact, that it makes the loading of patches slow is not a conceptual reason, but obviously a sad fact.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Frank Barknecht -
Hans-Christoph Steiner -
Luke Iannini -
Matt Barber -
Miller Puckette -
Roman Haefeli