Sorry to be silent on this issue so far...

I'm trying to patch 0.40 and "MAIN" in parallel - however, I don't think I've checked MAIN in for a while so they might appeat out of sync.

I'm also intending to look over "devel" and incorporate some of its features into MAIN, but this is a large project that I haven't yet got started on.

cheers Miller

On Sat, Dec 02, 2006 at 04:29:51PM -0500, Hans-Christoph Steiner wrote:

Sounds like a very good plan.

One possible difficulty is that Miller has a stable_0_40 branch now in addition to MAIN, and some patches are included in stable_0_40 that are not in MAIN (yet?).

And an FYI: you could use the autobuild stuff as is, right now.

.hc

On Dec 2, 2006, at 8:42 AM, Thomas Grill wrote:

...

Hi all, since things have been cleared up now, and obviously i have been assigned the role of the "keeper of the devel", i'm thinking of how to proceed with the mentioned branch.

A few points i'm considering:

• I have no interest in maintaining a branch open for the public,

when i'm the only user of it. It would be much more comfortable to keep it at home, with all the freedom to make changes where i like, not having to keep an eye on compatibility

• I'd find it beneficial to integrate Miller's changes that

happened since the last merge

• It would be nice to be able to provide patches of the devel

improvements for Miller, without investing a lot of time into it

• I'd like to use the autobuild system
• We need many of the extra features in devel for the vibrez

project, hence we have to keep them

The following solution comes to my mind:

• Make a list of things that are special for devel_0_39 (also

asking other devel contributors).

• Branch off a devel branch (without version number) from Miller's

latest cvs

• Gradually integrate the listed devel features into the branch,

and also making patches for Miller

• Rethink some architectural details, like the SIMD infrastructure

(ability to inline functions and enable auto-vectorization)

I think this is less work than merging in Miller's version into devel and it also makes later incremental updates easier. Miller's version and the devel branch can progress side by side.

Any ideas, comments, lamento?

best greeting, Thomas

-- Thomas Grill http://grrrr.org

---

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

---

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

---

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

hi thomas,

Once i started the new devel branch, i'll try to provide patches of the various extra features, which would save you from brwosing through the codebase. I'm wondering if we can find a way to even include SIMD, since i'm going to reimplement it without using assembly but rather compiler instrinsics

i've implemented most of the vectorizable dsp functions with intrinsics for pnpd. it's written with c++ templates, but it should be easy to wrap these functions into a c api for pd. possibly faster to reuse this code than rewriting the codelets from scratch and they are quite separate from the pnpd codebase, just implemented as header files.

cheers ... tim

-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk

The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs

The other thing is that i guess it has to be straight C for Miller to accept it,

yes, possibly ...

plus, older gcc versions have problems with intrinsics in c ++ code.

well, older gcc versions have problem with intrinsics in general. ;)

as for the license, it could be optional like the fftw support ...

cheers ... tim

-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk

Linux is like a wigwam: no windows, no gates, apache inside, stable.

On Sun, 3 Dec 2006, Thomas Grill wrote:

Hi Miller, clearly for a new devel branch, MAIN would be the right to start from.

The diff -u between pd 0.39-2 and 0.40-2 is 272k.

The diff -u between pd 0.39-2 and devel_0_39 is 600k.

Without the -u, the ratio between diff sizes becomes slightly steeper.

I merged 80% of the 0.39-2 0.40-2 diff into DesireData in one night (just after pre4). The rest of 0.40 will be coming before pre6.

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

On Dec 2, 2006, at 5:24 PM, Mathieu Bouchard wrote:

On Sat, 2 Dec 2006, Thomas Grill wrote:

...

and obviously i have been assigned the role of the "keeper of the devel",

It's been a while that I've been thinking of you as the keeper of the devel, and of myself as being a guest.

...

with all the freedom to make changes where i like, not having to keep an eye on compatibility

Well, compatibility would be a lot easier if we had automated tests like most programming languages have. (That's why I had started a project called PureUnity)

How about finishing it and adding it to the nightly builds?

.hc

...

• I'd find it beneficial to integrate Miller's changes that

happened since the last merge

Agreed.

...

• Branch off a devel branch (without version number) from Miller's

latest cvs

I don't agree with that, I believe that it will be easier to merge things the other way around.

...

• Gradually integrate the listed devel features into the branch,

and also making patches for Miller

Even though the 0.39->devel_0_39 is bigger, making patches for Miller would be one reason to start the new devel branch from Miller's 0.40, but I'm not going to encourage making patches for Miller.

...

• Rethink some architectural details, like the SIMD infrastructure

(ability to inline functions and enable auto-vectorization)

What would change about those features? (are those things in parentheses not implemented? I thought that auto-vectorisation was already enabled?)

I have an important question: which version of 0.39 was devel_0_39 branched off of?

_ _ __ ___ _____ ________ _____________ _____________________ ... | 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

------------------------------------------------------------------------

Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith

On Sun, 10 Dec 2006, Mathieu Bouchard wrote:

On Sun, 3 Dec 2006, Hans-Christoph Steiner wrote:

...

On Dec 2, 2006, at 5:24 PM, Mathieu Bouchard wrote:

...

Well, compatibility would be a lot easier if we had automated tests like most programming languages have. (That's why I had started a project called PureUnity)

How about finishing it and adding it to the nightly builds?

Well, if I'm still alone for doing it, I might have a partial demo to show off at the next PdConvention. As it is right now, I have already enough work with DesireData, and after that I have to work on GridFlow a lot. The test suite needs not to be written by me. How about you making that test suite? What would it be like? When?

Ok, we will have a major shift of focus now. PureUnity becomes a priority, but also, the scope of that project gets expanded to cover our current autotest needs. PureUnity will have DesireData-specific features so that Pd patches can be used to test Tcl/Tk code.

What's going on is that naïve testing (code then try) that most are using in the pd community, is not scaling well at all, given the growing feature set of DesireData, and especially the combinatorics of it. We need to reshape our software development process. PureUnity started as thought experiment that I planned would turn out useful later when I'd finally work on non-GUI components, but now it needs to be useful now, and the most pressing need is not even about testing the behaviour of individual objects or of simple object combinations, but about the process of putting objects together through the GUI, which is something radically different but for which I have faith that there will be significant commonality with the original goals of PureUnity.

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