[PD-dev] Refactoring Pure Data

[Tim Blechmann]

hi vincent ...

> That implies a primary work on architecture and a cooperation of all
> devs (commit often, criticize, propose, improve, test, submit
> patches, ...). 
> I'll develop on architecture on other posts soon, but I want to first
> focus on making the best out of what we have today.

well, i've been following the development of the pd kernel for two or
three years now ... most problems i faced where social rather than
technical problems, e.g. i introduced features to devel, that didn't
work with a more recent vanilla release ...
so i had to port them over, or abandon them ... spending days with
merging code is no fun, though ...


> It deserves a clear roadmap, and a little of architecture work.
> I think this work on architecture will be mandatory as we add new
> features (like video~)

again, there are social problems ... the people contributing to the code
have different goals (data structures, fancy gui, gui/kernel separation,
performance, threading) ... however ... 
a roadmap would only make sense, if these people would communicate ...
since they don't do it, there are 2.5 separate branches at the
moment ...

>         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

in theory, cleaning up the code would be really nice ... but it makes
merging of trivial code much harder (believe me, i tried it) ... the
diff between devel and vanilla are several thousand lines of code ...
and still increasing, mainly because of the desiredata stuff ...



> - Self explanatory naming (how many single letters variables and / or
> funny functions names do we have ?) 
> - Short functions (20 lines)
> - Short files (100 to 200 lines)
> - Reasonable Cyclomatic number
> - A little indenting
> - Getting rid of stuff.h which is a nonsense to me and having .h in
> modules when required. 
> 
> 
> 
> I went through a little static analysis and this is the start of my
> work.
> Again, naming refers to architecture / modules, and that's where the
> work needs to be done.
> I think isolating Audio, MIDI, GUI, network, CoreLibs is a good,
> ambitious but necessary start. It will make the development of Pd much
> faster, and the overall quality of the code, thus the final executable
> will be improved. 

i wish you good luck with that ... sounds like a _lot_ of work ...
however i doubt, that these drastic changes are really going to make it
into vanilla pd, taking into account that a simple patch as the tooltip
patch is still pending after about two years ...

cheers ... tim

--
tim at klingt.org    ICQ: 96771783
http://www.mokabar.tk

Most of the trouble in this world has been caused by folks who can't
mind their own business, because they have no business of their own to
mind, any more than a smallpox virus has.
  William S. Burroughs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060912/22039937/attachment.pgp>