Re: [Pytables-users] segmentation fault on Mac OS X Lion when running tables.test()
On Jun 19, 2012, at 4:37 AM, David Donovan wrote: Hi Anthony, Thanks for the response. Installed HDF5 1.8.9 using the following flags for configure. `./configure --prefix=/usr/local --with-szlib=/Library/Frameworks/Python.framework/Versions/Current CPPFLAGS=-I/Library/Frameworks/Python.framework/Versions/Current/include LDFLAGS=-L/Library/Frameworks/Python.framework/Versions/Current/lib` Also, I had to modify the optimization flag for gcc-4 in order to pass the make check part (as noted on the HDF5 page). `Conversion Tests fail on Mac OS X 10.7 (Lion) Users have reported that when building HDF5, the conversion tests failed (make check) in dt_arith.chk. A workaround is to edit ./ HDF5source /config/gnu-flags, search for PROD_CFLAGS under gcc-4.*, and change the value for PROD_CFLAGS to -O0.` Then: 'make' 'make check' 'sudo make install' Is there a better way? Is tables somehow having a hard time finding the HDF5 library do you think? Hi David, I always use homebrew for any of my prerequisites: http://mxcl.github.com/homebrew/ Cheers ~Josh Thanks! Best Regards, David On Sat, Jun 16, 2012 at 12:57 AM, Anthony Scopatz scop...@gmail.com wrote: Hi David, How did you build / install HDF5? Be Well Anthony On Fri, Jun 15, 2012 at 7:14 PM, David Donovan donov...@gmail.com wrote: Hi Everyone, I am having problems running the tests for PyTables on Mac OS X Lion. I have tried HDF5 version 1.8.5 as well, but I still get the same issue. Any thoughts would be helpful... Thanks for any help you can provide. Best Regards, David Donovan impPython 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin Type help, copyright, credits or license for more information. import tables table tables.test() -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PyTables version: 2.3.1 HDF5 version: 1.8.9 NumPy version: 1.7.0.dev-0c5f480 Numexpr version: 2.0.1 (not using Intel's VML/MKL) Zlib version: 1.2.5 (in Python interpreter) LZO version: 2.06 (Aug 12 2011) BZIP2 version: 1.0.6 (6-Sept-2010) Blosc version: 1.1.2 (2010-11-04) Cython version:0.16 Python version:2.7.1 (r271:86832, Jul 31 2011, 19:30:53) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] Platform: darwin-i386 Byte-ordering: little Detected cores:2 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Performing only a light (yet comprehensive) subset of the test suite. If you want a more complete test, try passing the --heavy flag to this script (or set the 'heavy' parameter in case you are using tables.test() call). The whole suite will take more than 4 hours to complete on a relatively modern CPU and around 512 MB of main memory. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .FSegmentation fault: 11 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] Mac Install Issue
On Feb 1, 2012, at 7:37 PM, Anthony Scopatz wrote: Hello All, Hi Tommasso, One of my collaborators (cc'd) has been trying to install PyTables on his MacBook. Everything compiles and installs just fine but there is and immediate issue on import with dynamic linking. However, I know very little about OS X development and it isn't readily apparent to me how to fix this problem. Anyone with more mac experience who knows how to fix this? Traceback below: Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. import tables Traceback (most recent call last): File stdin, line 1, in module File /Library/Python/2.6/site-packages/tables-2.3.1-py2.6- macosx-10.6-universal.egg/tables/__init__.py, line 59, in module from tables.utilsExtension import getPyTablesVersion, getHDF5Version ImportError: dlopen(/Library/Python/2.6/site-packages/tables-2.3.1- py2.6-macosx-10.6-universal.egg/tables/utilsExtension.so, 2): Symbol not found: _H5E_CALLBACK_g Referenced from: /Library/Python/2.6/site-packages/tables-2.3.1-py2.6- macosx-10.6-universal.egg/tables/utilsExtension.so Expected in: flat namespace in /Library/Python/2.6/site-packages/tables-2.3.1-py2.6- macosx-10.6-universal.egg/tables/utilsExtension.so Can you say a word or two about how you installed the pre-reqs as well as PyTables? Cheers, ~Josh. Be Well Anthony -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] Some experiences with PyTables
On Dec 6, 2011, at 11:06 PM, Anthony Scopatz wrote: ...snip... 5. The reference manual for numpy contains _many_ small examples. They partially compensate for any lack of precision or excessive precision in the documents. Also many people learn best from examples. If you would like to write up some additional example or contribute to the docs in any way *please* let me know. We would be ecstatic for your help! Anthony, do we have a place in the sphinx docs where cookbook-like examples could just be thrown in? If not, could you set one up? That way someone could push us a PR with just the modified file. ~J. PGP.sig Description: This is a digitally signed message part -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] adding column index hides data(?)
On Nov 18, 2011, at 6:29 PM, Alan Marchiori wrote: On Fri, Nov 18, 2011 at 9:21 AM, Josh Moore josh.mo...@gmx.de wrote: On Nov 17, 2011, at 10:35 PM, Alan Marchiori wrote: I am attempting to use PyTables (v2.3.1) to store timestamped data and things were going well until I added a column index. While the column is indexed no data is returned from a table.where call! I've reproduced with a number of different index configurations. If I change the column type to Float64, then the index works as expected. ... Josh, Thanks for confirming this. It would seem indexing is broken on Time64's (also the pytables unit tests do not catch this and unit tests should probably be added for all indexable Col datatypes and/or an error raised if you try to index on a non-indexable column). Switching to Float64 works (floating point time since epoch) I just have to ensure that gives sufficient precision for my data. Thanks, problem solved and hopefully can be better handled in the next release. Alan Hi Alan, I filed an issue on github: https://github.com/PyTables/PyTables/issues/119 Thanks for pointing this out! ~Josh. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] adding column index hides data(?)
On Nov 17, 2011, at 10:35 PM, Alan Marchiori wrote:
Hello,
Hi Alan,
I am attempting to use PyTables (v2.3.1) to store timestamped data and
things were going well until I added a column index. While the column
is indexed no data is returned from a table.where call!
This behavior is demonstrated with the following test code:
---begin test.py---
import tables
import random
class Descr(tables.IsDescription):
when = tables.Time64Col(pos = 1)
value = tables.Float32Col(pos = 2)
h5f = tables.openFile('/tmp/tmp.h5', 'w')
tbl = h5f.createTable('/', 'test', Descr)
tbl.cols.when.createIndex(_verbose = True)
t = 1321031471.0 # 11/11/11 11:11:11
tbl.append([(t + i, random.random()) for i in range(1000)])
tbl.flush()
def query(s):
print 'is_index =', tbl.cols.when.is_indexed
print [(row['when'], row['value']) for row in tbl.where(s)]
print tbl.readWhere(wherestr)
wherestr = '(when = %d) (when %d)'%(t, t+5)
query(wherestr)
tbl.cols.when.removeIndex()
query(wherestr)
h5f.close()
---end test.py---
This creates the table for storing time/value pairs, inserts some
synthetic data, and then checks to see if there is data in the table.
When the table is created there is an index added to the 'where'
column. The first query returns no data (which is incorrect). Then
the column index is removed (via table.removeIndex) and the query is
repeated. This time 5 results are returned as expected. The data is
clearly there however the index is somehow breaking the where logic.
Here is the output I get:
---begin output---
is_index = True
[]
[]
is_index = False
[(1321031471.0, 0.6449417471885681), (1321031472.0,
0.7889317274093628), (1321031473.0, 0.609708845615387), (1321031474.0,
0.9120397567749023), (1321031475.0, 0.2386845201253891)]
[(1321031471.0, 0.6449417471885681) (1321031472.0, 0.7889317274093628)
(1321031473.0, 0.609708845615387) (1321031474.0, 0.9120397567749023)
(1321031475.0, 0.2386845201253891)]
---end output---
Creating the index after the data has been inserted produces the same
behavior (no data is returned while the index exists). Any
suggestions would be greatly appreciated.
I've reproduced with a number of different index configurations. If I change
the column type to Float64, then the index works as expected.
BEFORE:
Initial index: verbose has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
remove indexhas_index= Falseuse_index=
frozenset([])where= 5readWhere= 5
re-add index (non-verbose) has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
remove againhas_index= Falseuse_index=
frozenset([])where= 5readWhere= 5
re-add index (with flush) has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
re-add index (full) has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
re-add index (ultralight) has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
re-add index (o=0) has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
re-add index (o=9) has_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
re-indexhas_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
also index valuehas_index= True use_index=
frozenset(['Awhen'])where= 0readWhere= 0
AFTER:
Initial index: verbose has_index= True use_index=
frozenset(['Awhen'])where= 5readWhere= 5
remove indexhas_index= Falseuse_index=
frozenset([])where= 5readWhere= 5
re-add index (non-verbose) has_index= True use_index=
frozenset(['Awhen'])where= 5readWhere= 5
remove againhas_index= Falseuse_index=
frozenset([])where= 5readWhere= 5
re-add index (with flush) has_index= True use_index=
frozenset(['Awhen'])where= 5readWhere= 5
re-add index (full) has_index= True use_index=
frozenset(['Awhen'])where= 5readWhere= 5
re-add index (ultralight) has_index= True use_index=
frozenset(['Awhen'])where= 5readWhere= 5
re-add index (o=0) has_index= True use_index=
frozenset(['Awhen'])where= 5readWhere= 5
re-add index (o=9) has_index= True use_index=
[Pytables-users] Next versions and git branches
All, there's been some back-and-forth on the developers' list[1] regarding what the next few PyTables versions should look like. A bug fix (2.3.1) will be released in the next week or so to correct a minor build issue which crept into 2.3.0. (As always, our apologies!) After that, 2.3 will remain largely bug-fixes-only since it's largely just the continuation of PyTables 2.2 with the addition of the caching/indexing code. Then, there are are two groups of changes which are on the horizon. The first group are largish fixes of issues raised perhaps some time ago which do *not* require upgrading your Python version[2]. The other group are those changes to add Python3 support to PyTables[3]. For the moment, we'll keep changes of each of these types separate (see technical details below) so that if there's enough interest in a PyTables 2.4 and we can't support Python3 without dropping Python 2.4 2.5 support, then we'll push out a PyTables 2.4. Otherwise, everything will be rolled together in one large super PyTables 3. Feedback (to the mailing list or privately) on which projects / individuals may still need or want Python 2.4 and 2.5 support is *very* welcome. Also, if there's anything else you want to see take priority, speak up; again here, via private email, or add an issue to github[4]. (Technical details follow) In order to keep track of the various branches of work, we're planning on organizing the git repository[5] based on the git-flow[6] scheme. The master branch will be considered stable and will have all released versions merged into it, starting with v.2.3.0. The develop branch will contain the ongoing more or less stable work. This would include the first group of fixes from above, which would become PyTables 2.4 if it materializes. Then there will be one or more branches (e.g. feature/py3k) with more breaking changes which will be merged in when it becomes time to release PyTables 3.0. If you are interested in more of these technical details, please add yourself to the pytables-dev mailing list[7]. We'll try to keep the distractions on pytables-users to a minimum. Many thanks! ~Josh Moore [1]: https://groups.google.com/group/pytables-dev/msg/2e0003aba7ca364c [2]: https://github.com/PyTables/PyTables/issues?milestone=3state=open [3]: https://github.com/PyTables/PyTables/issues?milestone=4state=open [4]: https://github.com/PyTables/PyTables/issues [5]: https://github.com/PyTables/PyTables [6]: https://github.com/nvie/gitflow [7]: https://groups.google.com/group/pytables-dev PGP.sig Description: This is a digitally signed message part -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
[Pytables-users] IRC meeting now.
Just a quick heads up in case anyone still wants to attend the IRC meeting, since we're about to start in 3...2...1... #PyTables @ irc.freenode.net Cheers, ~Josh. PGP.sig Description: This is a digitally signed message part -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] 2.3 release and governance
On Aug 27, 2011, at 8:56 PM, Anthony Scopatz wrote: On Sat, Aug 27, 2011 at 3:20 AM, Francesc Alted fal...@pytables.org wrote: 2011/8/26 Antonio Valentino antonio.valent...@tiscali.it I agree, governance issues should be hammered out before v2.3 +1 IMHO the Governance milestone is not really blocking for 2.3. Anyway it is OK for me closing governance first. I agree that it is a non-blocker, it can be a least a good thing in order to be able to include some news about the Governance team in the 2.3 announcement. I'm really sorry but my english is not good enough for a voice meeting but I don't want to be an impediment, so please feel free to choice the meeting type you prefer I'd say that I'm not really comfortable with a pure english spoken meeting either. I think the best would be to restrict ourselves to a written chat meeting. Also, it is easier to keep the logs of a written chat than a spoken one. +1 Also, most of you seem to be in Europe, which will make it difficult for me to participate, hopefully I'll be able to join in. Looking at the doodle 10PM CEST looks to be the consensus. I've setup a #PyTables IRC channel on irc.freenode.net. I'll look into having a MeetBot (http://wiki.debian.org/MeetBot) available, which we can choose to use or not. See you then, ~Josh. -- Francesc Alted PGP.sig Description: This is a digitally signed message part -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] 2.3 release and governance
I've created a doodle (also linked from the meeting ticket[6]) for confirming the time: http://www.doodle.com/tr8gyg699uiyhn3g If anyone would like to add a time slot, please let me know. Where possible, use your github name for your slots. Cheers, ~Josh. [6] https://github.com/PyTables/PyTables/issues/6 On Aug 23, 2011, at 8:25 PM, Francesc Alted wrote: 2011/8/23 Anthony Scopatz ascop...@enthought.com On Tue, Aug 23, 2011 at 1:46 AM, Josh Moore josh.mo...@gmx.de wrote: Hi Anthony, I don't know of a timeline yet, though it'd be great to get one hammered out. I can see an argument for getting all of the governance issues out of the way before we set that timeline, since the method by which we vote etc. would need to be determined. On the other hand, people are waiting for 2.3. I agree, governance issues should be hammered out before v2.3 +1 Maybe we could try to have a voice/IRC meet-up ( https://github.com/PyTables/PyTables/issues/6) first to work these things out? A voice or IRC meeting is a great idea. We should probably try to do these once every 3 months or so. I'll do my best to join you for the voice/IRC meeting. I could be of some help, one never knows ;) -- Francesc Alted :) ~J. PGP.sig Description: This is a digitally signed message part -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] 2.3 release and governance
Hi Anthony, I don't know of a timeline yet, though it'd be great to get one hammered out. I can see an argument for getting all of the governance issues out of the way before we set that timeline, since the method by which we vote etc. would need to be determined. On the other hand, people are waiting for 2.3. Maybe we could try to have a voice/IRC meet-up (https://github.com/PyTables/PyTables/issues/6) first to work these things out? Cheers, ~Josh On Aug 23, 2011, at 4:34 AM, Anthony Scopatz wrote: [thread hijack] Everyone else, Do we have a timeline for a release? Are we trying to release the Governance or the 2.3 Milestone or both? It would be nice if we could split up the remaining tickets somehow... Be Well Anthony PGP.sig Description: This is a digitally signed message part -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] 2.3 roadmap (proposal)
On Aug 6, 2011, at 9:42 AM, Antonio Valentino wrote: Hi Anthony, hi Josh, Il 06/08/2011 03:01, Anthony Scopatz ha scritto: Hello All, On Fri, Aug 5, 2011 at 2:51 PM, Josh Moore josh.mo...@gmx.de wrote: Chiming in late Also chiming in late. Oh, sorry guys if I left few time to respond. No worries. We're still pre-release. :) On Aug 4, 2011, at 10:17 AM, Antonio Valentino wrote: Hi list, hi developers, [CUT] All sounds fine. I'll certainly test on my Mac 10.6, and can do so in a virtual environment depending on what kind of coverage there is. Thank you Josh. I can perform tests on linux (64 bit) and, with a little ore effort, on Mac. No windows until September and, in any case, only win XP. Next week, I'll try to confirm access to Server 2003 and 2008, as well as various Linux flavors. It would be nice to have a wiki page (maybe Dev/Test) to track all test performed on the current development branch including details on the platform, library versions and so on. What do you think about? Definitely. As a part of DevPolicy maybe? [CUT] Cheers, ~Josh. P.S. Do we want to rename/close/merge the 2.3b1 milestone? https://github.com/PyTables/PyTables/issues?milestone=1state=open Maybe we could rename it. No idea about the new title, maybe something related to project organization. Changed to Governance. Also IMHO #4 can be closed (please check) and I would move #5 to milestone 2.3. [#4] https://github.com/PyTables/PyTables/issues/4 Closed, with link to your email thread. [#5] https://github.com/PyTables/PyTables/issues/5 Moved. Best regards Antonio Valentino Cheers, ~Josh. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] 2.3 roadmap (proposal)
Chiming in late On Aug 4, 2011, at 10:17 AM, Antonio Valentino wrote: Hi list, hi developers, it seems to me that the PyTables development is a little stalled at the moment. Certainly no thanks to the summer lull. Thanks for giving us a kick! I think that it is important to have PyTables 2.3 as soon as possible. Some job has already been done and new features coming from the PyTables Pro IMHO justify a new release. So my proposal is to: * merge the pro_liberation branch #1 * leave out, for the moment, advanced packaging #70 and #71 (unless anyone has already the job done). The debian directory sould be removed from the master branch IMHO. * proceed with deprecations #68 and #76 * merge all the work already done (#66, #77 TBC, ...) * perform some testing with numpy 1.6.1 * update docs for release * beta release * full test on all platforms * final release All sounds fine. I'll certainly test on my Mac 10.6, and can do so in a virtual environment depending on what kind of coverage there is. I think I have addressed issues #66, #68 and #77 in branches on my personal fork (https://github.com/avalentino/PyTables). It is only needed review and merge. You're going faster than I can review, which is great. I've pushed a few minor fixes, but otherwise all looks fine. I'm going to start working on #76. Job on #1 is almost complete. IMHO pro_liberation branch is ready for merge even if XSL stylesheets still need some cleanup (see #1). Unfortunately I don't know XSL enough to put my hands in. I can take on stripping out the XSL, but as all comments on that issue have said, it's not a priority. OK, any feedback is welcome and, most of all, I would appreciate a lot an OK from someone before starting to merge the various changes. [#1] https://github.com/PyTables/PyTables/issues/1 [#66] https://github.com/PyTables/PyTables/issues/66 [#68] https://github.com/PyTables/PyTables/issues/68 [#70] https://github.com/PyTables/PyTables/issues/70 [#71] https://github.com/PyTables/PyTables/issues/71 [#76] https://github.com/PyTables/PyTables/issues/76 Added comment about deprecation warning. [#77] https://github.com/PyTables/PyTables/issues/77 One other small thing which is mostly noticeable thanks to git's whitespace highlighting is that ^M line endings are creeping in. Finally, I'm going through https://github.com/PyTables/PyTables/wiki/ReleaseProcedure now, but am fumbling a bit with XSL on Mac (https://github.com/PyTables/PyTables/issues/82). Nothing major. best regards Antonio Valentino Cheers, ~Josh. P.S. Do we want to rename/close/merge the 2.3b1 milestone? https://github.com/PyTables/PyTables/issues?milestone=1state=open PGP.sig Description: This is a digitally signed message part -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] PyTables 2.3beta in EDP 7.1
Does anyone know where/how they build? Should we push all the more to merge into master now? ~Josh On Jul 8, 2011, at 6:33 PM, Antonio Valentino wrote: Hi list, PyTables 2.3beta has been included in in EDP 7.1. http://www.enthought.com/products/changelog.php nice! ciao -- Antonio Valentino -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] Create new Atom Class
Hi Mike,
you'll need to add your new classes to the __all__ list in tables/__init__.py
to have them appear via from tables import *. They are available via import
tables since tables/__init__.py imports everything from tables/atom.py with
the line from tables.atom import *.
However, there will be other changes that you will need to make. What do you
think about forking https://github.com/PyTables/PyTables and applying your
changes so we can take a look? One next place will be AtomToHDF5Type which does
not handle your link kind:
def AtomToHDF5Type(atom, char *byteorder):
cdef hid_t tid
cdef hsize_t *dims
# Create the base HDF5 type
if atom.type in PTTypeToHDF5:
tid = H5Tcopy(PTTypeToHDF5[atom.type])
# Fix the byteorder
if atom.kind != 'time':
set_order(tid, byteorder)
elif atom.kind in PTSpecialKinds:
# Special cases (the byteorder doesn't need to be fixed afterwards)
if atom.type == 'complex64':
tid = create_ieee_complex64(byteorder)
elif atom.type == 'complex128':
tid = create_ieee_complex128(byteorder)
elif atom.kind == 'string':
tid = H5Tcopy(H5T_C_S1);
H5Tset_size(tid, atom.itemsize)
elif atom.kind == 'bool':
tid = H5Tcopy(H5T_STD_B8);
elif atom.kind == 'enum':
tid = enumToHDF5(atom, byteorder)
else:
raise TypeError(Invalid type for atom %s % (atom,))
Cheers,
~Josh.
On Jun 23, 2011, at 1:41 AM, Tallhamer, Mike wrote:
Here is some additional information on the issue...
I see that if I type the following in ipython...
[1] import tables
I do get access to tables.LinkAtom and tables.LinkCol
If I type...
[2] from tables import *
Neither LinkAtom or LinkCol are available. Furthermore, if I use
tables.LinkCol in an IsDescription class and try to assign a string to
it I get a TypeError like the one below.
In [3]: class Test(IsDescription):
...: name = StringCol(100)
...: link_col = tables.LinkCol(100)
...:
...:
In [4]: h5file = openFile('mytables.h5','w')
In [5]: h5file.createTable('/', 'Test', Test, title='Test Table')
---
TypeError Traceback (most recent call
last)
C:\tmp\ipython console in module()
C:\Python27\lib\site-packages\tables\file.pyc in createTable(self,
where, name,
description, title, filters, expectedrows, chunkshape, byteorder,
createparents)
772 description=description, title=title,
773 filters=filters, expectedrows=expectedrows,
-- 774 chunkshape=chunkshape, byteorder=byteorder)
775
776
C:\Python27\lib\site-packages\tables\table.pyc in __init__(self,
parentNode, name, description, title, filters, expectedrows, chunkshape,
byteorder, _log)
590
591 super(Table, self).__init__(parentNode, name, new,
filters,
-- 592 byteorder, _log)
593
594
C:\Python27\lib\site-packages\tables\leaf.pyc in __init__(self,
parentNode, name, new, filters, byteorder, _log)
289 # is a lazy property that automatically handles their
loading.
290
-- 291 super(Leaf, self).__init__(parentNode, name, _log)
292
293
C:\Python27\lib\site-packages\tables\node.pyc in __init__(self,
parentNode, name, _log)
294 # Create or open the node and get its object ID.
295 if new:
-- 296 self._v_objectID = self._g_create()
297 else:
298 self._v_objectID = self._g_open()
C:\Python27\lib\site-packages\tables\table.pyc in _g_create(self)
745 # set because it is needed for setting attributes
afterwards.
746 self._v_objectID = self._createTable(
-- 747 self._v_new_title, self.filters.complib or '',
obversion )
748 self._v_recarray = None # not useful anymore
749 self._rabyteorder = None # not useful anymore
C:\Python27\lib\site-packages\tables\tableExtension.pyd in
tables.tableExtension.Table._createTable
(tables\tableExtension.c:1822)()
C:\Python27\lib\site-packages\tables\utilsExtension.pyd in
tables.utilsExtension.createNestedType (tables\utilsExtension.c:7912)()
C:\Python27\lib\site-packages\tables\utilsExtension.pyd in
tables.utilsExtension.AtomToHDF5Type (tables\utilsExtension.c:5703)()
TypeError: Invalid type for atom LinkCol(itemsize=100, shape=(),
dflt='', pos=0)
Any thoughts or ideas?
-Mike
-Original Message-
I would like to create my own atom class but appear to be doing
something wrong. I basically just need a StringAtom but want to define a
new class with a new PyTables 'kind' of 'link' instead of 'string.'
I have added the following code to the atom.py file...
class LinkAtom(Atom):
Defines an atom of type ``link``.
The item size is the *maximum*
Re: [Pytables-users] PyTables Pro has been liberated
Anthony et al. On Jun 5, 2011, at 4:00 AM, Anthony Scopatz wrote: Congrats Thanks Francesc on the new more liberal licence! And Josh, 'scopatz' is indeed me. Cool. Done. Could you also add Batuhan and Henry, as they indicated an interest in helping out. Batuhan has been added since he added himself as a watcher of the repository. I don't have a user name for Henry, though. I have also started a PyTables group on convore, if we need to discuss things there. https://convore.com/pytables/ Interesting. I've never used convore before, but it may make sense to move all of our discussions there in the short-term to not overwhelm the users list. Any thoughts? Would people rather keep the discussion here? (We've gained half a dozen watchers who are not involved in this conversation. They may have found out about the move via the list, in which case keeping things visible may be a sensible goal). We should probably have a discussion on what needs to be done in the near term and where we think things are going. Agreed. I've added everything that I had scribbled on a sheet of paper since Friday as github issues. Feel free to add your own, comment on others, etc. #6 Schedule first governance meeting could definitely stand to be commented on by everyone, both to when how (IRC, skype, webex, ...). It might even make sense to set up something on doodle.com. Be Well Anthony Cheers, ~Josh On Fri, Jun 3, 2011 at 4:48 PM, Josh Moore josh.mo...@gmx.de wrote: Hi all, On Jun 3, 2011, at 11:37 PM, Francesc Alted wrote: Hey Josh, 2011/6/3 Josh Moore josh.mo...@gmx.de First of all, an amazing thanks to Francesc for making PyTables Pro available!! This is a great opportunity to help boost the interest in PyTables and keep it growing now that it's being kicked out of the proverbial nest. :) :) I had mentioned to him that the newly-created governance system put in place by the Jenkins (formerly Hudson) developers might be a good model, and was hoping that something similar would be amenable to this group. I definitely second Steven Bamford's idea of making the code available on github, but it shouldn't be necessary for it to belong to one person. Instead, I created a PyTables organization: https://github.com/PyTables and pushed the trunk branch created via: git svn clone --authors authors.txt -s http://www.pytables.org/svn/pytables/PyTablesPro/ to: https://github.com/PyTables/PyTables Everyone who's expressed interest in maintenance duties should be added to the organization, and I'll turn over ownership to Francesc until we've decided how things move forward. I like your solution very much. Thanks for moving forward so fast :) I'm fine to have ownership for the time being, but I prefer if other person can take it over. Or, cannot we have several owners at the same time? Definitely. There can be any number of owners, and you need not be one of them! :) I tried to find the people who had mentioned wanting to take an active role on github and found these: • avalentino (Antonio Valentino) • bamford • scopatz (Anthony Scopatz) • wesm (Wes McKinney) Can you confirm that you are who I thought you were, not that some poor githubber is wondering what this pytables thing is. And if there are any other github users, please speak up. If the organization isn't the right way to go, we can delete it completely. No harm done. If we want to keep it around, a first topic of discussion might be what to do with the PyTables (non-Pro) svn. Does it get added to a separate repository for historical/practical reasons? Well, I plan to maintain pytables.org for at least a year, so I think we can go directly with Pro in github, and in case anybody wants the 'old' PyTables std, it can always create a new branch anywhere. Understood and agreed. PyTablesStd? A second topic might be whether or not maintenance is wanted/needed for python-blosc and carray: https://github.com/FrancescAlted/python-blosc https://github.com/FrancescAlted/carray I *do* have the purpose to continue with Blosc and carray as my toy projects, so I think I can still be the maintainer for those if you don't mind ;) But it would be a good idea to migrate the Blosc repository to github too. Added to my 'todo' list. And I'm sure we'll find any number of other topics to keep us busy. In any event, here's to PyTables' good health! Sure! Thanks a lot for you job! Gladly, but that's enough for one Friday evening, CEST. Cheers, ~Josh -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
[Pytables-users] PyTables Pro has been liberated
First of all, an amazing thanks to Francesc for making PyTables Pro available!! This is a great opportunity to help boost the interest in PyTables and keep it growing now that it's being kicked out of the proverbial nest. :) I had mentioned to him that the newly-created governance system put in place by the Jenkins (formerly Hudson) developers might be a good model, and was hoping that something similar would be amenable to this group. I definitely second Steven Bamford's idea of making the code available on github, but it shouldn't be necessary for it to belong to one person. Instead, I created a PyTables organization: https://github.com/PyTables and pushed the trunk branch created via: git svn clone --authors authors.txt -s http://www.pytables.org/svn/pytables/PyTablesPro/ to: https://github.com/PyTables/PyTables Everyone who's expressed interest in maintenance duties should be added to the organization, and I'll turn over ownership to Francesc until we've decided how things move forward. If the organization isn't the right way to go, we can delete it completely. No harm done. If we want to keep it around, a first topic of discussion might be what to do with the PyTables (non-Pro) svn. Does it get added to a separate repository for historical/practical reasons? PyTablesStd? A second topic might be whether or not maintenance is wanted/needed for python-blosc and carray: https://github.com/FrancescAlted/python-blosc https://github.com/FrancescAlted/carray And I'm sure we'll find any number of other topics to keep us busy. In any event, here's to PyTables' good health! ~Josh Moore On Jun 3, 2011, fal...@pytables.org, wrote: Hi List, Fortunately, now that it seems like there will be some opportunities for PyTables to be maintained, I'm happy to announce that, hereby, PyTables Pro drops its original, commercial license, and acquires a BSD license. The new ``LICENSE.txt`` in the root directory states this. You can find the SVN sources in: http://www.pytables.org/svn/pytables/PyTablesPro and browse the sources via Trac too in: http://pytables.org/trac/browser/PyTablesPro @ people interested in the future maintenance, please feel free to use Pro as a possible base for the future PyTables (with no Pro suffix anymore). Some caveats about doing this though: - The version format for the Pro version is something like 'X.Y.Zpro', and such a 'pro' suffix is necessary in certain parts of the code in order to enable the Pro-specific features (indexing and caching, mainly). It should be easy to get rid of this, but needs some modification of the code. - The manual is the same in PyTables Pro than PyTables standard, but if the new maintainers choose to put Pro as the default, the notes of the style ... is only available in PyTables Pro. should be obviously removed. - The copyright for the years 2002-2010 should be respected, and I have added a new entry for 2011 which is attributed to PyTables maintainers, in honor to those braves that are undertaking the maintenance task of PyTables. Please change this 'author' by something more meaningful if you feel like. So, enjoy data with PyTables Pro (BSD-flavored :) ! -- Francesc Alted -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
Re: [Pytables-users] PyTables Pro has been liberated
Hi all, On Jun 3, 2011, at 11:37 PM, Francesc Alted wrote: Hey Josh, 2011/6/3 Josh Moore josh.mo...@gmx.de First of all, an amazing thanks to Francesc for making PyTables Pro available!! This is a great opportunity to help boost the interest in PyTables and keep it growing now that it's being kicked out of the proverbial nest. :) :) I had mentioned to him that the newly-created governance system put in place by the Jenkins (formerly Hudson) developers might be a good model, and was hoping that something similar would be amenable to this group. I definitely second Steven Bamford's idea of making the code available on github, but it shouldn't be necessary for it to belong to one person. Instead, I created a PyTables organization: https://github.com/PyTables and pushed the trunk branch created via: git svn clone --authors authors.txt -s http://www.pytables.org/svn/pytables/PyTablesPro/ to: https://github.com/PyTables/PyTables Everyone who's expressed interest in maintenance duties should be added to the organization, and I'll turn over ownership to Francesc until we've decided how things move forward. I like your solution very much. Thanks for moving forward so fast :) I'm fine to have ownership for the time being, but I prefer if other person can take it over. Or, cannot we have several owners at the same time? Definitely. There can be any number of owners, and you need not be one of them! :) I tried to find the people who had mentioned wanting to take an active role on github and found these: • avalentino (Antonio Valentino) • bamford • scopatz (Anthony Scopatz) • wesm (Wes McKinney) Can you confirm that you are who I thought you were, not that some poor githubber is wondering what this pytables thing is. And if there are any other github users, please speak up. If the organization isn't the right way to go, we can delete it completely. No harm done. If we want to keep it around, a first topic of discussion might be what to do with the PyTables (non-Pro) svn. Does it get added to a separate repository for historical/practical reasons? Well, I plan to maintain pytables.org for at least a year, so I think we can go directly with Pro in github, and in case anybody wants the 'old' PyTables std, it can always create a new branch anywhere. Understood and agreed. PyTablesStd? A second topic might be whether or not maintenance is wanted/needed for python-blosc and carray: https://github.com/FrancescAlted/python-blosc https://github.com/FrancescAlted/carray I *do* have the purpose to continue with Blosc and carray as my toy projects, so I think I can still be the maintainer for those if you don't mind ;) But it would be a good idea to migrate the Blosc repository to github too. Added to my 'todo' list. And I'm sure we'll find any number of other topics to keep us busy. In any event, here's to PyTables' good health! Sure! Thanks a lot for you job! Gladly, but that's enough for one Friday evening, CEST. Cheers, ~Josh -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
