| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kludge
Description:
Since we're only about halfway through converting the internal use of
property lists from the "old way" to the generic property lists, we turned
off snapshots to avoid exposing lots of API changes to users, until the
APIs settled down.
Getting the snapshots rolling again seems to have become a priority, so
some changes are going to have to be made now that were going to be
postponed until we were completely finished with the conversion. This
requires that the old API functions be able to deal with both the old
and new property lists smoothly.
Solution:
Kludge together the property list code so that they can transparently handle
dealing with both the old and new property lists
Platforms tested:
FreeBSD 4.4 (hawkwind)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup (sorta)
Description:
When the first versions of the HDF5 library were designed, I remembered
vividly the difficulties of porting code from a 32-bit platform to a 16-bit
platform and asked that people use intn & uintn instead of int & unsigned
int, respectively. However, in hindsight, this was overkill and
unnecessary since we weren't going to be porting the HDF5 library to
16-bit architectures.
Currently, the extra uintn & intn typedefs are causing problems for users
who'd like to include both the HDF5 and HDF4 header files in one source
module (like Kent's h4toh5 library).
Solution:
Changed the uintn & intn's to unsigned and int's respectively.
Platforms tested:
FreeBSD 4.4 (hawkwind)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New Features!
Description:
Start migrating the internal use of property lists in the library from the
older implementation to the new generic property lists.
Currently, only the dataset transfer property lists are migrated to the
new architecture, all the rest of the property list types are still using
the older architecture.
Also, the backward compatibility features are not implemented yet, so
applications which use dataset transfer properties may need to make the
following changes:
H5Pcreate(H5P_DATASET_XFER) -> H5Pcreate_list(H5P_DATASET_XFER_NEW)
and
H5Pclose(<a dataset transfer property list>) -> H5Pclose_list(id)
This still may have some bugs in it, especially with Fortran, but I should
be wrapping up those later today.
Platforms tested:
FreeBSD 4.4 (hawkwind)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update
Description:
Changed includes of the form:
#include <hdf5_file.h>
to
#include "hdf5_file.h"
so that gcc can pick them up easier without including the system
header files since we don't care about them.
Platforms tested:
Linux
|
| |
|
|
|
|
|
|
|
|
|
| |
Code Tweaks
Description:
"FILE" macro for file names was getting confused with Standard C __FILE__
macro on certain platforms.
Solution:
Changed "FILE" macro usage to "DATAFILE"
Platforms tested:
FreeBSD 4.3 (hawkwind)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug fix (sort of)
Description:
The RCSID string in H5public.h was causing the C++ code problem as it
was included multiple times and C++ did not like multiple definitions
of the same static variable.
Solution:
Since we don't really make use of the RCSID strings as we have not
installed it in all source files, we decided to remove it.
Platforms tested:
eirene (linux), modi4 (IRIX64-64) both serial and parallel modes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
a bug fix
Description:
without explicitly including stdio.h in this file, it will fail in compiling
at the first time of building up the library. It needs to be recompiled separetely. Now it can work. The real reason is to be investigated.
Solution:
adding include <stdio.h> for win32.
Platforms tested:
win 2000
|
| |
|
|
|
|
|
|
| |
Backward compatibility code
Description:
Add in code to allow the library to emulate the v1.2 API and behavior.
Platforms tested:
FreeBSD 4.2 (hawkwind)
|
| | |
|
| |
|
