[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
it.
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.
Yep.
| 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).
-Ted
More information about the Kst
mailing list