Hi all,
I'm finally going to bite the bullet and try to check my Pd sources into the CVS site. I'm hoping to do this without causing too much damage to the existing CVS tree. Probably I'll just start a branch (named "msp-test" or something like that) and then, once I believe 0.38 is stable, copy it over to the "main" branch.
My sources are way broken right now, so I won't be doing this until at least sometime next week. So there's plenty of time for comments as to whether there's a better way to manage the tree...
cheers Miller
This is great news! I'll through in my two bits, but I think others will have something to say about it. I think that the MSP sources should be the MAIN branch, then we can reserve other branches for development projects, like IMPD. Otherwise, I think that we will have too many branches without much gain. Also, Guenter has been merging the MSP code into the MAIN branch already. Since Guenter has been the merge-master, I think he's the one to ask about how it should be done going forward.
If you want, I can also set up access lists to restrict write access to the MAIN branch, at least until the transition to the CVS is complete. But it might not be necessary since all changes are logged and reversible.
.hc
On Jul 29, 2004, at 10:32 PM, Miller Puckette wrote:
Hi all,
I'm finally going to bite the bullet and try to check my Pd sources into the CVS site. I'm hoping to do this without causing too much damage to the existing CVS tree. Probably I'll just start a branch (named "msp-test" or something like that) and then, once I believe 0.38 is stable, copy it over to the "main" branch.
My sources are way broken right now, so I won't be doing this until at least sometime next week. So there's plenty of time for comments as to whether there's a better way to manage the tree...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"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
I wrote Guenter privately first, since I trust his opinion most of all! I think he's leaving soon (if he hasn't already) for vacation though.
I think the "miller" branch is just a copy of the code I maintain (and merge stuff into myself when appropriate.) I think Guenter then merges this into Main branch... if this is so, then I think there would now need to be both "stable" and "unstable" miller branches, that would be 0.37 (with my bug fixes; cuttently 0.37.2) and 0.38test. Then when 0.38 is ready I'd check it into "stable" and start putting 0.39 versions in "unstable". But this might be a gross misunderstanding of how to use CVS effectively.
I only adopt other people's code when I think I can maintain it... so for instance I don't have the 64 bit extensions yet because I don't have a 64-bit machine to test them on. So there will always be a need for something like the current "main" branch. I do sometimes try to merge changes from "main" back into my own branch -- but not all of them.
Another situation comes up often, that someone makes a feature that is clearly needed, but which I think should be implemented differently. An example is the "print" hook in devel... I like it, but I want to do it in a way that I think is cleaner...
It would be nice if there were an easy way to document the intent of the many branches that show up in CVS. I think most of them are dormant, but would presumably have to check them out and look at them all to know that...
cheers Miller
On Fri, Jul 30, 2004 at 12:40:16AM -0700, Hans-Christoph Steiner wrote:
This is great news! I'll through in my two bits, but I think others will have something to say about it. I think that the MSP sources should be the MAIN branch, then we can reserve other branches for development projects, like IMPD. Otherwise, I think that we will have too many branches without much gain. Also, Guenter has been merging the MSP code into the MAIN branch already. Since Guenter has been the merge-master, I think he's the one to ask about how it should be done going forward.
If you want, I can also set up access lists to restrict write access to the MAIN branch, at least until the transition to the CVS is complete. But it might not be necessary since all changes are logged and reversible.
.hc
On Jul 29, 2004, at 10:32 PM, Miller Puckette wrote:
Hi all,
I'm finally going to bite the bullet and try to check my Pd sources into the CVS site. I'm hoping to do this without causing too much damage to the existing CVS tree. Probably I'll just start a branch (named "msp-test" or something like that) and then, once I believe 0.38 is stable, copy it over to the "main" branch.
My sources are way broken right now, so I won't be doing this until at least sometime next week. So there's plenty of time for comments as to whether there's a better way to manage the tree...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
"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
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I think the "miller" branch is just a copy of the code I maintain (and merge stuff into myself when appropriate.) I think Guenter then merges this into Main branch... if this is so, then I think there would now need to be both "stable" and "unstable" miller branches, that would be 0.37 (with my bug fixes; cuttently 0.37.2) and 0.38test. Then when 0.38 is ready I'd check it into "stable" and start putting 0.39 versions in "unstable". But this might be a gross misunderstanding of how to use CVS effectively.
I don't understand CVS myself, but another (common) approach would be, that releases are Tags inside the CVS repository. So effectivly MAIN always is considered to be *unstable*, but at a certain point in time, MAIN would be "tagged" as "0.38", and then it could move on.
If someone wants to download Pd version 0.38 (s)he would check out the tagged release from CVS. Bugs in tag 0.38 could still be fixed and then a new tag like 0.38.1 would be done.
I agree with Hans, that MAIN should be the one and only official version of Pd and the one that is packaged for distribution(s). But still MAIN should be considered an unstable branch unless it carries a stable tag. Another implication of this is: Other modules (externals, flext, etc.) should depend on MAIN. They should be tagged in parallel with MAIN. "devel" externals must be tagged in parallel with the "devel" branch.
This would still allow branches like "impd", "devel" and "miller", if those are needed. I think they will be needed, because:
"impd" is quite different from the others (correct my if this is wrong). IMO we should make the impd branch go away sooner or later and let it grow into "devel".
"devel" is more like a playground, where experimental changes and then even changes to the "language" could finally be implemented and tested, provided they are well documented somewhere. Well-tested features from "devel" can also go into MAIN, after some discussion brought consensus.
"miller" should be Miller's playground and ideally the one which flows into MAIN first. Only Miller would need write access to "miller". There would be no need for "miller-devel" and "miller-stable" normally, as "stable" i.e. tested and considered good, features in "miller" would be applied to "MAIN" as well.
So "miller" basically would almost be MAIN, except that some features like the 64bit support could be added here as well, if Miller doesn't want to support these himself, and in that "miller" it taboo for others.
(Oh, and I still sometimes dream of Subversion at IEM. ;)
Ciao
On Fri, 30 Jul 2004, Miller Puckette wrote:
Another situation comes up often, that someone makes a feature that is clearly needed, but which I think should be implemented differently. An example is the "print" hook in devel... I like it, but I want to do it in a way that I think is cleaner...
Would you please care to explain what's wrong with the print hook and how you do intend to fix it?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Well, the hook I found in devel includes stdargs.h right into m_pd.h, which I think is a serious portability problem (cellphones migth not implement stdargs :) -- and anyway, it seems like the hook should go _after_ the formatting step, not before it. In my copy right now (too unstable to check into anything!) I've got a new low-level function:
t_printhook sys_printhook; int sys_printtostderr;
static void dopost(const char *s) { if (sys_printhook) (*sys_printhook)(s); else if (sys_printtostderr) fprintf(stderr, "%s", s); else { (messy code to send it to the GUI layer) } }
... which lets the user choose whether to spit it to the GUI layer, to standard error, or to any function you put in "sys_printhook".
I'll release all this once I can decide what I think is the most portable way to get the GUI to start Pd up (which seems to be necessary if you don't want a "console" window popping up on MSW or Mac). Yuck...
Miller
On Sat, Jul 31, 2004 at 07:36:14PM -0400, Mathieu Bouchard wrote:
On Fri, 30 Jul 2004, Miller Puckette wrote:
Another situation comes up often, that someone makes a feature that is clearly needed, but which I think should be implemented differently. An example is the "print" hook in devel... I like it, but I want to do it in a way that I think is cleaner...
Would you please care to explain what's wrong with the print hook and how you do intend to fix it?
Mathieu Bouchard http://artengine.ca/matju
On Sat, 31 Jul 2004, Miller Puckette wrote:
Well, the hook I found in devel includes stdargs.h right into m_pd.h, which I think is a serious portability problem (cellphones migth not implement stdargs :)
Implementing <stdio.h> requires using <stdarg.h>, so either cellphones implement <stdarg.h> or nothing runs on it.
Other possibilities are that they'd only implement <varargs.h> instead (obsolete) or that they have printf() implemented in assembler (obsolete too). Those are more likely to happen when porting to vintage hardware using old-fashioned compilers not updated since 1989 or so. It's not the case for cellphones or even a recent GameBoy-type system.
In short, I don't think it's a valid rationale.
-- and anyway, it seems like the hook should go _after_ the formatting step, not before it. In my copy right now (too unstable to check into anything!) I've got a new low-level function:
Ok, that's another way to do it. Actually I don't really care how it's done as long as it's sent to the GUI console correctly and that buffer overflows are handled properly.
if (sys_printhook) (*sys_printhook)(s); else if (sys_printtostderr) fprintf(stderr, "%s", s); else { (messy code to send it to the GUI layer) }
Actually drop the "messy", and the last "else{}" block altogether. I'm using a printhook to send to the gui layer. What is the point for the gui console _not_ to use the printhook? who will use the printhook then?
I'll release all this once I can decide what I think is the most portable way to get the GUI to start Pd up (which seems to be necessary if you don't want a "console" window popping up on MSW or Mac). Yuck...
Why yuck? I think it's a feature Pd should have.
On a related note, I also think that commandline options should be replaced by ";pd"-type messages.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Actually drop the "messy", and the last "else{}" block altogether. I'm using a printhook to send to the gui layer. What is the point for the gui console _not_ to use the printhook? who will use the printhook then?
I think you're right about that. I'll go think about it...
I'll release all this once I can decide what I think is the most portable way to get the GUI to start Pd up (which seems to be necessary if you don't want a "console" window popping up on MSW or Mac). Yuck...
Why yuck? I think it's a feature Pd should have.
Yuck because I can't figure out how to get Wish, when I click on it in Windows, to just run my script and not make a Wish console... also, whatever program one identifies as Pd, it would be desirable to be able to drag a patch to it (or double-click the patch to start it) -- and I don't see how to get Wish to do that for me unless I recompile the whole thing with a very special startup behavior. This means actually sitting at a Windows machine for hours, which I don't find very fun.
On a related note, I also think that commandline options should be replaced by ";pd"-type messages.
Neat idea... ";pd args <blah blah>". This will mean being able, dynamically, to change any features controlled by arguments. Possibly a lot of rewriting. Meanwhile I spent most of last week trying to get a way to save and restore settings OS-independently.
cheers Miller
Mathieu Bouchard http://artengine.ca/matju
I'll release all this once I can decide what I think is the most portable way to get the GUI to start Pd up (which seems to be necessary if you don't want a "console" window popping up on MSW or
hi, to hide the DOS console on MSWindows, add -mwindows to the pd.exe linker flags in the (GNU) makefile. the current caveat to using mingw is the ASIO support is broken, at least until upgrading to either portaudio19, or adding the IASIOThiscallResolver.h ( http://www.audiomulch.com/~rossb/code/calliasio/ ) to portaudio sources..
Yuck because I can't figure out how to get Wish, when I click on it in Windows, to just run my script and not make a Wish console... also, whatever program one identifies as Pd, it would be desirable to be able to drag a patch to it (or double-click the patch to start it) -- and I don't see how to get
-r impd_0_37 has a feature which implements drag and drop by allowing a patch to be dropped on the parent window containing the peak meters, menu, etc...opening it in the current instance. usually the program is proably launched froma start menu shortcut or .bat or something, so the program icon is praobly not around to be dropped upon (sounds awfully system 7...)
it seems the command "console hide" will hide the wish console...
On Fri, 30 Jul 2004, Miller Puckette wrote:
I think the "miller" branch is just a copy of the code I maintain (and merge stuff into myself when appropriate.) I think Guenter then merges this into Main branch...
Yes, that was the idea. I just wanted to merge the differences between the different "miller" releases back into main. At the end I did not stick to that, so that the miller branch got terribly outdated.
I do agree with hc and Frank that you should stick to the MAIN branch. This means that the MAIN branch is not stable all the time, but you can tag it and make a tarball release when we think it is stable (or for testing purposes or whatever).
The average use won't download from the CVS, but the tarball releases.
The other branches would be devel (a playground for new features). I think this should be the branch were people can make suggestions and at the same time implement them for testing. Of course, you would have to decide at the end which of these additions you want to have in the main branch. In order to make this easy, the developers should prepare patches against the MAIN branch with a description. This way it is easy for you to look at the changes and apply them without too much hassle.
Bug fixes should be sent as patches against MAIN too.
Well, thats my idea about how to organize collaboration. I think that write access against MAIN should be restricted (hc, you are specialist there).
So, to resume, we have:
* MAIN (with release tags and restricted write access) * devel_XX (as it was now, branched away from MAIN after a release) * impd, etc, etc ..(other branches, maintained by single persons/groups, who go an even more adventurous way)
In my experience branching too much should be avoided. Merging is not only difficult but it is easy to really break things.
Guenter
if this is so, then I think there would now need to be both "stable" and "unstable" miller branches, that would be 0.37 (with my bug fixes; cuttently 0.37.2) and 0.38test. Then when 0.38 is ready I'd check it into "stable" and start putting 0.39 versions in "unstable". But this might be a gross misunderstanding of how to use CVS effectively.
I only adopt other people's code when I think I can maintain it... so for instance I don't have the 64 bit extensions yet because I don't have a 64-bit machine to test them on. So there will always be a need for something like the current "main" branch. I do sometimes try to merge changes from "main" back into my own branch -- but not all of them.
Another situation comes up often, that someone makes a feature that is clearly needed, but which I think should be implemented differently. An example is the "print" hook in devel... I like it, but I want to do it in a way that I think is cleaner...
It would be nice if there were an easy way to document the intent of the many branches that show up in CVS. I think most of them are dormant, but would presumably have to check them out and look at them all to know that...
cheers Miller
On Fri, Jul 30, 2004 at 12:40:16AM -0700, Hans-Christoph Steiner wrote:
This is great news! I'll through in my two bits, but I think others will have something to say about it. I think that the MSP sources should be the MAIN branch, then we can reserve other branches for development projects, like IMPD. Otherwise, I think that we will have too many branches without much gain. Also, Guenter has been merging the MSP code into the MAIN branch already. Since Guenter has been the merge-master, I think he's the one to ask about how it should be done going forward.
If you want, I can also set up access lists to restrict write access to the MAIN branch, at least until the transition to the CVS is complete. But it might not be necessary since all changes are logged and reversible.
.hc
On Jul 29, 2004, at 10:32 PM, Miller Puckette wrote:
Hi all,
I'm finally going to bite the bullet and try to check my Pd sources into the CVS site. I'm hoping to do this without causing too much damage to the existing CVS tree. Probably I'll just start a branch (named "msp-test" or something like that) and then, once I believe 0.38 is stable, copy it over to the "main" branch.
My sources are way broken right now, so I won't be doing this until at least sometime next week. So there's plenty of time for comments as to whether there's a better way to manage the tree...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
"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
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
So, to resume, we have:
- MAIN (with release tags and restricted write access)
- devel_XX (as it was now, branched away from MAIN after a release)
- impd, etc, etc ..(other branches, maintained by single
persons/groups, who go an even more adventurous way)
In my experience branching too much should be avoided. Merging is not only difficult but it is easy to really break things.
this sounds good, although i'd propose an additional branch for features considered to be stable, but not in the msp tree ... maybe this is something that goes into the third category ... but some of these features are important ... e.g. i can't run my performance patch without the threaded gui ...
cheers... tim
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
ix -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann