On Mon, 3 Nov 2014, Peter W. Draper wrote:

>> As many of you know, I've recently been working on a "brand new" 
>> implementation of HDS with this new version (version 5) based on top of
>> HDF5 rather than be an evolution of the existing HDS library.
>> 
>> I've got an almost complete implementation of the HDS API using HDF5 and 
>> you can find that at https://github.com/Starlink/hds-v5 -- it
>> should build and pass tests although it does require some Starlink 
>> libraries installed because I was too lazy to reimplement stuff from ONE
>> and recalculate bad values from PRM (and CNF is needed so that the pointers 
>> created by the library can be used in Fortran code).
>
> Must be some missing commits. I played around and got all the various HDS/HDF 
> libraries to build, but PCS will not build reporting:
>
> libhds.so: error: undefined reference to 'datGet1W_v4'
> libhds.so: error: undefined reference to 'datGet1W_v5'
> libhds.so: error: undefined reference to 'datGet1UW_v4'
> libhds.so: error: undefined reference to 'datGet1UW_v5'
> libhds.so: error: undefined reference to 'hdsFind_v4'
> libhds.so: error: undefined reference to 'hdsFind_v5'
>
> Don't see the source files for these. hdsClose_v4 was also missing but that 
> was just a missing include so the re-define was lost.

Sorry meant hdsStop_v4.

>
>
>> Meanwhile, on a branch, I've completely reorganzied the HDS library itself 
>> such that there libhds is a thin wrapper library that forwards
>> calls on to either the old HDS library (libhds_v4) or the new library 
>> (libhds_v5) and handles copying of structures between the two if you
>> just so happen to be wanting to move some data from files of different 
>> versions. The Fortran wrapper is still in libhdsf and is no
>> different to what it was previously.
>> 
>> As an aside, HDS locators now work differently in Fortran. I needed to 
>> guarantee that the locator buffer in Fortran was the same regardless
>> of v4 or v5 so locators are no longer memcpy-d into the buffer and copied 
>> out again (which results in new pointers). Instead I print the
>> pointer address to the buffer and then read the pointer address back out 
>> when going the other way. I'm sure there is a more efficient way
>> of doing it (like simply copying the 8 bytes of the pointer directly into 
>> the first 8 bytes of the buffer...) The size of the HDS structs
>> now varies a lot depending on which version you are using as now all the 
>> state is stored in the v5 locator whereas in v4 the locator is a
>> little stub to massive internals.
>> 
>> I've now got to the point where stuff is actually working. It's amazing how 
>> much of the core infrastructure code in Starlink exercises all
>> the little wrinkles of the HDS library. Even hdstrace was a pain when I 
>> realised that it calls datSlice on a vectorized locator, and don't
>> get me started on ARY which can call datSlice for all the contents of a 
>> vectorized locator (which I ignore). Anyhow,  I have managed to
>> take some JCMT raw data, make a map with SMURF and display it. That seems 
>> like a good start so if anyone is interested they can check out
>> the hdsv5 branch and give it a try. Note that you may want to set ADAM_USER 
>> as any new files will be created in HDF5 format and you won't
>> be able to read them when you switch to an older Starlink. All new files 
>> are created in v5 format and hdstools hcopy can be used to convert
>> data.
>> 
>> v5 files seem to be slightly larger than native HDS files but if you run 
>> h5repack on them they do shrink.
>> 
>> PS Regarding version numbers: the HDS library was at v5 and seemed to be 
>> implementing v4 file format. HDSv5 therefore refers to the file
>> format and not the version number of the HDS library itself (which is now 
>> at v6).
>> 
>> -- 
>> Tim Jenness
>> 
>> 
>
> -- 
> Peter W. Draper, http://astro.dur.ac.uk/~pdraper
>

-- 
Peter W. Draper, http://astro.dur.ac.uk/~pdraper