[Clam-devel] Get{In,Out}{Ports}{Controls}

[Hernán Ordiales]

I don't like to branch. I proposed bazaar "branch" only to prepare
complicated patches (because local commits feature). I felt that one
thing that contributed to increase the typed controls patch beyond
what is desirable was fear to break something since there are code
related with controls everywhere. Indeed i'm sure match those
uncommitted changes with last modifications will bring at a least one
headache. I'll talk with francisco to see if it's worth to continue
working with that code or maybe is better to start from trunk again.

On Mon, Sep 8, 2008 at 3:38 PM, David García Garzón <dgarcia at iua.upf.edu> wrote:
> Not to be taken seriously, but who knows, menace: Merge the typed-control
> changes or when i would be back on holidays in two weeks i'll start to develop
> them again in trunk in a more incremental way.
>
> Pau and me did a nice DynamicTypes refactor in a not so nice branch and it has
> been there for some years (3? 4?) without a merge. Big refactors should be
> integrated in an incremental way. If not the probability of the branch to
> become abandoned increases each day the merge doesn't happen. Branches are
> evil because merges scare so face the merge or kill the branch. Don't let the
> branch become a zombie like the DynamicTypes one.
>
> David.
>
>
> On Saturday 06 September 2008, Hernán Ordiales wrote:
>> I like this approach.
>>
>> Some related thoughts: Sometime ago I had started an experimental
>> bazaar/launchpad based "branch" to maintain (and btw trying the
>> launchpad thing) the typedcontrols migration patch, in other words,
>> francisco's changes without commit to the trunk yet. I already
>> commented something about this to him but I still have to find more
>> time to post a detailed mail about that. Main advantage i see is that
>> this allows to evolve the patch with private commits (and more free,
>> since you hasn't to be so careful to avoid breaking something) and
>> still having the opportunity to update from trunk (with the 'bzr
>> merge' command), not lose the sync and then produce a final patch to
>> apply. OTOH, I'm still not sure of how to turn it into a branch
>> allowing multiple developers "commits" or contributions, i think it's
>> just a matter of more merges but i have to try it. Beyond that, i
>> think it's pretty the same of having and maintaining a sandbox with
>> uncommitted changes but in this case with the option of private
>> commits (as example, useful to rollback some changes)
>>
>> On Fri, Sep 5, 2008 at 6:03 PM, David García Garzón <dgarcia at iua.upf.edu>
> wrote:
>> > I did a couple of changes which may have impact on existing code and in
>> > Francisco work with TypedControls and MIDI.
>> >
>> >  * Midi plugins joined into a single one
>> >
>> > This one just requires a warning to Francisco: I moved the sources to
>> > one 'src' folder and i made them to compile into a single libmidi plugin.
>> > So, if you had local changes save them, just in case.
>> >
>> >  * Processing::Get{In,Out}{Control,Port}() overloaded for indexes and
>> > names * Processing::GetN{In,Out}{Controls,Ports}() to get the number of
>> > connectors * Processing::Get{In,Out}{Controls,Ports}() are now protected
>> > methods
>> >
>> > I hope that this change will made CLAM coding more easy.
>> >
>> >  processing.GetOutControls().Get("gain");
>> >  processing.GetOutControls().GetByNumber(3);
>> >
>> > becomes:
>> >
>> >  processing.GetOutControl("gain");
>> >  processing.GetOutControl(3);
>> >
>> > and
>> >
>> >  InControlRegistry & inControls = processing.GetInControls().
>> >  for (InControlRegistry::iterator it = inControls.Begin();
>> >        it != inControls.End(); it++)
>> >  {
>> >        InControl & inControl = *it;
>> >
>> > becomes
>> >
>> >  unsigned nInControls = processing.GetNInControls();
>> >  for (unsigned i=0; i<nInControls; i++)
>> >  {
>> >        InControl & inControl = processing.GetInControl(i);
>> >
>> >
>> > This change also might have impact in Francisco work with Typed controls
>> > as i also changed the Typed related interface.
>> >
>> > I made base connectors Processing friends to still be able to access the
>> > old functions. A better solution is feasible for sure but not enough time
>> > to implement it.
>> >
>> > Going to Granada now. Bye.
>> >
>> > David.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Clam-devel mailing list
>> > Clam-devel at llistes.projectes.lafarga.org
>> > https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>
> --
> David García Garzón
> (Work) dgarcia at iua dot upf anotherdot es
> http://www.iua.upf.edu/~dgarcia
>
>



-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9