| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
was that H5Tpack didn't act
correctly with nested compound datatype. This code is better.
Tested on smirom - simple change.
|
|
|
|
| |
tested: linux
|
|
|
|
|
|
|
|
| |
Switch from H5Tarray_create -> H5Tarray_create2 to avoid problem when
building with v16 APIs.
Tested on:
Eyeballed (5 min before daily tests... :-)
|
|
|
|
| |
Remove tools/h52jpeg from configure.in & run bin/reconfigure on kagiso
|
|
|
|
| |
tested: linux
|
|
|
|
|
|
|
|
| |
several types) for the test generator program and file
Implementation of transforming 2D datasets with integer and float classes to 8bit acceptable by the jpeg library.
tested: windows, linux
|
|
|
|
|
|
|
|
| |
The new size of the type in the
inner nest wasn't passed to the outer nest. This has been fixed.
Tested on kagiso, linew, smirom.
|
|
|
|
|
|
|
|
|
|
| |
Description:
On Windows, we manage dynamically-generated code through "post-build" steps in Visual Studio. However, the command for it wasn't checking to see if the code already existed, so it was re-generating in each build (and thus re-generating all dependencies). To overcome, we simply check if the source file exists before generating it.
Also, put all paths inside quotes so we can handle directory names with spaces.
Tested:
VS2005 on WinXP
|
|
|
|
|
|
|
|
| |
Description:
A typo in the project output file name was causing Intel Fortran 10.1 to crash. The output file was set to "$(OutDir)\hdf5_fortranddll.dll " (three trailing spaces). IVF 9.1 ignored this error and continued gracefully. However, IVF 10.1 would simply crash. With this fix, we can now build on IVF 10.1 (so far..)
Tested:
VS2008 w/ IVF 10.1 on WinXP
|
|
|
|
|
|
| |
other minor cleanup in fillval.c.
Tested: kagiso (parallel), smirom, linew
|
|
|
|
| |
of code)
|
| |
|
| |
|
|
|
|
|
|
| |
added a new test run for the shell script with image name specified
tested: windows, linux
|
|
|
|
| |
tested: windows, linux
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
The fillval test uses random input to test various fill cases. Certain boundary cases cause the test to fail, which produces sporadic errors on Windows. There is a bug filed for the issue here:
http://bugzilla.hdfgroup.uiuc.edu/show_bug.cgi?id=1155
We will disable the test until the bug is fixed.
Tested:
None, simply disabled.
|
| |
|
|
|
|
|
|
|
|
| |
Description:
Somehow, the ttsafedll project was setup to build by default in Visual Studio .NET project files. This causes build errors when the HDF5_EXT_PTHREAD variable isn't defined or the pthreads library path isn't setup. It should be disabled by default.
Tested:
VS.NET on WinXP
|
|
|
|
|
|
|
|
| |
Description:
Simply change the "infiles" to use new testfiles directory
Tested:
VS2005 on WinXP
|
|
|
|
|
|
| |
tools/h5copy/testfiles
tested: linux
|
|
|
|
|
|
|
|
| |
Description:
More syntax changes for testfiles directory. This updates Windows for the neccessary changes as well.
Tested:
VS2005 on WinXP
|
|
|
|
|
|
|
|
| |
Description:
More updates were made to the h5diff test script structure. Specifically, the printing of output and how files are found in the actual test. This brings the changes to Windows as well.
Tested:
VS2005 on WinXP
|
| |
|
|
|
|
|
|
| |
tools/h5repack/testfiles
tested: linux
|
|
|
|
|
|
|
|
|
|
|
|
| |
The name of the files are now given by its full name relative to $srcdir
To avoid the printing of the complete full path of the test file, that hides
all the other parameters for long paths, the printing of the command line
is done first in TESTING with the name only of the test file, not its full path
the printing in the expected output that had the file name was removed as well as 3 tests that tested error messages in which the file name was present
tested: linux (in 2 different build directories relative to $srcdir), solaris
|
|
|
|
|
|
|
|
| |
Description:
The testfiles for h5diff were moved the a new folder, and the general script was updated. This checkin makes the minor changes neccessary for Windows to use the new folder.
Tested:
VS2005 on WinXP
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
On Windows, certain users were having trouble with the "ohdr" test, which does some processing on object header messages. The errors were hard to reproduce on our machines, and we eventually determined that the errors were timezone-specific.
The bug is triggered on Windows when processing timestamps very near the "Epoch" (midnight on 1/1/1970)-- the mktime() function does some automatic adjustment on the time to correct for timezones. In the USA, the correction adds a few hours; in Europe, it subtracts, thus giving us times pre-Epoch.
This only affects Windows because the Windows mktime() function cannot handle times before 1970-- other systems seemingly can.
The fix is to simply create timestamps only as early as 01/02/1970. This way, any timezone adjustment will still be post-Epoch.
This bug only affects the ohdr test, and shouldn't be a problem in the library. The earliest timestamps that will actually be read will be around the time HDF5 was created (~1996-7, per Quincey).
Tested:
VS2005 on WinXP
h5committest (kagiso, linew, smirom)
|
|
|
|
|
|
| |
Moved all h5diff testfiles from /tools/testfiles to tools/h5diff/testfiles
Tested: linux, solaris
|
|
|
|
|
| |
Added the function h5tget_native_type and associated
requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Small clean up of datatype copying.
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
|
|
| |
file for each HDF5 image
tested: windows, linux
|
|
|
|
|
|
|
| |
Clean up a few more compiler warnings.
Tested on:
FreeBSD/64 6.2 (liberty)
|
| |
|
|
|
|
|
|
|
|
| |
/tools/h52jpeg/testfiles
updated the shell script accordingly
tested: linux
|
| |
|
|
|
|
|
|
|
| |
for now, the test script just calls the tool binary with the command line parameters, with no special
checking of the accuracy of the output contents (jpeg files)
tested: linux
|
| |
|
|
|
|
|
|
|
|
| |
images from ASCII files, a true color and a gray color image
the HDF5 file generated is used by h52jpeg to generate jpeg images
tested: windows
|
|
|
|
|
|
| |
for now, just added "-ljpeg" to the list of libraries, until a permanent solution is added to configure --with-jpeg= that would allow users to specify their own jpeg libary
tested: linux (kagiso, that has a jpeg library installed)
|
| |
|
|
|
|
|
|
|
| |
Fix gcc 4.2 flag that was put in gcc 4.1 section
Tested on:
Eyeballed & man pages
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the gcc flags for version 4.3
Clean up warnings
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a "HDcompile_assert" macro for assertions that can/should be checked
at compile time, as opposed to run time. (And used it for a couple of simple
cases, to begin)
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
| |
tested: windows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid leaking memory when copying the internal "shared" struct for
a named datatype when it's already been opened earlier.
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
|
|
|
|
| |
issues surrounding
its location and its dependencies are worked out.
Tested: kagiso
|
| |
|
|
|
|
|
|
| |
unix systems
tested: linux, solaris
|
|
|
|
|
|
|
|
|
|
| |
Description:
As part of our Windows cleanup, we try to remove windows-specific tweaks in the source code. There are many instances where Windows code is introduces via ifdef's. We re-evaluate whether they are still required, and found that many of them are not. Others we change to "feature"-specific code, rather than Windows-specific.
Tested:
VS2005 on WinXP
VS.NET on WinXP
h5committest (kagisopp, smirom, linew)
|
| |
|