2009/12/3 Simon Loic <simon1l...@gmail.com> > Thanks, Thomas > Now everything is all right at work, compilatio went fine and uptodate > samples don't crash (I'll check at home if everything is ok after update). > If I understand well, the problem was that one swig interface (SGEOM.i) was > generated (by py++) using an older revision of salomegeometry than the one I > checked out, right? >
Yes, since some of the salomegeom headers changed since last Fotis' commit, I also have to regenerate the SWIG interface files. > > If I remember well there was a way to use setup.py to regenerate swig > interface files? > Is it still possible? and how? > The installation and SWIG generation features were splitted into 2 different scripts. On the svn trunk, you have now: - setup.py: build and install pythonOCC on your platform, - generate_swig_files.py: just run 'python generate_swig_files.py' to automatically parse the OCC/sgeom/smesh headers and create SWIG interface files. Not that this script is multiprocessed under Lin/MacOSX. It's then much faster than the older one. If you just want to re-generate the SWIG file for one specific module (for instance Aspect), then type 'python generate_swig_files.py Aspect'. If you're on Linux/MacOS, the SWIG files will be available in the src/wrapper/SWIG/lin_darwin directory. > > BTW, I am planning to try most samples (a part smesh related as I can't > build salomemesh so far). Therefore I will have to get them uptodate with > respect to SimpleGui. Are you interested by the modified version of those? I > could send you a zip or a patch. > Im' interested, thanks! Just send me a patch over the latest svn trunk, it will be fine. > Friendly, > Loïc > > Cheers, Thomas > > On Thu, Dec 3, 2009 at 3:52 PM, Fotios Sioutis <sfo...@gmail.com> wrote: > >> I agree with you on all issues, and i add that as long as i will release >> 5.1.2.6 (versioning is like a.b.c.d where "a, b, c" is the upstream release >> is based on, and d is my release counter), propably you will have to prepare >> on your svn the pyocc 0.5 so that it can follow any changes in the >> libraries.Also i would like to note that i want to avoid to provide >> downloadable binaries for any platform, and this is something you can >> provide (maybe with the pyocc installer).If I will find some time later in >> the evening i will tag the current svn version of GEOM and proceed with the >> release.For SMESH i will wait for your changes and proceed accordingly. >> >> Fotis >> >> >> >> On Thu, Dec 3, 2009 at 4:23 PM, Thomas Paviot <tpav...@gmail.com> wrote: >> >>> Cool. According to me, salomegeom can be released as-is. I succesfully >>> compiled/ran it over different platforms (Windows XP MSVC7/MSVC9, Ubuntu >>> 9.04 and 9.10, MacOSX Snow Leopard 64 bits). It works just great. >>> >>> It's a bit different for salomesmesh. I have modified the >>> automake/autoconf tools so that a few issues on Linux/MacOSX are solved: >>> - 64 bit support, >>> - check of boost/shared_ptr header, >>> - conditionnal netgen support. >>> >>> According to me, the following plan can be adopted: >>> - you release salomegeom source as a .zip archive (as it is for 4.1.4.5 >>> latest release) as soon as you want, >>> - when it's done, I can provide you precompiled binaries for OSX SL 64 >>> bits Intel, Ubuntu 9.10 and Windows msvc7/9 (.lib and .dll), >>> - in the meantime I commit the patch to salomesmesh trunk, >>> - you release salomesmesh source code as a .zip archive, >>> - I provide you precompiled binaries, >>> - then we release pythonOCC built upon those 2 releases: this will ensure >>> that pythonOCC is sync with latest geom and smesh releases, and that >>> pythonOCC users can properly and safely compile pythonOCC 0.4. >>> >>> What do you think about that? >>> >>> Best, >>> >>> Thomas >>> >>> 2009/12/3 Fotios Sioutis <sfo...@gmail.com> >>> >>>> Geom at the moment has no severe bug or issue ( I just add some features >>>> from time to time ) , so at any time i can create a release.The future >>>> plan >>>> is to create a smarter GEOM_Solver class and also a new 2d sketcher driver >>>> in GeomImpl.I am not so sure if it is worth to wait for such a thing, and >>>> in >>>> general it is up to you to notify me when to create a downloadable package >>>> and which svn version you want. >>>> >>>> Fotis >>>> >>>> >>>> >>>> On Thu, Dec 3, 2009 at 2:43 PM, Thomas Paviot <tpav...@gmail.com>wrote: >>>> >>>>> Hi Fotis, >>>>> >>>>> No, it's ok. Being sync with your developments is a requirement. >>>>> However, when do you plan to release a new version of your work? It would >>>>> definitely be much easier for us to build pythonOCC upon a official >>>>> downloadable .tar.gz salomegeom package. >>>>> >>>>> Loïc, I updated pythonOCC so that it's sync with rev.188 (the latest) >>>>> of salomegeometry. You can try to svn update/rebuild and test. >>>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> >>>>> >>>>> 2009/12/3 Fotios Sioutis <sfo...@gmail.com> >>>>> >>>>> In case it is needed i can leave a copy of the old API in the code. >>>>>> Thomas let me know in case you need such a thing >>>>>> >>>>>> Fotis >>>>>> >>>>>> >>>>>> On Thu, Dec 3, 2009 at 2:16 PM, Thomas Paviot <tpav...@gmail.com>wrote: >>>>>> >>>>>>> Loïc, >>>>>>> >>>>>>> I did not notice that Fotis commited a few changes these last few >>>>>>> days. I have to update to the latest svn rev. and regenerate the SWIG >>>>>>> files. >>>>>>> I'll let you know when it's done. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> 2009/12/3 Simon Loic <simon1l...@gmail.com> >>>>>>> >>>>>>> Hi Thomas, >>>>>>>> I wanted to give a try on my work computer (previously I was testing >>>>>>>> at home) but I can't compile with --enable-geom. >>>>>>>> If I build with the following command : >>>>>>>> >> python setup.py build --enable_geom >>>>>>>> >>>>>>>> I get >>>>>>>> """""""""""""""""""" >>>>>>>> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions >>>>>>>> build/temp.linux-x86_64-2.6/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/SGEOM_wrap.o >>>>>>>> -L/opt/OpenCASCADE6.3.0/lib -L/usr/local/lib -L/usr/local/lib >>>>>>>> -lBinLPlugin >>>>>>>> -lBinPlugin -lBinXCAFPlugin -lFWOSPlugin -lmscmd -lPTKernel >>>>>>>> -lStdLPlugin >>>>>>>> -lStdPlugin -lTKAdvTools -lTKBin -lTKBinL -lTKBinTObj -lTKBinXCAF >>>>>>>> -lTKBO >>>>>>>> -lTKBool -lTKBRep -lTKCAF -lTKCDF -lTKCDLFront -lTKCPPClient -lTKCPPExt >>>>>>>> -lTKCPPIntExt -lTKCPPJini -lTKCSFDBSchema -lTKDCAF -lTKDraw -lTKernel >>>>>>>> -lTKFeat -lTKFillet -lTKG2d -lTKG3d -lTKGeomAlgo -lTKGeomBase -lTKHLR >>>>>>>> -lTKIDLFront -lTKIGES -lTKLCAF -lTKMath -lTKMesh -lTKMeshVS -lTKNIS >>>>>>>> -lTKOffset -lTKOpenGl -lTKPCAF -lTKPLCAF -lTKPrim -lTKPShape >>>>>>>> -lTKService >>>>>>>> -lTKShapeSchema -lTKShHealing -lTKStdLSchema -lTKStdSchema -lTKSTEP >>>>>>>> -lTKSTEP209 -lTKSTEPAttr -lTKSTEPBase -lTKSTL -lTKTCPPExt -lTKTObj >>>>>>>> -lTKTObjDRAW -lTKTopAlgo -lTKTopTest -lTKV2d -lTKV3d -lTKViewerTest >>>>>>>> -lTKVRML >>>>>>>> -lTKWOK -lTKWOKTcl -lTKXCAF -lTKXCAFSchema -lTKXDEDRAW -lTKXDEIGES >>>>>>>> -lTKXDESTEP -lTKXMesh -lTKXml -lTKXmlL -lTKXmlTObj -lTKXmlXCAF >>>>>>>> -lTKXSBase >>>>>>>> -lTKXSDRAW -lXCAFPlugin -lXmlLPlugin -lXmlPlugin -lXmlXCAFPlugin >>>>>>>> -lSketcher >>>>>>>> -lShHealOper -lPartition -lNMTTools -lNMTDS -lGEOM -lGEOMImpl >>>>>>>> -lGEOMAlgo >>>>>>>> -lArchimede -o build/lib.linux-x86_64-2.6/OCC/_SGEOM.so >>>>>>>> -Wl,--no-undefined >>>>>>>> -lm -lstdc++ -lpython2.6 >>>>>>>> build/temp.linux-x86_64-2.6/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/SGEOM_wrap.o: >>>>>>>> In function `_wrap_GEOM_Engine_SetInterpreterConstant': >>>>>>>> SGEOM_wrap.cpp:(.text+0xaa33): undefined reference to >>>>>>>> `GEOM_Engine::SetInterpreterConstant(int, TCollection_AsciiString >>>>>>>> const&, >>>>>>>> double)' >>>>>>>> build/temp.linux-x86_64-2.6/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/SGEOM_wrap.o: >>>>>>>> In function `_wrap_GEOM_Engine_SetInterpreterConstantArray': >>>>>>>> SGEOM_wrap.cpp:(.text+0xad69): undefined reference to >>>>>>>> `GEOM_Engine::SetInterpreterConstantArray(int, >>>>>>>> Handle_TColStd_HArray1OfTransient, bool)' >>>>>>>> build/temp.linux-x86_64-2.6/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/SGEOM_wrap.o: >>>>>>>> In function `_wrap_GEOM_Engine_GetInterpreterConstantArray': >>>>>>>> SGEOM_wrap.cpp:(.text+0x1eb45): undefined reference to >>>>>>>> `GEOM_Engine::GetInterpreterConstantArray(int)' >>>>>>>> collect2: ld returned 1 exit status >>>>>>>> error: command 'g++' failed with exit status 1 >>>>>>>> """"""""""""""""""""" >>>>>>>> >>>>>>>> Note that I have the latest trunk revision of salomegeom installed. >>>>>>>> Maybe, pythonOcc is not synchronized with salomegeom, right? >>>>>>>> Loïc >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 3, 2009 at 10:46 AM, Simon Loic >>>>>>>> <simon1l...@gmail.com>wrote: >>>>>>>> >>>>>>>>> Thanks Thomas, >>>>>>>>> I updated your latest commit, and launched the samples you updated >>>>>>>>> (Level1/Geometry/geometry_demos.py and >>>>>>>>> Level1/TopologyBuilding/topology_building.py - I don't have smesh so >>>>>>>>> far) . >>>>>>>>> Unfortunately they both end with a seg fault after the viewer is >>>>>>>>> created. >>>>>>>>> >>>>>>>>> Here is the output. >>>>>>>>> """ >>>>>>>>> Display3d class initialization starting ... >>>>>>>>> Graphic device created. >>>>>>>>> Xw_Window created. >>>>>>>>> Viewer created. >>>>>>>>> zsh: segmentation fault python Level1/Geometry/geometry_demos.py >>>>>>>>> """ >>>>>>>>> I'll try to investigate further on later. >>>>>>>>> >>>>>>>>> Loïc >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 3, 2009 at 5:18 AM, Thomas Paviot >>>>>>>>> <tpav...@gmail.com>wrote: >>>>>>>>> >>>>>>>>>> Hi Loïc, >>>>>>>>>> >>>>>>>>>> The SmpleGui.py module is an improvement over the previous >>>>>>>>>> wxSamplesGui that enables multiple graphical backends. For instance, >>>>>>>>>> if you >>>>>>>>>> decide whether to use SimpleGui to manage the display, you first >>>>>>>>>> have to set >>>>>>>>>> the graphical backend to use. Fos instance: >>>>>>>>>> >>>>>>>>>> set_backend('wx') #if you want to use wxPython >>>>>>>>>> set_backend('qt') #if you want to use pyQt >>>>>>>>>> set_backend('X') #if you want to use python-xlib (Linux/MacOSX up >>>>>>>>>> to SL64bit) >>>>>>>>>> >>>>>>>>>> All the samples are not sync yet with the newest developments I >>>>>>>>>> made. In ordrer to make the scripts work, you first have to insert >>>>>>>>>> the 2 >>>>>>>>>> lines: >>>>>>>>>> >>>>>>>>>> from OCC.Display.SimpleGui import * >>>>>>>>>> >>>>>>>>>> display, start_display, add_menu, add_function_to_menu = >>>>>>>>>> init_display() >>>>>>>>>> >>>>>>>>>> The graphical backend used by default will be the one available on >>>>>>>>>> your machine. If you have both wxPython, PyQt and python-xlib >>>>>>>>>> installed, >>>>>>>>>> then the default one will bis 'wx'. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Thomas >>>>>>>>>> >>>>>>>>>> 2009/12/2 Simon Loic <simon1l...@gmail.com> >>>>>>>>>> >>>>>>>>>>> Hi thomas, >>>>>>>>>>> I've seen that you made a many commits recently relative to >>>>>>>>>>> SimpleGUI, I have updated pythonOcc trunk to the last revision. It >>>>>>>>>>> seems >>>>>>>>>>> that many samples have don't work anymore. >>>>>>>>>>> To be accurate if for example I call >>>>>>>>>>> >>python Level2/PAF/test_box.py >>>>>>>>>>> it wil throw me >>>>>>>>>>> "" >>>>>>>>>>> from OCC.Display.SimpleGui import start_display, display >>>>>>>>>>> ImportError: cannot import name start_display >>>>>>>>>>> "" >>>>>>>>>>> the same for Level1/Mesh/simple_mesh.py >>>>>>>>>>> Level1/Animation/animation.py and I guess many others (didn't try >>>>>>>>>>> all of >>>>>>>>>>> them). >>>>>>>>>>> >>>>>>>>>>> I also have a related problem with other scripts like >>>>>>>>>>> Level1/Dimensions/dimensions.py where there si first a statement: >>>>>>>>>>> >> from OCC.Display.SimpleGui import * >>>>>>>>>>> and then at some point >>>>>>>>>>> >> display.Context.Display(ais7.GetHandle()) >>>>>>>>>>> Then I get the following error: >>>>>>>>>>> ""NameError: name 'display' is not defined"" >>>>>>>>>>> >>>>>>>>>>> Are the samples uptodate and I simply did something wrong? >>>>>>>>>>> Cheers, >>>>>>>>>>> Loïc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >> >> _______________________________________________ >> 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