Thomas, Can you fwd. me your test script, such that I can fix the Topology.py module. Its unacceptable that it would error on this. I'm sorry, I thought this issue was under control. I will integrate this as a unit test to make sure this doesnt surface again.
The fix that I have in mind is that Topology.py will use the TopoDS_ListOfShapes wrapped in a python class that will make it available as a generator. -jelle On May 6, 2009, at 10:19 AM, Thomas Paviot wrote: > Hi Dave, > > As Jelle said, this was already discussed on this ml but the link > provided will not fix the but you report: I have the same segfault as > you. Here is the problem: the last occurence of the method > TopExp_Explorer.Next() erases all pointers. When you stores shapes > in a > python lists, you then have a list of null pointers (that cause the > segfault). > > The safest way to store shapes returned by the TopExp_Explorer is > certainly to use the TopoDS_ListOfShapes builtin iterator. However, if > you want to use python lists, then you have to ReInit() the explorer > when it's done with the .Next() method. In the sample you provide, you > then just have to add texp.ReInit() at the end of your 'findFaces' > function: > > def findFaces(shape): > faceList = []; > texp = TopExp.TopExp_Explorer(); > ts = TopoDS.TopoDS(); > texp.Init(shape,TopAbs.TopAbs_FACE); > while ( texp.More() ): > face = ts.Face(texp.Current()); > faceList.append(face); > texp.Next(); # if there's no 'next' shape, pointers are > destroyed > texp.ReInit() # Add this line so pointers are recreated before the > list is returned > return faceList; > > Fix successfully tested on my Windows XP machine. > > Cheers, > > Thomas > > jelle feringa a écrit : >> hi Dave, >> >> this was an issue with occ.utils.topology.py, which has been fixed in >> the SVN some time ago. it would be best if you can upgrade to: >> http://pythonocc.org/Releases/daily/pythonOCC-PDE2009.win32-py2.5.exe >> >> cheers, >> >> -jelle >> >> On Wed, May 6, 2009 at 4:05 AM, Dave Cowden <dave.cow...@gmail.com> >> wrote: >> >>> Hello, everyone: >>> >>> I could use some assistance. I know little about swig and subtle >>> python/c++ >>> binding details, but I suspect some subtle thing I'm doing wron >>> >> g is kicking >> >>> my butt. >>> >>> I am getting 'hard crashes' when I attempt to store object proxies >>> into a >>> list. >>> >>> Attached is an example script. in the script, I do the following >>> steps: >>> >>> (1) create a box >>> (2) dump the topology, using a function that will print the object >>> tree-- >>> solid, then faces, then wires, then edges. this works >>> (3) iterate through the box finding the faces, and print them out >>> one at a >>> time. this also works >>> (4) use the same code as (3), but instead of directly using the >>> objects, put >>> them into a list, and return them >>> (5) attempt to loop through the list, dumping the them exactly as >>> in (4). >>> >>> in step 5, i get a hard crash every time. it seems like the object >>> proxies >>> are going out of scope or something. I'm completely lost. >>> >>> Can anyone else duplicate these results, and/or tell me if i'm doing >>> something obviously wrong? >>> >>> Platform: windows xp >>> occ version 6.3.0 >>> pyocc version wo0.2 ( from prebuilt binaries ) >>> >>> as always help is appreciated. >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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
