I updated another prebuild that really fixes the problems: pythonOCC-2009_03_21_2.win32-py2.5.exe
Download on: http://www.pythonocc.org/Releases/daily Cheers, Thomas Frank Conradie a écrit : > Thanks Thomas, I will try the daily release, and also do a svn > checkout and build and let you know how that goes. > - Frank > > Thomas Paviot wrote: >> Frank, >> >> I uploaded a prebuilt binary for Windows-Python25 that fixes the bug >> you reported. >> >> http://www.pythonocc.org/Releases/daily >> >> Cheers, >> >> Thomas >> >> >> Thomas Paviot a écrit : >>> Frank, >>> >>> The build of pythonOCC on Windows is quite easier than on Linux (in >>> my opinion). I use VS2003. If you properly installed >>> OpenCascade6.3.0 (and the CASROOT env variable is set), then you >>> only have to >>> >>> cd src >>> python setup.py build -cmsvc >>> >>> And everything should go fine (strangely, scons build script does >>> not work under Windows and is then not usable). I don't know how to >>> deal with distutils and various VS installation. Any feedback is >>> welcome. >>> >>> There were many changes and improvements since the md0.1 release, >>> and the development is still very active. I usually upload 'daily >>> builds for Windows' (indeed, it's more 'weekly' builds) that you can >>> find at http://www.pythonocc.org/Releases/daily. Thanks to your >>> report, I hope to upload one more daily build this evening. If you >>> really wish to be up-to-date, you'd better check out source code >>> from the subversion repository and build your own pythonOCC. >>> >>> Cheers, >>> >>> Thomas >>> >>> Frank Conradie a écrit : >>> >>>> Hi Thomas >>>> >>>> Thanks for your thorough reply! I am using Vista and the md0.1 >>>> release of PythonOCC. I have used scons before - how big an issue >>>> is it to build PythonOCC on Windows (I have various versions of >>>> Visual Studio available - .NET, 2005, 2008)? >>>> >>>> Thanks again, >>>> Frank Conradie >>>> Rossland, BC, Canada >>>> >>>> >>>> Thomas Paviot wrote: >>>> >>>>> Hi Frank, >>>>> >>>>> I tested your script and have the same result. You point out a >>>>> really *serious* bug related to python/OpenCascade memory >>>>> management conflicts. In a sense, when you're 'outside' the >>>>> function, the python object points to an OCC object that was >>>>> deleted when exiting the function. I thought I fixed this >>>>> behaviour, and that it was enough to use a custom destructor only >>>>> for OCC objects that inherits from Standard_Transient. I was >>>>> wrong, and this fix has to be extended to *all* OCC objects. >>>>> Thanks for the feedback, I'll tryo to do that this week-end >>>>> (should be a simple line removing in the SWIG_generator.py script). >>>>> >>>>> Anyway, this discussion is far from your needs! If you cannot wait >>>>> for the fix to be commited, I have one solution: >>>>> >>>>> Just after the line 'mkface = >>>>> BRepBuilderAPI.BRepBuilderAPI_MakeFace(mkwire.Wire())', add the >>>>> following line: >>>>> mkface.thisown = False >>>>> (Tells python to *not* delete the object when exiting the >>>>> function). The result is then: >>>>> >>>>> f faceInsideFunction.IsNull: 0 >>>>> <OCC.TopoDS.TopoDS_Face; proxy of <Swig Object of type >>>>> 'TopoDS_Face *' at 0x00AE28C0> > >>>>> returnedFace.IsNull: 0 >>>>> <OCC.TopoDS.TopoDS_Face; proxy of <Swig Object of type >>>>> 'TopoDS_Face *' at 0x00ADFBC0> > >>>>> >>>>> Jelle and I had a long discussion about this topic (memory >>>>> management). Our conclusion is that this stuff *must* be >>>>> completely hidden to the end-user (since it's not pythonic at all) >>>>> before another pythonOCC version is released. Thanks so much for >>>>> your report, Franck. I know exactly what to do and it will be done >>>>> before the end of the week-end. I have however a bad news: the >>>>> complete solution will have to be rebuild from scratch since amost >>>>> all SWIG files will be modified. >>>>> >>>>> Just a question: what is your OS? Which pythonOCC version do you use? >>>>> >>>>> Best Regards, >>>>> >>>>> Thomas >>>>> >>>>> Frank Conradie a écrit : >>>>> >>>>>> I was hoping someone could explain the following odd wrapper >>>>>> behavior: if I build a TopoDS_Face inside a Python function, then >>>>>> return it from the function, the returned face seems to be >>>>>> different/invalid in the calling scope. >>>>>> Here is the output: >>>>>> >>>>>> faceInsideFunction.IsNull: 0 >>>>>> <OCC.TopoDS.TopoDS_Face; proxy of <Swig Object of type >>>>>> 'TopoDS_Face *' at 0x01BE4640> > >>>>>> >>>>>> returnedFace.IsNull: 1 >>>>>> <OCC.TopoDS.TopoDS_Face; proxy of <Swig Object of type >>>>>> 'TopoDS_Face *' at 0x01BDF7E0> > >>>>>> >>>>>> And here is the code that generated this output: >>>>>> >>>>>> from OCC import gp, BRepBuilderAPI, TopoDS >>>>>> >>>>>> def MakeFace(pts): >>>>>> gpnts = [gp.gp_Pnt(x,y,z) for x,y,z in pts] >>>>>> n = len(gpnts) >>>>>> gpnts.append(gpnts[0]) >>>>>> mkwire = BRepBuilderAPI.BRepBuilderAPI_MakeWire() >>>>>> for i in range(n): >>>>>> mkedge = BRepBuilderAPI.BRepBuilderAPI_MakeEdge(gpnts[i], >>>>>> gpnts[i+1]) >>>>>> mkwire.Add(mkedge.Edge()) >>>>>> mkface = BRepBuilderAPI.BRepBuilderAPI_MakeFace(mkwire.Wire()) >>>>>> f = mkface.Face() >>>>>> print 'faceInsideFunction.IsNull:', f.IsNull() >>>>>> print f >>>>>> return f >>>>>> >>>>>> def Test1(): >>>>>> y = 0.000 >>>>>> o = 0.000 >>>>>> d = 0.100 >>>>>> fpts = [ >>>>>> [o, y,o ], >>>>>> [o+d,y,o ], >>>>>> [o+d,y,o+d], >>>>>> [o, y,o+d], >>>>>> ] >>>>>> f1 = MakeFace(fpts) >>>>>> print >>>>>> print 'returnedFace.IsNull:', f1.IsNull() >>>>>> print f1 >>>>>> >>>>>> if __name__ == '__main__': >>>>>> Test1() >>>>>> >>>>>> Thanks for a great project! >>>>>> Frank Conradie >>>>>> Rossland, BC, Canada >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
