The patch where I just solved problems relative to sync the samples with the new SimpleGui. I was obtained via 'svn diff >>patch' run from the pythonOcc root directory. Note that I noticed some weird end of line encoding (like in Level1/Geometry/geomplate.py) : ^M on emacs. I don't know how to handle it (in some small project of which I was part, I think we were using Svn property svn:eol to handle that problem - which is minor)
There are also problems I noted but not solved; most of which occur after
clicking on a submenu, I didn't test all submenus though. I didn't try to
check if the sample was doing what it should, just that no python error were
thrown:
1)
>>python Level1/Geometry/geomplate.py (when clicking on 'Solve Raidus' menu)
""
Display3d class initialization starting ...
Graphic device created.
Xw_Window created.
Viewer created.
Interactive context created.
Display3d class successfully initialized.
scipy not installed, cannot continue the solve_radius example
Traceback (most recent call last):
File "Level1/Geometry/geomplate.py", line 201, in solve_radius
for i in scipy.arange(0.1,3.,0.2).tolist():
UnboundLocalError: local variable 'scipy' referenced before assignment
""
2)
>> python Level1/Geometry/surfaces.py (clicking on 'constrianed filling')
""
Display3d class initialization starting ...
Graphic device created.
Xw_Window created.
Viewer created.
Interactive context created.
Display3d class successfully initialized.
Traceback (most recent call last):
File "Level1/Geometry/surfaces.py", line 91, in constrained_filling
spl1, b1 = get_simple_bound(pts1)
File "Level1/Geometry/surfaces.py", line 46, in get_simple_bound
return spl1, bound1_h
NameError: global name 'bound1_h' is not defined
""
3)
>> python Level1/Plot/plot.py
One of the two windows remains empty, I don't know how it is bound to be
used.
4)
>> python Level1/Plot/plot_view.py
""
wxViewer2d inited
Display2d class initialization starting ...
Graphic device created.
Xw_Window created.
V2d_Viewer created.
AIS2D_InteractiveContext created.
V2d_View created.
V2d_View add to V2d_Viewer.
Traceback (most recent call last):
File "Level1/Plot/plot_view.py", line 75, in sphere
display.DisplayShape(BRepPrimAPI_MakeSphere(1).Shape())
File "/usr/local/lib/python2.6/dist-packages/OCC/Display/OCCViewer.py",
line 128, in DisplayShape
self.Context.Display(shape_to_display.GetHandle())
TypeError: in method 'AIS2D_InteractiveContext_Display', argument 2 of type
'Handle_AIS2D_InteractiveObject const &'
Motion!!
44 1
Traceback (most recent call last):
File "Level1/Plot/plot_view.py", line 78, in cube
display.DisplayShape(BRepPrimAPI_MakeBox(1,1,1).Shape())
File "/usr/local/lib/python2.6/dist-packages/OCC/Display/OCCViewer.py",
line 128, in DisplayShape
self.Context.Display(shape_to_display.GetHandle())
TypeError: in method 'AIS2D_InteractiveContext_Display', argument 2 of type
'Handle_AIS2D_InteractiveObject const &'
""
I hope this helps a bit
Loïc
On Thu, Dec 3, 2009 at 6:00 PM, Simon Loic <simon1l...@gmail.com> wrote:
> Actually, I had issue yesterday to buiild smesh! But I'm not much into
> autoconf ...
> I tried it the same way as for salomegeom:
> >> autoreconf --install
> then it fails with
> ""
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
> libtoolize: copying file `build-aux/config.guess'
> libtoolize: copying file `build-aux/config.sub'
> libtoolize: copying file `build-aux/install-sh'
> libtoolize: copying file `build-aux/ltmain.sh'
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.acand
> libtoolize: rerunning libtoolize, to keep the correct libtool macros
> in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> configure.ac:11: installing `build-aux/missing'
> Makefile.am: installing `build-aux/depcomp'
> Makefile.am: Fortran 77 source seen but `F77' is undefined
> Makefile.am: The usual way to define `F77' is to add `AC_PROG_F77'
> Makefile.am: to `configure.ac' and run `autoconf' again.
> autoreconf: automake failed with exit status: 1
> ""
>
> Previously you were telling Fotis that you were about to fix stuff for
> smesh and autoconf. Is this related?
>
> Loïc
>
>
> On Thu, Dec 3, 2009 at 5:33 PM, Thomas Paviot <tpav...@gmail.com> wrote:
>
>> I will commit changes to the smesh repository this evening or tomorrow
>> morning. For the precompiled binaries, I think I'll just provide a bundled
>> version of pythonOCC-0.4 for Windows (the 'all-in-one', including OCC,
>> salomegeom and salomesh). For Linux/MacOS users, the compilation of geom and
>> smesh should not be an issue for anyone.
>>
>> Looking forward to seeing this new releases!
>>
>> Cheers,
>>
>> Thomas
>>
>> 2009/12/3 Fotios Sioutis <sfo...@gmail.com>
>>
>>> 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
>>
>>
>
patch
Description: Binary data
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
