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

George Staikos staikos at kde.org
Wed Nov 16 02:17:01 CET 2005


------- 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 staikos kde org  2005-11-16 02:17 -------
On Tuesday 15 November 2005 20:05, Ted Kisner wrote:
> > 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 ;-)


  If you have some time to hook this into a datasource we could definitely 
give it a try too.  The current one is just Kst legacy... it was there and 
just got poked around as needed.


More information about the Kst mailing list