Menu
▾
▴
pytables-users — PyTables users discussion list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(2) |
Mar
|
Apr
(5) |
May
(11) |
Jun
(7) |
Jul
(18) |
Aug
(5) |
Sep
(15) |
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(5) |
Apr
(8) |
May
(8) |
Jun
(10) |
Jul
(4) |
Aug
(4) |
Sep
(20) |
Oct
(11) |
Nov
(31) |
Dec
(41) |
| 2005 |
Jan
(79) |
Feb
(22) |
Mar
(14) |
Apr
(17) |
May
(35) |
Jun
(24) |
Jul
(26) |
Aug
(9) |
Sep
(57) |
Oct
(64) |
Nov
(25) |
Dec
(37) |
| 2006 |
Jan
(76) |
Feb
(24) |
Mar
(79) |
Apr
(44) |
May
(33) |
Jun
(12) |
Jul
(15) |
Aug
(40) |
Sep
(17) |
Oct
(21) |
Nov
(46) |
Dec
(23) |
| 2007 |
Jan
(18) |
Feb
(25) |
Mar
(41) |
Apr
(66) |
May
(18) |
Jun
(29) |
Jul
(40) |
Aug
(32) |
Sep
(34) |
Oct
(17) |
Nov
(46) |
Dec
(17) |
| 2008 |
Jan
(17) |
Feb
(42) |
Mar
(23) |
Apr
(11) |
May
(65) |
Jun
(28) |
Jul
(28) |
Aug
(16) |
Sep
(24) |
Oct
(33) |
Nov
(16) |
Dec
(5) |
| 2009 |
Jan
(19) |
Feb
(25) |
Mar
(11) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(61) |
Aug
(20) |
Sep
(61) |
Oct
(11) |
Nov
(14) |
Dec
(53) |
| 2010 |
Jan
(17) |
Feb
(31) |
Mar
(39) |
Apr
(43) |
May
(49) |
Jun
(47) |
Jul
(35) |
Aug
(58) |
Sep
(55) |
Oct
(91) |
Nov
(77) |
Dec
(63) |
| 2011 |
Jan
(50) |
Feb
(30) |
Mar
(67) |
Apr
(31) |
May
(17) |
Jun
(83) |
Jul
(17) |
Aug
(33) |
Sep
(35) |
Oct
(19) |
Nov
(29) |
Dec
(26) |
| 2012 |
Jan
(53) |
Feb
(22) |
Mar
(118) |
Apr
(45) |
May
(28) |
Jun
(71) |
Jul
(87) |
Aug
(55) |
Sep
(30) |
Oct
(73) |
Nov
(41) |
Dec
(28) |
| 2013 |
Jan
(19) |
Feb
(30) |
Mar
(14) |
Apr
(63) |
May
(20) |
Jun
(59) |
Jul
(40) |
Aug
(33) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: dragan s. <sav...@ya...> - 2005-04-24 15:59:09
|
Hello! I use ns2 for simulating packet switches. I have dificulties with efficient storage and retrival of simulation data, therefore I would like to use Pytables for this tasks. A table is typically the result of a simulation run. When more runs are done, each run has normally different values for one of parameters. In my case I have for example three parameters: switch size, buffer size and load. I would like to have tables as elements of an N dimensional array, where each parameter represents a different dimension, and the number of possible values of that parameter is the size of the array along that dimension. Each dimension should have a scalar or a string type. Is this possible to achieve with Pytables? Thank you! Best regards, Dragan. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Francesc A. <fa...@ca...> - 2005-04-22 17:52:29
|
Hi Norm, Please, don't be afraid to write to the PyTables list, as your problems can provide hints and feedback for other people; also, others can help you as well. After all, this tries to be an open community ;) I've tried your test script (ShowLeak.py), and it seems like you have discovered a real leak. I think the problem arises when you are filling several tables that have plenty of columns (in your case 256/table). At first sight, I suspect that this can be a problem with HDF5 1.6.x series. It would be nice to check out with HDF5 1.7.x but, unfortunately, PyTables does not support the 1.7.x series right-of-the-box (although it is relatively easy to realize the necessary changes in PyTables to do that, so you can have a try if you want to). Meanwhile, what you can do is to group columns with equal type under a multidimensional column, so that you can create Tables with much less number of columns. As an example, I've modified your script (ShowLeak2.py) to use these multidimensional columns. With that, you have 10 tables with just 1 column each instead of 10 tables with 256 columns each. Using this new structure, the resulting code does not leak (or at least, I cannot detect it). Hope this helps, A Divendres 22 Abril 2005 16:45, v=E0reu escriure: > Hi Francesc, > > At the risk of bothering you further, it seems that Python (2.3.x) > gc.get_objects() crashes PyTables. I was curious about gc objects > before and after garbage collection, but the following error occurs > after one iteration of the script I sent you yesterday (modified to > import gc and do a gc.set_debug(gc.DEBUG_LEAK) before the iteration is > performed). Maybe this is a clue? > > < --- snip --- > > 11978057371, 'Tag1022': 0.34435703147292973, 'Tag1023': > 0.49131899838928439}, 'C > omplexCol': <class tables.IsDescription.ComplexCol at 0x010540F0>, > 'UInt64Col': > <class tables.IsDescription.UInt64Col at 0x0104CF30>, 'UInt8Atom': > <class tables > .VLArray.UInt8Atom at 0x01054300>, 'myrows': [Traceback (most recent > call last): > > File "C:\ShowLeak.py", line 53, in ? > print gc.get_objects() > File "hdf5Extension.pyx", line 2516, in hdf5Extension.Row.__repr__ > File "hdf5Extension.pyx", line 2510, in hdf5Extension.Row.__str__ > TypeError: unsubscriptable object > > I then tried calling gc.collect() before looking at gc.get_objects(), > and what flashes before my eyes *is* different. It looks like > gc.collect() succeeds in collecting all the "array" objects, but a whole > lot of what seem like rows are still in the snipped output before the > error above occurs again. > > One more thing, I ran my script on my Debian (unstable) system after > installing the latest python-tables package today, and it's up to 67MB > just in the past hour or so, so we are consistent across Win32, Cygwin, > and Linux... > > Thanks for your attention, > > Norm > > PS: Please let me know if you'd prefer I just post to the list. =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Francesc A. <fa...@ca...> - 2005-04-21 16:30:21
|
Hi Norm, Ivan and I are glad that you like PyTables. As far as I know, PyTables is relatively free of leaks. There is an issue, though, that exposes when using indexed columns in tables. This is due to a leak in the HDF5 library (I've checked that it exists in HDF5 1.6.2, 1.6.3 and 1.6.4), that has been reported to the NCSA. They claim that this issue will be fixed in the next series of HDF5 1.8.x and I've checked that this is true, because in the developer versions of HDF5, i.e. 1.7.x, this leak seems to have disappeared. So, the thing is, if you are using indexing with PyTables, you have been hitten by a know leak. If you don't use indexing, I'd ask you to send me a small program that can reproduce the leak, so that I can check it more thoughtfully. Cheers, A Dijous 21 Abril 2005 17:23, Norm Petterson va escriure: > Hello all, > > I'm designing an industrial data logging application, and hope to use > PyTables as the data storage mechanism. Thanks, Francesc, Ivan, and > everybody else for such an attractive product. > > I have a question, though, about process memory usage with PyTables: > specifically, it appears that the virtual memory size of my Python > process increases constantly as I append rows to my tables, and never > decreases. Is this a feature or a leak? Does PyTables (and/or the > underlying HDF5 library) map the full table(s) into my process address > space at all times? Logging 2500 values per second (new rows to each of > 10 tables), my process virtual size is over 100MB in an hour, and I run > out of virtual memory before my expected 86400 rows per day are > accumulated. It appears to make some difference whether I open/close the > file each scan, or just leave it open (flushing after each row is > appended, of course); opening/closing seems to cause virtual size to > increase faster. > > I am running on Windows 2000, with HDF5 1.6.3 and PyTables 0.9.1, > although I see the same behavior under Cygwin with HDF5 1.6.4 and the > most-recent PyTables snapshot I downloaded and built yesterday. > > I'd appreciate anything you can tell me about memory usage (to save me > having to dig directly into the sources ;-) ... Thanks again for your > fine work. > > Regards, > > Norm Petterson > > > ------------------------------------------------------- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 adds new functionality designed to reduce time involved in > creating, integrating, and deploying reporting solutions. Free runtime > info, new features, or free trial, at: > http://www.businessobjects.com/devxi/728 > _______________________________________________ > Pytables-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pytables-users =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Norm P. <nj...@nj...> - 2005-04-21 15:24:55
|
Hello all, I'm designing an industrial data logging application, and hope to use PyTables as the data storage mechanism. Thanks, Francesc, Ivan, and everybody else for such an attractive product. I have a question, though, about process memory usage with PyTables: specifically, it appears that the virtual memory size of my Python process increases constantly as I append rows to my tables, and never decreases. Is this a feature or a leak? Does PyTables (and/or the underlying HDF5 library) map the full table(s) into my process address space at all times? Logging 2500 values per second (new rows to each of 10 tables), my process virtual size is over 100MB in an hour, and I run out of virtual memory before my expected 86400 rows per day are accumulated. It appears to make some difference whether I open/close the file each scan, or just leave it open (flushing after each row is appended, of course); opening/closing seems to cause virtual size to increase faster. I am running on Windows 2000, with HDF5 1.6.3 and PyTables 0.9.1, although I see the same behavior under Cygwin with HDF5 1.6.4 and the most-recent PyTables snapshot I downloaded and built yesterday. I'd appreciate anything you can tell me about memory usage (to save me having to dig directly into the sources ;-) ... Thanks again for your fine work. Regards, Norm Petterson |
|
From: <ho...@gl...> - 2005-04-20 14:45:20
|
Francesc Altet <fa...@ca...> writes: > BTW, your machive seems to be *very* fast ;) That's why we bought it ;) Thanks Berthold H=F6llmann --=20 Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: ho...@gl... Internet: http://www.gl-group.com |
|
From: Francesc A. <fa...@ca...> - 2005-04-20 14:28:30
|
A Dimecres 20 Abril 2005 16:05, Berthold H=F6llmann va escriure: > Now, I downloaded and installed pytables 20050420. Here are my results > on a 4 AMD Opteron(tm) Processor 850 machine with 8 GB: I think all of these errors are related with 64-bit platforms issues. I'll look into this more carefully as soon as I find some spare time. BTW, your machive seems to be *very* fast ;) Thanks! =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: <ho...@gl...> - 2005-04-20 14:05:39
|
Francesc Altet <fa...@ca...> writes: > Hello Berthold, > > PyTables 0.9.1 does not work with HDF5 1.6.4. You can workaround on > this in a couple of ways: > > 1.- Use HDF5 1.6.3 with PyTables 0.9.1. > > 2.- Use HDF5 1.6.4 with the current development version of PyTables > (1.0-alpha, well, almost beta :). You can fetch this development > version of PyTables from our tarballs of snapshots repository: > > http://www.carabos.com/downloads/pytables/snapshots/ > > In any case, would you mind reporting whether the tests passes or not > on your Opteron machine? Now, I downloaded and installed pytables 20050420. Here are my results on a 4 AMD Opteron(tm) Processor 850 machine with 8 GB: hoel@amur:test /usr/local/gltools/python/Python-2.4/linux_x86_64/bin/python= test_all.py=20=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D PyTables version: 1.0 (alpha) Extension version: $Id: hdf5Extension.pyx 769 2005-04-14 15:39:46Z ivilata = $=20 HDF5 version: 1.6.4 numarray version: 1.3.0 Zlib version: 1.2.1 BZIP2 version: 1.0.2 (30-Dec-2001) Python version: 2.4.1 (#1, Apr 14 2005, 14:25:40)=20 [GCC 3.3.3 (SuSE Linux)] Platform: linux2-x86_64 Byte-ordering: little -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D Performing only a light (yet comprehensive) subset of the test suite. If you have a big system and lots of CPU to waste and want to do a more complete test, try passing the --heavy flag to this script. The whole suite will take more than 10 minutes to complete on a relatively modern CPU and around 100 MB of main memory. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D Numeric (version 23.8) is present. Adding the Numeric test suite. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D /usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/site-packag= es/tables/Leaf.py:97: UserWarning: ucl compression library is not available= . Using zlib instead!. warnings.warn( \ /usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/site-packag= es/tables/Leaf.py:97: UserWarning: lzo compression library is not available= . Using zlib instead!. warnings.warn( \ ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ......................FF...................................................= ...........................................................................= ...........................................................................= ...........................................................................= ..............................F............................................= ...........................................................................= .........................EE..EE..EE..EE..EEE. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DOneTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DOneTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DTwoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DTwoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DThreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DThreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic2DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic2DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic10DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic10DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.GroupsArrayTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 304, i= n test00_iterativeGroups b =3D dset.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAIL: None (test_vlarray.SetRangeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_vlarray.py", line 2383, = in test04_start_stop assert allequal(row[1], concatenate([arange(9, type=3DInt32)*2+3,9])) AssertionError =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAIL: None (test_vlarray.SetRangeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_vlarray.py", line 2416, = in test05_start_stop assert allequal(row[1], concatenate([arange(9, type=3DInt32)*2+3,9])) AssertionError =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAIL: Comparing written 32-bit time data with read data in a VLArray. ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_timetype.py", line 259, = in test00_Compare32VLArray "Stored and retrieved values do not match.") AssertionError: Stored and retrieved values do not match. ---------------------------------------------------------------------- Ran 1845 tests in 84.024s FAILED (failures=3D3, errors=3D11) hoel@amur:test /usr/local/gltools/python/Python-2.4/linux_x86_64/bin/python= test_all.py --heavy -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D PyTables version: 1.0 (alpha) Extension version: $Id: hdf5Extension.pyx 769 2005-04-14 15:39:46Z ivilata = $=20 HDF5 version: 1.6.4 numarray version: 1.3.0 Zlib version: 1.2.1 BZIP2 version: 1.0.2 (30-Dec-2001) Python version: 2.4.1 (#1, Apr 14 2005, 14:25:40)=20 [GCC 3.3.3 (SuSE Linux)] Platform: linux2-x86_64 Byte-ordering: little -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D Performing the complete test suite! -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D Numeric (version 23.8) is present. Adding the Numeric test suite. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D /usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/site-packag= es/tables/Leaf.py:97: UserWarning: ucl compression library is not available= . Using zlib instead!. warnings.warn( \ /usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/site-packag= es/tables/Leaf.py:97: UserWarning: lzo compression library is not available= . Using zlib instead!. warnings.warn( \ ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= .......................Warning: Encountered invalid numeric result(s) in l= ess Warning: Encountered invalid numeric result(s) in greater Warning: Encountered invalid numeric result(s) in less_equal Warning: Encountered invalid numeric result(s) in greater_equal Warning: Encountered invalid numeric result(s) in less_equal Warning: Encountered invalid numeric result(s) in greater_equal ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ............................................Warning: Encountered invalid nu= meric result(s) in greater_equal Warning: Encountered invalid numeric result(s) in less_equal Warning: Encountered invalid numeric result(s) in greater_equal Warning: Encountered invalid numeric result(s) in less Warning: Encountered invalid numeric result(s) in greater Warning: Encountered invalid numeric result(s) in less_equal Warning: Encountered invalid numeric result(s) in greater Warning: Encountered invalid numeric result(s) in less ...Warning: Encountered invalid numeric result(s) in less Warning: Encountered invalid numeric result(s) in greater Warning: Encountered invalid numeric result(s) in less_equal Warning: Encountered invalid numeric result(s) in greater_equal Warning: Encountered invalid numeric result(s) in less_equal Warning: Encountered invalid numeric result(s) in greater_equal ...........................................................................= .......................................................................FF..= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ....F......................................................................= ..........................................................................E= E..EE..EE..EE..EEE. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DOneTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DOneTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DTwoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DTwoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DThreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic1DThreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic2DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic2DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic10DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 106, i= n test02_types self.WriteRead(a) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.Basic10DTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 123, i= n test03_types_nc self.WriteRead(b) File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 42, in= WriteRead b =3D self.root.somearray.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERROR: None (test_Numeric.GroupsArrayTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_Numeric.py", line 304, i= n test00_iterativeGroups b =3D dset.read() File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 612, in read return self._convToFlavor(arr) File "/usr/local/gltools/python/Python-2.4/linux_x86_64/lib/python2.4/sit= e-packages/tables/Array.py", line 547, in _convToFlavor typecode=3Darr.typecode()) ValueError: Invalid type for array =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAIL: None (test_vlarray.SetRangeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_vlarray.py", line 2383, = in test04_start_stop assert allequal(row[1], concatenate([arange(9, type=3DInt32)*2+3,9])) AssertionError =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAIL: None (test_vlarray.SetRangeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_vlarray.py", line 2416, = in test05_start_stop assert allequal(row[1], concatenate([arange(9, type=3DInt32)*2+3,9])) AssertionError =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAIL: Comparing written 32-bit time data with read data in a VLArray. ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/tmp/hoel/pytables-20050420/test/test_timetype.py", line 259, = in test00_Compare32VLArray "Stored and retrieved values do not match.") AssertionError: Stored and retrieved values do not match. ---------------------------------------------------------------------- Ran 2414 tests in 255.982s FAILED (failures=3D3, errors=3D11) Kind regards Berthold H=F6llmann --=20 Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: ho...@gl... Internet: http://www.gl-group.com |
|
From: Francesc A. <fa...@ca...> - 2005-04-20 13:05:06
|
Hello Berthold, PyTables 0.9.1 does not work with HDF5 1.6.4. You can workaround on this in a couple of ways: 1.- Use HDF5 1.6.3 with PyTables 0.9.1. 2.- Use HDF5 1.6.4 with the current development version of PyTables (1.0-alpha, well, almost beta :). You can fetch this development version of PyTables from our tarballs of snapshots repository: http://www.carabos.com/downloads/pytables/snapshots/ In any case, would you mind reporting whether the tests passes or not on your Opteron machine? Cheers, A Dimecres 20 Abril 2005 14:09, Berthold H=F6llmann va escriure: > I try to get pytables installed on a Quad Opteron server under SuSE > SLES 9. I compiled and installed HDF5 1.6.4, numarray 1.3.0, and > Numeric 23.8. Current pytables is from CVS (but I had similar problems > with 0.9.1. Installing pytables, changing to the test subdirectory and > running "python test_all.py" gives > > ---------------------------------------------------------------------- > Ran 1651 tests in 73.074s > > FAILED (failures=3D55, errors=3D10) > > as a result. I get lots of > > > HDF5-DIAG: Error detected in HDF5 library version: 1.6.4 thread 0. Back > trace follows. #000: H5Tnative.c line 118 in H5Tget_native_type(): cannot > retrieve native type major(01): Function arguments > minor(03): Inappropriate type > #001: H5Tnative.c line 218 in H5T_get_native_type(): bit field type is > not supported yet major(01): Function arguments > minor(03): Inappropriate type > Problems deleting records. > FHDF5-DIAG: Error detected in HDF5 library version: 1.6.4 thread 0. Back > trace follows. #000: H5Tnative.c line 118 in H5Tget_native_type(): cannot > retrieve native type major(01): Function arguments > minor(03): Inappropriate type > #001: H5Tnative.c line 218 in H5T_get_native_type(): bit field type is > not supported yet major(01): Function arguments > minor(03): Inappropriate type > Problems deleting records. > > messages. The last 2 error reports are > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: None (test_Numeric.Basic1DThreeTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line > 124, in test03_types_nc self.WriteRead(b) > File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line > 76, in WriteRead assert allequal(a,b, "Numeric") > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: None (test_Numeric.Basic2DTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line > 124, in test03_types_nc self.WriteRead(b) > File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line > 76, in WriteRead assert allequal(a,b, "Numeric") > AssertionError > > Is there a known problem, or do I have problems with my software > installation? > > Kind regards > > Berthold H=F6llmann =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: <ho...@gl...> - 2005-04-20 12:09:34
|
I try to get pytables installed on a Quad Opteron server under SuSE
SLES 9. I compiled and installed HDF5 1.6.4, numarray 1.3.0, and
Numeric 23.8. Current pytables is from CVS (but I had similar problems
with 0.9.1. Installing pytables, changing to the test subdirectory and
running "python test_all.py" gives=20
----------------------------------------------------------------------
Ran 1651 tests in 73.074s
FAILED (failures=3D55, errors=3D10)
as a result. I get lots of
HDF5-DIAG: Error detected in HDF5 library version: 1.6.4 thread 0. Back tr=
ace follows.
#000: H5Tnative.c line 118 in H5Tget_native_type(): cannot retrieve nativ=
e type
major(01): Function arguments
minor(03): Inappropriate type
#001: H5Tnative.c line 218 in H5T_get_native_type(): bit field type is no=
t supported yet
major(01): Function arguments
minor(03): Inappropriate type
Problems deleting records.
FHDF5-DIAG: Error detected in HDF5 library version: 1.6.4 thread 0. Back t=
race follows.
#000: H5Tnative.c line 118 in H5Tget_native_type(): cannot retrieve nativ=
e type
major(01): Function arguments
minor(03): Inappropriate type
#001: H5Tnative.c line 218 in H5T_get_native_type(): bit field type is no=
t supported yet
major(01): Function arguments
minor(03): Inappropriate type
Problems deleting records.
messages. The last 2 error reports are
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: None (test_Numeric.Basic1DThreeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line 12=
4, in test03_types_nc
self.WriteRead(b)
File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line 76=
, in WriteRead
assert allequal(a,b, "Numeric")
AssertionError
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: None (test_Numeric.Basic2DTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line 12=
4, in test03_types_nc
self.WriteRead(b)
File "/data/tmp/hoel/pytables_CVS_20050420/test/test_Numeric.py", line 76=
, in WriteRead
assert allequal(a,b, "Numeric")
AssertionError
Is there a known problem, or do I have problems with my software
installation?
Kind regards
Berthold H=F6llmann
--=20
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: ho...@gl...
Internet: http://www.gl-group.com
|
|
From: Francesc A. <fa...@ca...> - 2005-04-15 14:08:34
|
Hello Randy, I've tried the tutorial you sent to me and it works just fine. I'm guessing here (you didn't sent to me which a detailed report specifying platform and software versions that you are using), but I'd bet that the problem is the HDF5 version of your library. Only HDF5 1.6.x series is supported currently; the HDF5 1.7.x is for NCSA development purposes, and not intended for general use. So, please, try with HDF5-1.6.3 if you are using PyTables-0.9.1. If you are using the bleeding edge PyTables (http://www.carabos.com/downloads/pytables/snapshots/), you may want to try with HDF5-1.6.4 that is supported as well. Cheers, A Dijous 14 Abril 2005 20:42, Randy Heiland va escriure: > Hello, > > I heard your talk at SciPy last year and am just now getting around to > trying PyTables. For starters, I get the following error when doing the > 'table.flush()' in the tutorial (attached). Similarly, for example, in > /.../pytables/test/test_tree.py > > Any suggestions? > > thanks, Randy > > python 2.4/home/heiland/PyTables/pytables/test > hdf5-1.7.45 (yes, I caught the 1.7.x check in src/utils.c) > --------------------------- > > % python pytables-tut1-1.py > > -**-**-**-**-**-**- file creation -**-**-**-**-**-**-**- > Creating file: tutorial1.h5 > > -**-**-**-**-**-**- group an table creation -**-**-**-**-**-**-**- > Group '/detector' created > Table '/detector/readout' created > flushing... > python: H5Odtype.c:749: H5O_dtype_encode_helper: Assertion > `dt->shared->u.atomic.order =3D=3D H5T_ORDER_NONE' failed. > Abort =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Francesc A. <fa...@ca...> - 2005-04-12 18:40:12
|
Hi Michael, The errors were probably a consequence of a different behaviour in recent versions of numarray when creating arrays from buffer objects. Apparently it seems that multiple-segment buffer objects were never supported, but now numarray complains about that with an explicit message like: TypeError: single-segment buffer object expected instead of the old one: libnumarray.error: NA_updateDataPtr: error getting read buffer data ptr Anyway, the tests has been fixed (the code was not affected, I believe) in the SVN repository: http://www.carabos.com/downloads/pytables/snapshots/ Wait until tonight (UTC) if you want to get a PyTables version that passes all tests with a recent numarray version and with either Python 2.3 or Python 2.4 (at least all goes well on my Linux platform!). Cheers, A Divendres 08 Abril 2005 02:39, v=E0reu escriure: > OS: Mac OS X 10.3.8 > Python: 2.4 > Pytables: 0.9.1 > Numeric: 23.8 > > While installing pytables the following errors were detected: > > python test_Numeric.py -v > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ok > Data integrity during recovery (numerical types) ... ok > Data integrity during recovery (non-contiguous numerical types) ... ok > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ok > Data integrity during recovery (numerical types) ... ok > Data integrity during recovery (non-contiguous numerical types) ... ok > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ok > Data integrity during recovery (numerical types) ... FAIL > Data integrity during recovery (non-contiguous numerical types) ... FAIL > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ok > Data integrity during recovery (numerical types) ... FAIL > Data integrity during recovery (non-contiguous numerical types) ... FAIL > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ok > Data integrity during recovery (numerical types) ... FAIL > Data integrity during recovery (non-contiguous numerical types) ... FAIL > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ERR= OR > Data integrity during recovery (numerical types) ... FAIL > Data integrity during recovery (non-contiguous numerical types) ... FAIL > Data integrity during recovery (character objects) ... ok > Data integrity during recovery (non-contiguous character objects) ... ok > Data integrity during recovery (numerical types) ... FAIL > Data integrity during recovery (non-contiguous numerical types) ... FAIL > Checking combinations of arrays with groups ... FAIL > Checking creation of large rank arrays (0 < rank <=3D 32) ... ok > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ERROR: Data integrity during recovery (non-contiguous character objects) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 95, in test01_char_nc > self.WriteRead(b) > File "test_Numeric.py", line 46, in WriteRead > if not allequal(a,b, "Numeric") and verbose: > File ".../pytables-0.9.1/test/test_all.py", line 66, in allequal > if hasattr(b, "type") and a.type() <> b.type(): > AttributeError: 'CharArray' object has no attribute 'type' > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 105, in test02_types > self.WriteRead(a) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (non-contiguous numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 122, in test03_types_nc > self.WriteRead(b) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 105, in test02_types > self.WriteRead(a) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (non-contiguous numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 122, in test03_types_nc > self.WriteRead(b) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 105, in test02_types > self.WriteRead(a) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (non-contiguous numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 122, in test03_types_nc > self.WriteRead(b) > File "test_Numeric.py", line 74, in WriteRead > assert allequal(a,b, "Numeric") > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 105, in test02_types > self.WriteRead(a) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (non-contiguous numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 122, in test03_types_nc > self.WriteRead(b) > File "test_Numeric.py", line 74, in WriteRead > assert allequal(a,b, "Numeric") > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 105, in test02_types > self.WriteRead(a) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Data integrity during recovery (non-contiguous numerical types) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 122, in test03_types_nc > self.WriteRead(b) > File "test_Numeric.py", line 71, in WriteRead > assert a.typecode() =3D=3D b.typecode() > AssertionError > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FAIL: Checking combinations of arrays with groups > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_Numeric.py", line 325, in test00_iterativeGroups > assert a.typecode() =3D=3D b.typecode() > AssertionError > > ---------------------------------------------------------------------- > Ran 30 tests in 8.589s > > FAILED (failures=3D11, errors=3D1) =2D-=20 =46rancesc Altet |
|
From: Francesc A. <fa...@ca...> - 2005-04-12 09:32:06
|
Hi List, Ivan Vilata is working hard to implement Bzip2 (http://sources.redhat.com/bzip2/) and Szip (http://hdf.ncsa.uiuc.edu/doc_resource/SZIP/) support for PyTables. Bzip2 would be useful to achieve best compression ratios in data. Its compression/decompression speed is pretty slow, but nevertheless it can be rather useful for data archival. Szip can also achieve pretty good compression ratios, but it is not entirely free (you may need a license for using the Szip encodes for commertial aplications). We want to suport Szip mainly for HDF5 datafiles compatibility. Of course, we would like to do some benchmarks on these new compressors. We are planning to do an study also by using also the Shuffle filter (http://pytables.sourceforge.net/html-doc/x4273.html) as pre-conditioner. We think that it would be better if we can do this study using real-life data instead of synthetic data. So, if you are willing to offer some of your datafiles, please, do not hesitate to send them to us. We are looking for datafiles in the range of 1 MB ~ 100 MB. Of course, we would prefer that you can place them in a publicly accessible area instead of that you send us the data directly by e-mail. =46inally, the results of the study will be conveniently publicized so that any of you may take it to decide the best compressor/precontioner combination for your data. Thanks! =2D-=20 >qo< Francesc Altet =A0 =A0 http://www.carabos.com/ V =A0V C=E1rabos Coop. V. =A0=A0Enjoy Data "" |
|
From: <ho...@gl...> - 2005-03-24 11:56:23
|
Francesc Altet <fa...@ca...> writes: > Hi Berthold, > > I'm glad that you finally found the source of the problem. > > By the way, your original message has arrived a few minutes ago, but > with date of YESTERDAY. Other people in this list are seeing such > delays in the distribution list, or it's just me? If other people are > experiencing these (or other) problems, we will have to migrate this > list away from SF (which I'm afraid is becoming more and more loaded). For me it took about 25hours for the original mail to arrive back at me. The later mails appeared faster. Maybe some spam protection on the sourceforge side? Kind regards Berthold H=F6llmann --=20 Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: ho...@gl... Internet: http://www.gl-group.com This e-mail contains confidential information for the exclusive = attention of the intended addressee. Any access of third parties to this = e-mail is unauthorised. Any use of this e-mail by unintended recipients = such as copying, distribution, disclosure etc. is prohibited and may be = unlawful. When addressed to our clients the content of this e-mail is = subject to the General Terms and Conditions of GL's Group of Companies = applicable at the date of this e-mail.=20 GL's Group of Companies does not warrant and/or guarantee that this = message at the moment of receipt is authentic, correct and its = communication free of errors, interruption etc. |
|
From: Francesc A. <fa...@ca...> - 2005-03-23 16:45:51
|
Hi Berthold, I'm glad that you finally found the source of the problem. By the way, your original message has arrived a few minutes ago, but with date of YESTERDAY. Other people in this list are seeing such delays in the distribution list, or it's just me? If other people are experiencing these (or other) problems, we will have to migrate this list away from SF (which I'm afraid is becoming more and more loaded). Regards, A Dimecres 23 Mar=E7 2005 17:03, Berthold H=F6llmann va escriure: > Berthold H=F6llmann <ho...@gl...> writes: > > We are need to read the PyTables generated HDF5 files to be read by > > applications linked against HDF5 1.4.4, so we are still bound to > > PyTables 0.5.1. But I now have as serious problem with a generated > > file. Trying to read the dataset written by PyTables using a FORTRAN > > application I get: > > The Probelem was in my FORTRAN code. The array I was trying to read in > had the wrong dimension. I was confused by the HDF5 back trace. For me > it looked like a problem in the imput file. Sorry for disturbing you. > > Kind regards > > Berthold H=F6llmann =2D-=20 >qo< Francesc Altet =A0 =A0 http://www.carabos.com/ V =A0V C=E1rabos Coop. V. =A0=A0Enjoy Data "" |
|
From: <ho...@gl...> - 2005-03-23 16:03:41
|
Berthold H=F6llmann <ho...@gl...> writes: > We are need to read the PyTables generated HDF5 files to be read by > applications linked against HDF5 1.4.4, so we are still bound to > PyTables 0.5.1. But I now have as serious problem with a generated > file. Trying to read the dataset written by PyTables using a FORTRAN > application I get: The Probelem was in my FORTRAN code. The array I was trying to read in had the wrong dimension. I was confused by the HDF5 back trace. For me it looked like a problem in the imput file. Sorry for disturbing you. Kind regards Berthold H=F6llmann --=20 Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: ho...@gl... Internet: http://www.gl-group.com This e-mail contains confidential information for the exclusive = attention of the intended addressee. Any access of third parties to this = e-mail is unauthorised. Any use of this e-mail by unintended recipients = such as copying, distribution, disclosure etc. is prohibited and may be = unlawful. When addressed to our clients the content of this e-mail is = subject to the General Terms and Conditions of GL's Group of Companies = applicable at the date of this e-mail.=20 GL's Group of Companies does not warrant and/or guarantee that this = message at the moment of receipt is authentic, correct and its = communication free of errors, interruption etc. |
|
From: <ho...@gl...> - 2005-03-23 13:58:17
|
ho...@gl... (Berthold H=F6llmann) writes:
> We are need to read the PyTables generated HDF5 files to be read by
> applications linked against HDF5 1.4.4, so we are still bound to
> PyTables 0.5.1. But I now have as serious problem with a generated
> file. Trying to read the dataset written by PyTables using a FORTRAN
> application I get:
...
To reproduce my problem I have written a .h5 file using the following
lines:
import numarray as N
import tables
out =3D N.identity(749, typecode=3DN.Float)
HDF =3D tables.openFile("probe.h5", mode=3D"w", title=3D'test')
HDF.createArray(where=3D'/', name=3D'T', object=3Dout)
HDF.close()
I installed numarray-1.2.3 and pytables-0.9.1. Again, the generated
'probe.h5' gives strange results when viewed using h5dump. Is there
anyone else who can find the lines
...
(174,1441): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(174,1461): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(174,1481): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
(175,749): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(175,769): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(175,789): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
...
with the above example using h5dump?
Kind regards
Berthold H=F6llmann
--=20
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: ho...@gl...
Internet: http://www.gl-group.com
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail.=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.
|
|
From: <ho...@gl...> - 2005-03-22 14:55:10
|
We are need to read the PyTables generated HDF5 files to be read by
applications linked against HDF5 1.4.4, so we are still bound to
PyTables 0.5.1. But I now have as serious problem with a generated
file. Trying to read the dataset written by PyTables using a FORTRAN
application I get:
HDF5-DIAG: Error detected in HDF5 library version: 1.4.4 thread 0. Back =
trace follows.
#000: H5D.c line 716 in H5Dread(): can't read data
major(15): Dataset interface
minor(20): Read failed
#001: H5D.c line 1738 in H5D_read(): optimized read failed
major(15): Dataset interface
minor(20): Read failed
#002: H5Sall.c line 606 in H5S_all_read(): unable to read data from =
the file
major(05): Low-level I/O layer
minor(20): Read failed
#003: H5Farray.c line 317 in H5F_arr_read(): block read failed
major(05): Low-level I/O layer
minor(20): Read failed
#004: H5Fcontig.c line 166 in H5F_contig_read(): block read failed
major(05): Low-level I/O layer
minor(20): Read failed
#005: H5F.c line 2686 in H5F_block_read(): file read failed
major(05): Low-level I/O layer
minor(20): Read failed
#006: H5FD.c line 2354 in H5FD_read(): driver read request failed
major(22): Virtual File Layer
minor(24): Unable to initialize
#007: H5FDsec2.c line 603 in H5FD_sec2_read(): file read failed
major(05): Low-level I/O layer
minor(20): Read failed
Using=20
>h5dump --version
h5dump: Version 1.6.3
I get:
HDF5 "firstTest.h5" {
DATASET "/modal_motion_coefficients/T" {
DATATYPE H5T_IEEE_F64LE
DATASPACE SIMPLE { ( 749, 749 ) / ( 749, 749 ) }
DATA {
(0,0): 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0,
(0,22): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
...
(1,726): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(1,748): 0,
(2,0): 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0,
(2,22): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
...
(172,715): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(172,736): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
(173,0): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(173,22): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0,
...
(174,1450): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(174,1471): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(174,1492): 0, 0, 0, 0, 0, 0,
(175,749): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
(175,770): 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, =
0, 0,
...
So from line 174 on something seems to go totally wrong. Has anyone an
idea what's going wrong here?
Kind regards
Berthold H=F6llmann
--=20
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: ho...@gl...
Internet: http://www.gl-group.com
This e-mail contains confidential information for the exclusive =
attention of the intended addressee. Any access of third parties to this =
e-mail is unauthorised. Any use of this e-mail by unintended recipients =
such as copying, distribution, disclosure etc. is prohibited and may be =
unlawful. When addressed to our clients the content of this e-mail is =
subject to the General Terms and Conditions of GL's Group of Companies =
applicable at the date of this e-mail.=20
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.
|
|
From: Francesc A. <fa...@ca...> - 2005-03-18 18:22:17
|
A Divendres 18 Mar=E7 2005 18:34, Waldemar Osuch va escriure: > Yes I can confirm the issues have been fixed. > The latest sources from Mar 18 pass the tests OK. The errors caused > by test_do_undo.py during tearDown are gone. Excellent. > The --heavy switch triggers two failures but I am not sure if they > were there before. These turned out to be bugs in the test_indexes.py itself actually. The fix has been uploaded and should appear in the nightly tarball by tomorrow. Thanks for reporting this out and for thoughtfully testing PyTables on Windows platforms. Cheers, =2D-=20 >qo< Francesc Altet =A0 =A0 http://www.carabos.com/ V =A0V C=E1rabos Coop. V. =A0=A0Enjoy Data "" |
|
From: Waldemar O. <wal...@gm...> - 2005-03-18 17:35:13
|
On Thu, 17 Mar 2005 11:42:30 +0100, Ivan Vilata i Balaguer
<iv...@ca...> wrote:
> On Thu, Mar 17, 2005 at 10:10:47AM +0100, Ivan Vilata i Balaguer wrote:
> > [...]
> We think that the issue has been finally fixed.
[...]
Thanks for amazingly fast reponses.
Yes I can confirm the issues have been fixed.
The latest sources from Mar 18 pass the tests OK. The errors caused
by test_do_undo.py during tearDown are gone.
The --heavy switch triggers two failures but I am not sure if they
were there before.
C:\inbox\pytables\test>c:\python\python24\python.exe test_all.py --heavy
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PyTables version: 1.0 (alpha)
Extension version: $Id: hdf5Extension.pyx 736 2005-03-15 15:34:11Z ivilata $
HDF5 version: 1.6.3-patch
numarray version: 1.2.3
Zlib version: 1.2.1
Python version: 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]
Byte-ordering: little
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Performing the complete test suite!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Skipping Numeric test suite
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
C:\inbox\pytables\test\tables\Leaf.py:94: UserWarning: ucl compression library i
s not available. Using zlib instead!.
warnings.warn( \
C:\inbox\pytables\test\tables\Leaf.py:94: UserWarning: lzo compression library i
s not available. Using zlib instead!.
warnings.warn( \
[...]
======================================================================
FAIL: None (test_indexes.AI5TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\inbox\pytables\test\test_indexes.py", line 704, in test05_icounters
assert table.nrows == indexedrows
AssertionError
======================================================================
FAIL: None (test_indexes.AI6TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\inbox\pytables\test\test_indexes.py", line 704, in test05_icounters
assert table.nrows == indexedrows
AssertionError
----------------------------------------------------------------------
Ran 2276 tests in 315.784s
FAILED (failures=2)
|
|
From: Ivan V. i B. <iv...@ca...> - 2005-03-17 10:43:03
|
On Thu, Mar 17, 2005 at 10:10:47AM +0100, Ivan Vilata i Balaguer wrote: > [...] > Thank you! It seems that MSVC does not support 'inline' in plain C. > The attached version tries to use the compiler-specific keyword to > enable inlining for lround(). Could you please try this? We think that the issue has been finally fixed. You can find a version that will compile under MSVC by tomorrow at the downloads section in www.carabos.com. Thanks for your help! import disclaimer --=20 Ivan Vilata i Balaguer >qo< http://www.carabos.com/ C=E1rabos Coop. V. V V Enjoy Data "" |
|
From: Ivan V. i B. <iv...@ca...> - 2005-03-17 09:11:08
|
On Wed, Mar 16, 2005 at 05:24:51PM -0700, Waldemar Osuch wrote: > [...] > I am not a C programmer by any stretch of imagination so although your > explanation seems to make sense I can not comment :-). > Good news is that the patch almost worked. I had to tweak it a little > to appease the MS compiler. See attached. Thank you! It seems that MSVC does not support 'inline' in plain C. The attached version tries to use the compiler-specific keyword to enable inlining for lround(). Could you please try this? > > test_timetype.py run in isolation passes all 12 tests. > test_all.py is not so lucky. There is about 75 file permission errors > showing during tear down but it must be something silly. I will have > a look at it and report back. We are having a look at that problem, and it seems you're right. We will try to fix that in a moment. ;) import disclaimer -- Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data "" |
|
From: Waldemar O. <wal...@gm...> - 2005-03-17 00:25:02
|
On Wed, 16 Mar 2005 18:09:12 +0100, Ivan Vilata i Balaguer <iv...@ca...> wrote: > On Tue, Mar 15, 2005 at 02:40:37PM -0700, Waldemar Osuch wrote: > > Recently I have set up my machine for compiling pytables on WindowsXP > > with Python-2.4. > > [...] > > building 'tables.hdf5Extension' extension > > C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox > > /MD /W3 /GX /DNDEBUG -DWIN32=1 -DNDEBUG=1 -D_HDF5USEDLL_=1 -Ic:\gnu\src\hdf5\in > > clude -Ic:\python\python24\include -Ic:\python\python24\PC /Tcsrc/typeconv.c /Fo > > build\temp.win32-2.4\Release\src/typeconv.obj > > typeconv.c > > src\typeconv.c(45) : error C2036: 'void *' : unknown size > > src\typeconv.c(51) : warning C4013: 'lround' undefined; assuming > > extern returning int > > src\typeconv.c(62) : error C2036: 'void *' : unknown size > > error: command '"C:\Program Files\Microsoft Visual Studio .NET > > 2003\Vc7\bin\cl.exe"' failed with exit status 2 > > [..] > Thanks a lot for your mail. The pointer problems seem to be related > with the strange way MSVC has to do pointer arithmetic. The missing > 'lround' function is part of the C99 standard, which is not supported by > MSVC. > > I have attached a simple patch which makes pointer arithmetic in the MS > way and defines an 'lround' function if C99 is not supported. Could you > please apply it to src/typeconv.c and check whether it works? I am also > interested in checking that tests/test_timetype.py works right. > I am not a C programmer by any stretch of imagination so although your explanation seems to make sense I can not comment :-). Good news is that the patch almost worked. I had to tweak it a little to appease the MS compiler. See attached. test_timetype.py run in isolation passes all 12 tests. test_all.py is not so lucky. There is about 75 file permission errors showing during tear down but it must be something silly. I will have a look at it and report back. Waldemar |
|
From: Ivan V. i B. <iv...@ca...> - 2005-03-16 17:09:34
|
On Tue, Mar 15, 2005 at 02:40:37PM -0700, Waldemar Osuch wrote: > Recently I have set up my machine for compiling pytables on WindowsXP > with Python-2.4. > [...] > building 'tables.hdf5Extension' extension > C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox > /MD /W3 /GX /DNDEBUG -DWIN32=1 -DNDEBUG=1 -D_HDF5USEDLL_=1 -Ic:\gnu\src\hdf5\in > clude -Ic:\python\python24\include -Ic:\python\python24\PC /Tcsrc/typeconv.c /Fo > build\temp.win32-2.4\Release\src/typeconv.obj > typeconv.c > src\typeconv.c(45) : error C2036: 'void *' : unknown size > src\typeconv.c(51) : warning C4013: 'lround' undefined; assuming > extern returning int > src\typeconv.c(62) : error C2036: 'void *' : unknown size > error: command '"C:\Program Files\Microsoft Visual Studio .NET > 2003\Vc7\bin\cl.exe"' failed with exit status 2 > > I completely understand that pytables-latest is just a development > version and it can fail. > The only purpose of this email is to indicate that there is a potential problem. Thanks a lot for your mail. The pointer problems seem to be related with the strange way MSVC has to do pointer arithmetic. The missing 'lround' function is part of the C99 standard, which is not supported by MSVC. I have attached a simple patch which makes pointer arithmetic in the MS way and defines an 'lround' function if C99 is not supported. Could you please apply it to src/typeconv.c and check whether it works? I am also interested in checking that tests/test_timetype.py works right. Thanks a lot. import disclaimer -- Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data "" |
|
From: Waldemar O. <wal...@gm...> - 2005-03-15 21:41:15
|
Recently I have set up my machine for compiling pytables on WindowsXP with Python-2.4. To confirm that my environment is OK I have compiled pytables-0.9.1 and run test_all. The tests passed. Unfortunately when I have tried to compile pytables-latest from daily snapshots provided by Carabos they failed with: building 'tables.hdf5Extension' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32=1 -DNDEBUG=1 -D_HDF5USEDLL_=1 -Ic:\gnu\src\hdf5\in clude -Ic:\python\python24\include -Ic:\python\python24\PC /Tcsrc/typeconv.c /Fo build\temp.win32-2.4\Release\src/typeconv.obj typeconv.c src\typeconv.c(45) : error C2036: 'void *' : unknown size src\typeconv.c(51) : warning C4013: 'lround' undefined; assuming extern returning int src\typeconv.c(62) : error C2036: 'void *' : unknown size error: command '"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe"' failed with exit status 2 I completely understand that pytables-latest is just a development version and it can fail. The only purpose of this email is to indicate that there is a potential problem. Waldemar |
|
From: Ivan V. i B. <iv...@ca...> - 2005-03-01 13:11:31
|
On Sun, Feb 27, 2005 at 03:24:36AM -0500, travlr wrote: > Hi Francesc, >=20 > The reference for walkGroups() says:=20 > Iterator that returns the list of Groups (not Leaves) hanging from where. >=20 > From this description, the list returned should not include the "/" > group if that is what is labled for where. -->walkGroups(where=3D"/") Yes, you're right on that. In fact, the documentation for File.walkGroups() and Group._f_walkGroups() was fixed some time ago to reflect that detail. It will show up in PyTables 1.0. If you want to get the updated documentation, you can get a development snapshot from PyTables at http://www.carabos.com/downloads/pytables/snapshots . >=20 > The tutorial provides great & diverse examples of how to attain the > public attributes of the object tree, but does not express how into > instantiate the leaves, via iteration, so they can be used for numeric > processing. For instance I'm trying to loop through the groups hanging > from "root", to work with the arrays contained within. You might be interested in File.listNodes() and File.walkNodes(). The first lists direct children of a specific node. The second recurses into children to get all descendent nodes. >=20 > One version I've tried: >=20 > import tables as ta > f =3D ta.openFile('/H5/ESdat.h5','r') >=20 > for group in f.walkGroups(where=3D"/"): > g =3D eval("f.root."+group._v_name) # You can directly use 'group' here instead of 'g'. > ap =3D g.AP.read() > aS =3D g.AS.read() > p1 =3D g.P1.read() > v1 =3D g.V1.read() > a1 =3D g.A1.read() > ud =3D g.UD.read() >=20 > ... do some things... > f.close() >=20 > I've tried many possible ways to iterate through the file and > auto-magically perform tasks. A simple example of Group._f_listNodes(): # For every group which descends from '/' (including it). for group in f.walkGroups('/'): # For every leaf in that group. for leaf in group._f_listNodes(classname =3D 'Leaf'): print leaf._v_pathname, leaf.read() Hope this helps. Regards, Ivan import disclaimer --=20 Ivan Vilata i Balaguer >qo< http://www.carabos.com/ C=E1rabos Coop. V. V V Enjoy Data "" |
22 messages has been excluded from this view by a project administrator.
