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

Peter Kümmel syntheticpp at gmx.net
Wed Mar 23 10:13:04 CET 2011

On 23.03.2011 00:05, Barth Netterfield wrote:
> 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).

I've hoped you have a better solution ;)

> This applies to about 6 plugins.
> There is clearly a need to simplify the creation of plugins though.

More information about the Kst mailing list