[Kst] [Bug 116461] getdata borks when the first field in the format file isn't (ASCII) alphabetically the first field.

[Ted Kisner]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=116461         




------- Additional Comments From tskisner.public gmail com  2005-11-16 02:05 -------
> 01:33 ------- I should point out that the supplied patch completely
> deprecates the third argument to GetNFrames (in_field) and will always look
> at the first valid raw field in the format file, whatever it is passed for
> that parameter.


In my dirfile library here:

http://cmb.phys.cwru.edu/kisner/code/dirfile/

I always return the number of available samples for the desired field.  This 
code is based on Barth's original getData, with lots of memory leak plugging 
and full "putData" functionality implemented by me.  Frankly I think it is 
silly to assume that all fields will have the same number of samples on disk.

> This is the behaviour Barth and I settled on when we hammered out getting
> defile (the BLAST dirfile writer) and kst to behave well together,


I still don't understand why you guys didn't just use my putData stuff for 
writing dirfiles- it does all of the reverse mapping from linterp/lincom/bit 
fields to the underlying RAW field.  But whatever- I know from personal 
experience that sometimes everyone needs to reinvent a wheel or 3 ;-)

> but I 
> don't know if this convention is universal.  AFAICT, kst never passes a
> non-NULL value for in_field when calling GetNFrames, so it shouldn't care.


I certainly have used kst to plot dirfile directories where the fields in the 
format file all have different sizes.  Is this situation formally 
unsupported?  In my opinion, that removes much of the usefullness of the 
dirfile format.

-Ted