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

2006-09-17 Thread Chris McCormick 
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.

---
[EMAIL PROTECTED]
http://mccormick.cx

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

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

2006-09-13 Thread Mathieu Bouchard 

On Wed, 13 Sep 2006, David Plans Casal wrote:

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? ;-)


I'm opposing to the use of the word "Darwinism" in this context. I'm not 
making an argument in favour of a closed process, I'm making one against 
likening an open process to Darwinism, even "some kind of".


What you say seems to imply you believe that only Miller is intelligent? 
;-)


 _ _ __ ___ _  _ _ ...
| 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

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

2006-09-13 Thread David Plans Casal 


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




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

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

2006-09-13 Thread Mathieu Bouchard 

On Wed, 13 Sep 2006, Chris McCormick wrote:

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.


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.


 _ _ __ ___ _  _ _ ...
| 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

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

2006-09-12 Thread Chris McCormick 
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:

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.

---
[EMAIL PROTECTED]
http://mccormick.cx

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

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

2006-09-12 Thread Vincent Lordier 


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


++

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

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

2006-09-12 Thread Mathieu Bouchard 

On Wed, 13 Sep 2006, Vincent Lordier wrote:


Code quality standards try to define what is "good" code.


That's the problem: they ought to try to _discover_ what is "good" code.


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)


 _ _ __ ___ _  _ _ ...
| 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

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

2006-09-12 Thread Mathieu Bouchard 

On Wed, 13 Sep 2006, Vincent Lordier wrote:


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

True.


Actually, they should be calls to error() or to pd_error(). The latter 
should be used when there's an object associated with the error, so that 
the GUI may find that error. Warnings should just go through post() as it 
is now.


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


This doesn't work if there are several clients connected to the server, 
who want error messages in different languages.



- Safe fprintf can be used to avoid overflow.
Which overflow?

see snprintf


Ah. But there wasn't any sprintf in your example, and I don't remember 
seeing error messages generated by calling sprintf directly.



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



=> http://www.coding-guidelines.com/cbook/sent787.pdf


That's a big document. If you want to show this to me you better find a 
page number in particular.



=> http://www.aivosto.com/project/help/pm-understandability.html


This one assumes that its code metrics do more revealing than hiding. I 
don't believe one can assess the value of identifiers in a program without 
first reading the program. What's important about identifiers is not 
their length, it's how valuable they are.


 _ _ __ ___ _  _ _ ...
| 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

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

2006-09-12 Thread Kyle Klipowicz 

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 <[EMAIL PROTECTED]> 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#search=%22understandability%20readability%20quality%20C%22
=>
http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html
=>
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






--

http://theradioproject.com
http://perhapsidid.blogspot.com

(()()()(()))()()())(
(())(())()(((
))(__
_())(()))___
(((000)))oOO

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

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

2006-09-12 Thread Vincent Lordier 
Even considering the actual implementation instead of the simplifiedexample, I wouldn't consider that renaming p1 to priority_min is
really helping anyone, because they already know p1 is the minimumpriority by looking two lines above. All uses of p1 lie within 5 lines ofcode, 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 canmake 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 doneserver-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 itneeds to be, and it's certainly possible for names to be too explicit, andi don't mean the "parental advisory" sys_defaultfontshit, I mean saying
things that are too obvious because they're already in your face 15 timesin the same page and cause the code to go on for longer than you shouldhave 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#search=%22understandability%20readability%20quality%20C%22
=> http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html=> 
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

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

2006-09-12 Thread Mathieu Bouchard 

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___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev