[Kst] Does kst have any support for data that changes, but doesn't grow?

[Fowler, Joseph W.]

Dear Barth,

Thanks for giving it some thought. You're right: the writer (or reader) would have to lock the file somehow. I hadn't thought of that.

In my understanding of GetData and kst, though, the real issue is that the idea of altering a data source rather than appending to it violates the basic abstraction of what a data source is. That's why it makes sense for kst not to read old data.

For the sake of argument, I picture a system where the a field can be tagged as volatile. A volatile field means that (1) it can change data without changing its length, and (2) its length is independent of the number of frames in the reference field. In dirfiles, I don't know if you'd want to have a /VOLATILE directive, or let VOLATILE be a basic type, an alternative to RAW. Probably the latter, since "samples per frame" makes no sense for volatile fields. Derived fields would inherit volatility from the raw one.

It might be too much of a departure and create too many problems. For example, what's the implied INDEX vector if a user wants to plot a volatile field? Will it depend on whether the volatile field is longer or shorter than the number of frames in the reference field? Also, how will kst know when to check the volatile field for changes?

Still, it might be worth it for you to consider it. You can see from the thread http://mail.kde.org/pipermail/kst/2013-August/021394.html that I'm not the first this year to ask about achieving oscilloscope-type behavior from kst.

For my immediate problem, I figure I'll either try to write a kst plugin for our obscure data file format or get our group to agree to using dirfiles for our raw data.

Thanks.
Joe

On Dec 11, 2013, at 3:25 PM, Barth Netterfield <barth.netterfield at utoronto.ca> wrote:

> Hey Joseph,
> 
> Handling this would at least require writing a new data source, since doing 
> something like this requires handling locking of the file to avoid race 
> conditions.
> 
> However, I'm not sure that this will be enough - kst itself, as far as I know, 
> optimizes by not reading old data.
> 
> On the other hand, I think this would be a cool feature.  Let me think some 
> more.
> 
> cbn