Hi list,
With the new [declare] behavior, I am a little confused (Pd.0.47). I've read that putting [declare] in abstractions was not the "right" way, but that what I've done. Shame.
In La Malinette (malinette.info), it is very useful to have an abstraction named [include] which contains all relatives paths of all abstractions folders. The goal is to be user friendly and not ask people to add 6 paths in preferences ... And if I want to change a path, to add a common feature for all patches, I have just to change it once, all patches that have this abstraction are affected. And I want to add paths to my patchs I have just to remember the name of [include] to add this object and paths. These are benefits of having abstractions, like object-oriented programming.
How can avoid to copy/paste 100 times a subpatch which contains [declare] and all paths, in all my files ? Or may be there is a way to add dynamically paths on all patches or current patches ? I can't see [import] in Deken, may be it could be the right way to add this kind of feature ? Is it downloable ?
Thanks,
Jerome
Hi Jerome,If you're saying that your patches used to work and they now break, do file a bug about it. Others on the list have mentioned using [declare] for this purpose-- I never have but it's a reasonable use case.
-Jonathan
On Saturday, May 7, 2016 7:30 PM, Jérôme Abel <abel.jerome@free.fr> wrote:
Hi list,
With the new [declare] behavior, I am a little confused (Pd.0.47). I've read that putting [declare] in abstractions was not the "right" way, but that what I've done. Shame.
In La Malinette (malinette.info), it is very useful to have an abstraction named [include] which contains all relatives paths of all abstractions folders. The goal is to be user friendly and not ask people to add 6 paths in preferences ... And if I want to change a path, to add a common feature for all patches, I have just to change it once, all patches that have this abstraction are affected. And I want to add paths to my patchs I have just to remember the name of [include] to add this object and paths. These are benefits of having abstractions, like object-oriented programming.
How can avoid to copy/paste 100 times a subpatch which contains [declare] and all paths, in all my files ? Or may be there is a way to add dynamically paths on all patches or current patches ? I can't see [import] in Deken, may be it could be the right way to add this kind of feature ? Is it downloable ?
Thanks,
Jerome
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I don't regard this as a patch-level incompatibility (I believe you can run all the patches -- only now you'll have to add 6 directories to Pd's search path). But it's a serious inconvenience for sure. But the old behavior was seriously broken and I don't see any good way to provide it without causing trouble and confusion. I'm open to ideas...
Miller
On Sun, May 08, 2016 at 12:09:04AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Jerome,If you're saying that your patches used to work and they now break, do file a bug about it. Others on the list have mentioned using [declare] for this purpose-- I never have but it's a reasonable use case.
-Jonathan
On Saturday, May 7, 2016 7:30 PM, Jérôme Abel <abel.jerome@free.fr> wrote:Hi list,
With the new [declare] behavior, I am a little confused (Pd.0.47). I've read that putting [declare] in abstractions was not the "right" way, but that what I've done. Shame.
In La Malinette (malinette.info), it is very useful to have an abstraction named [include] which contains all relatives paths of all abstractions folders. The goal is to be user friendly and not ask people to add 6 paths in preferences ... And if I want to change a path, to add a common feature for all patches, I have just to change it once, all patches that have this abstraction are affected. And I want to add paths to my patchs I have just to remember the name of [include] to add this object and paths. These are benefits of having abstractions, like object-oriented programming.
How can avoid to copy/paste 100 times a subpatch which contains [declare] and all paths, in all my files ? Or may be there is a way to add dynamically paths on all patches or current patches ? I can't see [import] in Deken, may be it could be the right way to add this kind of feature ? Is it downloable ?
Thanks,
Jerome
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
But the old behavior was seriously broken and I don't see any good way to provide it without causing trouble and confusion.
Deprecate the old [declare] and name the new [declare] something else.
-Jonathan
On Saturday, May 7, 2016 8:40 PM, Miller Puckette <msp@ucsd.edu> wrote:
I don't regard this as a patch-level incompatibility (I believe you can run all the patches -- only now you'll have to add 6 directories to Pd's search path). But it's a serious inconvenience for sure. But the old behavior was seriously broken and I don't see any good way to provide it without causing trouble and confusion. I'm open to ideas...
Miller
On Sun, May 08, 2016 at 12:09:04AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Jerome,If you're saying that your patches used to work and they now break, do file a bug about it. Others on the list have mentioned using [declare] for this purpose-- I never have but it's a reasonable use case.
-Jonathan
On Saturday, May 7, 2016 7:30 PM, Jérôme Abel abel.jerome@free.fr wrote:
Hi list,
With the new [declare] behavior, I am a little confused (Pd.0.47). I've read that putting [declare] in abstractions was not the "right" way, but that what I've done. Shame.
In La Malinette (malinette.info), it is very useful to have an abstraction named [include] which contains all relatives paths of all abstractions folders. The goal is to be user friendly and not ask people to add 6 paths in preferences ... And if I want to change a path, to add a common feature for all patches, I have just to change it once, all patches that have this abstraction are affected. And I want to add paths to my patchs I have just to remember the name of [include] to add this object and paths. These are benefits of having abstractions, like object-oriented programming.
How can avoid to copy/paste 100 times a subpatch which contains [declare] and all paths, in all my files ? Or may be there is a way to add dynamically paths on all patches or current patches ? I can't see [import] in Deken, may be it could be the right way to add this kind of feature ? Is it downloable ?
Thanks,
Jerome
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The trouble with that is that the old behavior depended on what order you created objects and saved/restored patches in - in other words, it was defective by design. I know it was possible to work around that, but I can't see any way to make it do the buggey thing it did and not be buggy.
cheers M
On Sun, May 08, 2016 at 03:25:01AM +0000, Jonathan Wilkes via Pd-list wrote:
But the old behavior was seriously broken and I don't see any good way to provide it without causing trouble and confusion.
Deprecate the old [declare] and name the new [declare] something else.
-Jonathan
On Saturday, May 7, 2016 8:40 PM, Miller Puckette <msp@ucsd.edu> wrote:I don't regard this as a patch-level incompatibility (I believe you can run all the patches -- only now you'll have to add 6 directories to Pd's search path). But it's a serious inconvenience for sure. But the old behavior was seriously broken and I don't see any good way to provide it without causing trouble and confusion. I'm open to ideas...
Miller
On Sun, May 08, 2016 at 12:09:04AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Jerome,If you're saying that your patches used to work and they now break, do file a bug about it. Others on the list have mentioned using [declare] for this purpose-- I never have but it's a reasonable use case.
-Jonathan
Â
  On Saturday, May 7, 2016 7:30 PM, Jérôme Abel abel.jerome@free.fr wrote: Â
 Hi list,
With the new [declare] behavior, I am a little confused (Pd.0.47). I've read that putting [declare] in abstractions was not the "right" way, but that what I've done. Shame.
In La Malinette (malinette.info), it is very useful to have an abstraction named [include] which contains all relatives paths of all abstractions folders. The goal is to be user friendly and not ask people to add 6 paths in preferences ... And if I want to change a path, to add a common feature for all patches, I have just to change it once, all patches that have this abstraction are affected. And I want to add paths to my patchs I have just to remember the name of [include] to add this object and paths. These are benefits of having abstractions, like object-oriented programming.
How can avoid to copy/paste 100 times a subpatch which contains [declare] and all paths, in all my files ? Or may be there is a way to add dynamically paths on all patches or current patches ? I can't see [import] in Deken, may be it could be the right way to add this kind of feature ? Is it downloable ?
Thanks,
Jerome
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Â
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
OK... so as a fall-back I'll just fix it so that setting Pd compatibility to 0.46 makes declare fall back to the old behavior. Meanwhile a "real" fix is needed...
cheers M
On Sun, May 08, 2016 at 11:07:15PM +0200, Jérôme Abel wrote:
if [import] can indeed be used
In fact, it seems that [import] only deals with libraries ... not with abstractions folders.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-05-08 23:21, Miller Puckette wrote:
Meanwhile a "real" fix is needed...
i think the sensible way would be, if a library loaded via declare could add paths (and load other libraries).
e.g. with Gem, there are abstractions and a single external: ~/pd-externals/Gem/Gem-meta.pd ~/pd-externals/Gem/Gem.pd_linux ~/pd-externals/Gem/gemwin.pd i would like to be able to say [declare -lib Gem], and this would
- load the Gem.pd_linux external (so i can use [square])
- add the path-to-Gem (~/pd-externals/Gem/) to the (local) searchpatch
(so i can use [gemwin], without any prefix)
i currently do this by automatically adding the path-to-Gem to Pd's search-paths. this works OKish, but has the side-effect that if the user *then* saves their startup preferences, they will have the path-to-Gem stored persistently; so the next time they start Pd (without Gem loaded), they will still have path-to-Gem in their search-path; also if they happen to load an other of Gem from a different path, they will now have *both* paths-to-Gem in their search-path. i think that this is something not applicable to all libraries (e.g. when loading "mrpeach/packOSC.pd_linux" i probably do *not* want to have the entire "mrpeach" path added to my search-path.
i also don't want the user to know/care, that "square" is an objectclass that get's added when loading the Gem.pd_linux, whereas "gemwin" is an abstraction that needs a "path" to be added and "gemglutwindows" is a single-object-external that also needs a "path" to be added. the user should just state that they want to load the "Gem" library package.
simlarily with la-malinette (and extended-view-toolkit and probably some more frameworks) a single importing of the framework should add a (configurable) number of paths.
i *think* that the best way to achieve this is to allow a library/framework to run some code when being setup. for me the obvious place would be the "-meta" file (Gem-meta.pd) which has become the de-facto standard to add meta-information to a library. in it's simplest form, Pd could just treat that meta-file special and run the "declare" statements of the meta-patch when importing the library. (a more advanced form would actually load (and loadbang) the meta-patch, so it can run some real code)
currently the meta-patch is really only used by the "libdir" loader. i guess it is possible to add the functionality described above to the "libdir" loader as a first step.
fgamsdr IOhannes
I don't regard this as a patch-level incompatibility
Indeed.
But the old behavior was seriously broken and I don't see any good way to provide it without causing trouble and confusion. I'm open to ideas...
I understand.
# USE CASE An abstraction [include] that you can put on all patches. Advantages : add search paths to all of these patches, add common behaviors too (variables, functions, ...)
# OPENFRAMEWORKS The functionality is used in OpenFrameworks for instance. You add the file "libs/openFrameworks/ofMain.h" which contains all paths you need for your project :
******* ofMain.h ******* #pragma once #include "ofConstants.h" #include "ofFileUtils.h" #include "ofLog.h" #include "ofSystemUtils.h" . . . #include "ofMesh.h" #include "ofNode.h"
# D.I.Y IDEAS
1 - Use a startup script, but is not enough user friendly for our
project and depend on platform (like egregore patches)
2 - Add a subpatch [pd include] in the parent patch which is
populate if there is no [declare] inside to make it once ... I don't know if it is possible with [iemguts]. And if it is, it won't be dynamic, I have to save and reload the patch...
3 - First time I load the patch, an abstraction look at the
preferences file and add paths if there are not added, but it depends on platform too ...
# PD IDEAS
1 - Update [import] object to be downloable via Deken, if it does it ?
2 - A new object which add paths to pd. It has to query preferences
file to add them once. We could add a "-file" flag to load paths from a file. The best would be it does effect instantaneously.
3 - Add features in [declare] : a "-relativepath" flag, which could
use paths from parent patch (order levels like iemguts), a "-file" flag
On 2016-05-08 11:33 AM, Jérôme Abel wrote:
# PD IDEAS
1 - Update [import] object to be downloable via Deken, if it does it ?
At https://github.com/electrickery/pd-playground/tree/master/import is the latest svn version of [import] with a modern build system, but I didn't made a deken package yet. It was unclear if it was useful outside support for existing patches.
Fred Jan
At any rate, if [import] can indeed be used in Jérôme Abel's situation, then he can include a compiled version of [import] with his library, and the main enabline abstraction can then invoke it. This might be the cleanest way forward.
thanks Miller
On Sun, May 08, 2016 at 12:18:28PM +0200, Fred Jan Kraan wrote:
On 2016-05-08 11:33 AM, Jérôme Abel wrote:
# PD IDEAS
1 - Update [import] object to be downloable via Deken, if it does it ?At https://github.com/electrickery/pd-playground/tree/master/import is the latest svn version of [import] with a modern build system, but I didn't made a deken package yet. It was unclear if it was useful outside support for existing patches.
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sun, May 08, 2016 at 12:09:04AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Jerome,If you're saying that your patches used to work and they now break, do file a bug about it. Others on the list have mentioned using [declare] for this purpose-- I never have but it's a reasonable use case.
Using [declare] in abstractions has never been an encouraged practice, The 0.41 helpfile includes this warning:
'WARNING: you might want to avoid putting "declare" statements inside abstractions, as their effects will extend to the calling patch. As of version 0.41, "declare path" is ignored inside abstractions, although, probably unwisely, "-stdpath" takes effect (on the calling patch as well as the abstraction.)'
So basically [declare] only was "allowed" in a toplevel patch.
I think it is was wise, that the confusing side effect of [declare] "extending to the calling patch" was removed.
Ciao
Frank Barknecht _ ______footils.org__
So basically [declare] only was "allowed" in a toplevel patch.
You write as if you aren't a time traveler. [declare] has had this behavior for at least a decade. That's more than enough time for the ninjas to test and package it up to use in the manner described by the OP. What is the cost of leaving a hook for functionality that has value to the community? (I count two documented uses on the list, both geared toward a larger community of users.) If the cost is old lines of code and a creator/flag, it should remain. If it's substantially greater than that, I'd be interested to here the technical argument for removing it.
Keep in mind there are way more obscure old code paths-- [template], for example...
-Jonathan
On Sunday, May 8, 2016 5:56 AM, Frank Barknecht <fbar@footils.org> wrote:
On Sun, May 08, 2016 at 12:09:04AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Jerome,If you're saying that your patches used to work and they now break, do file a bug about it. Others on the list have mentioned using [declare] for this purpose-- I never have but it's a reasonable use case.
Using [declare] in abstractions has never been an encouraged practice, The 0.41 helpfile includes this warning:
'WARNING: you might want to avoid putting "declare" statements inside abstractions, as their effects will extend to the calling patch. As of version 0.41, "declare path" is ignored inside abstractions, although, probably unwisely, "-stdpath" takes effect (on the calling patch as well as the abstraction.)'
So basically [declare] only was "allowed" in a toplevel patch.
I think it is was wise, that the confusing side effect of [declare] "extending to the calling patch" was removed.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
Fred Jan Kraan -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Jérôme Abel -
Miller Puckette