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
