[Kst] DirFile RAW INT16/s type broken?

[Peter Milne]

Hi Matt

Matthew D Truch wrote:
>> Plotting 16 bit signed RAW data from a DirFile.
>> Works as expected in KST 1.7/FC10, but is broken in KST 1.8/FC12, 2.0
>>
>> When broken, the data shows up with a sign-inverted pattern, looks like 
>> it's being interpreted as UINT16, maybe UINT32 instead of INT16 as 
>> specified.
>>
>> It looks like DirFile handling changed (googling suggests from 
>> internal?) on 1.7.
> 
> Yes, originally kst used its own internal dirfile reader (from which the
> getdata library was created).  
> 
>> I also don't understand the effect of the kst-getdata plugin; installing 
>> it from yum didn't solve the problem, the plugin doesn't appear to make 
>> any change - is that perhaps because the desktop is Gnome and not KDE?.
> 
> The desktop you are using should not matter.  You make it sound like if
> you remove the kst-getdata plugin that kst 1.8 will still read your
> dirfile data (albeit incorrectly), which is weird.  
> 
> Do you have both kst 1.8 and 2.0 installed at the same time?  How did
> you install kst 2.0?  What version of getdata do you have installed?  
> 
There are two separate systems.
One, running fc10 has:
[pgm at hoy ~]$ rpm -q kst
kst-1.7.0-5.fc10.x86_64

That works. There are also local builds of kst-1.8.0, kst-2.0.0-beta2 
built from tarballs but not installed.

The more interesting standard system is a vanilla fc12 where I first saw 
the problem, this has kst-1.8 installed from packages as shown before

>> rpm -q kst-getdata
>> kst-getdata-1.8.0-3.fc12.x86_64
>> rpm -q kst
>> kst-1.8.0-3.fc12.x86_64

and ..

[peter at gigha ~]$ rpm -q getdata
getdata-0.5.0-5.fc12.x86_64


However it really seems to me as if the getdata library (plugin?) isn't 
getting called since there's no sign of it in /proc/PID/maps

[peter at gigha ~]$ grep kst /proc/8254/maps  | wc
     170    1020   19915
[peter at gigha ~]$ grep getdata /proc/8254/maps | wc
       0       0       0

... but kst _is_ able to interpret and plot the DirFile (if incorrectly).


Thanks


Peter