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