The day we have meaningful diffs, we can systematise the >evolution of pd
help file translations, as mistakes are >corrected, as details are explained, and as new features are >added.
Nicely pointed Mathieu, I agreed. Although it is not trivial, its definitely a matter that should be addressed to allow a "better" evolution of pd as a community/open driven language.
How could pd's file structure could be easily changed to being more "diffable"? Have you organized any thoughts on that? (a quick self-mental exercise shows me that it would require major changes, or can we see conversely on a different "diff" process?)
best regards, Pedro
On Fri, Aug 13, 2010 at 11:39 PM, Mathieu Bouchard matju@artengine.cawrote:
The day we have meaningful diffs, we can systematise the evolution of pd help file translations, as mistakes are corrected, as details are explained, and as new features are added.
This would be an awesome project for someone to take on. From my point of view, I think the most fruitful place to start is not the .pd text file format, but the visual rendering of that text file. It is how the Pd patch looks that is meaningful, so I think that rendering an image of each patch/subpatch then using some kind of visual diff would be a good place to start.
.hc
On Sat, 2010-08-14 at 00:00 +0100, Pedro Lopes wrote:
The day we have meaningful diffs, we can systematise the >evolution
of pd help file translations, as mistakes are >corrected, as details are explained, and as new features are >added.
Nicely pointed Mathieu, I agreed. Although it is not trivial, its definitely a matter that should be addressed to allow a "better" evolution of pd as a community/open driven language.
How could pd's file structure could be easily changed to being more "diffable"? Have you organized any thoughts on that? (a quick self-mental exercise shows me that it would require major changes, or can we see conversely on a different "diff" process?)
best regards, Pedro
On Fri, Aug 13, 2010 at 11:39 PM, Mathieu Bouchard matju@artengine.ca wrote: The day we have meaningful diffs, we can systematise the evolution of pd help file translations, as mistakes are corrected, as details are explained, and as new features are added.
-- Pedro Lopes (ongoing MSc) contact: pedro.lopes@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
humm... isn't that the major issue concerning a graphical language like pd? We can try to diff both visual and text elements, but I think what has the most semantical meaning diff-wise should be the text file content. I am trying to think about small example first so I can see the extent of the problem.
Seems like an interesting project.
best regards, Pedro Lopes
On Sat, Aug 14, 2010 at 12:06 AM, Hans-Christoph Steiner hans@at.or.atwrote:
This would be an awesome project for someone to take on. From my point of view, I think the most fruitful place to start is not the .pd text file format, but the visual rendering of that text file. It is how the Pd patch looks that is meaningful, so I think that rendering an image of each patch/subpatch then using some kind of visual diff would be a good place to start.
.hc
On Sat, 2010-08-14 at 00:00 +0100, Pedro Lopes wrote:
The day we have meaningful diffs, we can systematise the >evolution
of pd help file translations, as mistakes are >corrected, as details are explained, and as new features are >added.
Nicely pointed Mathieu, I agreed. Although it is not trivial, its definitely a matter that should be addressed to allow a "better" evolution of pd as a community/open driven language.
How could pd's file structure could be easily changed to being more "diffable"? Have you organized any thoughts on that? (a quick self-mental exercise shows me that it would require major changes, or can we see conversely on a different "diff" process?)
best regards, Pedro
On Fri, Aug 13, 2010 at 11:39 PM, Mathieu Bouchard matju@artengine.ca wrote: The day we have meaningful diffs, we can systematise the evolution of pd help file translations, as mistakes are corrected, as details are explained, and as new features are added.
-- Pedro Lopes (ongoing MSc) contact: pedro.lopes@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Fri, 13 Aug 2010, Hans-Christoph Steiner wrote:
It is how the Pd patch looks that is meaningful, so I think that rendering an image of each patch/subpatch then using some kind of visual diff would be a good place to start.
There is the Visual Diff feature in desiredata, which blinks a big .gif file over a complete patcher, but this was meant for showing difference in rendering for the same patch in two pd versions.
Such a visual diff doesn't work when the patch has been spliced with new content because the blinking doesn't enhance the meaningful difference. the gif would have to be slided manually over the patch to account for insertions. Well, it could be done automatically too, but that's relatively very complicated. Then handling long patches and subpatches to make sure every change gets noticed, would be more complications.
In the end, what is important is not how the Pd patch looks, it's the content of the pd file. But not all of it : the ordering of the objects has to be somehow ignored, normalised or controlled in some way.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 14 Aug 2010, Pedro Lopes wrote:
How could pd's file structure could be easily changed to being more "diffable"? Have you organized any thoughts on that?
First I thought about major changes to pd, replacing the object linked list of each canvas, by a std::map structure or anything else allowing to skip numbers. That way, for example, deleting an object doesn't have to renumber all following objects (in the sequence) such that all the 'connect' lines involving the following objects have to change every time. The way I made it, you could also edit an object box's text (or a comment's text) while keeping it at the same place in the list. It's not a big change to the file format, but rather, a big change in pd's source code.
But then, there are solutions that are more approachable from the perspective of writing only new externals or abstractions.
If comments are replaced by externals that store a hidden serial number or random number, then you can keep track of their changes without need for them to stay in the same order. I can write a small programme for doing that from the commandline, the problem being more how to write the external exactly.
Then there's the question of where to store the translation. When there are only two languages (or a few) it's tempting to put them all in the same file (the external would save and load each comment's English, French, Portuguese and German text all at once consecutively).
But for more languages and more people organised more loosely (and with a file format that doesn't work well with SVN) then it might be better to store translations in a separate file (how?).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Pedro Lopes