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
