[Kst] Explanations on datasource readField/update methods ?

[George Staikos]

On July 6, 2004 09:07, Nicolas.Brisset at eurocopter.com wrote:
> I have finally found the way to test my cdf plugin that uses an external
> lib. After some fiddling around with Makefile.am files and the like and
> looking at the lffio datasource, I managed to add the appropriate
> kstdata_cdf_la_LIBADD flag somewhere. I could probably not do it again, but
> at least it runs now :-) Once the thing is ready for commit, someone will
> have to integrate it properly, but for now it needs more testing...

  Welcome to the wonderful world of automake.  Can't you see we're all 
grinning? :)

> When I select a cdf file in the first step of the datawizard, the
> understands_cdf function picks it up, and I can see the list of variables
> in the following page of the wizard. I select the ones I'm interested in,
> and proceed through the last steps. I can then see a progress dialog...
> before kst crashes ! Using some traces (with cout, probably not the right
> way but I don't know how to use kdDebug), I found out that the

  (kdDebug() << "string" << number << etc << endl; -- almost the same as cout)

> CdfSource::readField method is always called with a starting number of 0
> and a number of values to read of -1. I guess that's not the way it's meant
> to be, but it is not straightforward to understand why. In the case of a
> plain ASCII file, the method is called with sensible numbers (on a test
> file I used, starting value 0 and number of values = number of lines in
> that file). Why isn't this the case with cdf (which is a binary format) ?

    That means to read all values from the beginning until the end.  -1 is a 
sentinel value there.

> Another thing I noticed from the traces is that the DataSource::update()
> method is called on all files which have been clicked on in the first page
> of the datawizard, even another file is used in the end. This is surely not
> the desired behavior and actually looks like a bug ?!!? (I'm using code
> from a June 22 2004 CVS snapshot). It looks as if update timers were
> instantiated on the files a bit too quickly :-)

   The file dialog has been removed again.  I think this should solve your 
problem.  If you type, however, it will try to open the data source on each 
filename you type in because it needs to know if it's valid and it should 
enable the "Next" button in the wizard.

> Finally, I wonder when exactly the readField() and update() methods are
> called and when the datasource is instantiated and destroyed. I suppose it
> is safe to just return KstObject::NO_CHANGE from update when the files are
> not real-time sources but 'fixed', but I'd like to be sure...

   When a KstRVector is updated, and it's valid, the update will attempt to 
read in the data.  Therefore you get a call to readField() from within 
update() (doUpdate() actually).  This prepares the proper vector size and 
ensures the data is ready when another object tries to access it.  Why is it 
done this way?  Well, it's the way Kst has always done it, and it's simple.  
Is it optimal?  Not in all cases, but I think that when you attempt to read a 
data file, you generally intend to actually read the data.  At least some of 
the data sources do chunked reads so this doesn't result in [much] blocking.  
That is the only major concern I can think of for reading data early.  
Unfortunately changing this behaviour would be a major design change in Kst.  
We would then need to rely on explicit updates of objects, or make all of 
their accessors update when required.  Both are a pain and much more error 
prone.  A good way to think about it is that in Kst, flow is driven by the 
data inputs.  If data stops arriving, the objects [are supposed to] stop 
updating.  If we change it so that the objects drive data input, then we will 
have a bit of a paradox - who will initiate data flow, when does it stop, how 
do we update, etc?

   One option that might help your case, at least now, is if we didn't do an 
update() on RVectors that have no "users" yet.  Unfortunately the only clean 
way to do this is with explicit reference counting (along with the implicit 
reference counting), which I removed not even a year ago.  I guess a simpler 
form of this could be reintroduced if it's really of benefit.

-- 
George Staikos
KDE Developer			http://www.kde.org/
Staikos Computing Services Inc.	http://www.staikos.net/