Yes, absolutely. I already ran a few tests that work pretty well. I still have to check that each OCC module compile with the new wrapping rules, and run the unittests/samples, which is quite long but not so difficult.
2010/6/22 Cowdens <dave.cow...@gmail.com> > Thomas this is great news! I have not been active with development > either on my project, but i do remember that my last stopping spot was to > work on memory consumption, which was pretty crazy after slicing an object. > This may just 'magically' fix it! > > So in the new scheme, the rules of python scope will predict when an object > is freed? So for example if i store an OCC object in a python list, it will > live until the list itself is de-referenced, then it will die? > > > > ------------------------------ > *From:* pythonocc-users-boun...@gna.org [mailto: > pythonocc-users-boun...@gna.org] *On Behalf Of *Thomas Paviot > *Sent:* Tuesday, June 22, 2010 5:59 AM > *To:* pythonOCC users mailing list. > *Subject:* [Pythonocc-users] Development status > > Hi All, > > I've been very busy these last weeks and I was not very active on this ml. > I apologize if any of you didn't get any answer to his question although I > regularly checked the ml activity. > > However, the development on pythonOCC was not stopped and I've been working > silently on fixing open issues, and I found *the* way to fix what was still > unclear to me a few weeks ago: 1) memory leaks 2) TopExp_Explorer returned > values 3) python lists of OCC objects that return the same object when > iterated. Untill now, there are 3 tweaks to deal with these issues: 1) A > customized garbage collector 2) hashes 3) use builtin OCC lists/arrays/sets > etc. > > It is clear that it's not robust enough to imagine using pythonOCC in some > intensive modeling activities with thousands of objects, or run long term > modeling programs (I mean, programs running for hours or days). The fix I'm > working on will solve these 3 issues at the same time (no need for gc or > special hashes) without modifying the API, with an overall performance > improvement. In a few words, the idea is to move the 'return by reference' > C++ mechanism to static casting to the C++ object in order to get clean > python objects, properly deleted by python, the memory being freed by the > OCC reference counting mechanism (that is to say, the behavior we should > expect from a python wrapper!). > > First results are promising. I'm waiting for this work to be completed > before committing anything to the subversion repository. I will do it as > soon as I'm satisfied with this new wrapper and when it's ready to be > tested. > > Best Regards, > > Thomas > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
