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
