Re: [C++-sig] gtkglext & mesa = __cxa_allocate_exception
On 09/14/10 21:18, Leonard Ritter wrote: On Tue, Sep 14, 2010 at 9:12 PM, Leonard Ritter wrote: it seems that when gtk.glext is imported in python, and a boost python module hits a StopIteration exception (as it is usual for generators), the exception is not caught and the app segfaults. that is, unless OpenGL.GL is imported before gtk.glext - in this case, no segfaults; it's the translation of a sites suggestion to use "env LD_PRELOAD=libGL.so python script.py", which is essentially the same thing. i wonder what kind of voodoo is at work here :) Last time I run into this kind of problem it was because python was using different memory allocator than the library I was importing (that is: the library was linked against our slightly modified tcmalloc) ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Advice sought on making a large C++ application a Python extension
Hi Ben Thanks very much for your reply. Sorry that my response has been slow but I have been trying to digest yours. I have also taken a detour to investigate CMake. >As to how to make your functionality available with a Python >extension - I'm not sure exactly what kind of app you have, >but is it possible to make the Python portion only an >interface to the underlying C++ code? That's basically what >we did with our application - write a wrapper layer on top >of the ordinary C++ API that implemented a Python API. This >also allowed us to build the C++ application, and then with >an additional build step (in GNU make) we were able to >compile the python interface layer. I'm sorry to say that I don't really understand the concept of making the Python portion only an interface to the underlying C++ code. Please could you explain what that means? Best regards David ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Advice sought on making a large C++ application a Python extension
Does pybindgen interoperate with numpy? That would be required for me to use it. Ben Fitzpatrick wrote: > David, > > I'm still a newbie on this list myself, but I will tell you that for the > larger project which we were attempting to wrap, we had excellent luck > with Gustavo Carniero's Pybindgen project. We found it to be much simpler > to work with than boost.python and py++, and also it compiled much faster. > > As to how to make your functionality available with a Python extension - > I'm not sure exactly what kind of app you have, but is it possible to make > the Python portion only an interface to the underlying C++ code? That's > basically what we did with our application - write a wrapper layer on top > of the ordinary C++ API that implemented a Python API. This also allowed > us to build the C++ application, and then with an additional build step > (in GNU make) we were able to compile the python interface layer. > > It may be that you need to make all of your classes into python > extensions, in which case py++ and boost.python may be the better tool, I > am not certain, but for writing just an interface layer, our experience > was that Pybindgen was easier. > > Hope this helps! > > -Ben > > -Original Message- > From: cplusplus-sig-bounces+bfitzpatrick=vtiinstruments@python.org > [mailto:cplusplus-sig-bounces+bfitzpatrick=vtiinstruments@python.org] > On Behalf Of David Aldrich Sent: Monday, September 06, 2010 11:16 AM To: > Development of Python/C++ integration Subject: [C++-sig] Advice sought on > making a large C++ application a Python extension > > Hi > > We have a large C++ application that we develop in-house. It consists of a > large number of source files, some of which are linked directly and some > of which are first built as static libraries. > > It has been suggested that we make the application's functionality > available as a Python extension. Simplistically speaking, we could then > let users replace our C++ main() by a Python script. > > I have only looked at the boost.python tutorial that demonstrates a 'Hello > world' Python extension. For our project we would be dealing with > something very much bigger, with many classes, singleton classes and > (possibly) global data. My question is, would it be practical to make all > of those entities Python extensions? > > We would also want to continue to support the application as a wholly C++ > application. Currently, we use gnu make to build it. Would I have to > add a parallel build system using bjam to build the extensions? And then > maintain both make's makefiles and bjam's Jamroot files? > > Can .pyd files be loaded by the C++ linker? > > Any advice would be gratefully received. > > Best regards > > David > > = > David Aldrich, NEC Telecom MODUS, Ltd, > Cleeve Road, Leatherhead, Surrey, KT22 7SA, UK > Direct tel. +44 (0) 1372 381857 > = > > ___ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Advice sought on making a large C++ application a Python extension
>I'm sorry to say that I don't really understand the concept of making the >Python portion only an interface to the >underlying C++ code. Please could you >explain what that means? David, Sorry, I must not have communicated this well. I'll try again. It depends on how your code works, but the idea is, we generate a shared library with some (large) number of entry points. This is our API, basically. We allow users to program against our API, but there's a ton of other code within the shared library that they don't see, or don't get access to. So, we still generate the C++ shared library, but in addition we generate a layer using Pybindgen that sits on top of the API and exposes it via Python. We didn't have to wrap all the internal function calls in the shared library in Python - that would have been too much work. Instead we built a wrapper around our shared library that implements all the same calls our shared library's API implements, and when they are accessed just makes a call via pybindgen into the existing C++ shared library. Inside the library, we don't care what happens - C++ functions can call other C++ functions, etc - and eventually a result comes back to the python wrapper layer, is translated from C++, and is returned to Python. For something that's more of a program instead of a library, I imagine you could do something similar - instead of wrapping all of your modules or functions, replace the main() function of your program with a python version - and only bother generating a wrapper for the functions called directly from main. I haven't tried the main-replacement bit, but I can verify that for the shared library, it works just fine. -Ben ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
