btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc.
This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
i've fixed most of them already. (except in g_*.c)
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc.
This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
well, i once started to work on this, but stopped, after realizing that it makes merging the code _much_ more difficult ...
please think about this, before checking it the core ...
cheers ... tim
On Sun, 27 Nov 2005, Tim Blechmann wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc. This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
well, i once started to work on this, but stopped, after realizing that it makes merging the code _much_ more difficult ... please think about this, before checking it the core ...
Too late, I've checked it into devel_0_39 several hours ago.
Here's a bit of the chat with Tim on #dataflow:
<matju> tim: however i think that it shouldn't be you doing all the work <matju> tim: "if i would have worked on a day job during the time i read diffs, merged files or rewrote things, i could easily afford a fancy powerbook and a few licenses of max/msp" -- Tim Blechmann
<matju> tim: i propose organising a special dev meeting everytime there is a merge to do. then we can discuss what to merge and what not to merge and how it should be done, and by looking at the merge process we'll have a better overview of the directions both pd's are taking, *and* we will be able to share the work of merging so that you don't have to do all of it yourself
<tim> matju: a merging dev meeting would definitely be of some help ... the best would be to have maintainers for the different parts of pd ... d_ m_ g_ x_ s_ ... but there are too little people, who are familiar with the pd source code and who would be willing to work on devel
<matju> tim: i could volunteer for m_* and/or x_*; i'm certainly going to leave d_* to you; and g_* is out of my scope now; ... i could do s_* except the #ifdef-ridden crossplatform parts.
<matju> tim: whenever you think it's best to do a merge, just organise a meeting here, or ask me to organise one
<matju> tim: actually i'll finish handling the warnings and will deal with the consequences when they come
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Am 27.11.2005 um 19:51 schrieb Mathieu Bouchard:
On Sun, 27 Nov 2005, Tim Blechmann wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc. This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
well, i once started to work on this, but stopped, after realizing that it makes merging the code _much_ more difficult ... please think about this, before checking it the core ...
Too late, I've checked it into devel_0_39 several hours ago.
Hey all, what i like(d) about the pd-devel branch is that it is/has been still possible to keep up with Miller's improvements to the main branch, without sacrifying too much time with merging. I don't think we should endanger that opportunity by changing the code in a more or less cosmetic fashion. Ok, memory leaks have been found, that's great, how about a general patch --reverse now? I was always sceptical about large-area changes to the code base and am pleased that DesireData has its own sandbox within desire.c and some tcl scripts. As already proposed, since pd-devel is a collaborative project, i would strongly encourage that larger changes to the code are discussed before and have to be supported by some majority of people working on the branch.
best greetings, Thomas
Hi devels, while i had to spend some time today fixing things in Mathu's "fixes" i wondered why someone would really need these changes. They have no impact on performance, but rather introduce new bugs as they are obviously untested. Hence, i took the risk and reverted them in the devel cvs, before it's too late and other changes have been superimposed. Nevertheless i posted the changes to the patch tracker so they are saved and can still eventually be considered by the community after some discussion.
I also added the actual patches to the tracker items of the two bugs that Matju found (Matju, you have to check the "upload" box to really upload your patches!!) and re-applied them in devel_0_39
all the best, Thomas
Thomas Grill schrieb:
Am 27.11.2005 um 19:51 schrieb Mathieu Bouchard:
On Sun, 27 Nov 2005, Tim Blechmann wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc. This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
well, i once started to work on this, but stopped, after realizing that it makes merging the code _much_ more difficult ... please think about this, before checking it the core ...
Too late, I've checked it into devel_0_39 several hours ago.
Hey all, what i like(d) about the pd-devel branch is that it is/has been still possible to keep up with Miller's improvements to the main branch, without sacrifying too much time with merging. I don't think we should endanger that opportunity by changing the code in a more or less cosmetic fashion. Ok, memory leaks have been found, that's great, how about a general patch --reverse now? I was always sceptical about large-area changes to the code base and am pleased that DesireData has its own sandbox within desire.c and some tcl scripts. As already proposed, since pd-devel is a collaborative project, i would strongly encourage that larger changes to the code are discussed before and have to be supported by some majority of people working on the branch.
best greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, 30 Nov 2005, Thomas Grill wrote:
Matju, you have to check the "upload" box to really upload your patches!!) and re-applied them in devel_0_39
Do you mean that when I do upload my .diff files, Sourceforget throws them into the bit recycling bin just because I didn't check the little box even though the file *has* been uploaded?
Wow.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Am 30.11.2005 um 21:05 schrieb Mathieu Bouchard:
On Wed, 30 Nov 2005, Thomas Grill wrote:
Matju, you have to check the "upload" box to really upload your patches!!) and re-applied them in devel_0_39
Do you mean that when I do upload my .diff files, Sourceforget throws them into the bit recycling bin just because I didn't check the little box even though the file *has* been uploaded?
yes, seems so....
T
On Tue, 29 Nov 2005, Thomas Grill wrote:
I was always sceptical about large-area changes to the code base and am pleased that DesireData has its own sandbox within desire.c and some tcl scripts.
It hasn't. I mean, some things are outside of desire.*, especially because they can't be implemented in there.
i would strongly encourage that larger changes to the code are discussed before and have to be supported by some majority of people working on the branch.
If there is a majority then there has to be a population. If there's a population then there has to be a list of the electorate. So, who's allowed to vote and who's not?
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 1, 2005, at 6:17 PM, Mathieu Bouchard wrote:
On Tue, 29 Nov 2005, Thomas Grill wrote:
I was always sceptical about large-area changes to the code base and am pleased that DesireData has its own sandbox within desire.c and some tcl scripts.
It hasn't. I mean, some things are outside of desire.*, especially because they can't be implemented in there.
i would strongly encourage that larger changes to the code are discussed before and have to be supported by some majority of people working on the branch.
If there is a majority then there has to be a population. If there's a population then there has to be a list of the electorate. So, who's allowed to vote and who's not?
Yes, we do need to define a collective decision process. But for such things, just a consensus of the pd-dev list has worked pretty well, i.e. post your suggested changes, and wait for some responses.
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
On Thu, 1 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 1, 2005, at 6:17 PM, Mathieu Bouchard wrote:
If there is a majority then there has to be a population. If there's a population then there has to be a list of the electorate. So, who's allowed to vote and who's not?
Yes, we do need to define a collective decision process. But for such things, just a consensus of the pd-dev list has worked pretty well, i.e. post your suggested changes, and wait for some responses.
What if there is no response?
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On 2 Dec 2005, at 09:32, Mathieu Bouchard wrote:
On Thu, 1 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 1, 2005, at 6:17 PM, Mathieu Bouchard wrote:
If there is a majority then there has to be a population. If there's a population then there has to be a list of the electorate. So, who's allowed to vote and who's not?
Yes, we do need to define a collective decision process. But for such things, just a consensus of the pd-dev list has worked pretty well, i.e. post your suggested changes, and wait for some responses.
What if there is no response?
In the ASF, that's called 'lazy consensus'. You propose, wait for responses, and it in the absence of any, it is understood that you should just go ahead an JFDI.
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Dec 2, 2005, at 4:46 AM, David Plans Casal wrote:
On 2 Dec 2005, at 09:32, Mathieu Bouchard wrote:
On Thu, 1 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 1, 2005, at 6:17 PM, Mathieu Bouchard wrote:
If there is a majority then there has to be a population. If there's a population then there has to be a list of the electorate. So, who's allowed to vote and who's not?
Yes, we do need to define a collective decision process. But for such things, just a consensus of the pd-dev list has worked pretty well, i.e. post your suggested changes, and wait for some responses.
What if there is no response?
In the ASF, that's called 'lazy consensus'. You propose, wait for responses, and it in the absence of any, it is understood that you should just go ahead an JFDI.
Yeah, as long as you give it a few days. We can't all always be reading the list everyday.
.hc
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
On Fri, 2 Dec 2005 04:32:22 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 1 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 1, 2005, at 6:17 PM, Mathieu Bouchard wrote:
If there is a majority then there has to be a population. If there's a population then there has to be a list of the electorate. So, who's allowed to vote and who's not?
Yes, we do need to define a collective decision process. But for such things, just a consensus of the pd-dev list has worked pretty well, i.e. post your suggested changes, and wait for some responses.
What if there is no response?
what if someone objects?
t
On Sun, 27 Nov 2005, Mathieu Bouchard wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc. This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand. i've fixed most of them already. (except in g_*.c)
I've fixed most of the rest.
While doing that I also fixed a memory leak in [poly] and one in [bonk~].
(I found both *because* I was fixing the warnings)
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 27, 2005, at 6:27 PM, Mathieu Bouchard wrote:
On Sun, 27 Nov 2005, Mathieu Bouchard wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc. This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand. i've fixed most of them already. (except in g_*.c)
I've fixed most of the rest.
While doing that I also fixed a memory leak in [poly] and one in [bonk~].
(I found both *because* I was fixing the warnings)
Could you submit patches for these to the patch tracker on SourceForge? That would ensure that they got into the main Pd source.
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin
On Sun, 27 Nov 2005, Hans-Christoph Steiner wrote:
On Nov 27, 2005, at 6:27 PM, Mathieu Bouchard wrote:
On Sun, 27 Nov 2005, Mathieu Bouchard wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons
I've fixed most of the rest. While doing that I also fixed a memory leak in [poly] and one in [bonk~].
Could you submit patches for these
All of those things, or just the memory leaks?
How should I submit those? Would those be copy+paste from the pd-cvs mailing-list, or should they be something else?
If not pd-cvs, then what should I diff against? PureMSP 0.39 ?
That would ensure that they got into the main Pd source.
Well, no, it doesn't *ensure* that. No need to pretend it would.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 27, 2005, at 7:33 PM, Mathieu Bouchard wrote:
On Sun, 27 Nov 2005, Hans-Christoph Steiner wrote:
On Nov 27, 2005, at 6:27 PM, Mathieu Bouchard wrote:
On Sun, 27 Nov 2005, Mathieu Bouchard wrote:
btw i'm making efforts to "fix" warnings that i get with using "scons
I've fixed most of the rest. While doing that I also fixed a memory leak in [poly] and one in [bonk~].
Could you submit patches for these
All of those things, or just the memory leaks?
Well, anything you are willing to turn into a diff patch, really. The memory leaks sound the most pressing.
How should I submit those? Would those be copy+paste from the pd-cvs mailing-list, or should they be something else?
"cvs diff -uw" works well for me. diff -u allows the patch to fudge a bit with the line numbers.
If not pd-cvs, then what should I diff against? PureMSP 0.39 ?
The HEAD of pd MAIN in CVS.
That would ensure that they got into the main Pd source.
Well, no, it doesn't *ensure* that. No need to pretend it would.
Its a step in the right direction.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
On Sun, 27 Nov 2005, Hans-Christoph Steiner wrote:
All of those things, or just the memory leaks?
Well, anything you are willing to turn into a diff patch, really. The memory leaks sound the most pressing.
I uploaded both memory leak fixes, a few unused var fixes, a few C++ fixes.
"cvs diff -uw" works well for me. diff -u allows the patch to fudge a bit with the line numbers.
I think -u is the most human-readable output format too. I've used it for 6 years now.
If not pd-cvs, then what should I diff against? PureMSP 0.39 ?
The HEAD of pd MAIN in CVS.
I would have submitted several times as many diffs as I did, but unfortunately diffing with -rMAIN extracts a damn lot of changes that I didn't do and that I suspect have already been submitted a long time ago.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
hi devs ...
matju and me disagree on one the following problem:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc.
This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
i've fixed most of them already. (except in g_*.c)
in my opinion, we shouldn't fix these warnings, because it make merging much more difficult. it would make the code slightly more readable, but merging will be _much_ more difficult. (in this case, i'd stop merging stuff)
i think, this is one of the first instances, where the pd developer community should try to find a _common_ decision and thus would propose an election.
best ... tim
On Nov 27, 2005, at 8:08 PM, Tim Blechmann wrote:
hi devs ...
matju and me disagree on one the following problem:
btw i'm making efforts to "fix" warnings that i get with using "scons wall=1", which turns on "-Wall" in gcc.
This is so that new warnings are more easily noticed, and because unused variables make the code more difficult to understand.
i've fixed most of them already. (except in g_*.c)
in my opinion, we shouldn't fix these warnings, because it make merging much more difficult. it would make the code slightly more readable, but merging will be _much_ more difficult. (in this case, i'd stop merging stuff)
i think, this is one of the first instances, where the pd developer community should try to find a _common_ decision and thus would propose an election.
I agree, something like this that will cause a lot of menial work needs to be discussed. How about submitting a patch to Miller? If Miller accepted this patch, would that also create a lot of work?
.hc
best ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
-
David Plans Casal -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann