[Kst] Sort of serious bug...

[Barth Netterfield]

On March 6, 2015 2:03:35 PM D. V. Wiebe wrote:
> I'm not sure if this is one of the options listed but, if kst is to be
> used in production environments, being backwards compatible when it comes to
> reading old .kst files is necessary.

No question!

> There needs to be better versioning of the .kst files.  Right now they
> all seem to have version="2.0" at the top, which would be grand if that
> number ever got updated.  You might want to add a separate version number
> for the kst XML syntax (is this what people call a "DOM"?) which is
> updated whenever that changes.  That would divorce it from the kst
> package version.

I have updated the header to 2.0.9.  It doesn't have to have anything to do 
with the kst version, but I thought that it might as well because... why not.

> Then you need to extend the parser to handle multiple versions of the
> syntax and convert old versions to the current one.  If this requires
> renaming or renumbering scalars when reading the .kst file, then do it.
> If this is potentionally surprising to the user, make a pop-up dialog
> box inform them that this is what's happening because the .kst file is
> old, and maybe they should update it.

The problem is not the syntax.  That hasn't changed.  It is the naming of 
objects in the session itself which is the issue.

in kst, the short names for scalars starts at X1 and goes up as each scalar is 
added.  So, if you start kst with a 2.0 session and then create some vectors, 
then the 'slave' scalars will be named X1 to X12.  The scalars from the 2nd 
vector will be called X13 to X24, etc.  These names are set by the inherited 
NamedObject constructor at construction time, based on some internal 
variables.  

In a 2.0.9 session, vectors have two new slave scalars, so the numbers go from 
X1 - X14, then X15 - X26, etc.

When you use a scalar (say in a label or in an equation) then it is referred 
to by its short name (the full name is included, but ignored).  So if the 
index of the slave scalar name is changed, then all references to it will be 
broken.

As a hack to keep current kst from being totally broken I have done a commit 
in which, if an old (2.0) session is detected, the new slave scalars (ie, iMax 
and iMin) are not created and are not made available.  This means that new kst 
can happily load old kst files, but such a session can never be upgraded to the 
new 2.0.9 session.  It also splits session versioning out into other parts of 
kst, which is bad.

It also means that any .kst file which has been created using the git version 
of kst since the commit in November will suddenly loose access to iMin and 
iMax.  This is bad for people who have been using git head, but not the total 
end of the world since it wasn't in any release.

The way to really fix it is to go through references to scalars in all objects 
as they are loaded and change their names (ie, parse the labels, and 
equations, and adjust).  This is possible, and correct, and should be done, 
but is bug-prone and not completely trivial.  We are sure to forget something.


> My recommendation is that all the logic for handling old .kst files be
> in the .kst file parser itself, and the output of the parser present a
> single, standardised object to the rest of kst, regardless of the age of
> the .kst file.
> 
> I don't think you should write old versions of .kst files.  If a user
> loads an old file and then saves it again, just convert it to the new
> version.  The only benefit the user gets from writing old .kst files
> is the ability to read them in old version of kst.

yeah... see above.

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