Having Problem extending wxPython

Emmanuel_Bacry · November 13, 2011, 10:28pm

Hello,

I am new on wxPython. I plan to write a pretty complex extension... To
start (for training), I am just trying to write a very simple
extension. I bumped into a very "simple" problem.
My main problem is that I want to use the class wxPoint in C++ and I
want it to be automatically wrapped into the wx.Point class of
wxPython.
(I am not using here any display yet! I am feeling I am missing
something really basic here!)
After I run (see the files below)

python setup.py build_ext --inplace

(everything seems to go fine, the 'stupid' module is built and imports
correctly after 'wx' is imported and the stupid.Simple class is known)
However, in python, the C++ wxPoint class IS NOT converted into the
wx.Point class

Am I missing something ?

Thank you very much

Emmanuel

//////////////////////////////////////////////////////
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////
// FILE stupid.h
#include "wx/wx.h"
class Simple {
   public :
      wxPoint aPoint;
      Simple(wxPoint p);
      wxPoint GetPoint;
};

//////////////////////////////////////////////////////
// FILE stupid.cpp
Simple::Simple(wxPoint p)
{
aPoint = p;
}

wxPoint Simple::GetPoint()
{
return aPoint;
}

So I wrote a stupid.i file

//////////////////////////////////////////////////////
// FILE stupid.i
%module stupid
%{
#include "wx/wxPython/wxPython.h"
#include "wx/wxPython/pyclasses.h"
#include "stupid.h"
%}
%include typemaps.i
%include my_typemaps.i
%import core.i
%import windows.i

class Simple {
   public :
      wxPoint aPoint;
      Stupid(wxPoint p);
      wxPoint GetPoint;
};

Here is my (basic) setup.py file (copied from a template on the web)
//////////////////////////////////////////////////////
// FILE setup.py
import wx
from wx.build.config import *

USE_SWIG=1
swig_sources = run_swig(['stupid.i'], '', '.', '.',
USE_SWIG, swig_force, swig_args, swig_deps)

extopts = dict(include_dirs = includes,
               define_macros = defines,
               library_dirs = libdirs,
               libraries = libs,
               extra_compile_args = cflags,
               extra_link_args = lflags,
               swig_opts = swig_args,
               language = 'c++',)

def simpleExt(name, path = './'):
return Extension('_%s' % name, ['%s%s.cpp' % (path, name), '%s
%s_wrap.cpp' % (path, name)], **extopts)

setup(ext_modules = [simpleExt('stupid')])

Robin · November 14, 2011, 5:32pm

Hello,

I am new on wxPython. I plan to write a pretty complex extension... To
start (for training), I am just trying to write a very simple
extension. I bumped into a very "simple" problem.
My main problem is that I want to use the class wxPoint in C++ and I
want it to be automatically wrapped into the wx.Point class of
wxPython.
(I am not using here any display yet! I am feeling I am missing
something really basic here!)
After I run (see the files below)

python setup.py build_ext --inplace

(everything seems to go fine, the 'stupid' module is built and imports
correctly after 'wx' is imported and the stupid.Simple class is known)
However, in python, the C++ wxPoint class IS NOT converted into the
wx.Point class

What are you getting instead?

Am I missing something ?

Are you using the patched swig 1.3.29 from here?

http://wxpython.kosoftworks.com/tools/

When the compiler runs is this on the command line?

-DSWIG_TYPE_TABLE=_wxPython_table

···

On 11/13/11 2:28 PM, Emmanuel Bacry wrote:

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · November 14, 2011, 7:11pm

Are you using the patched swig 1.3.29 from here?

http://wxpython.kosoftworks.com/tools/

When the compiler runs is this on the command line?

-DSWIG_TYPE_TABLE=_wxPython_table

Using these two points ..... and it is working !!!
Thank you very much

Emmanuel

Emmanuel_Bacry · November 15, 2011, 9:04pm

So now I encounter a new problem. It has to do with the use of SWIG....
I post the message here because I think this is something that had been done for writing wxPython (if I'm wrong then just say so .... and I'll post this message somewhere else)

The C++ library I want to wrap has the following class structure

class SimpleObject
{
// .....
};

class DerivedObject : public SimpleObject
{
// .....
};

class ObjectList
{
SimpleObject *list[100]; // So here I have an array of 100 pointers to SimpleObject's and a method
void AddObjectToList(SimpleObject *obj); // And a method to a SimpleObject to this list
};

OK. I basically succeeded in encapsulating everything with SWIG
Let's say I could define a new C++ class of derived from SimpleObject :

class DerivedObject1 : public SimpleObject
{
// .....
};

I can encapsulate it the same way I did for DerivedObject and a pointer to an instance of that class will be able to be added to an ObjectList instance

NOW : I would like to be able to define in the interpreter language (let's say it is Python) a new class inheriting of SimpleObjectList

class DerivedPythonObject(SimpleObject):
# ..... blabla

The problem comes when I want to be able (in Python) to add an instance of this object to an ObjectList instance.

It looks like wxPython is more or less doing that for making both the classes hierarchy of the classes in C++ and in Python ?

Thank you

Emmanuel

···

Le 14 nov. 2011 à 18:32, Robin Dunn a écrit :

On 11/13/11 2:28 PM, Emmanuel Bacry wrote:

Hello,

I am new on wxPython. I plan to write a pretty complex extension... To
start (for training), I am just trying to write a very simple
extension. I bumped into a very "simple" problem.
My main problem is that I want to use the class wxPoint in C++ and I
want it to be automatically wrapped into the wx.Point class of
wxPython.
(I am not using here any display yet! I am feeling I am missing
something really basic here!)
After I run (see the files below)

      python setup.py build_ext --inplace

(everything seems to go fine, the 'stupid' module is built and imports
correctly after 'wx' is imported and the stupid.Simple class is known)
However, in python, the C++ wxPoint class IS NOT converted into the
wx.Point class

What are you getting instead?

Am I missing something ?

Are you using the patched swig 1.3.29 from here?

  http://wxpython.kosoftworks.com/tools/

When the compiler runs is this on the command line?

  -DSWIG_TYPE_TABLE=_wxPython_table

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Robin · November 15, 2011, 9:44pm

And the problem is... what? Do you get any error messages or exceptions?

···

On 11/15/11 1:04 PM, Emmanuel Bacry wrote:

So now I encounter a new problem. It has to do with the use of SWIG....
I post the message here because I think this is something that had been done for writing wxPython (if I'm wrong then just say so .... and I'll post this message somewhere else)

The C++ library I want to wrap has the following class structure

class SimpleObject
{
    // .....
};

class DerivedObject : public SimpleObject
{
    // .....
};

class ObjectList
{
    SimpleObject *list[100]; // So here I have an array of 100 pointers to SimpleObject's and a method
    void AddObjectToList(SimpleObject *obj); // And a method to a SimpleObject to this list
};

OK. I basically succeeded in encapsulating everything with SWIG
Let's say I could define a new C++ class of derived from SimpleObject :

class DerivedObject1 : public SimpleObject
{
    // .....
};

I can encapsulate it the same way I did for DerivedObject and a pointer to an instance of that class will be able to be added to an ObjectList instance

NOW : I would like to be able to define in the interpreter language (let's say it is Python) a new class inheriting of SimpleObjectList

class DerivedPythonObject(SimpleObject):
      # ..... blabla

The problem comes when I want to be able (in Python) to add an instance of this object to an ObjectList instance.

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · November 16, 2011, 5:15am

So now I encounter a new problem. It has to do with the use of SWIG....
I post the message here because I think this is something that had been done for writing wxPython (if I'm wrong then just say so .... and I'll post this message somewhere else)

The C++ library I want to wrap has the following class structure

class SimpleObject
{
   // .....
};

class DerivedObject : public SimpleObject
{
   // .....
};

class ObjectList
{
   SimpleObject *list[100]; // So here I have an array of 100 pointers to SimpleObject's and a method
   void AddObjectToList(SimpleObject *obj); // And a method to a SimpleObject to this list
};

OK. I basically succeeded in encapsulating everything with SWIG
Let's say I could define a new C++ class of derived from SimpleObject :

class DerivedObject1 : public SimpleObject
{
   // .....
};

I can encapsulate it the same way I did for DerivedObject and a pointer to an instance of that class will be able to be added to an ObjectList instance

NOW : I would like to be able to define in the interpreter language (let's say it is Python) a new class inheriting of SimpleObjectList

class DerivedPythonObject(SimpleObject):
     # ..... blabla

The problem comes when I want to be able (in Python) to add an instance of this object to an ObjectList instance.

And the problem is... what? Do you get any error messages or exceptions?

Sorry!
No, there is no problem to add an instance of this object to the objectList. However, if I use standard swig encapsulations, I loose all he information (fields, virtual functions) at the level of DerivedPythonObject, and basically keep only the information (fields,...) at the level of of DerivedObject1.

If I am not clear, here is a full (short) example :(I hope it is clear!)

## testclass.h
class A
{
  public :
  int a;
  A(int a1) {a = a1;}
  virtual int Bingo() {return a;}
};
class B : public A
{
  public :
  B() : A(0) {}
  virtual int Bingo() {return 48;}
};
class AList
{
  public:
  int n;
  A* array[10];
  AList() {n = 0;}
  void Add(A* elem) {
    array[n] = elem;
    n++;
  }
  void Print() {
    for (int i = 0;i<n;i++) {
      printf ("%d : %d\n",i,array[i]->Bingo());
    }
  }
};

## testclass.cpp
is empty

## testclass.i
%module testclass

%{
#include "testclass.h"
%}

class A
{
  public :
  int a;
  A(int a1);
  virtual int Bingo();
};
class B : public A
{
  public :
  B();
  virtual int Bingo();
};

class AList
{
public:
  int n;
  A* array[10];
  AList();
  void Add(A* elem);
  void Print();
};

## Now in python, if I do
from testclass import *

class C(B):
    def __init__(self):
        B.__init__(self)
    def Bingo(self):
        print 25

u = AList()
c = C()
b = B()
a = A(12)
u.Add(a)
u.Add(b)
u.Add(c)

u.Print()

12
48
48

# So the last element prints as 48
# However
c.Bingo()

···

On 11/15/11 1:04 PM, Emmanuel Bacry wrote:

25

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Robin · November 16, 2011, 7:07pm

You need to use SWIG's directors feature to be able to reflect C++ virtual method calls to the overridden methods that are in the Python class. I don't have a whole lot of experience with it (wxPython uses a home-grown scheme that does something similar because I was doing it before directors was added to SWIG, and the first few iterations of the feature was not that good) but it should work okay for you. Read up on directors in the SWIG docs.

···

On 11/15/11 9:15 PM, Emmanuel Bacry wrote:

On 11/15/11 1:04 PM, Emmanuel Bacry wrote:

So now I encounter a new problem. It has to do with the use of SWIG....
I post the message here because I think this is something that had been done for writing wxPython (if I'm wrong then just say so .... and I'll post this message somewhere else)

The C++ library I want to wrap has the following class structure

class SimpleObject
{
    // .....
};

class DerivedObject : public SimpleObject
{
    // .....
};

class ObjectList
{
    SimpleObject *list[100]; // So here I have an array of 100 pointers to SimpleObject's and a method
    void AddObjectToList(SimpleObject *obj); // And a method to a SimpleObject to this list
};

OK. I basically succeeded in encapsulating everything with SWIG
Let's say I could define a new C++ class of derived from SimpleObject :

class DerivedObject1 : public SimpleObject
{
    // .....
};

I can encapsulate it the same way I did for DerivedObject and a pointer to an instance of that class will be able to be added to an ObjectList instance

NOW : I would like to be able to define in the interpreter language (let's say it is Python) a new class inheriting of SimpleObjectList

class DerivedPythonObject(SimpleObject):
      # ..... blabla

The problem comes when I want to be able (in Python) to add an instance of this object to an ObjectList instance.

And the problem is... what? Do you get any error messages or exceptions?

Sorry!
No, there is no problem to add an instance of this object to the objectList. However, if I use standard swig encapsulations, I loose all he information (fields, virtual functions) at the level of DerivedPythonObject, and basically keep only the information (fields,...) at the level of of DerivedObject1.

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · November 17, 2011, 6:25am

Thank you

Emmanuel

···

Le 16 nov. 2011 à 20:07, Robin Dunn a écrit :

On 11/15/11 9:15 PM, Emmanuel Bacry wrote:

On 11/15/11 1:04 PM, Emmanuel Bacry wrote:

So now I encounter a new problem. It has to do with the use of SWIG....
I post the message here because I think this is something that had been done for writing wxPython (if I'm wrong then just say so .... and I'll post this message somewhere else)

The C++ library I want to wrap has the following class structure

class SimpleObject
{
   // .....
};

class DerivedObject : public SimpleObject
{
   // .....
};

class ObjectList
{
   SimpleObject *list[100]; // So here I have an array of 100 pointers to SimpleObject's and a method
   void AddObjectToList(SimpleObject *obj); // And a method to a SimpleObject to this list
};

OK. I basically succeeded in encapsulating everything with SWIG
Let's say I could define a new C++ class of derived from SimpleObject :

class DerivedObject1 : public SimpleObject
{
   // .....
};

I can encapsulate it the same way I did for DerivedObject and a pointer to an instance of that class will be able to be added to an ObjectList instance

NOW : I would like to be able to define in the interpreter language (let's say it is Python) a new class inheriting of SimpleObjectList

class DerivedPythonObject(SimpleObject):
     # ..... blabla

The problem comes when I want to be able (in Python) to add an instance of this object to an ObjectList instance.

And the problem is... what? Do you get any error messages or exceptions?

Sorry!
No, there is no problem to add an instance of this object to the objectList. However, if I use standard swig encapsulations, I loose all he information (fields, virtual functions) at the level of DerivedPythonObject, and basically keep only the information (fields,...) at the level of of DerivedObject1.

You need to use SWIG's directors feature to be able to reflect C++ virtual method calls to the overridden methods that are in the Python class. I don't have a whole lot of experience with it (wxPython uses a home-grown scheme that does something similar because I was doing it before directors was added to SWIG, and the first few iterations of the feature was not that good) but it should work okay for you. Read up on directors in the SWIG docs.

Emmanuel_Bacry · December 25, 2011, 2:59pm

Hello,

Ok, I have spent a lot of time now both learning how to extend wxpython in C++ and uing swig (and the director feature).
It looks like that enabling the director feature while extending wxpython leads to a segmentation fault.

For instance, if I write a code independent from wx, that compiles/runs fine with directors.

Now, if in the main .i file I just include the following lines

%{
#include "wx/wxPython/wxPython.h"
#include "wx/wxPython/pyclasses.h"
%}

%include typemaps.i
%include my_typemaps.i

%import core.i
%import windows.i

as I would if I was writing a wxpyhon extension then I get a segmentation fault...

Searching the web, I found that somebody had the same kind of problem few years ago

http://permalink.gmane.org/gmane.comp.programming.swig/8428

but I can't see if it was solved.

Could anybody help me ?

Thank you

Emmanuel

···

Le 16 nov. 2011 à 20:07, Robin Dunn a écrit :

On 11/15/11 9:15 PM, Emmanuel Bacry wrote:

On 11/15/11 1:04 PM, Emmanuel Bacry wrote:

So now I encounter a new problem. It has to do with the use of SWIG....
I post the message here because I think this is something that had been done for writing wxPython (if I'm wrong then just say so .... and I'll post this message somewhere else)

The C++ library I want to wrap has the following class structure

class SimpleObject
{
  // .....
};

class DerivedObject : public SimpleObject
{
  // .....
};

class ObjectList
{
  SimpleObject *list[100]; // So here I have an array of 100 pointers to SimpleObject's and a method
  void AddObjectToList(SimpleObject *obj); // And a method to a SimpleObject to this list
};

OK. I basically succeeded in encapsulating everything with SWIG
Let's say I could define a new C++ class of derived from SimpleObject :

class DerivedObject1 : public SimpleObject
{
  // .....
};

I can encapsulate it the same way I did for DerivedObject and a pointer to an instance of that class will be able to be added to an ObjectList instance

NOW : I would like to be able to define in the interpreter language (let's say it is Python) a new class inheriting of SimpleObjectList

class DerivedPythonObject(SimpleObject):
    # ..... blabla

The problem comes when I want to be able (in Python) to add an instance of this object to an ObjectList instance.

And the problem is... what? Do you get any error messages or exceptions?

Sorry!
No, there is no problem to add an instance of this object to the objectList. However, if I use standard swig encapsulations, I loose all he information (fields, virtual functions) at the level of DerivedPythonObject, and basically keep only the information (fields,...) at the level of of DerivedObject1.

You need to use SWIG's directors feature to be able to reflect C++ virtual method calls to the overridden methods that are in the Python class. I don't have a whole lot of experience with it (wxPython uses a home-grown scheme that does something similar because I was doing it before directors was added to SWIG, and the first few iterations of the feature was not that good) but it should work okay for you. Read up on directors in the SWIG docs.

Thank you

Emmanuel

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Robin · December 26, 2011, 6:48pm

Have you tried running in a debugger so you can see where the crash is and perhaps what is causing it?

···

On 12/25/11 6:59 AM, Emmanuel Bacry wrote:

Hello,

Ok, I have spent a lot of time now both learning how to extend wxpython in C++ and uing swig (and the director feature).
It looks like that enabling the director feature while extending wxpython leads to a segmentation fault.

For instance, if I write a code independent from wx, that compiles/runs fine with directors.

Now, if in the main .i file I just include the following lines

%{
#include "wx/wxPython/wxPython.h"
#include "wx/wxPython/pyclasses.h"
%}

%include typemaps.i
%include my_typemaps.i

%import core.i
%import windows.i

as I would if I was writing a wxpyhon extension then I get a segmentation fault...

Searching the web, I found that somebody had the same kind of problem few years ago

http://permalink.gmane.org/gmane.comp.programming.swig/8428

but I can't see if it was solved.

Could anybody help me ?

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · December 29, 2011, 2:25pm

Ok, I understand a little more what is going on.

The bug appears even if, properly speaking, I am not extending wxPython.
And it happens as soon as (and only if) a virtual method of a director class is called within an event call back. If it is used any where else then everything is just working fine.

Let's be more precise

···

On 12/25/11 6:59 AM, Emmanuel Bacry wrote:

Hello,

Ok, I have spent a lot of time now both learning how to extend wxpython in C++ and uing swig (and the director feature).
It looks like that enabling the director feature while extending wxpython leads to a segmentation fault.

For instance, if I write a code independent from wx, that compiles/runs fine with directors.

Now, if in the main .i file I just include the following lines

%{
#include "wx/wxPython/wxPython.h"
#include "wx/wxPython/pyclasses.h"
%}

%include typemaps.i
%include my_typemaps.i

%import core.i
%import windows.i

as I would if I was writing a wxpyhon extension then I get a segmentation fault...

Searching the web, I found that somebody had the same kind of problem few years ago

http://permalink.gmane.org/gmane.comp.programming.swig/8428

but I can't see if it was solved.

Could anybody help me ?

Have you tried running in a debugger so you can see where the crash is and perhaps what is causing it?

#####

Let's say I write a C++ library with some classes using virtual methods. However, none of these classes are related to wxWidgets.
I encapsulate them using Swig and the %feature{director} on all the classes. I create a module named MyModule.
(so I don't include any of the .i or .h wxPython files)

For instance let's say (this is C++)

class MyObject
{
public :
virtual void Method() {.....}
};

Now, I write a new wxWindow class in wxPython. This widget is using a pointer to an instance object of the class MyObject and particularly the Method.
Let's say (this is python)

class MyWindow(wx.Window):
   def __init__(self,frame,object): # Here object is of type MyModule.MyObject
       wx.Window.__init__(self,frame,wx.ID_ANY)
       self.object = object
   # Some methods of this class will use
   # self.object->Method()

#############
As is, it works fine... as long as the object used to create the MyWindow is an instance of MyModule.MyObject
So, for instance

win = MyWindow(frame,MyModule.MyObject())

This widget works just fine.

#############
Now, if I define a subclass of MyObject in python (using the director feature)

class DerivedMyObject(MyModule.MyObject) :
def Method(self):
.... # Here I overload the virtual Method

The following widget does not work

win = MyWindow(frame, DerivedMyObject())

To be more precise :

1- Of course I checked that both classes DerivedMyObject and MyModule.MyObject are 100% working as expected (with the director feature)
2- When I make the call
self.object->Method()
in the __init__ method of MyWindow everything works fine even if the self.object is an instance of DerivedMyObject and not of MyModule. MyObject

THE FOLLOWING IS THE MOST IMPORTANT PART :

3- The segmentation fault happens "only" when the virtual method MyMethod is called from within an event call back.
Otherwise everything is working fine !!
It happens exactly when the call to the virtual method is made.

If somebody could help me I would be very grateful !

Emmanuel

Now, let's say
as long as the code is not REALLY using the director feature, i.e., as long as I am using an object whose class is really defined in C++.
If I am using an object whose class

If, in python, I define a subclass of a class

WHENEVER a vir

Let's say I have defined a new class
Whenever a

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Robin · December 29, 2011, 6:39pm

Does this mean that it happens when the C++ call is made to the C++ implementation of the virtual method created by SWIG/directors? Or is it when the Python implementation in the derived class is called?

If the former then I would double-check that the pointer to the C++ object (or the this pointer if inside some other method) is still what it was when the object was created.

If the latter then then one thing to check is what is going on with the GIL. Most of the wxPython wrappers will release the GIL before calling the C++ function/method and then reacquire it again before returning to Python, and the callbacks made to event handlers or overridden virtuals (where supported) will acquire the GIL first and release it before returning to the calling code. The code produced by the directors feature will need to do something similar when it is making calls to the virtual methods overridden in Python classes. Since I've not used the feature I can't tell you how to do so, but look for any options they give you for wrapping the generated C++ code in the reflector functions with bits of your own code. I (ab)used %exception for the Python-->C++ wrappers, there may be something similar for the directors code.

···

On 12/29/11 6:25 AM, Emmanuel Bacry wrote:

THE FOLLOWING IS THE MOST IMPORTANT PART :

3- The segmentation fault happens "only" when the virtual method MyMethod is called from within an event call back.
Otherwise everything is working fine !!
It happens exactly when the call to the virtual method is made.

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · December 29, 2011, 7:00pm

Ok, thank you for your answer.... I'll let you know.

By the way (for something else), is it safe to

1- Create a wxWindow using wxPython
2- Pass it to a C++ code
3- In C++ use the FindWindowById static method in order to find a C pointer to the wxWindow *
4- Do some stuff on this window using this pointer in C++

?

Emmanuel

pass from wxPython a wxWindow.Id to a C++ code and get the

···

On 12/29/11 6:25 AM, Emmanuel Bacry wrote:

THE FOLLOWING IS THE MOST IMPORTANT PART :

3- The segmentation fault happens "only" when the virtual method MyMethod is called from within an event call back.
Otherwise everything is working fine !!
It happens exactly when the call to the virtual method is made.

Does this mean that it happens when the C++ call is made to the C++ implementation of the virtual method created by SWIG/directors? Or is it when the Python implementation in the derived class is called?

If the former then I would double-check that the pointer to the C++ object (or the this pointer if inside some other method) is still what it was when the object was created.

If the latter then then one thing to check is what is going on with the GIL. Most of the wxPython wrappers will release the GIL before calling the C++ function/method and then reacquire it again before returning to Python, and the callbacks made to event handlers or overridden virtuals (where supported) will acquire the GIL first and release it before returning to the calling code. The code produced by the directors feature will need to do something similar when it is making calls to the virtual methods overridden in Python classes. Since I've not used the feature I can't tell you how to do so, but look for any options they give you for wrapping the generated C++ code in the reflector functions with bits of your own code. I (ab)used %exception for the Python-->C++ wrappers, there may be something similar for the directors code.

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Robin · December 29, 2011, 8:02pm

Yes, I think that should be okay. You should also be able to get the pointer directly from the PyObject using wxPyConvertSwigPtr and not have to do FindWindowById.

···

On 12/29/11 11:00 AM, Emmanuel Bacry wrote:

Ok, thank you for your answer.... I'll let you know.

By the way (for something else), is it safe to

1- Create a wxWindow using wxPython
2- Pass it to a C++ code
3- In C++ use the FindWindowById static method in order to find a C pointer to the wxWindow *
4- Do some stuff on this window using this pointer in C++

?

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · January 1, 2012, 2:33pm

The latter clearly applies for me.
However I still don't quite understand.

Here is what my code doing :

1- in wxPython : defining a new class of wxWindow. Each time such a wxXindow is created I pass its id to a C++ function that connects some C++ call back to this id for some events

2- Some of the C++ call backs are sometimes using some virtual methods of some C++ objects. These virtual methods can be Python implementation of a derived class using SWIG/directors.

Now,

- whenever the call to the virtual method is made, if it corresponds to a Python implementation using a derived class I get a segmentation fault (otherwise everything is going well)

- It looks like the problem comes from the fact that the use of the director class is made within a wxWidget call back.

Here are some questions :

- When the C++ call backs are called, is the GIL released ?
- If it is the case then, if I understand correctly your last answer, I should be sure that the GIL is acquired before calling any director's class method ?
- But then I would be surprised that SWIG does not do exactly that ?
- If it leads to a segmentation fault, do I have to understand it clearly does not ? In which case what is the best way to do it ?
- I found a discussion you had on the internet a few years ago about this problem. On of the "solution" was to use
  wxPyBlock_t blocked = wxPyBeginBlockThreads();
  call the director's methods
  wxPyEndBlockThreads(blocked);
But if I do that within my C++ call back it core dumps right away ....

Emmanuel

···

On 12/29/11 6:25 AM, Emmanuel Bacry wrote:

THE FOLLOWING IS THE MOST IMPORTANT PART :

3- The segmentation fault happens "only" when the virtual method MyMethod is called from within an event call back.
Otherwise everything is working fine !!
It happens exactly when the call to the virtual method is made.

Does this mean that it happens when the C++ call is made to the C++ implementation of the virtual method created by SWIG/directors? Or is it when the Python implementation in the derived class is called?

If the former then I would double-check that the pointer to the C++ object (or the this pointer if inside some other method) is still what it was when the object was created.

If the latter then then one thing to check is what is going on with the GIL. Most of the wxPython wrappers will release the GIL before calling the C++ function/method and then reacquire it again before returning to Python, and the callbacks made to event handlers or overridden virtuals (where supported) will acquire the GIL first and release it before returning to the calling code. The code produced by the directors feature will need to do something similar when it is making calls to the virtual methods overridden in Python classes. Since I've not used the feature I can't tell you how to do so, but look for any options they give you for wrapping the generated C++ code in the reflector functions with bits of your own code. I (ab)used %exception for the Python-->C++ wrappers, there may be something similar for the directors code.

Emmanuel_Bacry · January 1, 2012, 4:30pm

Yes !

It looks like I found a solution :

Each C++ callback starts with

PyGILState_STATE gstate;
gstate = PyGILState_Ensure();

and ends with

PyGILState_Release(gstate);

......

It does not segmentation fault any more...
Of course, from what I understand it forbids running threads in my call backs... but I don't really care.

Does it look safe to you ?

Any way thank you very much for all your help

Emmanuel

···

Le 1 janv. 2012 à 15:33, Emmanuel Bacry a écrit :

On 12/29/11 6:25 AM, Emmanuel Bacry wrote:

THE FOLLOWING IS THE MOST IMPORTANT PART :

3- The segmentation fault happens "only" when the virtual method MyMethod is called from within an event call back.
Otherwise everything is working fine !!
It happens exactly when the call to the virtual method is made.

Does this mean that it happens when the C++ call is made to the C++ implementation of the virtual method created by SWIG/directors? Or is it when the Python implementation in the derived class is called?

If the former then I would double-check that the pointer to the C++ object (or the this pointer if inside some other method) is still what it was when the object was created.

If the latter then then one thing to check is what is going on with the GIL. Most of the wxPython wrappers will release the GIL before calling the C++ function/method and then reacquire it again before returning to Python, and the callbacks made to event handlers or overridden virtuals (where supported) will acquire the GIL first and release it before returning to the calling code. The code produced by the directors feature will need to do something similar when it is making calls to the virtual methods overridden in Python classes. Since I've not used the feature I can't tell you how to do so, but look for any options they give you for wrapping the generated C++ code in the reflector functions with bits of your own code. I (ab)used %exception for the Python-->C++ wrappers, there may be something similar for the directors code.

The latter clearly applies for me.
However I still don't quite understand.

Here is what my code doing :

1- in wxPython : defining a new class of wxWindow. Each time such a wxXindow is created I pass its id to a C++ function that connects some C++ call back to this id for some events

2- Some of the C++ call backs are sometimes using some virtual methods of some C++ objects. These virtual methods can be Python implementation of a derived class using SWIG/directors.

Now,

- whenever the call to the virtual method is made, if it corresponds to a Python implementation using a derived class I get a segmentation fault (otherwise everything is going well)

- It looks like the problem comes from the fact that the use of the director class is made within a wxWidget call back.

Here are some questions :

- When the C++ call backs are called, is the GIL released ?
- If it is the case then, if I understand correctly your last answer, I should be sure that the GIL is acquired before calling any director's class method ?
- But then I would be surprised that SWIG does not do exactly that ?
- If it leads to a segmentation fault, do I have to understand it clearly does not ? In which case what is the best way to do it ?
- I found a discussion you had on the internet a few years ago about this problem. On of the "solution" was to use
  wxPyBlock_t blocked = wxPyBeginBlockThreads();
  call the director's methods
  wxPyEndBlockThreads(blocked);
But if I do that within my C++ call back it core dumps right away ....

Emmanuel

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Robin · January 2, 2012, 8:57pm

Yes !

It looks like I found a solution :

Each C++ callback starts with

PyGILState_STATE gstate;
gstate = PyGILState_Ensure();

and ends with

PyGILState_Release(gstate);

......

It does not segmentation fault any more...
Of course, from what I understand it forbids running threads in my call backs... but I don't really care.

Only while running in the Python part of your callbacks. If they subsequently call out to C++ code (adding another layer to the sandwich) then the GIL may be released and reacquired again in that C++ code and other Python threads could be run at that time. This should be the same as any other transition to/from C++/wxPython code too.

Does it look safe to you ?

Yes.

···

On 1/1/12 8:30 AM, Emmanuel Bacry wrote:

--
Robin Dunn
Software Craftsman

Emmanuel_Bacry · January 11, 2012, 1:02pm

Hello,

Here is the architecture of my soft :

- I have a wxpython (main) program which creates some wxWindows objects.

- I create some wxWindows callbacks for these objects directly in C++ (using the Bind method in C++ and the wxWindows id's)

- These callbacks, some times, make some call in Python using the C-API.

All this works just fine !

The "only" problem I get, is that when I use (within the callbacks) PyErr_.... functions, for instance

PyErr_SetString("There is an error"); \\ Generate an error
PyErr_Print()); \\ prints it

I am very surprised because I just don't understand what error stream it uses. It is NOT using the python stream sys.stderr (as my soft in wxPython does)

why is that so ?

Emmanuel

Tim_Roberts · January 11, 2012, 6:07pm

Emmanuel Bacry wrote:

The "only" problem I get, is that when I use (within the callbacks) PyErr_.... functions, for instance

PyErr_SetString("There is an error"); \\ Generate an error
PyErr_Print()); \\ prints it

I am very surprised because I just don't understand what error stream it uses. It is NOT using the python stream sys.stderr (as my soft in wxPython does)

PyErr_Print imports sys and writes to sys.stderr. What leads you to
believe that's not happening?

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Emmanuel_Bacry · January 11, 2012, 7:57pm

Emmanuel Bacry wrote:

The "only" problem I get, is that when I use (within the callbacks) PyErr_.... functions, for instance

PyErr_SetString("There is an error"); \\ Generate an error
PyErr_Print()); \\ prints it

I am very surprised because I just don't understand what error stream it uses. It is NOT using the python stream sys.stderr (as my soft in wxPython does)

PyErr_Print imports sys and writes to sys.stderr. What leads you to
believe that's not happening?

I am using the qtconsole of ipython with the wx loop. I don't know if you are familiar with that, but it lets you control the ipython kernel (within a wx loop) from a console.
The connection between the console and the kernel is made using TCP using the library zmq.
It works VERY well.

So the sys.stderr is set to a TCP client that I can see in the qtconsole

Now, within the C AND within an event callback execution of wxwidgets, I can check that the object sys.stderr is still the same.
Moreover if I do PyRun_SimpleString("print >> sys.stderr 'kjkj'") it works fine, it prints in the qt console
but when I do a PyErr_Print() call it prints the message on the standard stderr (i.e., in the unix terminal)

Let me point out that this seems to happen ONLY when these calls are made within a wx call back (not if I make a "direct" call from the qtconsole)

?

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en