| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
1.7 daily tests failed in HL library when Fortran was not
enabled; also long long instead of long_long declarations
were used and caused failures on Windows
Solution:
Removed Fortran related functions (except H5IM_find_palette) from
H5IM.c file and put it into fortran/src/H5IMcc.c
Modified appropriate Makefile.am files, regenerated Makefile.in files, updated header files, MANIFEST, etc.
Note: H5IM_find_palette should be also in H5IMcc.c, but
for some unknown to me reason, linking fails if the function is
included in H5IMcc.c. I will really appreciate if some C guru
will look into the code and figure out what is wrong :-) Thanks!
Platforms tested: mir with g95, heping with and without Fortran enabled
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
removed some outdated comments
Description:
Solution:
Platforms tested:
linux
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bug fix
Description:
the fortran type integer*1 has become not portable.
define the image fortran datatype as "integer" and make special save, read, and palette functions
that use native integer for a memory type and UCHAR as disk type for the image data
added some more tests with new palette definitions
Solution:
Platforms tested:
linux
solaris
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new tests for DS
Description:
add a test that ckecks if a scale being attached itself has scales attached (error)
add a test for the dataset being attached to is a reserved High Level class (image, palette, table)
Solution:
Platforms tested:
linux
solaris
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added a first batch of dimension scales
fix some small bubgs in lite (a close function was not being called )
Description:
this batch contains the basic API functions described in the RFC and a minimal test file
Solution:
Platforms tested:
linux
solaris 64
AIX
windows
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
|
|
|
insert high level library into main library
Description:
configure.in has a new entry (--enable-hl, disable-hl) it is on by default
the configure message prints info regarding if hl is enabled or not
the tree is
/hl
/hl/src
/hl/test
Solution:
Platforms tested:
linux
solaris
AIX
Misc. update:
|
