[Kst] [Bug 123699] fails to create INDEX from .fits file binary extention

Theodore Kisner tskisner.public at gmail.com
Sat Jun 17 07:49:59 CEST 2006

On Friday 16 June 2006 21:52, Barth Netterfield wrote:
| The reason to have a single length per field is to handle asyronously
| arriving real time data in count from end mode (ie, the #1 requirement for
| kst), to make sure that the X vectors and the Y vectors stay synced. 
| Because of this, in fact, currently, fields within a data source are
| required to have the same frame count.  NF is a property of a datasource.

Yes, we've beaten on this issue a ton for dirfiles, but it seems to me that 
synchronicity is a datasource-dependent feature which doesn't make sense for 
some datasources. 

| Perhaps the best solution is to let the data source decide - it can know
| which is appropriate.

I thought this was why we had the "field" argument to the frameCount function?  
The datasource can choose whether to use it or ignore it.

| -kst learns to read NF on a per field basis, not a per data source basis.

I am obviously confused- doesn't it already do this???  As far as I can tell 
from grep'ing through the sources, every call to KstDataSource::frameCount 
includes the field parameter- and thus the datasource can take advantage of 

What am I missing?  Obviously the dirfile source can ignore the field 
parameter, but other datasources can use it already.

| -Data sources that need to are responsible to make sure that NF is the same
| for all fields.  Data sources that don't need to don't (eg: dirfiles can
| have a bool in the format file which tells getdata what to do here)  We
| keep datasource->update() in order for syncronized data sources to
| determine their one and only NF.  non-sycronized data sources don't have to
| do anything here.

Exactly- the dirfile source is synchronous, but other sources don't have to 
be.  This is how the code works *right now*.  

| -INDEX always returns what you ask for, without wondering if the data
| exists for any other fields.


| Seem sensible?

I think so :-)  Also, it *would* be possible for a datasource to have 
mechanisms for synchronous updates with fields of varying length- but such 
things are left up to the datasource (as they should be).


More information about the Kst mailing list