[Kst] Re: CDF datasource debugging ?

Nicolas.Brisset at eurocopter.com Nicolas.Brisset at eurocopter.com
Mon Jul 12 18:19:23 CEST 2004

On Friday 09 July 2004 21:05, you wrote:
> > 1) why is seems to be called more than once even though in the first call
> > the arguments say from the 0th value, for -1 values (which means all
> > values as you said in an earlier mail)
>   Oh dear, I think I gave you misinformation.  I'm really sorry about that.
>   The ascii source actually returns 1 sample for n < 0.  Hrm we really need
> to document this better.
I changed the behavior or readField() to be that of ASCII (if (n < 0) n = 1), 
and it does work better :-) However, at first only 1 point was read, which I 
found out to be linked to the fact that frameCount() always returned 1. I 
started changing that, which exposed another problem: in my cdf files, the 
variables do NOT all have the same frame count. This does not seem to have 
been planned, though... As a result, I am now using the maximum value across 
all variables, and I have to handle this in the readField method otherwise I 
get a lot of extra "0"s under some circumstances. Not really great !

> > 2) how the v table of doubles can be allocated to the right size when the
> > caller obviously has not way of knowing how many items will be read
> > (which is why I realloc it
>    You cannot reallocate it.  That would cause the crashes you're seeing.
I no longer do it :-) But I still produce nice crashes !
I suspect there is a problem with threading. From the traces in the code, 
frameCount() seems to be called very often, even though update always 
returns ::NoChange. Strange ?
Furthermore, I originally chose to open the cdf file only in the constructor 
and close it in the destructor because that operation can become quite long 
(especially with large compressed cdf files). But it does not seem to be 
thread-safe to leave the file open when multiple threads are trying to access 
it concurrently !!! I now open and close the file in each method and things 
work better. Some problems remain, though...

>     I received the one you sent.  I will try to build it asap and see if I
> can make it work.  I do have to try to finish the 0.98 release before
> Monday though.
Don't waste time with last week's code (it does not even compile because of a 
bad guess: rVAR_RECNUMBER_ is actually called rVAR_SEQPOS_). Attached is a 
better version, with still some ugly hacks (like harcoded include paths you 
will have to change, but changing the name of the datasource is so 
complicated with autotools :-( !)

Feel free to comment/improve this piece of code !


-------------- next part --------------
A non-text attachment was scrubbed...
Name: cdf.cpp
Type: text/x-c++src
Size: 8605 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20040712/63318014/cdf.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cdf.h
Type: text/x-chdr
Size: 1657 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20040712/63318014/cdf-0001.bin

More information about the Kst mailing list