Bring r17230 back from trunk to 1.8 branch:
Various minor tuneups noticed in working on the revise_chunks branch.
Tested on:
Mac OS X/32 10.5.7 (amazon) debug & production
full testing done on trunk before bringing change back.
Description:
Divided Attribute::read into specific private functions for fixed-
and variable-len string data: p_read_fixed_len and p_read_variable_len.
Added test to write/read array of strings to attributes.
Platforms tested:
Linux/32 2.6 (jam)
FreeBSD/64 6.3 (liberty)
SunOS 5.10 (linew)
Description:
Divided Attribute::read into specific private functions for fixed-
and variable-len string data: p_read_fixed_len and p_read_variable_len.
Added test to write/read array of strings to attributes.
Platforms tested:
Linux/32 2.6 (jam)
FreeBSD/64 6.3 (liberty)
SunOS 5.10 (linew)
PathScale was mistaken as the Gcc compiler such that gcc flags were added
to it but PathScale did not honor many of them. (e.g. -Wvariadic-macros,
-Wold-style-definition, -Winit-self, -Wvariadic-macros, -Wmissing-include-dirs,
-Winit-self, -Wc++-compat)
Solution:
Added a pre-condition to detect pathScale compiler before Gcc is
accepted.
Tested:
Sandia Glory where PathScale compiler is available.
gfortran is more likely installed with gcc now.
Tested:
jam and amani which covers both linux and linux64.
No h5committest because this is gnu compiler specific, usually
applicable to Linux.
to undefined and let the caller functions decide the location of the datatype. For
H5Tdecode, it should mark the datatype as in memory. For other callers like H5Dopen or
H5Aopen, they should makr it as on disk.
Tested it on jam, smirom, linew.
Bring r17152 from trunk to 1.8 branch:
Clean up some minor formatting and misc. errors noticed while working on
fixed array code merge.
Tested on:
Mac OS X/32 10.5.7 (amazon)
Too minor to require h5committest
Bring r17148:17149 from trunk into 1.8 branch:
Refactor how chunked dataset information is computed, moving it earlier and
avoiding more recomputation.
Tested on:
FreeBSD/32 6.3 (duty) in debug mode
FreeBSD/64 6.3 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (jam) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/Intel compilers w/default API=1.6.x,
w/C++ & FORTRAN, in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in debug mode
Linux/64-amd64 2.6 (abe) w/parallel, w/FORTRAN, in production mode
Mac OS X/32 10.5.7 (amazon) in debug mode
Mac OS X/32 10.5.7 (amazon) w/C++ & FORTRAN, w/threadsafe,
in production mode
Bring r17146 from trunk to 1.8 branch:
Bring a bunch of misc. improvements & tweaks from the revise_chunks
branch back to the trunk, so that future merges won't be so painful.
Tested on:
FreeBSd/32 6.3 (duty)
(h5committested on trunk)
Bring r17138 from trunk into 1.8 branch:
Disable use of temporary file space allocation when using a parallel VFD,
until we've made changes to broadcast the new address of the metadata when it
is relocated down into 'normal' file space.
Tested on:
Mac OS X/32 10.5.8 (amazon)
(h5committested on trunk)
replaced it with H5Aopen in this round. I also updated some hard-coded numbers with some
macros.
Tested on jam only. I have tested the same change for the trunk.
the attribute structure wan't set correctly. It caused some confusion in H5A_read. This
flag was actually redundant because the library can alwasy check if the data buffer is
present. To fix it, I removed the "initialized" flag in the attribute structure and let
H5A_read check the data buffer.
I tested it on jam only but have tested the same change for the trunk on jam, smirom,
and linew.
Description:
Previously, when H5Z_filter_info was called for a filter that was not present,
it would succeed and return the information from one position past the end of
the pipeline, possibly causing a segfault. This affected at least
H5Pget_fitler_by_id1/2, and possibly other API functions. Fixed to properly
return failure.
Tested: jam, linew, smirom (h5committest)
Bring r17038-17039,17045,17062 from trunk to 1.8 branch:
Switch fractal heap direct & indirect blocks to use temp. space alloc.
Improvements to metadata accumulator
Tested on:
FreeBSD/32 6.3 (duty) in debug mode
FreeBSD/64 6.3 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (jam) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/Intel compilers w/default API=1.6.x,
w/C++ & FORTRAN, in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in debug mode
Linux/64-amd64 2.6 (abe) w/parallel, w/FORTRAN, in production mode
Mac OS X/32 10.5.7 (amazon) in debug mode
Mac OS X/32 10.5.7 (amazon) w/C++ & FORTRAN, w/threadsafe,
in production mode
Bring r17010,17017,17021-17022,17029-17031,17035 back from trunk:
"temporary" file allocation space changes.
Tested on:
FreeBSD/32 6.3 (duty) in debug mode
FreeBSD/64 6.3 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (jam) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/Intel compilers w/default API=1.6.x,
w/C++ & FORTRAN, in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in debug mode
Linux/64-amd64 2.6 (abe) w/parallel, w/FORTRAN, in production mode
Mac OS X/32 10.5.7 (amazon) in debug mode
Mac OS X/32 10.5.7 (amazon) w/C++ & FORTRAN, w/threadsafe,
in production mode
bug fix: h5repack was not applying a requested contiguous layout for a dataset with filters
added a test to the C program test (not to the script), that verifies the layout and filters
tested: linux
Add a run to the h5repack shell script to read a family file
The file used for input is located in the common source tools for testfiles, in tools/testfiles
Modified the h5repack shell script to read files from this location (h5repack reads its input files from a dedicated testfiles location in h5repack/testfiles)
Changed the h5diff open file call to use h5tools_fopen, so that it can open all file drivers
Tested: linux
