hi all ...
1. any objections if i add a new package to the sourceforge file section called pd-devel (or maybe rename the pd-extended package)?
2. any objections if i release a pd-0.38-4-devel-1 tarball?
thanks ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
- any objections if i add a new package to the sourceforge file section
called pd-devel (or maybe rename the pd-extended package)?
- any objections if i release a pd-0.38-4-devel-1 tarball?
No objections in general, however it occured to me, that some distributions (rpm-based) use the "-devel" suffix to name packages containing development files like headers etc. So this might not be the optimal name, which may lead to the other question: should "devel" be renamed...
Ciao
On Fri, 6 May 2005, Tim Blechmann wrote:
- any objections if i add a new package to the sourceforge file section
called pd-devel (or maybe rename the pd-extended package)?
You're welcome, but don't call it pd-devel, nor pd-dev, because both suffixes are used in several linux distros to indicate the package holding both the *.h and *.a files that are related to the other package that doesn't have the suffix; so, in those distros, the "pd-devel" package would contain the m_pd.h corresponding to the package called just "pd".
- any objections if i release a pd-0.38-4-devel-1 tarball?
No objections, and just do it with that kind of name until a better name is found. A more inviting name is welcome.
More opinions:
I think that we don't need to rename the "devel_0_38" branch right away; it's not the right moment yet. But it should be done some day, and the new branch shouldn't have a version number in it. If needed, we will make subbranches of it for particular stable releases of our work.
I also think that, to promote evolution of the PureData source code base, when Miller's 0.39 gets published, diffs between Miller's 0.38 and 0.39 should be merged to devel_0_38, and not the other way around. This is especially important if there is more work being done on the non-Miller side than on the Miller side.
What do you think of this?
,-o---------o---------o---------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'
Hi all,
More opinions:
I think that we don't need to rename the "devel_0_38" branch right away; it's not the right moment yet. But it should be done some day, and the new branch shouldn't have a version number in it. If needed, we will make subbranches of it for particular stable releases of our work.
Since have been using the devel branch regularly for nearly 2 years now i have the impression that it's more usable and more stable than the official pd. In my opinion Miller's vanilla PD is more like a development version in the way that it introduces more fundamental changes to the structure, while the devel branch normally just adds convience features. I don't know what i have missed in the devel meeting but up to now there was no indication that important features like SIMD code, low latency callbacks and array update time will make it into Miller's PD soon. Therefore i think it's important to have tarballs and binary packages of the devel branch and i'm thankful to Tim to spend some time on it. I see no real importance of having another name, but if it helps spreading the word, why not. How about "pure devil"?
I also think that, to promote evolution of the PureData source code base, when Miller's 0.39 gets published, diffs between Miller's 0.38 and 0.39 should be merged to devel_0_38, and not the other way around. This is especially important if there is more work being done on the non-Miller side than on the Miller side.
To my knowledge this has always been the case, no? Or maybe i don't get what you want to say. You are right, that the devel branch version has already become obsolete due to the large amount of differences to the "stable" one.
all the best, Thomas
features. I don't know what i have missed in the devel meeting but up to now there was no indication that important features like SIMD code, low latency callbacks and array update time will make it into Miller's PD soon. Therefore i think it's important to have tarballs
this is a crucial point, since it also concerns external developers:
- external developers can't call pd's simd functions, nor the runtime dispatching functions - external developers can't place idle callbacks if they want to stay compatible with miller's branch
i think these two features should be made available to external developers as soon as possible ... on the other hand, the last thing i heard from miller about the simd stuff was, that he doesn't think, he can maintain this code and i'm not sure, if he ever wrote a comment on the idle callbacks ... so i'm not sure, if any of the devel features will ever make it into miller's pd ...
cheers ... tim
Hi all,
I'm sticking an idle callback in the upcoming 0.39... in fact I thought I'd already checked that in, but CVS is such a pain for me that I don't keep close track of when I've updated things...
cheers Miller
On Mon, May 09, 2005 at 12:45:10AM +0200, Tim Blechmann wrote:
features. I don't know what i have missed in the devel meeting but up to now there was no indication that important features like SIMD code, low latency callbacks and array update time will make it into Miller's PD soon. Therefore i think it's important to have tarballs
this is a crucial point, since it also concerns external developers:
- external developers can't call pd's simd functions, nor the runtime
dispatching functions
- external developers can't place idle callbacks
if they want to stay compatible with miller's branch
i think these two features should be made available to external developers as soon as possible ... on the other hand, the last thing i heard from miller about the simd stuff was, that he doesn't think, he can maintain this code and i'm not sure, if he ever wrote a comment on the idle callbacks ... so i'm not sure, if any of the devel features will ever make it into miller's pd ...
cheers ... 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
I'm sticking an idle callback in the upcoming 0.39... in fact I
please make sure, to use the latest version from devel including grame's lockfree fifos, since they include lock-free code for nearly all supported architectures ...
thought I'd already checked that in, but CVS is such a pain for me that I don't keep close track of when I've updated things...
hm ... i can't find it in m_sched.c revision 1.7 ...
cheers ... tim
Oh, so this must be something else from what I was talking about. I'll look at it next time I download 'devel' (I plan to do this once a 'release' to try to merge in stuff I can understand...)
cheers Miller
On Mon, May 09, 2005 at 01:50:03AM +0200, Tim Blechmann wrote:
I'm sticking an idle callback in the upcoming 0.39... in fact I
please make sure, to use the latest version from devel including grame's lockfree fifos, since they include lock-free code for nearly all supported architectures ...
thought I'd already checked that in, but CVS is such a pain for me that I don't keep close track of when I've updated things...
hm ... i can't find it in m_sched.c revision 1.7 ...
cheers ... 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
Miller Puckette wrote:
Oh, so this must be something else from what I was talking about. I'll look at it next time I download 'devel' (I plan to do this once a 'release' to try to merge in stuff I can understand...)
and just to ensure that these do not get forgotten: the patch-tracker at sourceforge http://sourceforge.net/tracker/?group_id=55736&atid=478072 holds loads of patches against your stable version of pd which are mostly committed into the devel-branch too.
so those patches should be easier to understand (as each of them is targeted at a single problem)
i try to close "open"-patches whenever i notice that they have made it into the the stable release, but of course this is kind of double work (and i might well miss the one or the other)
so if you mind looking through those once and again _and_ find some of them useful _and_ import them to your stable release (or something that accomplishes the same thing), i (and probably other people too who use the tracker) would be very thankful if you could "close" the patches (or tag them with something more appropriate like "wontfix")
mfg.uit.ggh IOhannes
Yep, I should do this first...
M
On Mon, May 09, 2005 at 05:52:09PM +0200, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
Oh, so this must be something else from what I was talking about. I'll look at it next time I download 'devel' (I plan to do this once a 'release' to try to merge in stuff I can understand...)
and just to ensure that these do not get forgotten: the patch-tracker at sourceforge http://sourceforge.net/tracker/?group_id=55736&atid=478072 holds loads of patches against your stable version of pd which are mostly committed into the devel-branch too.
so those patches should be easier to understand (as each of them is targeted at a single problem)
i try to close "open"-patches whenever i notice that they have made it into the the stable release, but of course this is kind of double work (and i might well miss the one or the other)
so if you mind looking through those once and again _and_ find some of them useful _and_ import them to your stable release (or something that accomplishes the same thing), i (and probably other people too who use the tracker) would be very thankful if you could "close" the patches (or tag them with something more appropriate like "wontfix")
mfg.uit.ggh IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sun, 8 May 2005, Thomas Grill wrote:
In my opinion Miller's vanilla PD is more like a development version in the way that it introduces more fundamental changes to the structure, while the devel branch normally just adds convience features.
This is going to change. The devel branch will introduce more fundamental changes to the structure. The reason why no-one has really been daring to is because it's too much trouble to repatch every devel version of PureData this way:
miller-0.37 ---fork---> devel-0.37 | / | | / | | / merge evolve .--obliviate--' if you | / care | / | v v v miller-0.38 ---fork---> devel-0.38
That is, currently, a new devel version is the last released miller version plus part of the diff between devel 0.37 and miller 0.37. The diagonal arrow is for the most part a non-arrow; to be fair, it's a "merge" arrow but with a small percentage, whereas devel 0.38 has all the new features of miller 0.38. Basically the same thing happened between 0.36 and 0.37 (but I wasn't really in the team yet, so correct me if I'm wrong).
What I would see for the future is this:
miller-0.38 ----fork-----> community (formerly devel-0.38) | / | | / |----fork---> community stable R1 | whatever / | evolve .-- miller ---' evolve | / wants to do | | / |----fork---> community stable R2 v v merge v miller-0.39 --- if you ---> community | care | etc etc
Note that there are no version numbers for devel anymore. Here I renamed it to "community". This system supports major changes in the community branch, and no-longer supports the primacy of the miller branch. The community branch would have its own stable releases independent from the miller branch; they would be numbered differently so that there would be no confusion _and_ that the miller-0.xx.0 releases *don't* drive version changes of the releases of the community branch.
but up to now there was no indication that important features like SIMD code, low latency callbacks and array update time will make it into Miller's PD soon.
There is still no such indication for SIMD, and it will get worse when ImpureData enters the picture, which is Real Soon Now (tm).
I also think that, to promote evolution of the PureData source code base, when Miller's 0.39 gets published, diffs between Miller's 0.38 and 0.39 should be merged to devel_0_38, and not the other way around. This is especially important if there is more work being done on the non-Miller side than on the Miller side.
To my knowledge this has always been the case, no?
Does the long explanation above answer your question?
,-o---------o---------o---------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'
Renaming to community sounds good. But if you are going to fork (i.e. make structural changes, IMPd, etc.) then it seems that we should have a distinct fork branch, and a devel branch. devel would be for adding changes to miller's version and the community/fork branch would be separate.
Or it'd probably make the most sense to keep devel as a branch, then make the "community" fork its own directory. If the idea is to make major, incompatible changes then keeping it a branch doesn't seem to make a lot of sense to me.
.hc
On May 10, 2005, at 10:05 PM, Mathieu Bouchard wrote:
On Sun, 8 May 2005, Thomas Grill wrote:
In my opinion Miller's vanilla PD is more like a development version in the way that it introduces more fundamental changes to the structure, while the devel branch normally just adds convience features.
This is going to change. The devel branch will introduce more fundamental changes to the structure. The reason why no-one has really been daring to is because it's too much trouble to repatch every devel version of PureData this way:
miller-0.37 ---fork---> devel-0.37 | / | | / | | / merge evolve .--obliviate--' if you | / care | / | v v v miller-0.38 ---fork---> devel-0.38
That is, currently, a new devel version is the last released miller version plus part of the diff between devel 0.37 and miller 0.37. The diagonal arrow is for the most part a non-arrow; to be fair, it's a "merge" arrow but with a small percentage, whereas devel 0.38 has all the new features of miller 0.38. Basically the same thing happened between 0.36 and 0.37 (but I wasn't really in the team yet, so correct me if I'm wrong).
What I would see for the future is this:
miller-0.38 ----fork-----> community (formerly devel-0.38) | / | | / |----fork---> community stable R1 | whatever / | evolve .-- miller ---' evolve | / wants to do | | / |----fork---> community stable R2 v v merge v miller-0.39 --- if you ---> community | care | etc etc
Note that there are no version numbers for devel anymore. Here I renamed it to "community". This system supports major changes in the community branch, and no-longer supports the primacy of the miller branch. The community branch would have its own stable releases independent from the miller branch; they would be numbered differently so that there would be no confusion _and_ that the miller-0.xx.0 releases *don't* drive version changes of the releases of the community branch.
but up to now there was no indication that important features like SIMD code, low latency callbacks and array update time will make it into Miller's PD soon.
There is still no such indication for SIMD, and it will get worse when ImpureData enters the picture, which is Real Soon Now (tm).
I also think that, to promote evolution of the PureData source code base, when Miller's 0.39 gets published, diffs between Miller's 0.38 and 0.39 should be merged to devel_0_38, and not the other way around. This is especially important if there is more work being done on the non-Miller side than on the Miller side.
To my knowledge this has always been the case, no?
Does the long explanation above answer your question?
,-o---------o---------o---------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'_______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Renaming to community sounds good. But if you are going to fork (i.e. make structural changes, IMPd, etc.) then it seems that we should have a distinct fork branch, and a devel branch. devel would be for adding changes to miller's version and the community/fork branch would be separate.
well, i disagree with you ... the changes that have been made to devel reached a point, where they can't easily be merged with miller's version any more ... of course, someone could branch of a devel2_0_39 that's based on stable_0_39 ... but i think this is not worth the effort. having more than one major branches _is_ a bad idea (but it's the current situation) ... having more two is insane. so the one branching from stable_ should consider discussing with the PD community / Pure Devil developers about the changes he proposes...
Or it'd probably make the most sense to keep devel as a branch, then make the "community" fork its own directory. If the idea is to make major, incompatible changes then keeping it a branch doesn't seem to make a lot of sense to me.
well a few changes will have to be made. some may even break the binary compatibility with miller's branch ... still, i think it would be a very bad approach to get a too big distance between miller's pd and what's now devel ...
cheers ... tim
I also think that, to promote evolution of the PureData source code base, when Miller's 0.39 gets published, diffs between Miller's 0.38 and 0.39 should be merged to devel_0_38, and not the other way around. This is especially important if there is more work being done on the non-Miller side than on the Miller side.
well, i don't know, what miller is planning for 0.39, but i'm not willing to merge the devel_0_38 branches to 0.39 ... i did it once from 0.37 to 0.38 and it was a pain.
- there are too many changes in devel_0_38 at the moment ... and still increasing - some of the changes are too heavy to be easily merged, the simd stuff is all over the pd code ... dsp objects, dsp tree, audio i/o - it doesn't seem that miller is incorporating any of the devel_0_38 features to 0.39
merging miller's changes to devel won't be fun, either, since it will most likely break some features ... but it's not as bad as the other way around ...
cheers ... tim
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Thomas Grill -
Tim Blechmann