2010/5/24 Christoph Gohlke <cgoh...@uci.edu>
> 2.- In order to load DLLs, PyTables uses a the `LoadLibrary` function to
>> check whether the DLL is available or not (see `getLibrary` function in
>> src/utils.c for details). Perhaps `LoadLibrary` Win call does not work
>> the same in Python 64/Win 64?
>>
>
>
>
> Thanks for the hint. Turns out that the 64 bit DLL name is "libbz2" on my
> system, while utilsExtension.pyx hard-codes the name "bzip2". Also, while
> "import tables._comp_lzo" succeeds, LoadLibrary("lzo2") does not because the
> Python\Lib\site-packages\tables directory, where I place the DLLs, is not in
> the system path. Easy to fix...
Great. But I don't know why LZO DLL is not searched by default in
Python\Lib\site-packages\tables as this path should be searched by default
by the Python interpreter. Or perhaps this is valid only for extensions
(.pyd) and not DLLs (.dll)?
> I ran examples/table1.py with no compression, zlib, lzo, blosc, and bzip2
> just fine.
>
This means that zlib (or any other compression library) is not the problem.
I have recompiled everything using the following version, but the tests
> still fail as before. Zlib shows as version 1.2.3 (that's what Python is
> using internally) event though I am now linking against 1.2.5.
>
Do not pay too much attention to the Zlib version stated by
tables.print_versions(). As HDF5 does not allow to query the version of
their compression libraries, print_versions() only prints the zlib version
available via the Python interpreter. Mmh, this is misleading, and perhaps
it would be better if I remove this info (I've added a ticket about this:
http://www.pytables.org/trac/ticket/277).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> PyTables version: 2.2rc1
> HDF5 version: 1.8.5-pre1
> NumPy version: 2.0.0.dev8426
>
> Numexpr version: 1.3.1 (not using Intel's VML/MKL)
> Zlib version: 1.2.3
> LZO version: 2.03 (Apr 30 2008)
> BZIP2 version: 1.0.5 (10-Dec-2007)
>
> Blosc version: 0.9.0 (2010-05-04)
> Python version: 2.7b2 (r27b2:81019, May 9 2010, 10:33:25) [MSC v.1500
> 64 bit (AMD64)]
> Byte-ordering: little
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> The following examples fail/crash:
>
> array1.py
>
Hey, array1.py does not use compression at all, so compression is definitely
not the issue. Moreover, it is small enough to allow a guess on what is
failing. With the next stripped out version or array1.py:
"""
from numpy import *
from tables import *
fileh = openFile("array1.h5", mode = "w")
# Get the root group
root = fileh.root
# Create an Array
a = array([-1, 2, 4], int16)
# Save it on the HDF5 file
hdfarray = fileh.createArray(root, 'array_1', a, "Signed short array")
# Create a scalar Array
a = array(4, int16)
# Save it on the HDF5 file
hdfarray = fileh.createArray(root, 'array_s', a, "Scalar signed short
array")
# Create a 3-d array of floats
a = arange(120, dtype=float64).reshape(20,3,2)
# Save it on the HDF5 file
hdfarray = fileh.createArray(root, 'array_f', a, "3-D float array")
# Close the file
fileh.close()
"""
could you try to comment out ``createArray()`` lines until it works well?
Knowing the which line triggers the error would put us into the good track
(I suspect of internal handling of ints, but let's see).
--
Francesc Alted
------------------------------------------------------------------------------
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users
