| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
#879. This checkin takes care of the first two, I will look at the last one today.
Tested:
Visual Studio 2005 on WinXP
|
| |
|
|
| |
Tested: kagiso.
|
| |
|
|
|
|
|
| |
were exposed on Windows.
Platforms tested: Those were changes to the Windows related code only; will be tested
by windows daily tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous implementation failed to compile on MAC OS X Tiger 10.4 and AIX 5.2
In previous implementation, each overloaded Fortran function called the same
C function. Since declaration of parameters in INTERFACE block for
C Function differed, some compilers issued warnings but g95 on MAC and AIX
failed to compile.
Solution: Add C wrappers corresponding to each overloaded Fortran function
to call C stub function. This fix should also reduce number of warnings
on IRIX systems.
Platforms tested: MAC OS and AIX 5.2 (copper) with g95;
sol (with Sun compilers), heping with PGI compilers
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
When compiler flag was used to set the size of Fortran integer
to 8 bytes, library would fail.
Solution:
Cleaned up the code; added detection of Fortran INTEGER type size
and appropriately defined int_f type for C-stubs routines.
Platforms tested:
Solaris 2.8 32 and 64-bit, AIX 5.1 64-bit parallel
PGI Fortran with -i8 flag on heping
Absoft Fortran with -i8 flag on heping
g95 on mir (Fortran integer is 8 bytes by default that cannot be
changed - compiler bug ;-)
AIX Fortran with -qintsize=8 32 and 64-bit modes on copper
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug fix
Description:
Belatedly chase change of hobj_ref_t in C APIs.
Platforms tested:
FreeBSD 4.10 (sleipnir) w/backward compatibility turned on
IRIX64 6.5 (modi4) w/FORTRAN
h5committest
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Fix/Code Cleanup/Doc Cleanup/Optimization/Branch Sync :-)
Description:
Generally speaking, this is the "signed->unsigned" change to selections.
However, in the process of merging code back, things got stickier and stickier
until I ended up doing a big "sync the two branches up" operation. So... I
brought back all the "infrastructure" fixes from the development branch to the
release branch (which I think were actually making some improvement in
performance) as well as fixed several bugs which had been fixed in one branch,
but not the other.
I've also tagged the repository before making this checkin with the label
"before_signed_unsigned_changes".
Platforms tested:
FreeBSD 4.10 (sleipnir) w/parallel & fphdf5
FreeBSD 4.10 (sleipnir) w/threadsafe
FreeBSD 4.10 (sleipnir) w/backward compatibility
Solaris 2.7 (arabica) w/"purify options"
Solaris 2.8 (sol) w/FORTRAN & C++
AIX 5.x (copper) w/parallel & FORTRAN
IRIX64 6.5 (modi4) w/FORTRAN
Linux 2.4 (heping) w/FORTRAN & C++
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose: Maintenance
Description: h5dwrite/read_f and h5awrite_read_f functions were overloaded
with dims argument being of type INTEGER and INTEGER(HSIZE_T).
We promised to remove overloading in 1.4 release. It was
removed from documentation but not from the source code.
Solution: Finish code cleanup.
Platforms tested: Solaris 2.7 32 and 64 bit, and copper with --enable-
parallel. Windows are broken, so Kent and Xuan
will test it with their changes later.
Misc. update:
|
| |
|
|
|
|
|
|
|
| |
Updated, cleanup or added Copyright notice.
Platforms tested:
"h5committested"
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose: Added copyright statement; cleaned code and fixed bugs for
Windows and Cray T90IEEE
Description: Fortran files did not have copyright statement; VL types
did not work on T90IEEE since I never brought the correct code
from 1.4 branch; there were compilation warnings on Windows;
some character parameters were not passed correctly to C stubs
causing tests to fail on Windows.
Solution: Added copyright statement and clean the code.
Platforms tested: CRAY T90IEEE, arabica, modi4 with parallel, Windows 2000
Only static tests (both debug and release) passed on Windows.
DLLs have multiple problems ;-)
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose: Catching up with the C library
Description: Added the follwoing new fortran functions
h5iget_name_f
h5tis_variavle_str_f
h5zunregister_f
h5zfilter_avail_f
h5pset_shuffle_f
h5pset_fletcher32
h5pset_edc_check_f
h5pget_edc_check_f
h5dfill_f
Solution:
Platforms tested: arabica(C and F90), burrwhite (pgcc and pgf90), modi4 (F90 and parallel)
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Maintenance
Description:
* Added support for generic properties.
* Added support for time allocation properties.
* Added support for variable length datatypes (only datatypes based
on INTEGER, REAL and CHARACTER Fortran types are supported).
* added some missing functions
Solution:
I am checking in new Fortran APIs and their man pages to support
1.5 features listed above.
Not all APIs have tests yet. APIs were written in Fall 2002, and I am afraid
that I will loose the code or totally forget what I did if I wait longer. ;-)
Platforms tested:
arabica (fortran), eirene (fortran), modi4 (parallel, fortran)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Bug#670 fix
Description:
dims parameter to the h5dwrite_f, h5dread_f, h5awrite_f and h5aread_f
subroutines was declared as INTEGER array of size 7 (max number of dimensions
in Fortran). Users could not use the same buffer dims as an argument to
the h5screate_simple_f subroutine since it should be an array of size = RANK
and type INTEGER(HSIZE_T).
Solution:
Overload subroutines with dims parameter to be assumed size array of
INTEGER(HSIZE_T) type for backward compatibility.
Subroutine with the INTEGER dims argument should be depricated in 1.6 release
Platforms tested:
Windows, Solaris2.7, IRIX64-6.5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
DEC UNIX port
Description:
Windows port caused problems on DEC UNIX.
Names of C functions called from F90 subroutines were converted
to UPPER case while DEC UNIX expected them to be in lower case.
Solution:
Added special DEC compiler directives to avoid the conflict on two
systems
Platforms tested:
Windows98, DEC UNIX, Linux
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
HPUX 11.00 port
Description:
Redundant USE statements triggered a bug in the HP F90 compiler.
Solution:
Source code was rearranged to avoid redundancy: definitions of the
object and dataset region reference types were moved from H5Rff.f90
to H5f90global.f90; "USE H5R" statement was removed from H5Rff.f90.
Now H5Rff.f90 uses "USE H5GLOBAL" statement only as the rest of
the modules.
Platforms tested:
HPUX 11.00 (kelgia), Solaris 2.7 (arabica)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Windows port
Description:
Multiple changes:
* Windows platforms require special compiler directives
in order to create DLLs.
* In read/write subroutines data arrays were passed by descriptor.
This worked on UNIX but did not work on Windows.
Solution:
* added compiler directives.
* read/write APIs have been changed. There is an additional
parameter (array that contains the sizes of data buffer dimensions)
and regular arrays are used instead of assumed-shaped arrays.
Platforms tested:
* Currently this feature does not work. Common blocks are not exported correctly
from one F90 module to another.
I am checking this in so I can ask DEC for help.
* For static library tests passed on Windows 98 ( except flush2_fortran)
All tests passed on Linux, Solaris 2.7, O2K and T3E
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Windows port and maintenance
Description:
Windows Fortran requires interface bocks for each C function
called from F90 stub.
I also added comment blocks for each F90 API.
Solution:
Added interface blocks.
Platforms tested:
Linux (eirene) to test that things are still working on UNIX.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Code maintenance and development
Description:
I added two functions h5open_f and h5close_f to initialize
C library and Fortran interface (flags, predefined datatypes, etc).
Those calls are required for any F90 program that uses HDF5.
I renamed H5f90misc.c and H5f90miscf.f90 files to H5f.c and H5ff.f90.
New functions are added to those new files.
Platforms tested:
Solaris 2.6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
New feature
Description:
Now all Fortran flags such as H5F_ACC_RDONLY_F (previously defined in the
H5fortran_flags.f90 file) are generated at runtime when h5init_fortran_f
subroutine is called. All flags have now the same value as
corresponding C flags. This change affects user's programming model:
Every Fortran program that uses F90 HDF5 Library has to call
h5init_fortran_f(error) subroutine before the first call to the
F90 HDF5 Library and h5close_fortran_f(error) after the last call to the
Library. h5init(close)_types_f calls are not needed anymore since
F90 datatypes are intialized(closed) with the h5init(close)_fortran_f
calls.
Platforms tested:
O2K and Solaris2.7
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Buf fix
Description:
On DEC, H5Dff.f90 would not compile because of variables declaration
order. Other UNIX platforms including J90 did not care.
Solution:
Change the order of variables declarations.
Platforms tested:
DEC Unix (gondolin)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose:
Reimplemented references to the objects and dataset regions.
Description:
Previous implementation was not portable. This implementation
should work on UNIX workstations and Crays, but is very inefficient
since it uses memcpy to repack Fortran buffers with references
to C buffers and vice versa.
Solution:
I used fortran derived datatype with integer fields. h5dwrite_f and
h5dread_f have extra parameter when references are written or read.
This parameter describes size of the buffer that holds references.
Platforms tested:
J90 and Solaris 2.6
H5Pf.c
Some of the functions do not exist now in the development branch.
Commented those out, so one does not need to apply patch in order
to build Fortran Library.
|
|
|
Adding the Fortran interface to the HDF5 library
Description:
Fortran is now a subdirectory of the HDF5 library tree.
Platforms tested:
Solaris and IRIX (O2K)
|
