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

[Barth Netterfield]

Arggg...
It is implemented, but doesn't work.

Here is why:
  The output vectors get stored in a hash.
  A Hash's order is undefined.
  The names of the output vectors are written in the order of the hash.
  The short name numbers are allocated in the order they are created
  When creating the plugin in the first case, they are created in some
order at the whim of the programmer (eg, in setupOutputs).
  When creating the plugin when being loaded from file, they are
created in the order they were listed in the file, which is different.
Mehem ensues.

It is possible that save/load used to work because QHash at one time
might have kept the order of creation.  Or maybe it never worked.

In any case, we need to fix it:
options:
a) change from QHash to QMap, and change setupOutputs in all plugins
so things are created alphabetically (seems fragile)
b) something less fragile that I can't think of off hand.

I implemented (a) for unweighted linear fits and it does work.




On Sun, Mar 20, 2011 at 8:29 AM, Nicolas Brisset
<nicolas.brisset at free.fr> wrote:
>> Saving the fit does not work (looks like it is not implemented).
>> Should we release any way?
>> Implementing it will take same days.
> Hum, good question. On the one hand, releasing something with saving partly broken sounds like a bad idea, but on the other hand we can't undefinitely postpone 2.0.3.
>
> I am a bit surprised that it is not implemented. But I'm not familiar with that part of the code. Maybe we should wait and get Barth's advice?
> What do others think? In any case we'd do 2.0.4 with essentially bug fixes before moving on to bigger changes for 2.1.0...
>
> Nicolas
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>



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