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
