[Kst] getdata patch
tskisner.public at gmail.com
Fri Jan 6 20:50:34 CET 2006
I like this idea, especially since I've been meaning to add the INCLUDE and
multiply functionality to libdirfile...
One caveat though: is it worth doing this now, or should libdirfile simply be
obsoleted by a new, network transparent, general purpose, super duper binary
Perhaps we should keep libdirfile for the near term. If so, and we decide to
combine our efforts, then I think we need to:
1. Find a place to host a cvs/svn tree (I don't want to do this at CWRU,
since I'll no longer be part of John's group in the near future)
2. Do a general code cleanup and agree on some style guidelines (same as
3. Improve documentation
4. Make it threadsafe by adding pthread locking around the static structures
The features that I've added beyond standard getdata are:
b) largefile support
d) endian swapping, so that data is *always* stored little endian
(this is so that you can copy files between different machines)
check out dirfile-0.87 here
Some parts of the autoconf system need improved, since I've learned a bunch
since I wrote the configure.ac :-)
On Friday 06 January 2006 11:33, Barth Netterfield wrote:
| Without commenting on this particular patch....
| This brings up an idea that Ted has championed for a while now: that
| getdata should be its own library (as is cfitsio, HDF, etc etc) and not a
| part of kst.
| The advantage is that we could have a single libDirfile svn tree somewhere,
| and would avoid the problem of forking that has been a problem in the past,
| and people could easily install libDirfile without installing kst (of
| course, why would someone want to do such a horrible thing?) and could
| install kst without installing dirfiles.
| The disadvantage is that it would mean one more install for people who want
| dirfile access through kst.
| Any thoughts on this?
| On January 6, 2006 01:52 pm, Matthew D Truch wrote:
| > Attached is a patch I'd like to apply to getdata (the 'library' for the
| > dirfile reader), but I'm going to ask here first. It modifies no code
| > that kst uses; it merely adds a new function to getdata that lets you
| > close all the open files getdata has for a given dirfile. I'd like to
| > apply it just to make things easy in keeping kst's getdata in sync with
| > the getdata we use in other blast analysis programs.
| > The reason I want the close function is: when you read files over nfs,
| > often there are errors (nfs sucks). Generally this causes the file to
| > become stale; a re-read will continue to fail, unless you close and
| > reopen the file first. With GetDataClose(), you can close all the
| > files, and the next time you try and read them, GetData will open and
| > read for you.
| Kst mailing list
| Kst at kde.org
More information about the Kst