Hi list, I think that this question was already pointed out in this list, but I can't find it anymore. Is there a simple way to chek if a pd patch is made only using vanilla object? Or: Is there a way to find which external lib are needed for a given patch? A possible solution is to keep a plain vanilla distribution to load a given patch and check the console for missing object, but this approach, for a BIG patch is not practical. The ideal case should be, for example, to load a patch and see a list of each object/lib pair that are actually loaded.
My goal is to find if a patch is vanilla compatible and, if not, which are the lib that I need to run it.
Thank you,
On 27/02/16 11:05, Alessio Degani via Pd-list wrote:
Hi list, I think that this question was already pointed out in this list, but I can't find it anymore. Is there a simple way to chek if a pd patch is made only using vanilla object? Or: Is there a way to find which external lib are needed for a given patch? A possible solution is to keep a plain vanilla distribution to load a given patch and check the console for missing object, but this approach, for a BIG patch is not practical. The ideal case should be, for example, to load a patch and see a list of each object/lib pair that are actually loaded.
My goal is to find if a patch is vanilla compatible and, if not, which are the lib that I need to run it.
This is kind of the holy grail I guess :) I think there is an issue on the Deken tracker about this or something similar.
I had some success years ago by patching Pd core to print out when classes are registered by externals, so that I could generate a few object lists for libraries (including 'vanilla' as a virtual library). I could then use these lists with shell scripts parsing a Pd patch to see which objects were needed from which libraries - it was all proof of concept stuff, don't think I even supported chasing local abstractions, and of course it would only work neatly with all-in-one multi-object libraries without library abstractions...
I attached the state of this mini-project from 2008 or so.
Claude
On 27/02/2016 13:12, Claude Heiland-Allen wrote:
On 27/02/16 11:05, Alessio Degani via Pd-list wrote:
Hi list, I think that this question was already pointed out in this list, but I can't find it anymore. Is there a simple way to chek if a pd patch is made only using vanilla object? Or: Is there a way to find which external lib are needed for a given patch? A possible solution is to keep a plain vanilla distribution to load a given patch and check the console for missing object, but this approach, for a BIG patch is not practical. The ideal case should be, for example, to load a patch and see a list of each object/lib pair that are actually loaded.
My goal is to find if a patch is vanilla compatible and, if not, which are the lib that I need to run it.
This is kind of the holy grail I guess :) I think there is an issue on the Deken tracker about this or something similar.
I had some success years ago by patching Pd core to print out when classes are registered by externals, so that I could generate a few object lists for libraries (including 'vanilla' as a virtual library). I could then use these lists with shell scripts parsing a Pd patch to see which objects were needed from which libraries - it was all proof of concept stuff, don't think I even supported chasing local abstractions, and of course it would only work neatly with all-in-one multi-object libraries without library abstractions...
I attached the state of this mini-project from 2008 or so.
Thank you Claude, I'll give it a try :)
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
Is there a simple way to chek if a pd patch is made only using vanilla object?
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch?
then see if any object couldn't create. then check the Pd-console to see where it found the objects that it could create, and check whether any of those are outside your patch path.
gfmsarI IOhannes
+1 Yep, with : $ pd -noprefs -verbose... seems the way to go. ++
Jack
Le 27/02/2016 16:35, IOhannes m zmölnig a écrit :
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
Is there a simple way to chek if a pd patch is made only using vanilla object?
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch?
then see if any object couldn't create. then check the Pd-console to see where it found the objects that it could create, and check whether any of those are outside your patch path.
gfmsarI IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 27/02/2016 16:35, IOhannes m zmölnig wrote:
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
Is there a simple way to chek if a pd patch is made only using vanilla object?
Hi IOhannes,
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch?
Thank you for the answer. That works. But how about a more direct "this patch uses the following libs/extern: ...". Do you think that is feasible? Maybe in a future release of pd
Cheers
then see if any object couldn't create. then check the Pd-console to see where it found the objects that it could create, and check whether any of those are outside your patch path.
gfmsarI IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
One possibility : A patch is a text file. In this file each object is represented with a line beginning with : #X obj ... For example, a [drip] at position (179,93) is : #X obj 179 93 drip;
So it could be doable, with the [text] object, to analize your patch and return each object. Then you can get a list of externals. ++
Jack
Le 28/02/2016 13:26, Alessio Degani via Pd-list a écrit :
On 27/02/2016 16:35, IOhannes m zmölnig wrote:
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
Is there a simple way to chek if a pd patch is made only using vanilla object?
Hi IOhannes,
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch?
Thank you for the answer. That works. But how about a more direct "this patch uses the following libs/extern: ...". Do you think that is feasible? Maybe in a future release of pd
Cheers
then see if any object couldn't create. then check the Pd-console to see where it found the objects that it could create, and check whether any of those are outside your patch path.
gfmsarI IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- a.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 28/02/2016 13:26, Alessio Degani via Pd-list a écrit :
On 27/02/2016 16:35, IOhannes m zmölnig wrote:
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
Is there a simple way to chek if a pd patch is made only using vanilla object?
Hi IOhannes,
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch?
Thank you for the answer. That works. But how about a more direct "this patch uses the following libs/extern: ...". Do you think that is feasible?
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
cheers c
Maybe in a future release of pd
Cheers
then see if any object couldn't create. then check the Pd-console to see where it found the objects that it could create, and check whether any of those are outside your patch path.
gfmsarI IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
-- a.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I tried to install via deken all externals disponibles for Mac in vanilla 0.46-7 to load all patches of the world, but I was stopped because pd limit the number of loading path externals in 98 libraries. What the importance of this limitation?
Em dom, 28 de fev de 2016 10:15, cyrille henry ch@chnry.net escreveu:
Le 28/02/2016 13:26, Alessio Degani via Pd-list a écrit :
On 27/02/2016 16:35, IOhannes m zmölnig wrote:
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
Is there a simple way to chek if a pd patch is made only using vanilla object?
Hi IOhannes,
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch?
Thank you for the answer. That works. But how about a more direct "this patch uses the following
libs/extern: ...".
Do you think that is feasible?
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
cheers c
Maybe in a future release of pd
Cheers
then see if any object couldn't create. then check the Pd-console to see where it found the objects that it could create, and check whether any of those are outside your patch
path.
gfmsarI IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- a.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Cyrille,
On 28/02/2016 14:14, cyrille henry wrote:
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
I do care of both. I've used to write my patch with pd-extended, that eliminates the problem "from the root". In this way my patch will work (almost) certainly with pd-extended across each platform and from now on. But I've decided to abandon extended for all the reason that we all know :) The problem, now, is:
- If I want to distribute my patch, it would be great to write down the
dependencies, for example in the README. And virtually, since I've used to work with pd-extended, I've in some way "lost" the border within vanilla objects and extended objects, so I've to manually check each time (i.e.: hummm spigot~ is vanilla? NO, ok... let me check... oh ok... is in the unathorized package -> each time for each object).
- I use different machines with different OS, etc... and sometimes I use
"fresh" pd vanilla installation. Ideally, I want to install only the externals that I need. If I have a list of externals needed for my patch, this process would be much more easy (few clicks with Deken)!
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
I totally agree with this! :)
Cheers
cheers c
Le 28/02/2016 20:25, Alessio Degani via Pd-list a écrit :
Hi Cyrille,
On 28/02/2016 14:14, cyrille henry wrote:
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
I do care of both. I've used to write my patch with pd-extended, that eliminates the problem "from the root".
pd-extended did not solve this problem: pd-extended create this problem!
In this way my patch will work (almost) certainly with pd-extended across each platform and from now on.
But I've decided to abandon extended for all the reason that we all know :) The problem, now, is:
- If I want to distribute my patch, it would be great to write down the dependencies, for example in the README. And virtually, since I've used to work with pd-extended, I've in some way "lost" the border within vanilla objects and extended objects, so I've to manually check each time (i.e.: hummm spigot~ is vanilla? NO, ok... let me check... oh ok... is in the unathorized package -> each time for each object).
- I use different machines with different OS, etc... and sometimes I use "fresh" pd vanilla installation. Ideally, I want to install only the externals that I need. If I have a list of externals needed for my patch, this process would be much more easy (few clicks with Deken)!
i think you should first reduce number of external you need : spigot~ can be certainly be replace with a *~...
you can replace lot's of externals using abstractions. that's a lot of work, but your patchs will be lot's more portable.
cheers c
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
I totally agree with this! :)
Cheers
cheers c
On 29/02/2016 12:11, cyrille henry wrote:
Le 28/02/2016 20:25, Alessio Degani via Pd-list a écrit :
Hi Cyrille,
On 28/02/2016 14:14, cyrille henry wrote:
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
I do care of both. I've used to write my patch with pd-extended, that eliminates the problem "from the root".
pd-extended did not solve this problem: pd-extended create this problem!
Again, I totally agree with you! :)
In this way my patch will work (almost) certainly with pd-extended across each platform and from now on.
But I've decided to abandon extended for all the reason that we all know :) The problem, now, is:
- If I want to distribute my patch, it would be great to write down
the dependencies, for example in the README. And virtually, since I've used to work with pd-extended, I've in some way "lost" the border within vanilla objects and extended objects, so I've to manually check each time (i.e.: hummm spigot~ is vanilla? NO, ok... let me check... oh ok... is in the unathorized package -> each time for each object).
- I use different machines with different OS, etc... and sometimes I
use "fresh" pd vanilla installation. Ideally, I want to install only the externals that I need. If I have a list of externals needed for my patch, this process would be much more easy (few clicks with Deken)!
i think you should first reduce number of external you need : spigot~ can be certainly be replace with a *~...
Yes, I'm going to proceed this way in order to reduce the number of abstraction. That's the way I've used to work before starting to use pd-extended. I prefer to implement the object as abstraction by myself, but pd-extended has spoiled me :) I guess that I will have to do a lot of work in vanilla-izing all my old patches.
Anyway, I think that a method to "attach" a list of "used externals" to a given patch would be useful!
Cheers
you can replace lot's of externals using abstractions. that's a lot of work, but your patchs will be lot's more portable.
cheers c
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
I totally agree with this! :)
Cheers
cheers c
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think this can be done with Pd-l2ork. [find(|[canvasinfo] This will return a list of pointers to all the objects on the parent canvas. For each one you can send the pointer to the right inlet of [objectinfo] and do this: [class(|[objectinfo] I also have [classinfo]. Now, there's a special "objectmaker" class in Pd that has a method for each "creator" symbol for every loaded Pd class. I have a method for returning those methods, though I can't remember what it is atm and I'm not in front of a machine running Pd.
Putting that altogether, you can:1. Run Pd-l2ork with no externals loaded, and walk the "objectmaker" methods using [classinfo]. This will give you a list of symbols that are essentially the class names and aliases for "core" Pd. (Plus some other stuff that we can ignore for the moment.)2. Save that list of symbols in an abstraction.3. Run Pd-l2ork with all externals loaded, and load an arbitrary patch.4. Use [find(---[canvasinfo1] inside your abstraction to get a list of the objects on the parent.5. Use [class(--[objectinfo] to get the class of each object6. Compare that class to your list of "core" classes from #1 above. If it matches it's a "core" object. If not, it's an external. Caveats:1. For Pd Vanilla objects, you probably need to manually prune the internal objects that have been added in Pd-l2ork-- preset_hub, preset_node, and my introspection classes above.2. I can't remember if I have a way to drill down into a subpatch or abstraction with [canvasinfo]. But I can add that. 3. For externals that try to override internal objects, all bets are off. (But there may be a way to check for that, too.) I'll try coding it up later. -Jonathan
On Monday, February 29, 2016 9:46 AM, Alessio Degani via Pd-list <pd-list@lists.iem.at> wrote:
On 29/02/2016 12:11, cyrille henry wrote:
Le 28/02/2016 20:25, Alessio Degani via Pd-list a écrit :
Hi Cyrille,
On 28/02/2016 14:14, cyrille henry wrote:
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
I do care of both. I've used to write my patch with pd-extended, that eliminates the problem "from the root".
pd-extended did not solve this problem: pd-extended create this problem!
Again, I totally agree with you! :)
In this way my patch will work (almost) certainly with pd-extended across each platform and from now on.
But I've decided to abandon extended for all the reason that we all know :) The problem, now, is:
- If I want to distribute my patch, it would be great to write down
the dependencies, for example in the README. And virtually, since I've used to work with pd-extended, I've in some way "lost" the border within vanilla objects and extended objects, so I've to manually check each time (i.e.: hummm spigot~ is vanilla? NO, ok... let me check... oh ok... is in the unathorized package -> each time for each object).
- I use different machines with different OS, etc... and sometimes I
use "fresh" pd vanilla installation. Ideally, I want to install only the externals that I need. If I have a list of externals needed for my patch, this process would be much more easy (few clicks with Deken)!
i think you should first reduce number of external you need : spigot~ can be certainly be replace with a *~...
Yes, I'm going to proceed this way in order to reduce the number of abstraction. That's the way I've used to work before starting to use pd-extended. I prefer to implement the object as abstraction by myself, but pd-extended has spoiled me :) I guess that I will have to do a lot of work in vanilla-izing all my old patches.
Anyway, I think that a method to "attach" a list of "used externals" to a given patch would be useful!
Cheers
you can replace lot's of externals using abstractions. that's a lot of work, but your patchs will be lot's more portable.
cheers c
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
I totally agree with this! :)
Cheers
cheers c
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On 27/02/16 19:05, Alessio Degani via Pd-list wrote:
My goal is to find if a patch is vanilla compatible and, if not, which are the lib that I need to run it.
One of the ideas IOhannes and I were exploring was a way that Pd patch authors could specify which externals their patches depend on, and Deken could be asked to examine the list and fetch & install them automatically. This could work kind of like Python's requirements.txt or Ruby's Gemfile or npm's packages.json. The biggest issue to solve here is probably what to do about multiple conflicting versions of a particular external, but maybe the simplest way is to install those dependencies into a directory local to the patch itself rather than ~/pd-externals - like Node's nodeenv or Python's virtualenv do.
Because sometimes the best machine intelligence available is human intelligence.
Cheers,
Chris.
Hi,
On 01/03/16 08:13, Chris McCormick wrote:
On 27/02/16 19:05, Alessio Degani via Pd-list wrote:
My goal is to find if a patch is vanilla compatible and, if not, which are the lib that I need to run it.
One of the ideas IOhannes and I were exploring was a way that Pd patch authors could specify which externals their patches depend on
I've written up a basic spec for this. Feedback welcome.
https://github.com/pure-data/deken/issues/122
Cheers,
Chris.
-
Alessio Degani -
Chris McCormick -
Claude Heiland-Allen -
cyrille henry -
Esteban Viveros -
IOhannes m zmölnig -
Jack -
Jonathan Wilkes