| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
tested: windows, linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the target object as part of TARGETPATH, noted with some extra indentation
The previous printing of
LINKCLASS 64
was removed
HDF5 "textlinksrc.h5" {
GROUP "/" {
EXTERNAL_LINK "ext_link1" {
TARGETFILE "textlinktar.h5"
TARGETPATH "dset"
DATASET "dset" {
DATATYPE H5T_STD_I32LE
DATASPACE SIMPLE { ( 6 ) / ( 6 ) }
DATA {
(0): 1, 2, 3, 4, 5, 6
}
}
}
}
}
There is no script test for this behavior so far, because test script uses complete paths that vary from test to test, making not possible to define a valid TARGETFILE in the file
tested: windows, linux, solaris
|
| |
|
|
|
|
| |
tested: windows, linux, solaris
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usage is
-m T, --format=T
Where T - is a string containing the floating point format, e.g '%.3f'
The test consists of writing a number with 7 fractional digits (default precision display of %f is 6 digits) and have the 7 digits displayed with
-m %.7f fpformat.h5
Tested: windows, linux, solaris
Note: the output file was generated in linux, it may be possible that platforms other than the ones tested have a different representation of the number
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: Applying update to autotools that was applied to 1.8 a couple
of weeks ago to the trunk.
Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. When using libtool 2.2.2, the
libtool script doesn't generate until later in the configuration
process, so I had to move a test that parsed through the libtool
script to a point after where it was actually being generated.
Ran libtoolize on the project, and ran bin/reconfigure to
regenerate configure and Makefile.in's throughout.
Tested: kagiso, smirom, linew (h5committest)
|
|
|
|
|
|
|
|
| |
compressed size
in the printing of the compression with 3 digits of precision per hdf-forum NASA developers suggestion
tested: windows, linux
|
|
|
|
|
|
|
|
| |
size / compressed size
in the printing of the compression with 3 digits of precision per hdf-forum NASA developers suggestion
tested: windows, linux, solaris
|
| |
|
|
|
|
| |
New fortran wrappers added.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here's the current behavior of h5dump regarding the printing of the dataset creation property list
For example
./h5dump -H -p -d filters
HDF5 "tfilters.h5" {
DATASET "deflate" {
DATATYPE H5T_STD_I32LE
DATASPACE SIMPLE { ( 20, 10 ) / ( 20, 10 ) }
STORAGE_LAYOUT {
CHUNKED ( 10, 5 )
SIZE 385
}
FILTERS {
COMPRESSION DEFLATE { LEVEL 9 }
}
FILLVALUE {
FILL_TIME H5D_FILL_TIME_IFSET
VALUE 0
}
ALLOCATION_TIME {
H5D_ALLOC_TIME_INCR
}
}
}
The proposed behavior is to add this information after SIZE
SIZE 385 (51.9%COMPRESSION)
That percentage is obtained trough
Per = (b-a) / a
Where a = theoretical size obtained by multiplying datum size times number of elements
b = size obtained with H5Dget_storage_size
The final print would look like
HDF5 "tfilters.h5" {
DATASET "deflate" {
DATATYPE H5T_STD_I32LE
DATASPACE SIMPLE { ( 20, 10 ) / ( 20, 10 ) }
STORAGE_LAYOUT {
CHUNKED ( 10, 5 )
SIZE 385 (51.9%COMPRESSION)
}
FILTERS {
COMPRESSION DEFLATE { LEVEL 9 }
}
FILLVALUE {
FILL_TIME H5D_FILL_TIME_IFSET
VALUE 0
}
ALLOCATION_TIME {
H5D_ALLOC_TIME_INCR
}
}
}
tested: windows, linux, solaris
|
|
|
|
|
|
| |
after the first one. One variable that controls the binary output was incorrectly reset to zero after a binary output was done a first time. The effect was that on cases of several datasets, the ones after the first were not binary written. Eliminated the resetting of that variable and tested a file with several datasets. Modified the test file so that it is easier to test with the tool binread, that reads the binary output of h5dump.
tested: windows, linux
|
|
|
|
|
| |
formatted code
tested: windows, linux
|
|
|
|
|
|
| |
formatted code
bug fix: the 1.6 branch did not have a test for the existence of long double type on print_type (print name of datatype)
tested: windows, linux
|
|
|
|
| |
Tested: windows, linux
|
|
|
|
| |
Tested: windows, linux
|
|
|
|
| |
Tested: windows, linux
|
|
|
|
| |
Tested: windows, linux
|
|
|
|
|
|
| |
block selection
tested: linux
|
|
|
|
|
|
|
|
|
|
|
|
| |
#1072 in H5HF_man_iblock_size().
2. H5HFstat.c: Since H5HF_space_size() zeroed out fs_size, add "meta_size" to store
free-space size before adding to "heap_size".
3. h5stat_gentest.c: increase # of groups to get "h5stat_newgrat.h5" that contains
indirect block entries in fractal heap.
This is for testing the recursive part of the code in H5HF_man_iblock_size().
4. h5stat_newgrat.h5: the new .h5 file generated by h5stat_gentest.c.
5. h5stat_newgrat.ddl: expected output from new "h5stat_newgrat.h5".
|
|
|
|
|
|
| |
did not had nan logic for the cases of options -d and -p
tested: windows, linux
|
|
|
|
|
|
|
| |
Handle comparing datasets & attributes w/variable-length strings properly.
Tested on:
Linux/64 2.6.9 (chicago)
|
|
|
|
| |
tested: linux
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fread in windows needs a binary file to be open with "rb" instead of "r" otherwise it terminates execution if an end of file character is found on the input file. Besides that the binary file generated needs to be open with "wb" , otherwise an end of line character is read twice. DONE NOW for 1.8, already done previously for 1.6
renamed the h5import test files to have the extensions
text input files = .txt
binary input files = .bin
configuration files = .conf
hdf5 files = .h5
besides that in very test the files have the same name except extension.
For example
TOOLTEST txtin16.txt -c $srcdir/testfiles/txtin16.conf -o txtin16.h5
The convention for the test name is for example, for "txtin16"
"txt" for text then "in16" means integer 16 size
Tested: linux, solaris
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: IRIX64 failed to build tools/h5import, as well as c++/test
with szip. This is because IRIX is very picky when it comes
to linking libraries, and must be done in specific order.
(other UNIXes are not as such, and thus the problem wasn't
present).
Solution: Rearrange the order in which the libraries are
linked on the compiler line by sorting the line that
assigns libraries into the LDADD variable in the Makefile.am's
of the two respective directories.
Tested: IRIX64, kagiso, smirom
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add a check for block overlap after the command line parsing
* Algorithm
*
* In a inner loop, the parameters from SSET are translated into temporary
* variables so that 1 row is printed at a time (getting the coordinate indices
* at each row).
* We define the stride, count and block to be 1 in the row dimension to achieve
* this and advance until all points are printed.
* An outer loop for cases where dimensionality is greater than 2D is made.
* In each iteration, the 2D block is displayed in the inner loop. The remaining
* slower dimensions above the first 2 are incremented one at a time in the outer loop
*
* The element position is obtained from the matrix according to:
* Given an index I(z,y,x) its position from the beginning of an array
* of sizes A(size_z, size_y,size_x) is given by
* Position of I(z,y,x) = index_z * size_y * size_x
* + index_y * size_x
* + index_x
*
tested: windows, linux
|
|
|
|
|
|
|
|
| |
Correct the prototype for H5Sselect_elements() to take an 'hsize_t *' for
the coordinates, instead of 'hsize_t **'.
Tested on:
Mac OS X/32 10.5.1 (amazon)
|
|
|
|
|
|
| |
bug with size > 1
tested: linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change H5P[gs]et_format_bounds() => H5P[gs]et_libver_bounds() and also
enumerated values H5F_FORMAT_{EARLIEST, LATEST} => H5F_LIBVER_{EARLIEST, LATEST}
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.4.10 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
|
|
| |
modified the 3D test case for subsetting with block and stride factors
tested: windows, linux
|
|
|
|
|
|
|
| |
modified the 2D test case for subsetting with block and stride factors
tested: windows, linux
|
| |
|
|
|
|
|
|
| |
modified the 1D test case for subsetting with block and stride factors
tested: windows, linux
|
|
|
|
|
|
|
| |
more progress on the block hyperslab bug, clean code
tested: windows, linux
|
|
|
|
| |
tested: windows, linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add work-around to allow reading files that were produced with a buggy
earlier version of the library, which could create objects with the wrong
object header message count. There is now a configure flag
"--enable-strict-format-checks" which triggers a failure on reading a file
with this sort of corruption (when enabled) and allows the object to be read
(when disabled). The default value for the "strict-format-checks" flag is
yes when the "debug" flag is enabled and no when the "debug" flag is disabled.
Note that if strict format checks are disabled (allowing objects with
this particular kind of corruption to be read) and the file is opened with
write access, the library will re-write the object header for the corrupt
object with the correct # of object header messages.
This closes bugzilla bug #1010.
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.4.10 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
| |
tested: windows, linux
|
| |
|
| |
|
|
|
|
|
|
| |
note: RFC at http://www.hdfgroup.uiuc.edu/RFC/HDF5/NaNs_and_HDF5/
tested: windows, linux, solaris
|
| |
|
|
|
|
| |
tested: windows, linux
|
|
|
|
|
|
|
|
| |
on the h5repack verify function
note: some sybols were made public
tested: windows, linux
|
|
|
|
|
|
| |
needed by h5repack
tested: windows, linux
|
|
|
|
|
|
| |
unused functions
tested: windows, linux
|
| |
|
|
|
|
|
|
| |
NOTE: szip client symbols were made public
Tested: windows, linux, solaris
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switched from "H5P[gs]et_latest_format" to "H5P[gs]et_format_bounds".
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.4.10 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|