[PD-dev] Refactoring Pure Data (1 of 2)

[Mathieu Bouchard]

On Tue, 12 Sep 2006, Vincent Lordier wrote:

>> do you do unit-testing?
> Here's my point of view : to be able to do unit testing, we need functions
> that are actually "testable", and that means they are :
> - small
> - not complex (small Cyclomatic number)
> - doing one single thing

So do you want to first refactor pd and then make unit tests for it, 
or do you want to first make unit tests so that pd can be safely and 
efficiently refactored?

(I did it without the unit-tests... it's not efficient; but then it's 
not like the GUI is an easy thing to do unit-tests on)

> - easily isolated from the rest of the program

How much isolation do you mean here? because you surely don't mean 
complete isolation...

> I believe more in "good conception leads to less bugs", and I'm not a big
> fan of unity testing myself.

I believe the same. The way I say it, is "The best way to write less 
bugs is to write less code".

But I also believe that unit-testing prevents grey hair so I better get 
started on it soon.

> m_pd.h is an API, Johannes has put together a documentation,

Martin Peach also has written some doc about m_pd.h and pd's internals. 
(where is that doc again?)

> The "core" should be as minimalist as possible, so it allows anyone to build
> their own "Pd" on top of it.

I basically agree with this: the m_*.c section of Pd should be separable 
from the rest, except for the parts that are covered by other sections but 
really belong in m_*.c; likewise for some other sections of pd.

I won't be pushing for making it really as small as possible, but just 
rather small, which is still much smaller than what it is now.

> (with any GUI, with any components, float or int,

also consider float32 vs float64, because it is rather often that someone 
asks for something that would only be doable with float64.

> make it available on webservers,

pd is already available to webservers, it just doesn't need to be embedded 
inside a webserver.

>> I agree about splitting s_stuff.h or otherwise cleanly indicating what its
>> sections are; however I don't know what you mean by having .h "in"
>> modules. Is a "module" some kind of directory?
> Yes, like
> /audio
> |-/pd_audio.c, pd_audio.h
> |--/alsa
> |--/jack
> |--/whatever

Splitting things into directories is really optional, and doesn't really 
fit with CVS (because in CVS, renaming and/or moving requires to restart 
the log because it gets treated as a new file). This could wait until a 
switch to SVN (if it ever happens).

What's more important than directories is defining clear separations 
between the parts of pd, and that doesn't need directories.

> stuff.h already has sections. But there it is confusing and unsafe that all
> files include "stuff.h" and can access anything declared in it ! It is
> against separation of variables, functions, structures and ... modularity !

yes... though even if it's split in several, in many projects there's a 
big central header that slurps everything that you need, as well as 
everything that you don't need and then possibly a lot that isn't even 
compiled in. (but does this matter SO much, then?)

>> I stopped caring about trying to organise PureData developers meetings
>> some time ago. I think we've had seven of them. It didn't catch on.
> Communication is key.

But communication can only be done among people who want to communicate.

> IRC isn't the best tool but it's a start.

What's "the" best tool?

> Meetings are nice too :) The one we had in Paris during the NIME06 was 
> interesting.

The ones in Montréal (saturday afternoons) are often nice, but are not 
among core developers. There's been one developers' meeting Sept 27 - Oct 
3 2004, and there will be one Aug 21-25 2007, but in the meanwhile there 
are the Piksel festivals, mid-october 2005 and 2006, in Bergen, Norway.

> I like launchpad, but we could also make a better use of puredata.info 
> wiki, or setup trac or anything like this.

There's a Trac but it's reserved for DesireData 
(http://desiredata.goto10.org/)

I have more to reply about, so, à suivre...

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada