Since Pd-Extended is basically EOL at this point, maybe we should discuss more formal plans on a transition to Pd-vanilla+deken. I know this has been happening informally, but I think it would be cool to come up with some sort of timeline and list of things to do to reach a relative parity, all of which are “signed off” by the interested parties involved. We could also reach out to the list with some test cases, etc.
This thought sprang to mind as yet another bug report for Pd-extended came in ...
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hi Dan,
On 01/10/15 00:25, Dan Wilcox wrote:
Since Pd-Extended is basically EOL at this point, maybe we should discuss more formal plans on a transition to Pd-vanilla+deken.
I think the main outstanding issue is whether deken functions correctly on Windows. Roman did some testing and I think there were some outstanding issues but my memory is blurry.
Cheers,
Chris.
On Thu, 2015-10-01 at 09:48 +0800, Chris McCormick wrote:
Hi Dan,
On 01/10/15 00:25, Dan Wilcox wrote:
Since Pd-Extended is basically EOL at this point, maybe we should discuss more formal plans on a transition to Pd-vanilla+deken.
I think the main outstanding issue is whether deken functions correctly on Windows. Roman did some testing and I think there were some outstanding issues but my memory is blurry.
As far as I can tell, there are no out-standing issues on Windows regarding deken. Two things have been fixed that affected the usage of deken:
* Some standard paths were missing so that deken wasn't found on newer Windows' (fixed with commit 7fb6311c)
* [declare -stdpath] did not work on Windows (fixed with commit 1b7af3c)
I remember that deken on Windows did not automatically unzip the packages, but only download them. Is that still the case? On my test machine I installed a bunch of unix-y toos for building (git bash, mingw, etc.) and then auto-unzipping worked, though I haven't investigated what exactly made it work. I guess some installer came with a unzip binary. Is that something that you would like to address?
Roman
Right. I guess that would go under “list of things to do to reach parity”. :D
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 30, 2015, at 7:48 PM, Chris McCormick chris@mccormick.cx wrote:
Hi Dan,
On 01/10/15 00:25, Dan Wilcox wrote:
Since Pd-Extended is basically EOL at this point, maybe we should discuss more formal plans on a transition to Pd-vanilla+deken.
I think the main outstanding issue is whether deken functions correctly on Windows. Roman did some testing and I think there were some outstanding issues but my memory is blurry.
Cheers,
Chris.
On Wed, 2015-09-30 at 10:25 -0600, Dan Wilcox wrote:
Since Pd-Extended is basically EOL at this point, maybe we should discuss more formal plans on a transition to Pd-vanilla+deken. I know this has been happening informally, but I think it would be cool to come up with some sort of timeline and list of things to do to reach a relative parity,
I'm not sure what you mean by 'relative parity'. Things probably won't be the same with deken, I assume. In Pd-extended times, people would have created patches with whatever externals, they even didn't have to know what externals their patches used. It was sufficient to specify "Pd-extended" as a dependency for running the patch. With deken, the author needs to specifically list all externals when sharing the patch. To me shifting to deken means raised awareness about externals. It also means that it provides a path to get rid of unmaintained and/or buggy stuff. There is no need anymore to install deprecated stuff per default for anyone just for the sake of keeping backwards compatibility. In that regard, the deken era will be different from the Pd-extended era.
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Roman
On 2015-10-01 10:12, Roman Haefeli wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
it was mostly chris work.
i reorganized the externals into folders on the portal, which unfortunately changed ownership; so now they appear to be coming from "zmoelnig" rather than "chr13m".
fixing this is not very high on my todo list.
fmasdr IOhannes
-
Chris McCormick -
Dan Wilcox -
IOhannes m zmoelnig -
Roman Haefeli