So, supposing you want to work with Miller

Why no ? As long as the developments are not made "under closed doors" (= frequents commits / test releases / bug submits ), I'm willing to work with anyone.

To me, I shouldn't have to "work with Miller" or "work with Mathieu" or anything like this, simply because we are wasting way too much energy doing theses diffs / merge stuff. Having different branches is fine and even desirable (!), as long as it leads to more generic modules that can be tested and refined in more diverse cases. We should be working on what we're good at and what interests us, and a successful project is a project that's truly OPEN, and broken down into workable / testable / improvable modules. And each of them could have their own maintainer, structure or language even. It works very well with externals. It doesn't (yet) with the internals of Pure Data.

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.

This said, I don't think Miller wants any help with that, but I'll let him

tell you.

Miller ? ;)

'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.

I do understand. Taking things apart is also going beyond what we have today. Let's face it : Pd is wonderful and mostly well written, but its code is a little hairy (no offense intended). And its development is slow, quite unpredictable and hard to read compared to many other projects. 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~)

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.

The solution isn't to make forks on forks IMO : the key is to reduce the amount of code to be merged. Making Pd more modular allows to work on what you want, remove what needs to be removed easily (if you need a small footprint, have some other realtime constraints or implementation issues like no FPU or loads of processor extensions), and leave the rest untouched.

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...)

Exactly : making embedded Pd much easier. If all I need is just a few filters, debounce, NN and OSC to drive an embedded device, and no GUI and a small footprint, I could do it with Pd very easily : just upload a patch into embedded Pd running on top of ucLinux and you're done. Only today, it requires quite a bit of effort to make an embedded Pd. PDa is a great initiative and we've seen this project ported on other platforms like iPod, and someone on pd-list was asking about putting it on his Archos. We will see more ports in a near future as embedded devices get more exciting, accessible and hacked. I want these ports to be smoother, so we could load a patch into a little standalone device which only deals with sensors/actuators and network for instance.

But having a simple, modular, readable code is useful to anyone.

Again, my goal is not to alter pd in its behavior (yet),

my goal is.

I think you've done much in showing how we could / should separate the GUI from what I call the engine. It allows more flexibility, and as long as what makes the strength of Pd isn't altered, it goes in the right direction in terms of realtime behavior and creativity. Because of the dev process, it takes a lot of energy. Same goes with gg's PDa and Pd's possibilities in embedded environments, and others I apologize for not mentioning.

I don't want to change its behavior in terms of features : splitting the code into functionally coherent modules is "just" architecture & quality and that's my goal.

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?

- 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.

It should be possible to replace the actual CoreLib with a pure integer one if needed (see gg's port). And if there's nothing else but "pure data" (!) to process (sensor=>network), it should be possible to adapt Pd to do just this and do it well. This applies to any application you might think of.

Maybe Pd's internals architecture could be a nice topic for a little IRC meeting ? Who's in ?

BUT my main problem right now is : on which version / branch should I

...

work on ?

I wish you good luck in figuring that out.

thx :)

++

vincent

On Tue, 12 Sep 2006, Tim Blechmann wrote:

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 ...

1. Does communication imply collaboration?

2. Does collaboration imply everybody on the same branch?

3. If people don't want to communicate, why is that? How can it be changed? And I don't mean one side surrendering to the wishes of the other side...

the diff between devel and vanilla are several thousand lines of code ... and still increasing, mainly because of the desiredata stuff ...

DesireData hardly changes anything in files that are already existing... Ok, there are 33 small #ifdefs, many of which around one-liners.

Mainly, DesireData adds 14700 lines of code. Because it's coexisting with the traditional GUI in the devel_0_39, it doesn't remove the files that it doesn't use anymore (which are 25500 lines all together).

But give me some weeks and I promise that DesireData will be smaller. :-)

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

On Mon, 11 Sep 2006, Vincent Lordier wrote:

...

So, supposing you want to work with Miller

Why no ?

Because you want to refactor Pd and because, I suppose that you've read pd-list and/or pd-dev for some time.

To me, I shouldn't have to "work with Miller" or "work with Mathieu" or anything like this,

So you are going to work alone? Or you're going to reunite the family?

simply because we are wasting way too much energy doing theses diffs / merge stuff. Having different branches is fine and even desirable (!),

If there's not going to be merging then what do you want the branches to do? split further apart?

as long as it leads to more generic modules that can be tested and refined in more diverse cases.

do you do unit-testing?

Let's face it : Pd is wonderful and mostly well written,

It's well written in the sense that it doesn't have so many bugs.

but its code is a little hairy (no offense intended).

I'd say it louder and bolder than that.

It deserves a clear roadmap,

Several people have their own roadmaps. Does it need one big shared one? Just how shared would that one be?

I think this work on architecture will be mandatory as we add new features (like video~)

Do you think that adding a sixth video subsystem to pd is going to solve anything?

The solution isn't to make forks on forks IMO : the key is to reduce the amount of code to be merged. Making Pd more modular allows to work on what you want,

You don't understand what I mean: there's a catch-22 (a deadlock) - modularizing may reduce the amount of merging in the long term, but in the short term, it's increasing it, and that's what will prevent modularization from happening in the current branches, despite its benefits.

...

Again, my goal is not to alter pd in its behavior (yet), my goal is.

Actually, I also have the goal of refactoring, of course, but I can't guarantee invariance of behaviour in any way...

• Self explanatory naming (how many single letters variables and / or

funny functions names do we have ?)

most names don't have to be long, especially when local and also especially when often used.

• Short functions (20 lines)
• Reasonable Cyclomatic number

I agree on both of those.

• Short files (100 to 200 lines)

I don't believe this buys us any advantage, and actually has several disadvantages. This is why I put all of the DesireData server-side code in one file, and most of the client-side code in one file too.

• A little indenting

I haven't seen any spots in PureData where the indentation was not done, or not done correctly, according to its own rules. I might not like the way it's indented, but I can say it's indented the same everywhere I looked. (DesireData is not nearly as uniform in its indentation).

• Getting rid of stuff.h which is a nonsense to me and having .h in modules

when required.

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?

Maybe Pd's internals architecture could be a nice topic for a little IRC meeting ?

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. I decided to call DesireData meetings instead, but the 2nd meeting is loooong overdue.

Who's in ?

I could be in. Is this going to happen on #dataflow ?

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

Hi all,

Sorry not to jump in before now... I'm in the middle of getting ready for the school year here and don't have much time for longer-range planning at the moment.

My top priority for Pd is to finish getting the 'language' defined. I don't see this as an open-ended pursuit; another year or so of fooling with 'data structures' seems to be the main remaining thing. Until this is fairly well under control I don't see much point in rewriting existing code; in particular, I want to do some heavy run-time profiling to find out what really needs improvement. But this is pointless until I know what typical patterns of usage will look like, particularly as regards to 'data' traversal, which I think has some severe inefficiencies now.

I think Vincent is right on about the need for better error handling. This is also, partly, a design issue, since patches themselves sometimes need a mechanism for detecting errors. I've spent some time thinking about this and eventually I want to make a formal structure for flagging and inquiring about errors... but not just yet; the data traversal objects need to get finalized first.

cheers Miller

On Tue, Sep 12, 2006 at 04:05:50PM +0200, Vincent Lordier wrote:

Hi again ;)

...

...

So, supposing you want to work with Miller Why no ?

Because you want to refactor Pd and because, I suppose that you've read pd-list and/or pd-dev for some time.

I did. And I've seen how this project works a little. The thing is, it doesn't work as a truly open community, but this can change.

...

To me, I shouldn't have to "work with Miller" or "work with Mathieu" or

...

anything like this,

So you are going to work alone? Or you're going to reunite the family?

At first, doing little splitting here and there could be done by one single person and I can do this. Now, as I said, the real issue is "where do I cut", and "how", and that's architecture, conception, and that has to be done with the whole "family". And as you pointed out, changing anything today means lots of work in merging.

But if we don't want to do merging, we need to break down vanilla into pieces, and put these pieces together with others, like DD's GUI.

To me, making DesireData (or any other project) a viable solution starts with splitting vanilla into "what you want to work on" and "the rest". Then, natural selection will come and we'll pick which solution is best.

...

simply because we are wasting way too much energy doing theses diffs /

...

merge stuff. Having different branches is fine and even desirable (!),

If there's not going to be merging then what do you want the branches to do? split further apart?

...

as long as it leads to more generic modules that can be tested and refined in more diverse cases.

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
• handling errors
• easily isolated from the rest of the program

I believe more in "good conception leads to less bugs", and I'm not a big fan of unity testing myself. But it is a honorable goal to do unit-tests.

This is how we could avoid quite a few stupid bugs : => just look at callgraphs using Doxygen with callgraphs enabled, it's free & easy and it'll show you a lot about the program structure (and where to "cut") Attached is an Doxyfile example with callgraphs enabled. Takes a while to generate, and produces big callgraphs (from / to) images. => running splint, uno, and others. It also shows some little pieces of dirt here and there.

CCCC can also help us keeping track of the size of the code and its complexity, as a default of stuff like RSM, and to know where to start working first. We don't necessarily need these tools, but they can help.

Some of you guys, Mac users, have access to Shark (part of XCode) for instance (http://developer.apple.com/tools/sharkoptimize.html). I don't. But i'd be interested to see the results published on PD and see its memory usage, and to profile the application to have an idea of where we should focus efforts. Sure Kprof and others exist too, but it's not the same :) There's also http://www.drugphish.ch/~jonny/cca.html

Anyway, the point is we have loads of tools to check and split the program and I used them on Pd. Now, my initial question was : "ok, I found that lots can be improved : how do I propose improvments to the community that imply refactoring and splitting ?" And I see why everyone so far answered "You're getting into social issue man, good luck !" And that's why I'm saying : "Fine, let's break things down so we can all work on Pd's development then" Now, I can't and don't want to do that by myself, behind closed doors or on a separate repository or do another useless fork : I need the adhesion of the "community", or else I won't be able to make any changes... like many others who have been discouraged.

...

[Pd] deserves a clear roadmap,

Several people have their own roadmaps. Does it need one big shared one? Just how shared would that one be?

Architecture goals should be shared. Then, on each SW component, everyone can do what they want, as long as they respect / define / communicate on interfaces. Again : it works with pd / externals. m_pd.h is an API, Johannes has put together a documentation, and developments of externals take place.

The goals of each person are achievable as long as they don't interfere with other's : and that's where separating the codebase and functions is essential. The "core" should be as minimalist as possible, so it allows anyone to build their own "Pd" on top of it. (with any GUI, with any components, float or int, externals or not, network or not, full pack, whatever).

The final distribution for users should still include everything possible as Hans is doing (congrats on the build farm btw). But the code should allow us to carry on projects like PDa, ePD (embedded PD), make PD core into a plugin, or a standalone app with GriPD-reloaded, make it available on webservers, or anything people have been talking about for a while now.

...

I think this work on architecture will be mandatory as we add new

...

features (like video~)

Do you think that adding a sixth video subsystem to pd is going to solve anything?

I absolutely don't. What I think is adding it might present the advantage of making pd more modular than it is today, otherwise it's going to be hell. Cuz we might ask ourselves : how do we integrate these new objects ? We need to treat audio, MIDI, video like any other external ! We need to reduce Pd's core to the minimum possible (=put CoreLibs, Audio, MIDI, GUI aside of it).

...

The solution isn't to make forks on forks IMO : the key is to reduce the

...

amount of code to be merged. Making Pd more modular allows to work on what you want,

You don't understand what I mean: there's a catch-22 (a deadlock) - modularizing may reduce the amount of merging in the long term, but in the short term, it's increasing it, and that's what will prevent modularization from happening in the current branches, despite its benefits.

Mmh ... I guess we should start by putting everything on the table and splitting vanilla and stop working on devel and other branches, at first. That way, DD's (and others) developments / merges could be easier right after. Since you understand french "C'est un mal pour un bien".

...

...

Again, my goal is not to alter pd in its behavior (yet),

...

my goal is.

Actually, I also have the goal of refactoring, of course, but I can't guarantee invariance of behaviour in any way...

That's true. It's a risk. But it needs to be taken, and it'll help understanding how we can improve Pd.

...

• Self explanatory naming (how many single letters variables and / or

...

funny functions names do we have ?)

most names don't have to be long, especially when local and also especially when often used.

Let me take a quick example to illustrate my point :

(from s_inter.c, removed #ifdefs for this example)

void sys_set_priority(int higher) { struct sched_param par; int p1 ,p2, p3; p1 = sched_get_priority_min(SCHED_FIFO); p2 = sched_get_priority_max(SCHED_FIFO);

p3 = (higher ? p1 + 7 : p1 + 5); par.sched_priority = p3; if (sched_setscheduler(0,SCHED_FIFO,&par) != -1) fprintf(stderr, "priority %d scheduling enabled.\n", p3);

if (mlockall(MCL_FUTURE) != -1) fprintf(stderr, "memory locking enabled.\n"); }

and

(quick and dirty version)

int sys_set_priority(int higher) { struct sched_param pd_sched_settings; int priority_min; int priority_max; int priority; int error_desc;

priority_min = sched_get_priority_min(SCHED_FIFO); priority_max = sched_get_priority_max(SCHED_FIFO);

priority = (higher ? priority_min + WATCHDOG_PRIORITY_BUMP : priority_min + PD_PRIORITY_BUMP); pd_sched_settings.sched_priority = priority;

if (sched_setscheduler(0, SCHED_FIFO, &pd_sched_settings) != -1) { fprintf(stderr, "priority %d scheduling enabled.\n", priority); return (0); } else { error_desc=errno; fprintf(stderr, "couldn't change process priority to %d.\n", priority); fprintf(stderr, "%s (%d)", strerror(error_desc), error_desc); return (WHATEVER_ERROR_TO_BE_DEFINED); } }

(since this is ANOTHER function, so we separate it ! )

int sys_set_memory_lock(void) { int error_desc;

if (mlockall(MCL_FUTURE) != -1) { fprintf(stderr, "memory locking enabled.\n"); return(0); } else { error_desc=errno; fprintf(stderr, "couldn't enable memory locking.\n"); fprintf(stderr, "%s (%d)", strerror(error_desc), error_desc); return (WHATEVER_ERROR_TO_BE_DEFINED); } }

I know it's so not the "best" code ever and it is improvable, but I just wanted to illustrate my point. For instance,

• Better error handling can be done here,
• Localization can be done here,
• Generic error function can be written,
• Safe fprintf can be used to avoid overflow.

An explicit name doesn't take more memory at runtime, and saves the dev brain power at coding time ;) And splitting functions won't make Pd noticeably slower, since these functions are called ONCE or TWICE throughout the whole program's runtime ;) But it'll allow comprehension, flexibility, error handling, debug and testability.

...

• Getting rid of stuff.h which is a nonsense to me and having .h in

modules

...

when required.

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

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 !

...

Maybe Pd's internals architecture could be a nice topic for a little IRC

...

meeting ?

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. I decided to call DesireData meetings instead, but the 2nd meeting is loooong overdue.

Communication is key. IRC isn't the best tool but it's a start. Meetings are nice too :) The one we had in Paris during the NIME06 was interesting. I like launchpad, but we could also make a better use of puredata.info wiki, or setup trac or anything like this.

...

Who's in ?

I could be in. Is this going to happen on #dataflow ?

Wherever you guys want. I think we need Miller on board though. We need to know who's in, it's a community's job :)

I'd like to have Miller's point of view on this whole conversation too.

++

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

On Tue, 12 Sep 2006, Vincent Lordier wrote:

=> you want to focus on the "language and data structure" for the coming year and that's your right (!) => Some want to focus on GUI and that's their right. It is independent from data structures & language, since no matter what the objects do, drawing boxes, connecting them and talking to the "engine" is generic no matter how the language evolves, unless you tell us so.

In Pd, it's not. A large portion of what Miller calls "the language" is actually defined in g_*.c files as it is. This is something I'm working on extracting. Soon, my version of g_*.c will only contain what has nothing to do with GUI.

So really, Miller means that he's going to work on g_*.c; no merging of that into my code is possible at this point and any point in the future; I have to reimplement whatever features he adds, hoping that they're easier to implement in my branch than in his...

Checking if another pd "engine" is running / alive at launch time can be

Pd shouldn't check for another pd running. It is extremely common to use two pd's at once. This is required due to conflicts between audio and video. This is even something that we teach to newbies in workshops, including how to circumvent OSX's "launch only once" feature.

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

Yep... it's on my dolist :)

M

On Wed, Sep 13, 2006 at 05:39:02PM +0100, padawan12 wrote:

On Tue, 12 Sep 2006 22:39:16 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:

...

Pd shouldn't check for another pd running. It is extremely common to use two pd's at once. This is required due to conflicts between audio and video. This is even something that we teach to newbies in workshops, including how to circumvent OSX's "launch only once" feature.

Agreed, but actually it would be good to have the choice as a comandline arg of the first one launched with a way to accept patches to open in the same instance from, say a web browser. Like also when you are in a file manager and browsing some .pd files you really want them to open in the same running instance.

2c

a.

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

What's the point of keeping this "running two instances" feature and make the check as default ? Why not take the opportunity to rework the scheduler (with threads) so we don't have to launch two instances ? Sorry if I'm missing smth ... and please explain :)

++

On 9/13/06, Mathieu Bouchard matju@artengine.ca wrote:

On Wed, 13 Sep 2006, padawan12 wrote:

...

On Tue, 12 Sep 2006 22:39:16 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote: Agreed, but actually it would be good to have the choice as a comandline arg of the first one launched with a way to accept patches to open in the same instance from, say a web browser. Like also when you are in a

file

...

manager and browsing some .pd files you really want them to open in the

same

...

running instance.

oh ok, if it's an option... i put it in my TODO.

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

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

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

On Tue, 12 Sep 2006, Vincent Lordier wrote:

Let me take a quick example to illustrate my point : (from s_inter.c, removed #ifdefs for this example)

void sys_set_priority(int higher) { struct sched_param par; int p1 ,p2, p3; p1 = sched_get_priority_min(SCHED_FIFO); p2 = sched_get_priority_max(SCHED_FIFO);

What's wrong in your example is that you rename p2 to something else, instead of removing it. p2 is not used in your example. However, when I look at the source, I see that it's because of the #ifdefs that you remove.

Even considering the actual implementation instead of the simplified example, I wouldn't consider that renaming p1 to priority_min is really helping anyone, because they already know p1 is the minimum priority by looking two lines above. All uses of p1 lie within 5 lines of code, so using a longer name doesn't do much more than making the name longer to read. In some extreme situations (not this function) this can make the code harder to read, as the longer names clutter the function.

 fprintf(stderr, "priority %d scheduling enabled.\n", priority);
  fprintf(stderr, "couldn't change process priority to %d.\n",

priority); fprintf(stderr, "%s (%d)", strerror(error_desc), error_desc);

You didn't replace the fprintfs by posts. It should be posts because then it can be routed through the GUI.

• Localization can be done here,

No, localization should be done in the GUI. What should be done server-side, is to make error messages easier to process by the GUI.

• Safe fprintf can be used to avoid overflow.

Which overflow?

An explicit name saves the dev brain power at coding time ;)

I assert that often it doesn't. A name shouldn't be more explicit than it needs to be, and it's certainly possible for names to be too explicit, and i don't mean the "parental advisory" sys_defaultfontshit, I mean saying things that are too obvious because they're already in your face 15 times in the same page and cause the code to go on for longer than you should have to read.

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

I agree with this, from a non/novice programmer perspective. It would make it a lot easier for me to learn the inner workings of Pd if it were nicely labeled, and modularized.

It's so hard for me to just pick up and figure it all out! Even taking computer science courses cannot prepare a person for learning how to use/program a specific code base. It takes care and training to become acquainted with it, and most of all, time and friendly guides to help.

Matju, Vincent, and others, please join forces so we can kick Max/MSP/Jitter's ass! (Don't hate me Cycling74!)

~Kyle On 9/12/06, Vincent Lordier vincent.lordier@gmail.com wrote:

...

Even considering the actual implementation instead of the simplified example, I wouldn't consider that renaming p1 to priority_min is really helping anyone, because they already know p1 is the minimum priority by looking two lines above. All uses of p1 lie within 5 lines of code, so using a longer name doesn't do much more than making the name longer to read. In some extreme situations (not this function) this can make the code harder to read, as the longer names clutter the function.

...

 fprintf(stderr, "priority %d scheduling enabled.\n", priority);
  fprintf(stderr, "couldn't change process priority to %d.\n",

priority); fprintf(stderr, "%s (%d)", strerror(error_desc), error_desc);

You didn't replace the fprintfs by posts. It should be posts because then it can be routed through the GUI.

True.

...

...

• Localization can be done here,

No, localization should be done in the GUI. What should be done server-side, is to make error messages easier to process by the GUI.

Why not ? the engine, if running on a remote machine should also be able to send messages to the user in its language...

...

...

• Safe fprintf can be used to avoid overflow.

Which overflow?

see snprintf

...

...

An explicit name saves the dev brain power at coding time ;)

I assert that often it doesn't. A name shouldn't be more explicit than it needs to be, and it's certainly possible for names to be too explicit, and i don't mean the "parental advisory" sys_defaultfontshit, I mean saying things that are too obvious because they're already in your face 15 times in the same page and cause the code to go on for longer than you should have to read.

Quote from Wikipedia on software quality "Understandability

Are variable names descriptive of the physical or functional property represented? Do uniquely recognizable functions contain adequate comments so that their purpose is clear? Are deviations from forward logical flow adequately commented? Are all elements of an array functionally related?"+ => http://www.gnu.org/prep/standards/standards.html#Names => http://www.coding-guidelines.com/cbook/sent787.pdf => http://www.raytheon.com.au/Files/Achieving%20Software%20Quality%20PDF.pdf#se... => http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.... => http://www.aivosto.com/project/help/pm-understandability.html => http://en.wikipedia.org/wiki/Hrair_limit

etc etc ...

my 2 cents about naming.

++

vincent

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

...

...

...

An explicit name saves the dev brain power at coding time ;)

I assert that often it doesn't. A name shouldn't be more explicit than it needs to be,

Quote from Wikipedia on software quality => http://www.gnu.org/prep/standards/standards.html#Names

yes, according to that page, "Local variable names can be shorter, because they are used only within one context". So, what's your point?

...

=> http://en.wikipedia.org/wiki/Hrair_limit

Exactly: if it's too long, one identifier may occupy the mind more than it could, and thus it isn't really optimal.

Mathieu, it's all about compromises : what's "good" practice will hopefully last, what's not will eventually die. Only real life experience tells us. It's still good to look at other's practices, standards, and conclusion, but nobody should dictate to the others what to do here. It's an open source project, we can take it wherever we want.

Code quality standards try to define what is "good" code. Here, it's up to us to define what's good to us. And since we won't reinvent the wheel or write some ISO doc, we'll just let many hands get on the code, and many eyes read it, alter it, test it, manipulate it, reuse it.

So for now, I guess we should simply be able to "open" pd's internal developments to see some kind of Darwinism happening on pd's code and architecture... Then, what's "optimal" will emerge by itself IMO.

I proposed a lead for a solution to make the developments faster and better : breaking vanilla into independent modules. It'll be a long process, but I hope it'll be adopted in the long run.

Since vanilla is mostly in Miller's hands right now, I sort of asked him to delegate control on parts of code he wouldn't work on in the coming year, and let others add value to what already exist...

So it's basically up to Miller to let the development process change, so we can propose improvements. If not, then I guess I'll join the growing group of discouraged ones, eventually. devel_ is the good place for experimentation, as long as it can be merged to main easily, and that means we need to make modifications in vanilla first, so it's actually possible to work on devel_ easily.

++

On 13 Sep 2006, at 03:02, Mathieu Bouchard wrote:

...

So for now, I guess we should simply be able to "open" pd's internal developments to see some kind of Darwinism

Genetic evolution has more to do with monkeys on typewriters than about people wanting to make intelligent decisions. (Darwin knew this... even though typewriters didn't exist in his day)

Hold on. This seems to make an argument *for* closed code, and for pumpkin holding, and therefore, in favour of Miller's control. Are you feeling ok, Matthieu? ;-)

d

-- David Plans Casal main at davidcasal dot com http://www.davidcasal.com

On Wed, Sep 13, 2006 at 04:00:20AM +0200, Vincent Lordier wrote:

So it's basically up to Miller to let the development process change, so we can propose improvements. If not, then I guess I'll join the growing group of discouraged ones, eventually.

I think you have hit the nail on the head with this statement, Vincent. The situation is such that Miller has a particular way of working that doesn't include frequent CVS commits and doesn't include allowing others to hack on the vanilla sourcecode. This is fine, and is infact the way a lot of open source projects work; with a 'benevolent dictator' - the linux kernel for example follows this model. The only way to get something into the kernel is to submit a patch, just like Pd.

Miller seems to be a pretty busy person with things other than Pd and although he has made efforts to adopt tools like CVS it seems unlikely to me that he will find the time to change his entire development methodology to suit every person on this list.

In short, I think that if people want to see changes to Pd they have two choices to follow:

1. Follow the tried and tested method of other similar projects; read the notes.txt file and start submitting patches that fix issues that Miller wants fixed. We have seen Miller adopt many patches leading up to 0.40.

2. Whine a whole bunch and then fork the source code (and then hopefully stop whining).

3. If people want new features added to Pd they can submit patches, but they have to understand that as the leader of the project it is completely Miller's right to reject patches that he doesn't want to see as part of his vision of Pd. It should be noted that Linus (for example) frequently drops patches completely silently. Not because he's an asshole, but because there are more efficient ways for him to spend his time than understanding and replying to every single wacky change to the kernel.

There have for example been several complaints about the tooltips patch that never got submitted. Miller specified the exact reason that the patch was not accepted: http://lists.puredata.info/pipermail/pd-dev/2005-09/004847.html It seems like he never provided a follow up answer to Tim's question of how that they should be implemented, which is sad. I for one would be really happy for Miller to provide a reply as to how tooltips can be worked into his vision of Pd so we can all get that wonderful feature.

But everyone should also stop making indirect rude complaints about it, and just write him an email on this list to ask him specifically and politely. Let me do that now;

Miller; you rejected the tooltips patch that many people want to see applied. What do we need to change to see that patch make it into Pd?

Hopefully your emails Vincent, which are much more balanced, positive, and less accusatory than many others on this list will help Miller to see that there is some call for more openness in the development of Pd, and help others see that there is a way of working that is not so negative, egotistical and demanding.

Best,

Chris.

------------------- chris@mccormick.cx http://mccormick.cx

On Wed, Sep 13, 2006 at 03:26:41AM -0400, Mathieu Bouchard wrote:

As a human being, Miller has the right to reject patches. That doesn't mean that as a human being I have the duty to enjoy it.

I genuinely believe that PureData is a fantastic piece of software in many ways (else I surely wouldn't have posted a thousand mails about PureData).

I don't think that I would be complaining so much if there wasn't people insisting that I ought to submit my diffs to someone who doesn't want them. Hopefully I'll stop getting caught into that trap every damn time: it just makes me want to restate disagreements that I've already stated enough times and in a less angry way. I still have to learn about this.

It's good to hear this viewpoint. I think in your situation where what you want Pd to be seems to be quite different from what Miller wants Pd to be, forking was and is the correct course of action. Software evolution in the 'marketplace' will define which version is more successful for which types of things.

Best,

Chris.

------------------- chris@mccormick.cx http://mccormick.cx