[Kst] Re: branches/work/kst/portto4/kst/src

[Barth Netterfield]

On Tue, Mar 22, 2011 at 6:21 PM, Peter Kümmel <syntheticpp at gmx.net> wrote:
> On 22.03.2011 22:49, Nicolas Brisset wrote:
>>> I've reverted my workaround in fitpolynomial_unweighted.cpp because
>>> it was no generic solution. But then the reload bug pops up again.
>>> So the order of output/input doesn't matter here.
>>>
>>> The problem (when loading) is that the dataobject is created with
>>> a xnum, and it assumes that xnum is incremented when the input scalar
>>> is loaded. But the scalar already exits with the initial xnum as
>>> name.
>>> Thus xnum is not incremented and when the xnum value is used for the
>>> next creation of a scalar then two scalars have the same name.
>> I confirm that reloading a polynomial unweighted fit label currently does not work.
>> It seems you have identified the issue quite precisely, I hope it can be fixed easily... I believe it is the last problem holding 2.0.3 back, is it right?
>
> Yes, I hope ;)
>

The issue is that all output primitives associated with a data object
must be created in sequential order with no breaks.
The problem is that in some cases, scalars are created from the
scalarselector in the middle of creation.  The previous patch I put in
attempted to move the creation of the input scalars until after the
output scalars had been created.  This worked for all of the filters,
and some of the fits, but did not work for fits which output a
parameters vector, as the scalars associated with it are not created
until after the inputs are created, and, at least in the case of the
polynomials, they can't be.

So a solution (other than a more severe re-structuring of shortNames)
in these cases is to move the creation of the input scalars to before
the object is created (ie, Peter's previous patch which he reverted).

This applies to about 6 plugins.

There is clearly a need to simplify the creation of plugins though.

-- 
C. Barth Netterfield
University of Toronto
416-845-0946