netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Quincey, > My current idea is to add a "creation time" piece of metadata to each > object as it is created in the file, and then the H5Giterate() call (or > something resembling it) could choose whether to use creation times or the > object names (or last modification times, etc.) as the method of indexing the > objects to iterate over. Fairly simple and straightfoward, I think... Even simpler would be a "creation sequence number" piece of metadata. This would just be an integer that incremented for each new HDF5 object, or maybe several such sequences for different kinds of objects. There are some advantages of sequence numbers over times: - you don't have to worry about clock resolution and the possibility that creation times of two objects are equal - you can use gaps in the sequence numbers to tell that objects have been deleted, something not possible with times - adding 1 is cheaper than the system call necessary to access the system clock - in distributed systems, there is not necessarily a well-defined time ordering for events (only a partial ordering) I don't foresee any need for knowing the actual creation time of a netCDF-4 object, but if there are other applications for this kind of information, than feel free to ignore this suggestion ... --Russ >From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 12 2003 Nov -0700 10:31:32 Message-ID: <wrxptfxbiiz.fsf@xxxxxxxxxxxxxxxxxxxxxxx> Date: 12 Nov 2003 10:31:32 -0700 From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx> To: netcdf-hdf@xxxxxxxxxxxxxxxx Subject: error handling with HDF5... Received: (from majordo@localhost) by unidata.ucar.edu (UCAR/Unidata) id hACHVXoO001169 for netcdf-hdf-out; Wed, 12 Nov 2003 10:31:33 -0700 (MST) Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu [126.96.36.199]) by unidata.ucar.edu (UCAR/Unidata) with ESMTP id hACHVWOb001157 for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Wed, 12 Nov 2003 10:31:32 -0700 (MST) Organization: UCAR/Unidata Keywords: 200311121731.hACHVWOb001157 Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx Precedence: bulk Quincey, Unfortunately, all your example code has little or no error handling of HDF function calls. For example, from h5_compound.c: /* * Create a data type for s3. */ s3_tid = H5Tcreate(H5T_COMPOUND, sizeof(float)); status = H5Tinsert(s3_tid, "b_name", 0, H5T_NATIVE_FLOAT); /* * Read field b from s1 dataset. Field in the file is found by its name. */ status = H5Dread(dataset, s3_tid, H5S_ALL, H5S_ALL, H5P_DEFAULT, s3); In this code, the return values are never even checked for anything. Could you post some HDF5 which has some more complex error handling? For example, handling a case of opening a bunch of HDF5 objects, handling an error somewhere in the middle of it all, and still closing the already opened HDF5 object before exiting the function. Our new programmer, Dan, told me that I shouldn't be using goto in C. I decided to ask to see some code from you, rather than launch into a long and (believe me) very boring rant about how when I was a boy, and gotos were first invented, and 25 cents was a lot of money, blah, blah, blah. ;-) Thanks! Ed