On Mon, 11 Sep 2006, Vincent Lordier wrote:
I want to work on pd's code readability and structure, only refactoring, not adding new features. (http://en.wikipedia.org/wiki/Refactoring)
Making diffs and applying diffs doesn't go too well with refactoring. This leads to large diffs that clash easily. The only way to eliminate this problem with refactoring would be to use a super-sophisticated diff program that understands the language it works with. (This won't happen with the C language anytime soon...)
So, supposing you want to work with Miller, you should get agreement with him about doing this, because the diffs you would submit will expire rather quickly by conflicting with other diffs. This said, I don't think Miller wants any help with that, but I'll let him tell you.
'We've got to undo the MIDI revolution! said Miller'
This sentence is misleading. Pd doesn't undo the MIDI revolution, it goes beyond it. There's no going backwards here.
You could work on devel_0_39, but I doubt you can make any big changes. I once tried to remove unused variables from the code, and my change got reverted. Any change that doesn't bring a new feature is likely to be reverted, IMHO. This is both due to the diffing process used for submitting diffs to Miller and the diffing process used for merging new Miller releases into devel (supposing that there will ever be a devel_0_40... I don't know yet). Those are factors that encourage to keep devel_0_39 as close to Miller's as possible.
I've done heavy refactoring, but that was only the GUI section, and it isn't strictly refactoring, as there has been a bunch of established features that haven't been working for many months. Even then, the way I did it was to copy all g_*.c files into one big file, desire.c, and then in the buildfile, conditionally compile either g_*.c or desire.c. And then I work on the big file only, except for some changes that really had to be done in other files, but those changes are kept to the strict minimum.
While this same concept could be used in other parts of devel_0_39, soon we wouldn't have a reason to not have a separate branch for that kind of work...
I don't plan to do more of this forking before I actually switch to using my own GUI... and even after that I'm not sure how long I'll take. Until then, I'll only fork the files that I really need to fork, if I find any.
=> Well, as far as I know, removing MIDI from PD's hairy code isn't as easy as "./configure --nomidi' make install ... yet !
Why do you need to remove MIDI? Is it for code structure reasons or do you also have needs for that? (running Pd on very small computers...)
Again, my goal is not to alter pd in its behavior (yet),
my goal is.
just to improve readability and separation of modules.
Pd's style guide says that the one-or-two-letter prefixes on all the struct member names are there for "readability" purposes. That's not my kind of readability at all. What's your kind of readability? What does it mean to you?
BUT my main problem right now is : on which version / branch should I work on ?
I wish you good luck in figuring that out.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada