[Kst] [Bug 116461] getdata borks when the first field in the format file isn't (ASCII) alphabetically the first field.
tskisner.public at gmail.com
Wed Nov 16 02:05:51 CET 2005
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
------- 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:
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
More information about the Kst