On Nov 9, 2015, at 2:56 PM, IOhannes m zmoelnig wrote:
hi hans,
great to hear from you!
On 2015-11-09 14:49, Hans-Christoph Steiner wrote:
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
what i would find more interesting: how hard would it be to update the PdX-core to Pd-0.47? that is, the patcheset against Pd-vanilla.
i once had a look at the PdX repository (which is based on miller's vanilla Pd), but even for PdX-0.43 the two repositories had diverged by (iirc) a few hundred commits, which makes it highly impractical to rebase/reapply/cherry-pick.
is there any meta-description available of the diffs between PdX and Pd?
For a long time, I used a git workflow that kept the Pd-extended changes as a set of patches on top of vanilla, you can see that in the 'patch_series' branch. You can see that in the history. I ultimately abandoned that because there were too many commits from vanilla that I had to remove in order to keep things working. So I switched to treating vanilla as a source of patches which I included into the pd-extended master. I regularly submitted patches that didn't rely on the Pd-extended stuff to the patch tracker. Many of those were ignored for years. I have no idea the current state of them.
That workflow is documented here under "Pd-extended": https://puredata.info/docs/developer/GitWorkflows
As for syncing up Pd-extended with the latest vanilla commits, that is a manual process of reviewing them and including them. If I remember correctly, basically anything that touches an object, e.g. src/x_list.c, src/d_soundfile.c is directly accepted. The objects in extra/ actually removed from pd-extended.git, so those changes can all be ignored. I generally automatically accepted changes to the DSP core too. Stuff related to the GUI definitely needs to be carefully reviewed.
.hc